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

Johnny Billquist bqt at softjar.se
Tue Nov 22 06:49:51 EST 2016


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.

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





More information about the Info-vax mailing list