[Info-vax] DECnet Phase IV and VMS code comments

[johnwallace4 at yahoo.co.uk]

On Tuesday, 22 November 2016 13:21:40 UTC, Simon Clubley  wrote:
> On 2016-11-22, Dirk Munk <munk at home.nl> wrote:
> > Johnny Billquist wrote:
> >>
> >> I don't know about VMS much, but I do know that RSX will check incoming
> >> packets so that the MAC address agrees with the claimed node address.
> 
> Well, that's one better than VMS manages...
> 
> >
> > How do you mean? The original MAC address of a NIC is replaced by a 
> > DECnet generated MAC address, AA-00-04-00-aa-bb, where aa-bb contains 
> > the DECnet Phase IV address. So if you give some node on your LAN such a 
> > MAC address by hand, DECnet will see it as a DECnet node. Furthermore 
> > you can't uses two NIC's of the same computer on one network segment.
> >
> 
> No, that's only part of the story.
> 
> The routing layer messages in DECnet Phase IV also contain the source
> DECnet address, and this information is not crosschecked against the
> Ethernet level frame header in any way that I have been able to detect.
> 
> VMS DECnet Phase IV appears to use the information in the routing layer
> message in preference to the Ethernet frame header information and
> completely trusts the source address field in the routing layer message.
> 
> (Based in the reported contents, the Remote node id: field in the OPCOM
> messages I posted last night came from the routing layer s_id field and
> not from the Ethernet frame source MAC address field.)
> 
> >>
> >> And it is impossible to establish a connection with another machine if
> >> you lie about you node address compared to your MAC address anyhow, as
> >> any responses will not be sent back to you. This is because of the very
> >> basic design of DECnet on ethernet.
> >>
> >> I don't know exactly what you are seeing here, and I haven't spent
> >> enough time to get into all details of what you are saying.
> >>
> >> But it would seem to me to be similar to what you have in TCP/IP, where
> >> you can certainly lie all you want about the source IP address in
> >> packets. However, responses will then not come back to you.
> >>
> 
> That is absolutely true, but the difference in TCP/IP is that the
> higher level protocols do not even come into play until after the
> source IP address has been validated as a result of the initial
> SYN/ACK sequence.
> 
> With DECnet, because that information is present in the initial
> Connect-Init packet, the higher layers get triggered even though
> the source address has not yet been validated.
> 
> The demo was more a demo of how the whole of DECnet Phase IV on VMS
> (instead of just one part) completely trusts the originating address.
> 
> Simon.
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

With greatest respect :)

Back in the day, there was an expectation that those who
really cared about network security (rather than about the
*appearance* of security, which nowadays often seems to be
sufficient) wouldn't all be so naive as to rely on OS 
software to manage it.

So DEC offered a secure Ethernet network interface about
which little is written, but the magic part number is based
around DESNC. It arrived in the 1980s and did link-layer
encryption of LAN traffic and that's about all I remember.
Other more definitive references very welcome.

Then along came Phase V, and a more general approach to 
networks which might have Bad Things on them was needed,
an approach which couldn't rely on hardware support and
which as BlackCat noted already, did in the right 
circumstances do a bit of 'authentication' in software.

Incidentally in trying (and largely failing) to find useful
information on the DESNC, I came across this 2015 paper which
some readers may find interesting. Note that although Butler
Lampson is now a long term employee of MS Research (as are Dave
Cutler, Tony Hoare and others!!!), he's previously worked
extensively at Xerox PARC and at DEC's Systems Research Center:

http://research.microsoft.com/en-us/um/people/blampson/Slides/Security%20perspectives%20(SOSP%202015).pdf

It's a shame no one elsewhere in MS is actually listening to
these good people.

Meanwhile, someone with a valid pointer to a DEC "Systems
and Options" or "Networks and Communications" catalogue from
the relevant era may be able to shed a little more light on
the DESNC than I can.

Have a lot of fun.