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

[Dirk Munk]

Johnny Billquist wrote:
> On 2016-11-21 22:11, Simon Clubley wrote:
>> On 2016-11-21, Simon Clubley
>> <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>
>>> I also had another look at this last night and further discovered
>>> that 1.1 ACKed an incoming connect-init from what was claimed to
>>> be 1.1 in the router level s_id field before FAL rejected it due
>>> to missing username and password.
>>>
>>> It also ACKed an incoming packet with the s_id field set to a
>>> multicast address (the OPCOM network login failure message showed
>>> it as DECnet node 1.0).
>>>
>>
>> Loose wording on my part above. I don't know if Connect ACKs were
>> actually issued in the above two cases; all I know is that the dodgy
>> packets were fully processed instead of being dropped on the floor.
>>
>> Here's a couple of OPCOM messages from last night's experiments; as
>> before, these are as the result of external packets from 1.2 being
>> received by node 1.1.
>>
>> The field of interest is the Remote node id: field.
>>
>> %%%%%%%%%%%  OPCOM  20-NOV-2016 23:15:48.04  %%%%%%%%%%%
>> Message from user AUDIT$SERVER on AXPA
>> Security alarm (SECURITY) and security audit (SECURITY) on AXPA,
>> system id: 1025
>> Auditable event:          Network login failure
>> Event time:               20-NOV-2016 23:15:48.03
>> PID:                      000000AC
>> Process name:             FAL_16391
>> Username:                 DECNET
>> Process owner:            [1,3]
>> Image name:               AXPA$DKA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
>> Remote nodename:          AXPA
>> Remote node id:           1025 (1.1)
>> Posix UID:                -2
>> Posix GID:                -2 (%XFFFFFFFE)
>> Status:                   %LOGIN-F-NOTVALID, user authorization failure
>>
>> %%%%%%%%%%%  OPCOM  20-NOV-2016 23:53:32.80  %%%%%%%%%%%
>> Message from user AUDIT$SERVER on AXPA
>> Security alarm (SECURITY) and security audit (SECURITY) on AXPA,
>> system id: 1025
>> Auditable event:          Network login failure
>> Event time:               20-NOV-2016 23:53:32.80
>> PID:                      000000B6
>> Process name:             FAL_8210
>> Username:                 DECNET
>> Process owner:            [1,3]
>> Image name:               AXPA$DKA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
>> Remote node id:           1024 (1.0)
>> Posix UID:                -2
>> Posix GID:                -2 (%XFFFFFFFE)
>> Status:                   %LOGIN-F-NOTVALID, user authorization failure
>>
>> BTW, the only reason this is even possible is due to the design of
>> DECnet.
>>
>> In protocols where you have to first do an exchange of SYN and ACK
>> packets (or equivalent) before the higher level protocols even get
>> a chance to transmit anything, the source IP address has to be
>> valid or the initial connection will never complete.
>>
>> In DECnet however, all that higher level information gets transmitted
>> in the initial Connect Init packet before any ACKs (or more critically,
>> the target port number to use) are even required.
>>
>> This is what allows DECnet packets to get all the way to FAL without
>> a valid DECnet source node address.
>
> 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.

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.

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