[TUHS] NSA MILNET IMP 57 & Explosive Bolts

Fri Jan 4 12:54:58 AEST 2019

415-327-5220


On 1/3/2019 9:34 PM, Don Hopkins wrote:
> (I originally posted this to hacker news, but I’ll repost it here too.)
>
>
>
> At the University of Maryland, our network access was through the NSA's "secret" MILNET IMP 57 at Fort Mead. It was pretty obvious that UMD got their network access via NSA, because mimsy.umd.edu had a similar "*.57" IP address as dockmaster, tycho and coins.
>
> https://emaillab.jp/dns/hosts/
>
>      HOST : 26.0.0.57 : TYCHO : PDP-11/70 : UNIX : TCP/TELNET,TCP/SMTP,TCP/FTP :
>      HOST : 26.0.0.57 : DOCKMASTER.NCSC.MIL,DOCKMASTER.DCA.MIL, DOCKMASTER.ARPA : HONEYWELL-DPS-8/70 : MULTICS : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/ECHO,TCP/DISCARD,ICMP :
>      HOST : 26.1.0.57 : COINS-GATEWAY,COINS : PLURIBUS : PLI ::
>      HOST : 26.2.0.57, 128.8.0.8 : MARYLAND,MIMSY,UMD-CSD,UMD8,UMCP-CS : VAX-11/780 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,UDP,TCP/ECHO,TCP/FINGER,ICMP :
>
> https://multicians.org/site-dockmaster.html
>
> Whenever the network went down (which was often), we had to call up a machine room at Fort Mead and ask them to please press the reset button on the box labeled "IMP 57". Sometimes the helpful person who answered the phone had no idea which box I meant, so I had describe to him which box to reset over the phone. ("Nope, that didn't work. Try the other one!" ;) They were even generous enough to issue us (CS department systems staff and undergrad students) our own MILNET TACACS card.
>
> On mimsy, you could get a list of NSA employees by typing "grep contact /etc/passwd", because each of their courtesy accounts had "network contact" in the gecos field.
>
> Before they rolled out TACACS cards, anyone could dial up an IMP and log in without a password, and connect to any host they wanted to, without even having to murder anyone like on TV:
>
> https://www.youtube.com/watch?v=hVth6T3gMa0
>
>
>
> I found this handy how-to tutorial guide for "Talking to the Milnet NOC" and resetting the LH/DH, which was useful for guiding the NSA employee on the other end of the phone through fixing their end of the problem. What it doesn't mention is that the key box with the chase key was extremely easy to pick with a paperclip.
>
> Who would answer the Milnet NOC's 24-hour phone was hit or miss: Some were more helpful and knowledgeable than others, others were quite uptight.
>
> Once I told the guy who answered, "Hi, this is the University of Maryland. Our connection to the NSA IMP seems to be down." He barked back: "You can't say that on the telephone! Are you calling on a blue phone?" (I can't remember the exact color, except that it wasn't red: that I would have remembered). I said, "You can't say NSA??! This is a green phone, but there's a black phone in the other room that I could call you back on, but then I couldn't see the hardware." And he said "No, I mean a voice secure line!" I replied, "You do know that this is a university, don't you? We only have black and green phones.”
>
>      Date: Thu, 11 Sep 86 13:53:45 EDT
>      From: Steve D. Miller <steve at brillig.umd.edu>
>      To: staff at mimsy.umd.edu
>      Subject: Talking to the Milnet NOC
>
>         This message is intended to be a brief tutorial/compendium of
>      information you probably want to know if you need to see about
>      getting the LH/DH thingy (and us) talking to the world.
>
>         First, you need the following numbers:
>          (1)  Our IMP number (57),
>          (2)  Mimsy's milnet host address (26.2.0.57),
>          (3)  The circuit number for our link to the NSA
>              (DSEP07500-057)
>          (4)  The NOC number itself (692-5726).
>
>         Second, you need to know something about the hardware.  There
>      are three pieces of hardware that make up our side of the link:
>      the LH/DH itself, the ECU, and the modem.  The LH/DH and the
>      ECU are the things in the vax lab by brillig; the ECU is the
>      thing on top (with the switches), and the LH/DH is the thing
>      on the bottom.  The normal state is to have the four red LEDs
>      on the ECU on and the Host Master Ready, HRY, Imp Master Ready,
>      and IRY lights on at the LH/DH.  If these lights are not on,
>      something is wrong.  If mimsy is down, then we'll only have some
>      of the lights on, but that should fix itself when mimsy comes up.
>      Some interesting buttons or switches on the ECU are:
>          reset - resets something or another
>          stop - stops something or another
>          start - restarts something or another
>          local loopback -- two switches and two leds; you may need
>              to throw one or the other of these if the NOC asks
>              you to.  These loopback switches should be distinguished
>              from those on the modem itself.
>          remote loopback -- like local loopback, but does something else.
>
>         The modem is in the phone room beside the terminal room (rm.
>      4322, if memory serves).  It can be opened with the chase key from
>      the key box...but if someone official and outside of staff asks
>      you that, you probably shouldn't admit to it.  It has a switch on
>      it, too; it seems that switch normally rests in the middle, and
>      there's a "LL" setting to the left which I assume puts the modem in
>      local loopback mode.
>
>         Now that you have some idea of where things are, call the NOC.
>      Identify yourself as from the University of Maryland, and say that
>      we're not talking to the outside world.  They will probably ask for
>      our Milnet address or the number of the IMP we're connected to,
>      and will then poke about and see what's happening.  They will ask
>      you to do various things; ask if you're not sure what they mean,
>      but the background info above should help in puzzling it out.
>
>         Hopefully, this will make it easier to find people to fix
>      our net problems in the future; it's still hard to do 'cause
>      we have so little info (no hardware manual, for example),
>      but this should give us a fighting chance.
>
>          -Steve
>
>
>
> There were rumored to be "explosive bolts" on the ARPA/MILNET gateways (whether they were metaphorical or not, I don't know).
>
> Here's something interesting that Milo Medin wrote about dual homed sites like NSA and NASA, that were on both the ARPANET and MILNET:
>
>      To: fair at ucbarpa.berkeley.edu (Erik E. Fair)
>      Cc: Hackers_Guild at ucbvax.berkeley.edu, ucdavis!ccohesh at ucbvax.berkeley.edu
>      Subject: Re: a question of definition
>      Date: Thu, 29 Jan 87 15:33:35 PST
>      From: Milo S. Medin (NASA ARC Code ED) <medin at orion.arpa>
>
>      Right, the core has many gateways on it now, maybe 20-30.  All the LSI's will
>      be stubbed off the core however, and only buttergates will be left after
>      the mailbridges and EGP peers are all converted.  Actually, I think DARPA is
>      paying for it all...
>
>      Ames is *not* getting a mailbridge.  You are right of course, that we could
>      use 2 gateways, not just 1 (actually, there will be a prime and backup anyways),
>      and then push routing info appropriately.  But that's anything but simple.
>      Firstly, the hosts have to know which gateway to send a packet to a given
>      network, and thus have to pick between the 2.  That's a bad idea.
>      It also means that I have to pass all EGP learned info around on the
>      local cable, and if I do that, then I can't have routing info from
>      the local cable pass out via EGP.  At least not without violating
>      the current EGP spec.   Think about it.  It'd be really simple to
>      create a loop that way.  Thus, in order to maximize the use of both
>      PSN's, you really need one gateway wired to both PSN's, and just
>      have it advertise a default route inside.  Or use a reasonble IGP,
>      of which RIP (aka /etc/routed stuff) is not.  I'm hoping to get
>      an RFC out of BBN at this IETF meeting which may go a long way in
>      reducing the use of RIP as an IGP.
>
>      BTW, NSA is an example of a site on both MILNET and ARPANET but without
>      a mailbridge...
>
>      There is no restriction that a network can only be on ARPANET or MILNET.
>      That goes against the Internet model of doing things.  Our local
>      NASA gatewayed nets will be advertised on both sides.  The restriction
>      on BARRNet is that the constituent elements of BARRNet do not all
>      have access to MILNET.  NSF has an understanding with DARPA and
>      DCA that NSFnet'd sites can use ARPANET.  That does not extend to
>      the MILNET.  Thus, Davis can use UCB's or Stanford's, our even NASA's
>      ARPANET gateways, with the approval of the site of course, but
>      not MILNET, even though NASA has MILNET coverage.  Thus we are required
>      to restrict BARRNet routing through our MILNET PSN.  If we were willing
>      to sponsor UCB's MILNET access, for some requirement which NASA
>      had to implement, then we would turn that on.  But BARRNet itself will
>      but cutoff to MILNET (and probably ARPANET too) at Ames, but not
>      cut off to other NASA centers or sites that NASA connects.  There is
>      no technical reason that prevents this, in fact, we have to take
>      special measures to prevent it.  But those are the rules.  Anyways,
>      mailbridge performance should improve after the conversion, so
>      UCB should be in better shape.  And you'll certainly be able to
>      talk to us via BARRNnet...  I have noticed recently that MILNET<->
>      ARPANET performance has been particularly poor...  Sigh.
>
>      The DCA folks feel that in case of an emergency they may be
>      forced to use an unsecure network to pass certain info around.  The
>      DDN brochure mentions SIOP related data for example.  Who knows,
>      if the balloon goes up, the launch order might pass through Evans
>      Hall on its way out to SAC...  :-)
>
>
>                          Milo
>
>
>
> I dug up an "explosive bolts" reference -- fortunately that brilliant plan didn't get far.
>
> (Milo Medin knows this stuff first hand: https://innovation.defense.gov/Media/Biographies/Bio-Display/Article/1395855/milo-medin/ )
>
>      To: fair at ucbarpa.berkeley.edu (Erik E. Fair)
>      Cc: ucdavis!ccohesh at ucbvax.berkeley.edu, Hackers_Guild at ucbvax.berkeley.edu
>      Subject: Re: a question of definition
>      Date: Thu, 29 Jan 87 12:29:36 PST
>      From: Milo S. Medin (NASA ARC Code ED) <medin at orion.arpa>
>
>      Actually its:
>
>      SCINET -- Secret Compartmented Information Net  (if you don't know what
>      compartmented means, you don't need to ask)
>      DODIIS -- DoD Intelligence Information Net
>
>      The other stuff I think is right, at least without me looking things
>      up.  I probably shouldn't have brought this subject of the secure part
>      of the DDN up.  People like being low key about such things...
>
>      Erik, all the BBN gateways on MILNET and ARPANET currently comprise
>      the core, not just mailbridges.  Some are used as site gateways, others
>      as EGP neighbors, etc...  And just because you are dual homed doesn't mean
>      you get a mailbridge.  And the IETF doesn't deal with low level stuff
>      like that; DCA does all that.  In fact, the reason we are getting an
>      ARPANET PSN is because when DCA came out to do a site survey, they
>      liked our site so much they asked if they could put one here!  It's
>      amazing how many sites have tried to get ARPANET PSN's the right
>      way and have had to wait much longer than us...  BTW, since we are
>      dual homed (probably a gateway with 2 1822 interfaces in it), we
>      are taking steps to be sure that people on ARPANET or MILNET can't
>      use our gateway to bypass the mailbridges.  The code will be hacked
>      to drop all packets that aren't going to a locally reachable network.
>      BARRNet, even though its locally reachable, will be excluded
>      from this however, since the current procedural limitations call for
>      not allowing any BARRNet traffic to flow out of BARRNet to MILNET
>      and the reverse.  NASA traffic of course can traffic through BARRNet,
>      and even use ARPANET that way (though that's not a big deal when
>      we get our own ARPANET PSN).  That's because only NASA is authorized
>      to directly connect to MILNET, not UCB or Stanford, etc...
>
>      DCA must have the ability to partition the ARPANET and MILNET in
>      case of an "emergency", and having non-DCA controlled paths between
>      the nets prevents that.  There was talk some time ago about putting
>      explosive bolts in the mailbridges that would be triggered by
>      destruct packets...  That idea didn't get far though...
>
>      The DDN only includes MILNET,ARPANET,SCINET,etc...  Not the attached
>      networks.  If it did, you'd need to file a TSR to add a PC to your
>      local cable.  A TSR is a monstrous piece of paperwork that needs to
>      be done anytime anything is changed on the DDN...  Rick knows all
>      about them don't you Rick?
>
>      The whole network game is filled with acronyms!  I gave up trying
>      to write documents with full explainations in terms long ago...
>      I have yet to see a short and concise (and correct) way of describing
>      DDN X.25 Standard Service for example...  That's probably one of the
>      harder things about getting into networking these days.  We won't
>      even talk about Etherbunnies and Martians and other Millspeak...
>
>                          Milo '1822' Medin
>
>
>