[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