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

[Johnny Billquist]

On 2016-11-22 14:21, 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...

A bit surprising, but on the other hand, this is from the era when 
systems was much more trusting of everything.

>> 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.

Right. The routing messages as such are not checked for any authority or 
such. Same as RIP under TCP/IP. You just broadcast things, and others 
might accept it.

> 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.

Yeah. But apart from checking the ethernet header (which can be faked 
anyway) against the source DECnet address (which can also be faked), 
there is no identification for authority. Anyone can do this.
Very easy to fake, and thus mess up routing on all nodes.

Very much the same way RIP works. RIP is pretty much deprecated today, 
and partially for this same reason.

> (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.)

Right. Which is how it should be handled. The only additional checking 
that could be done (and RSX do), is just verifying that the source MAC 
address agrees with the source DECnet address. But since you can easily 
fake both, this is pretty much no security at all.

But any communication will sooner or later require two way 
communication, which means that if you want to talk, you'll need to have 
the appropriate MAC address matching your DECnet address, and be talking 
the DECnet protools, or you are not going anywhere.

But if you just want to mess DECnet up, then sure, just broadcast fake 
routing announcements, and everything will break.

>>> 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.

That is only for TCP. For IP and UDP, there is no such thing.

> 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.

Here it will also be a questions of what protocol we're talking.

> 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.

There is trust. Too much in todays world. A malicious computer will 
easily corrupt DECnet.

You can improve security by having passwords on circuits, but noone does 
that normally...

	Johnny