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

[Simon Clubley]

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.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world