<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>DECnet, like ARPAnet (the predecessor of IP) were designed in an
      era of point-to-point (largely synchronous) communications over
      private lines and locked down routers (called IMP's or Interface
      Message Processors).  PC what??  If you control the wires (which
      AT&T did), the router (which BBN did) and the (timeshared) CPU
      (which was the case for large systems with staff), then the model
      is not immediately horrifying.</p>
    <p>All of that went out the window with broadcast networks (1983),
      non-government user owned routers (I.E., Cisco) and PC's. 
      However, you'd be surprised at how many people out there still
      think that ACL's for IP address are sufficient.  Nope.<br>
    </p>
    <p>You can not rely on <i>anything</i> you put out on the Internet
      getting snooped unless you secure (I.E., encrypt) and firewall <u>all</u>
      legs of the transport.  This is frequently done with NAT'ing
      routers and IPsec, so it is largely transparent.  I have installed
      a large number of these and they appear to function well.  At
      least, I haven't gotten nailed yet through that avenue (as he
      knocks on wood).</p>
    <p>Off the top of my head, the only way to handle credential
      exchange in a public setting is to either not do it at all (I.E.,
      allowing limited ANONYMOUS usage), non-transmitted shared secret
      (I.E., private key sent outside of regular channels), asymmetric
      authentication or information theoretic secure paradigms.</p>
    <p>All of my HECnet hosts are behind a firewall specifically so they
      can't be scanned.  The only time I bring a host on the general
      Internet is to do regression tests of my FTP server.  Perhaps also
      when I get around to implementing some more TELNET options (not
      having SIGWINCH on Tops-20 is <i>really</i> annoying).<br>
    </p>
    <div class="moz-cite-prefix">On 3/2/20 4:33 PM, Mark J. Blair wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:228CD474-BC9F-4521-BFD0-E15C534D8B91@nf6x.net">
      <pre class="moz-quote-pre" wrap="">Re: multiple DECnet nodes on the same physical machine, I've set up things like tun/tap before for that. I don't remember the details, but I still have my scripts from the last time I played with it so that I can learn it all over again.

Re: security, I don't expect any sort of modern security within HECnet. I presume that anything I connect to it may get to relive things like the Father Christmas worm at any moment, all of my packets transiting HECnet outside my local network are printed on billboards, and nothing but obscurity stands between my local network and all of the DECnet-aware malicious hackers in the world using my old VMS and RSX nodes as beachheads to break in. I was mostly just wondering if there's anything in place to provide a modicum of protection for the Internet-connected, IP-aware hosts on HECnet (particularly any nodes providing upstream connectivity to others on HECnet) from random bad people port-scanning them and making connections to their open IP ports. Is there even a plaintext login/password challenge at connection time when a downstream node connects to its upstream node over the public Internet? Does that vary depending on whether GRE, Multinet, etc. is used for the link?


</pre>
    </blockquote>
  </body>
</html>