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

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of johnwallace4--- via Info-vax
> Sent: 22-Nov-16 11:04 AM
> To: info-vax at rbnsn.com
> Cc: johnwallace4 at yahoo.co.uk
> Subject: Re: [Info-vax] DECnet Phase IV and VMS code comments
> 
> 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.
> 

http://bit.ly/2gj6tnn

[snip..]


Regards,

Kerry Main
Kerry dot main at starkgaming dot com