Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

DECnet Phase IV and VMS code comments

439 views
Skip to first unread message

Simon Clubley

unread,
Nov 21, 2016, 9:14:49 AM11/21/16
to
The reason I've been asking about DECnet Phase IV recently is
because I decided to explore it a little bit from the security
point of view. I didn't expect to find anything major in the
limited time I allocated for this and sure enough I didn't.

However, I did find something unusual which while not an obvious
security issue caused me a little concern because it does raise
questions about the level of checking in the VMS networking code.

What I have discovered is that DECnet blindly trusts what it is
being told about the originating address, even when that information
cannot possibly be valid. For example, when the target node is 1.1,
then the target node trusts (and processes) an incoming packet which
also claims to be 1.1 instead of instantly dropping it.

While this isn't an immediate security issue (which is why I am
comfortable discussing this here), the question it raises is if VMS
networking code, which was written in a more trusting era, has all
the checks in it that one would expect to find in networking code
written in today's more hostile world.

My concern is that the next missing check might be something which
could be exploited to cause a system crash (for example) or maybe
actually compromise system security.

Comments invited.

Here's an example I sent to VSI recently. The target node is 1.1
which is VMS Alpha 8.4. The originating node is 1.2 which is a Linux
box with it's MAC address altered to appear as DECnet node 1.2.

What you are looking at are Endnode hello packets sent from a test
program running on 1.2 which alternatively claims that it's node 1.1
and node 1.2.

Also note that these are supposed to be multicast messages and VMS
blindly processed them even though they were deliberately sent to
the MAC address of 1.1 directly.

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

---------------------------------------------------------------------
$ mcr ncp show adj node


Node Volatile Summary as of 9-NOV-2016 20:16:38

%NCP-E-INVRSP, invalid management response
$
%%%%%%%%%%% OPCOM 9-NOV-2016 20:16:43.22 %%%%%%%%%%%
Message from user DECNET on AXPA
DECnet event 4.15, adjacency up
From node 1.1 (AXPA), 9-NOV-2016 20:16:43.21
Circuit EWA-0, Adjacent node = 1.1 (AXPA)


$
%%%%%%%%%%% OPCOM 9-NOV-2016 20:16:48.03 %%%%%%%%%%%
Message from user DECNET on AXPA
DECnet event 4.15, adjacency up
From node 1.1 (AXPA), 9-NOV-2016 20:16:48.03
Circuit EWA-0, Adjacent node = 1.2


$ mcr ncp show adj node


Node Volatile Summary as of 9-NOV-2016 20:16:56

Node State Active Delay Circuit Next node
Links

1.1 EWA-0 0
1.2 EWA-0 0
$
%%%%%%%%%%% OPCOM 9-NOV-2016 20:17:28.05 %%%%%%%%%%%
Message from user DECNET on AXPA
DECnet event 4.18, adjacency down
From node 1.1 (AXPA), 9-NOV-2016 20:17:28.04
Circuit EWA-0, Adjacent node listener receive timeout
Adjacent node = 1.1 (AXPA)


$
%%%%%%%%%%% OPCOM 9-NOV-2016 20:17:33.05 %%%%%%%%%%%
Message from user DECNET on AXPA
DECnet event 4.18, adjacency down
From node 1.1 (AXPA), 9-NOV-2016 20:17:33.05
Circuit EWA-0, Adjacent node listener receive timeout
Adjacent node = 1.2


$ mcr ncp show adj node


Node Volatile Summary as of 9-NOV-2016 20:17:35

%NCP-E-INVRSP, invalid management response
---------------------------------------------------------------------

The following Ethernet frames are what caused the above behaviour:

---------------------------------------------------------------------
[root@[deleted] vms]# ./endnode_hello
Interface index = 2
0000: aa 00 04 00 01 04 aa 00 04 00 02 04 60 03 22 00 ............`.".
0010: 0d 02 00 00 aa 00 04 00 01 04 03 da 05 00 00 00 ................
0020: 00 00 00 00 00 00 aa 00 04 00 00 00 0f 00 00 02 ................
0030: aa aa 00 00 00 00 00 00 00 00 00 00 ............
[root@[deleted] vms]# make
gcc -Wall -o endnode_hello endnode_hello.c
[root@[deleted] vms]# ./endnode_hello
Interface index = 2
0000: aa 00 04 00 01 04 aa 00 04 00 02 04 60 03 22 00 ............`.".
0010: 0d 02 00 00 aa 00 04 00 02 04 03 da 05 00 00 00 ................
0020: 00 00 00 00 00 00 aa 00 04 00 00 00 0f 00 00 02 ................
0030: aa aa 00 00 00 00 00 00 00 00 00 00 ............
---------------------------------------------------------------------

(It was run as root so I could access the packet interface on Linux).

Simon.

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

David Froble

unread,
Nov 21, 2016, 12:55:00 PM11/21/16
to
Simon Clubley wrote:
> The reason I've been asking about DECnet Phase IV recently is
> because I decided to explore it a little bit from the security
> point of view. I didn't expect to find anything major in the
> limited time I allocated for this and sure enough I didn't.
>
> However, I did find something unusual which while not an obvious
> security issue caused me a little concern because it does raise
> questions about the level of checking in the VMS networking code.
>
> What I have discovered is that DECnet blindly trusts what it is
> being told about the originating address, even when that information
> cannot possibly be valid. For example, when the target node is 1.1,
> then the target node trusts (and processes) an incoming packet which
> also claims to be 1.1 instead of instantly dropping it.

Without getting into the rest of your post, DECnet can be used for task to task
communications in the same system. At least, that's what I remember from the
dim past while using it on RSTS/E.

So, yeah, node 1.1 getting a connection from another task on node 1.1 should be
valid. Now, if DECnet can determine that the connection came from another node,
(the lack of which seems to be your issue), then such a connection should be
considered a problem. Perhaps not for handling the connection, but surely a
problem with network configuration.

Not sure what you're looking at, I can also use sockets for task to task
communications on the same system?

Simon Clubley

unread,
Nov 21, 2016, 1:49:51 PM11/21/16
to
Any decent network stack should be able to validate an incoming packet
based on it's origin. That's the core issue here and is what allows an
internal connection on a node to loop back to itself while also at the
same time dropping external packets which claim to be coming from itself.

Under no circumstances _whatsoever_ should an external node be able to
pretend to be the target node and be able to get away with it.

The lowest levels of the DECnet code should have hard dropped those
packets the moment they saw the external packet had the same source
address as their node's address and it's more than a little unsettling
that they didn't.

It's a basic security countermeasure and something which I would expect
to be implemented in every network stack written today, regardless of
protocol, as a routine measure.

The concern here is not so much DECnet Phase IV (which isn't exactly
secure to begin with by today's standards) but more if the same types
of expected checks are missing elsewhere and in areas that it might
actually matter to system security.

> Not sure what you're looking at, I can also use sockets for task to task
> communications on the same system?

As explained above, that's not the issue here.

Simon Clubley

unread,
Nov 21, 2016, 4:12:23 PM11/21/16
to
On 2016-11-21, Simon Clubley <clubley@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.

Michael Moroney

unread,
Nov 21, 2016, 5:02:23 PM11/21/16
to
DECnet was created in an environment where it was pretty much assumed
the company had total control of the network infrastructure and
tapping/eavesdropping or spoofing was pretty much unheard of, except
perhaps for spy movies involving three letter agencies. Different
world now. A bigger problem is simple monitoring and getting passwords
and so forth.

I suspect that this was created as an unintentional side effect of
a node with more than one adapter seeing itself. That is, receiving
a hello from its own address that was sent by another interface. But
who knows.

BlackCat

unread,
Nov 22, 2016, 4:01:59 AM11/22/16
to
>>> What I have discovered is that DECnet blindly trusts what it is
>>> being told about the originating address, even when that information
>>> cannot possibly be valid. For example, when the target node is 1.1,
>>> then the target node trusts (and processes) an incoming packet which
>>> also claims to be 1.1 instead of instantly dropping it.
That should of course say DECnet IV. DECnet V would produce "Verification failures".
"generated each time Session Control is unable to verify that the addresses and protocols of an incoming connection request are
consistent with the DNA$Towers attribute of the source node name."



Johnny Billquist

unread,
Nov 22, 2016, 6:49:53 AM11/22/16
to
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


Dirk Munk

unread,
Nov 22, 2016, 7:30:17 AM11/22/16
to
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.

Johnny Billquist

unread,
Nov 22, 2016, 7:56:41 AM11/22/16
to
On 2016-11-22 13:30, Dirk Munk 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.
>
> 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.

The original MAC of the NIC is not something visible to other machines
on the network, so that is never usable. The DECnet MAC address is what
other machines will see. And DECnet in RSX will check that the claimed
DECnet address matches the source MAC address as computed.

Obviously any machine can have that MAC address, and if several machines
on a network have the same MAC address, many funny things can and will
happen.

DECnet will see another machine as a DECnet node if it has an
appropriate MAC address, and are speaking the appropriate protocols.
Which should also be very obvious. :-)

Johnny

Simon Clubley

unread,
Nov 22, 2016, 8:21:40 AM11/22/16
to
On 2016-11-22, Dirk Munk <mu...@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...

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

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.

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

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

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.

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.

Johnny Billquist

unread,
Nov 22, 2016, 9:16:38 AM11/22/16
to
On 2016-11-22 14:21, Simon Clubley wrote:
> On 2016-11-22, Dirk Munk <mu...@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

Bob Koehler

unread,
Nov 22, 2016, 9:17:59 AM11/22/16
to
In article <o11bd0$qds$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>
> 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.

Nice to have, but DECnet predates ethernet. Did DDCMP include any
such information to verify against?

johnwa...@yahoo.co.uk

unread,
Nov 22, 2016, 11:04:26 AM11/22/16
to
With greatest respect :)

Back in the day, there was an expectation that those who
really cared about network security (rather than about the
*appearance* of security, which nowadays often seems to be
sufficient) wouldn't all be so naive as to rely on OS
software to manage it.

So DEC offered a secure Ethernet network interface about
which little is written, but the magic part number is based
around DESNC. It arrived in the 1980s and did link-layer
encryption of LAN traffic and that's about all I remember.
Other more definitive references very welcome.

Then along came Phase V, and a more general approach to
networks which might have Bad Things on them was needed,
an approach which couldn't rely on hardware support and
which as BlackCat noted already, did in the right
circumstances do a bit of 'authentication' in software.

Incidentally in trying (and largely failing) to find useful
information on the DESNC, I came across this 2015 paper which
some readers may find interesting. Note that although Butler
Lampson is now a long term employee of MS Research (as are Dave
Cutler, Tony Hoare and others!!!), he's previously worked
extensively at Xerox PARC and at DEC's Systems Research Center:

http://research.microsoft.com/en-us/um/people/blampson/Slides/Security%20perspectives%20(SOSP%202015).pdf

It's a shame no one elsewhere in MS is actually listening to
these good people.

Meanwhile, someone with a valid pointer to a DEC "Systems
and Options" or "Networks and Communications" catalogue from
the relevant era may be able to shed a little more light on
the DESNC than I can.

Have a lot of fun.

Johnny Billquist

unread,
Nov 22, 2016, 12:06:02 PM11/22/16
to
Good point. No, DDCMP do not have any information similar to the MAC
address. DDCMP is mostly just a point-to-point protocol anyway, so such
a piece of information is not really needed. That said, the MAC address
isn't really enhancing security in any real way. You can fake a MAC
address just as easily as the DECnet address in a packet.

If you want some security, you should use passwords for the circuits.
Then you will not get any traffic across until the other side
authenticated itself.

Johnny

Simon Clubley

unread,
Nov 22, 2016, 2:14:54 PM11/22/16
to
On 2016-11-22, Johnny Billquist <b...@softjar.se> wrote:
> On 2016-11-22 14:21, Simon Clubley wrote:
>>
>> 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.
>

Which directly leads into my concerns about if the rest of the VMS
networking code could do with some checking to make sure it's suitable
for use in today's more hostile environment.

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

In case anyone following along is getting confused by the use of the
word routing in the above thread, I should point out that the word
routing applies to the routing layer in DECnet Phase IV which does
two distinct things:

1) It emits standalone packets which contain network configuration
information (such as the endnode hello packets).

2) When higher level layers (ie: NSP) are present in a packet,
routing has various additional data structures, and one of these
routing data structures is always present within those packets.

In both cases, DECnet is trusting the information in the routing
layer data structures much more than it should be.

As an aside, I think that's about it for DECnet. I wonder what
I should look at next ? :-)

Paul Sture

unread,
Nov 22, 2016, 4:09:24 PM11/22/16
to
On 2016-11-22, johnwa...@yahoo.co.uk <johnwa...@yahoo.co.uk> wrote:

> Incidentally in trying (and largely failing) to find useful
> information on the DESNC, I came across this 2015 paper which
> some readers may find interesting. Note that although Butler
> Lampson is now a long term employee of MS Research (as are Dave
> Cutler, Tony Hoare and others!!!), he's previously worked
> extensively at Xerox PARC and at DEC's Systems Research Center:
>
> http://research.microsoft.com/en-us/um/people/blampson/Slides/Security%20perspectives%20(SOSP%202015).pdf
>
> It's a shame no one elsewhere in MS is actually listening to
> these good people.

Nice find, thanks for passing it on.

> Meanwhile, someone with a valid pointer to a DEC "Systems
> and Options" or "Networks and Communications" catalogue from
> the relevant era may be able to shed a little more light on
> the DESNC than I can.

No success with those documents but I found references to
DESNC in the following documents:

----
<ftp://ftp.uni-mainz.de/pub/software/CERT/nist/nistgen/sp4rpt.txt>

"Prototyping SP4 - A Secure Data Network System Transport Protocol
Interoperability Demonstration Project"

(skip forward to "6.1 Establishing the SP4 Laboratory" to get to the
interesting bits)

----
<http://decdoc.itsx.net/dec94mds/vaxctcg6.txt>

"Guidelines for VAXcluster System Configurations", September 1992

Ethernet VAXcluster configurations can include VAXstation CPUs that
are located outside secure areas. For truly stringent security
precautions, consider using Digital Ethernet Secure Network
Controller (DESNC) devices to connect these VAXstation CPUs to the
Ethernet. These devices encrypt packets traveling across the
Ethernet. You may want to locate all CPUs in secure areas, which is
usually the case for CI or DSSI VAXcluster systems.

----
<http://securitydigest.org/rutgers/archive/1989/09>

scroll to bottom to see the following (I ignored the previous stuff)

----MESSAGE-BEGIN---- <1989092918531100>
From: ishi...@ultra.enet.dec.com (Jim Ishikawa, DTN_293_5054) 1-OCT-1989 2:33:11
To: "secu...@pyrite.rutgers.edu"@decwrl.dec.com
Subj: [1546] RE: Encryption hardware/software available?

>The DEC encryption approach was described to me to have 2 significant defects:
>1. You have to have a VAX to use it.

While it is true that the security management software (VAX KDC) will only run
on a VAX system, only *one* VAX system is required on a network. Furthermore,
VAX KDC software will run on any VAX, including small ones like the MicroVAX
3100.

Digital's Ethernet Enhanced-Security System product set actually comprises two
separate products. In addition to the VAX KDC software, there is the DESNC
secure network controller.

The DESNC controllers are freestanding devices that provide a secure network
interface for client nodes. Client nodes may be any device that complies with
Ethernet or IEEE 802.3 standards. The network security manager uses one or
more VAX KDC systems to manage the DESNC controllers and their associated
client nodes on a network.

>2. Too much of the packet is encrypted, such that the packets can only pass
> thru bridges, and not routers.

It is true that DESNC encryption is done at the data-link layer, and as such,
encrypted packets can only be forwarded through routers after first decrypting
them. Of course, this means that DESNC controllers will support
vendor-independent, multiprotocol environments. Network-layer encryption
schemes, which allow packets to be forwarded through routers without
decryption, are generally restricted to a single network-layer protocol and
typically do not support other protocols that run directly on the data-link
layer protocol.

Jim Ishikawa
DEC
----MESSAGE-END----

----
<http://odl.sysworks.biz/disk$vaxdocdec022/network/d33vaa65.p27.bkb>

Workstations Network Guide


1.8 Network Security: DESNC Secure Ethernet Controller
If your organization needs a secure environment for its
data processing operations, the DESNC product may be the
solution.

DESNC hardware and VAX KDC security management
software provide a security-enhanced local area network,
in which only authorized systems have access to sensitive
data. DESNC controllers and VAX KDC software can be
used on single segment, multisegment, or extended Ethernet
local area networks that use a variety of media including
ThinWire, baseband, and broadband cable.

The DESNC is a standalone, store-and-forward
cryptographic controller that provides a number of security
features, including...


Figure 1.3 off that page: <http://odl.sysworks.biz/disk$vaxdocdec022/network/d33vaa65.p28.bkb#85>

----

The odl.sysworks.biz website is something of a treasure trove, reaching
back to 1996 for Alpha, 1994 for VAX, and Jan-1991 for plain old VMS.

<http://odl.sysworks.biz/swadm_dat_root/cddoc04jan1/library.html>

The Jan-1991 docset includes various software products that I recall
reading about but alas never got to use, for example DECdecision,
DECdesign, DECintact


--
A sure cure for sea-sickness is to sit under a tree.
-- Spike Milligan

Kerry Main

unread,
Nov 22, 2016, 4:35:04 PM11/22/16
to comp.os.vms to email gateway
http://bit.ly/2gj6tnn

[snip..]


Regards,

Kerry Main
Kerry dot main at starkgaming dot com





Kerry Main

unread,
Nov 22, 2016, 5:05:04 PM11/22/16
to comp.os.vms to email gateway

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Paul Sture via Info-vax
> Sent: 22-Nov-16 4:03 PM
> To: info...@rbnsn.com
> Cc: Paul Sture <nos...@sture.ch>
> Subject: Re: [Info-vax] DECnet Phase IV and VMS code comments
>
For easier reading, there is also a PDF version of this file in
the same directory:
http://decdoc.itsx.net/dec94mds/vaxctcg6.pdf

Btw, some likely already knew about this site, but it was new to
me (or at least I forgot about it) so ....

I tripped across some excellent docs for older devices in this
site as well:

http://decdoc.itsx.net/dec94mds/ (scroll down for txt/pdf file
flavors)

http://decdoc.itsx.net
http://decdoc.itsx.net/uq/pdf/ (huge number of user guides -
including older LCG systems and peripherals)

Gordon Bell "Computer Engineering" (large file)
http://decdoc.itsx.net/bitsavers/pdf/dec/Bell-ComputerEngineering
.pdf

(site is highly recommended for those interested in some not
readily available older docs)

[snip]

Bob Koehler

unread,
Nov 23, 2016, 9:56:16 AM11/23/16
to
In article <o11k04$cbd$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>
> You can improve security by having passwords on circuits, but noone does
> that normally...

We looked into that, but the documentation implied that it was not
supported on ethernet.

Johnny Billquist

unread,
Nov 23, 2016, 11:33:37 AM11/23/16
to
Hmm. You might very well be right on that one. I mostly remember seeing
the options in the initial setup of DDCMP links. Can't remember if it
even exists for ethernet.

Johnny

Bob Koehler

unread,
Nov 23, 2016, 1:50:42 PM11/23/16
to
IIRC, you can enter it for any circuit, and we did enter it for
our ethernet circuits, but I don't recall it having any affect and
I do recall the documentation implying that it woudln't.

Dirk Munk

unread,
Nov 25, 2016, 4:21:13 AM11/25/16
to
My question is, why are you interested in this very old protocol? DECnet
Phase V was designed for let's say an OSI Internet, so I'm sure it's
beter designed in this respect. Before some one else tries to point it
out, yes I know it doesn't have encryption when used with the OSI
transport layers. It could have been done, and it still can be done
using TLS, that has been designed for the OSI transport layer. I'm sure
VSI will look into this :-)

Simon Clubley

unread,
Nov 25, 2016, 8:43:31 AM11/25/16
to
On 2016-11-25, Dirk Munk <mu...@home.nl> wrote:
>
> My question is, why are you interested in this very old protocol?

If you were thinking like a security researcher, then it would be
obvious why. :-) However, since it's probably not clear to various
people, here is the explanation.

First off, I'm not interested in DECnet Phase IV as a protocol to
be used. It's an insecure and obsolete protocol and if you are
actually using it (as opposed to just having it enabled) on a
network that you don't 100% control then you don't really care
about the security of your VMS boxes.

What I _am_ interested in, and what a security researcher would
be interested in, is that it's a piece of software that's enabled
routinely on many VMS systems, even when it's not really used,
which makes it a possible attack vector against a VMS system
(either a system crasher (more likely) or actual unauthorised
access (less likely)) if an implementation flaw could be found.

Thankfully, in the limited time I decided to allocate to this,
I was not to find such an exploit.

However, the other reason a security researcher would be interested
in DECnet Phase IV would be to find clues about the implementation
that might help them when probing other parts of VMS for vulnerabilities.

Here, I was more successful. If I were a security researcher, I would
now know that some basic checks which I would expect in a network
stack written today simply don't exist in the VMS implementation of
DECnet Phase IV so I would now have motivation to explore the other
VMS network stacks for similar issues.

I would now know that when information is reproduced within the
different layers within a packet, that different parts of the code
use different weightings for which of those fields to trust. That's
_very_ useful information when you are looking for vulnerabilities.

I would now know that the code was written in a more trusting era
and that at least some of the assumptions and checks in the code
had not been reviewed as networks became more hostile over the years.

In summary, no actual exploits found in DECnet Phase IV, but a
good set of useful clues to consider when looking at the other
network stacks were found, especially when you consider that the
same people who implemented DECnet Phase IV may have also
implemented those other network stacks and made similar mistakes
or omissions.

(One of the things you are supposed to do when a vulnerability is
reported is to review similar code written by the person or persons
who wrote the vulnerable code and see if the same mistakes were
made there as well.)

Johnny Billquist

unread,
Nov 25, 2016, 9:08:21 AM11/25/16
to
While you have some half points in here, I feel that this is making more
out of it than is meaningful.

I can just as easily also pollute the ARP table of any IPv4 host. There
is no checking of the authenticity of an ARP packet, and if can cause
traffic to suddenly be redirected elsewhere for all IPv4 traffic you are
sending out.

I can also easily pollute the routing table of many IPv4 hosts by
sending bogus RIP packets. There is no authenticity there either. The
data is just processed, and acted upon.

I fail to see that DECnet have any more problems than IP here. The big
issue is cleartext usernames and passwords. Something IP protocols also
have, but in IP those protocols are now considered security problems.

What you have found is that the routing table in DECnet can be
subverted. I'd consider that very much to be the same kind of problem as
ARP and RIP in IP.

Johnny

Johnny Billquist

unread,
Nov 25, 2016, 9:12:13 AM11/25/16
to
On 2016-11-25 10:21, Dirk Munk wrote:
> My question is, why are you interested in this very old protocol? DECnet
> Phase V was designed for let's say an OSI Internet, so I'm sure it's
> beter designed in this respect. Before some one else tries to point it
> out, yes I know it doesn't have encryption when used with the OSI
> transport layers. It could have been done, and it still can be done
> using TLS, that has been designed for the OSI transport layer. I'm sure
> VSI will look into this :-)

We've been over this before. I very much disagree, and I seriously doubt
VSI will put any work into Phase V, and I believe the comments from
others here pretty much agreed with that.

You seem to be just about the only person who haven't got it that OSI is
dead, and so is Phase V. (And it's an ugly corpse, and trying to revive
it would not make it any prettier...)

Johnny

David Froble

unread,
Nov 25, 2016, 10:38:24 AM11/25/16
to
Johnny Billquist wrote:
> On 2016-11-25 10:21, Dirk Munk wrote:
>> My question is, why are you interested in this very old protocol? DECnet
>> Phase V was designed for let's say an OSI Internet, so I'm sure it's
>> beter designed in this respect. Before some one else tries to point it
>> out, yes I know it doesn't have encryption when used with the OSI
>> transport layers. It could have been done, and it still can be done
>> using TLS, that has been designed for the OSI transport layer. I'm sure
>> VSI will look into this :-)
>
> We've been over this before. I very much disagree, and I seriously doubt
> VSI will put any work into Phase V, and I believe the comments from
> others here pretty much agreed with that.

Now, now, Johnny, don't be so fast with that disagreement. Perhaps Dirk has
more money than sense, and is going to be one of those willing to pay VSI big
bucks for some work on DECnet V. Don't forget, VSI has indicated that they will
"follow the money". How else could he be "sure VSI will look into this"?

:-)

> You seem to be just about the only person who haven't got it that OSI is
> dead, and so is Phase V. (And it's an ugly corpse, and trying to revive
> it would not make it any prettier...)

Got to agree, the user interface sure is ugly ....

Johnny Billquist

unread,
Nov 25, 2016, 11:30:13 AM11/25/16
to
On 2016-11-25 16:38, David Froble wrote:
> Johnny Billquist wrote:
>> On 2016-11-25 10:21, Dirk Munk wrote:
>>> My question is, why are you interested in this very old protocol? DECnet
>>> Phase V was designed for let's say an OSI Internet, so I'm sure it's
>>> beter designed in this respect. Before some one else tries to point it
>>> out, yes I know it doesn't have encryption when used with the OSI
>>> transport layers. It could have been done, and it still can be done
>>> using TLS, that has been designed for the OSI transport layer. I'm sure
>>> VSI will look into this :-)
>>
>> We've been over this before. I very much disagree, and I seriously
>> doubt VSI will put any work into Phase V, and I believe the comments
>> from others here pretty much agreed with that.
>
> Now, now, Johnny, don't be so fast with that disagreement. Perhaps Dirk
> has more money than sense, and is going to be one of those willing to
> pay VSI big bucks for some work on DECnet V. Don't forget, VSI has
> indicated that they will "follow the money". How else could he be "sure
> VSI will look into this"?
>
> :-)

Ah! You have a very good point. I'm sure that VSI is happy to work on in
if someone pays for it. I should have made my comment conditionalized on
that.

>> You seem to be just about the only person who haven't got it that OSI
>> is dead, and so is Phase V. (And it's an ugly corpse, and trying to
>> revive it would not make it any prettier...)
>
> Got to agree, the user interface sure is ugly ....

That is also true. :-)

Johnny

Dirk Munk

unread,
Nov 25, 2016, 12:32:21 PM11/25/16
to
No, it is not. Once you have mastered it, you will see the beauty behind
it. If you say it takes a lot of effort and time to get used to it, then
I agree.

Seems you didn't miss the " :-) " like Johnny did?

johnwa...@yahoo.co.uk

unread,
Nov 25, 2016, 1:38:31 PM11/25/16
to
Your opinion on whether Phase V is important or not is less
important than the $$$ from the customers who may be
interested in the continued support of OSI stuff.

DEC/Omni and DEC/OSAP, back in the day, both relied on
Phase V/OSI support. They are used for talking between
VMS boxes and the plant floor automation devices that
control multi-million-dollar multi-decade-lifetime
automation systems. Not some $5 here today gone
tomorrow PC peripheral.

Have a look at the roadmap. Do you see OMNI and OSAP
still on there? I did. Am I 100% confident this means
there is no alternative to OSI on VMS for talking to
these devices? Not confident at all. But it might be
interesting to know, so that well-informed comments
can be made. (Or at worst, to update the information
provided last time this topic came up).

Money talks, as DaveF, who doesn't get out much,
already pointed out (and indeed as you eventually
acknowledged yourself).

Opinions are cheap, usable standards-based multi-vendor
connectivity code (and usable support) can be more
expensive.

It might be nice if there was a reasonably recent SPD
for OMNI/OSAP readily accessible.

Robert A. Brooks

unread,
Nov 25, 2016, 9:58:10 PM11/25/16
to
On 11/25/2016 1:38 PM, johnwa...@yahoo.co.uk wrote:

> It might be nice if there was a reasonably recent SPD
> for OMNI/OSAP readily accessible.

I suspect the code has not changed much in the past decade; what
would you like to know about OMNI and/or OSAP?

--
-- Rob (who will be the VSI OMNI/OSAP maintainer)

Dirk Munk

unread,
Nov 26, 2016, 3:53:20 AM11/26/16
to
Simon Clubley wrote:
> On 2016-11-25, Dirk Munk <mu...@home.nl> wrote:
>>
>> My question is, why are you interested in this very old protocol?
>
> If you were thinking like a security researcher, then it would be
> obvious why. :-) However, since it's probably not clear to various
> people, here is the explanation.
>
> First off, I'm not interested in DECnet Phase IV as a protocol to
> be used. It's an insecure and obsolete protocol and if you are
> actually using it (as opposed to just having it enabled) on a
> network that you don't 100% control then you don't really care
> about the security of your VMS boxes.

I would never enable Phase IV on a VMS system, or Phase V in Phase IV
compatibility mode, if it was only to prevent the same MAC address
appearing on all Ethernet interfaces. In the past there were more
network protocols that used the MAC address to identify systems with
that protocol. A very obsolete method, dating from the time that is was
unheard of to use more then one Ethernet interface on one network segment.
I suppose DEC/Compaq/HP never envisioned that people would still be
using the antique Phase IV on a VMS system many years after they
introduced the replacement Phase V. So it may well be that the engineers
were quite aware of vulnerabilities in Phase IV, but didn't care to fix
them. The reasoning being that if the customer doesn't want to use the
replacement product, then any security problem arising from him using
the old stack is his problem. We (DEC/Compaq/HP) are not going to spend
time and money in improving an antique network stack.

> (One of the things you are supposed to do when a vulnerability is
> reported is to review similar code written by the person or persons
> who wrote the vulnerable code and see if the same mistakes were
> made there as well.)
>
> Simon.
>
Why don't you do a similar check with Phase V, in Phase IV compatibility
mode, and in non-compatibility mode.

johnwa...@yahoo.co.uk

unread,
Nov 26, 2016, 4:59:16 AM11/26/16
to
Thanks for volunteering!

When I last touched OMNI/OSAP and the correspoding automation
kit, it was a decade and a half ago; apologies for any errors
in my memory.

Back in those days, an OSI transport (for OSAP) and an full 7
layer OSI network (for OMNI) were required. Not because DEC
evangelists wanted people to use them, but because that's what
the automation equipment in the picture was using.

In the early days VOTS and OSAK provided that connecivity,
later to be replaced by DECnet Phase V's OSI stack.

Back in those days, it was irrelevant that there was an
option to use OSI protocols over an IP LAN, because aiui
you need *both* ends to talk the same language, and the
automation kit (and its assoiated network) didn't
understand IP, and a retrofit/rewrite may not have been
practical when you need the factory running continuously
and trustworthily and cost-effectively for building cars,
bottling drinks, etc.

Does that description sound vaguely correct (albeit much
oversimplified), and is it still the case?


All input gratefully received.

Paul Sture

unread,
Nov 26, 2016, 6:56:33 AM11/26/16
to
And here's an example of the problem faced by a relatively small company
who went the NETBEUI route, with that protocol no longer being available
with Windows 7:

<http://www.theregister.co.uk/2014/04/02/the_mathematics_of_trust/>

--- start quote ---
This machine shop is family owned and operated. There are three owners
with maybe 15 people working there during peak season. They turn over
about $1m a year. Much of their equipment was bought in the late 1990s
and is perfectly serviceable today. Equipment like CnC lathes that can
only accept jobs from networked PCs running NetBEUI.

The companies that manufactured the equipment no longer exist. There is
nobody to rewrite the code in that lathe. The machinists running the
shop certainly don't know how to do it, and a forklift upgrade of all
their gear would cost $7m.
--- end quote ---

Methinks that the figures could be substantially larger for customers
who went the DEC/Omni and DEC/OSAP route.

> It might be nice if there was a reasonably recent SPD
> for OMNI/OSAP readily accessible.

Indeed.

--
tar: Cowardly refusing to create an empty archive

Kerry Main

unread,
Nov 26, 2016, 8:20:07 AM11/26/16
to comp.os.vms to email gateway
> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Dirk Munk via Info-vax
> Sent: 26-Nov-16 3:53 AM
> To: info...@rbnsn.com
> Cc: Dirk Munk <mu...@home.nl>
> Subject: Re: [Info-vax] DECnet Phase IV and VMS code comments
>
[snip..]

Regardless of the company logo, my experience (including often
working closely with CSSE - WW interface for DEC Field Services
to Engineering) with the culture in OpenVMS engineering was/is
that security was always a top priority. If the issue was OpenVMS
related, I highly doubt the statement "the security issue is
their problem" ever came up.

Re: DECnet Phase IV - Hindsight is always 20-20.

However, it's fair to say that those who developed a new
networking architecture 35+ years ago (when the design started -
not when it was released) had no idea of the chaotic world
networks would evolve into today.

In a similar vein, what will the folks in the year 2050 think of
our discussions today on our "next gen" protocol - IPV6?

:-)

johnwa...@yahoo.co.uk

unread,
Nov 26, 2016, 8:49:46 AM11/26/16
to
Indeed, thanks for the article/link. I'd forgotten it
and the associated mass of comments.


Fortunately there may be a bit of a difference between
a half baked PC-centric here today gone tomorrow setup
in a Mom and Pop machine shop (no disrespect to them,
they're the victims here) with a home brewed
application on top, and some standardised multi-vendor
enterprise-class protocols that in 2018 will have been
around (largely invisibly and largely unchanged) for
thirty years or so.

Swap devices or applications and (in principle) the
other end remains largely the same.

In that time they have been supported (perhaps
reluctantly at times) by 'expensive' vendors like DEC,
Siemens, and GE (or their successors).

The price of investment protection, it used to be
called.

Some 'modern' IT emperors still want to replace the
whole 'estate' every two to four years (god knows why,
these days) but other organisations may have different
priorities. Their only constant seems to be the box
vendor and the OS vendor (god knows why, these days).

I'll get me coat. It's the one with the "We're putting
Maynard on the MAP" badge(button?) on it (vintage 1985
or so).

Dirk Munk

unread,
Nov 27, 2016, 6:01:48 AM11/27/16
to
I get your point, but if it would have meant a complete rewrite of the
stack, or even changes in the protocol itself, then maybe it was another
matter.

Johnny Billquist

unread,
Nov 27, 2016, 8:18:28 AM11/27/16
to
On 2016-11-25 19:38, johnwa...@yahoo.co.uk wrote:
> On Friday, 25 November 2016 14:12:13 UTC, Johnny Billquist wrote:
>> On 2016-11-25 10:21, Dirk Munk wrote:
>>> My question is, why are you interested in this very old protocol? DECnet
>>> Phase V was designed for let's say an OSI Internet, so I'm sure it's
>>> beter designed in this respect. Before some one else tries to point it
>>> out, yes I know it doesn't have encryption when used with the OSI
>>> transport layers. It could have been done, and it still can be done
>>> using TLS, that has been designed for the OSI transport layer. I'm sure
>>> VSI will look into this :-)
>>
>> We've been over this before. I very much disagree, and I seriously doubt
>> VSI will put any work into Phase V, and I believe the comments from
>> others here pretty much agreed with that.
>>
>> You seem to be just about the only person who haven't got it that OSI is
>> dead, and so is Phase V. (And it's an ugly corpse, and trying to revive
>> it would not make it any prettier...)
>>
>> Johnny
>
> Your opinion on whether Phase V is important or not is less
> important than the $$$ from the customers who may be
> interested in the continued support of OSI stuff.

My opinions are just that - opinions. I do not work for VSI, nor
represent them, so obviously what I say cannot in any way be construed
as the VSI position on anything.

> Money talks, as DaveF, who doesn't get out much,
> already pointed out (and indeed as you eventually
> acknowledged yourself).

Yeah, "eventually", as in the next reply right after he pointed out that
if someone wants to pay, obviously VSI would not have any problems
working on anything.

I'm sure that VSI will not intentionally break any existing products
without a good reason. So it's a good guess that any existing Phase V
stuff might continue to work, unless there is some serious problems
interfacing it to the new TCP/IP product.

But anything beyond that - I seriously doubt it will get any money.

Time will tell.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Simon Clubley

unread,
Nov 27, 2016, 10:15:22 PM11/27/16
to
On 2016-11-25, Johnny Billquist <b...@softjar.se> wrote:
>
> While you have some half points in here, I feel that this is making more
> out of it than is meaningful.
>
> I can just as easily also pollute the ARP table of any IPv4 host. There
> is no checking of the authenticity of an ARP packet, and if can cause
> traffic to suddenly be redirected elsewhere for all IPv4 traffic you are
> sending out.
>
> I can also easily pollute the routing table of many IPv4 hosts by
> sending bogus RIP packets. There is no authenticity there either. The
> data is just processed, and acted upon.
>
> I fail to see that DECnet have any more problems than IP here. The big
> issue is cleartext usernames and passwords. Something IP protocols also
> have, but in IP those protocols are now considered security problems.
>
> What you have found is that the routing table in DECnet can be
> subverted. I'd consider that very much to be the same kind of problem as
> ARP and RIP in IP.
>

I would say that's an accurate summary with the addition that DECnet
running on a target host trusts information provided by an external
host that is pretending to be the target host.

This also includes a lack of origin address checking by the routing
layer when it's processing LDP messages containing actual NSP data
(although as you pointed out, even though the Connect Init message
will make it's way to the target object and be processed, the connection
will never be fully completed and will eventually timeout).

Anyway, my exploration of DECnet is at an end; I'm currently having
a look at an unrelated part of VMS.

Simon Clubley

unread,
Nov 27, 2016, 10:18:12 PM11/27/16
to
On 2016-11-26, Dirk Munk <mu...@home.nl> wrote:
> Why don't you do a similar check with Phase V, in Phase IV compatibility
> mode, and in non-compatibility mode.

That would require me to get up to speed on how DECnet Phase V works.
My total experience in that area is about 1/2 day's exploration about
a couple of decades ago and I have _never_ touched DECnet Phase V since.

Anyway, I've found a new part of VMS to look at. :-)

Simon Clubley

unread,
Nov 27, 2016, 10:32:22 PM11/27/16
to
On 2016-11-26, Kerry Main <kemain...@gmail.com> wrote:
>
> [snip..]
>
> Regardless of the company logo, my experience (including often
> working closely with CSSE - WW interface for DEC Field Services
> to Engineering) with the culture in OpenVMS engineering was/is
> that security was always a top priority. If the issue was OpenVMS
> related, I highly doubt the statement "the security issue is
> their problem" ever came up.
>

The problem Kerry is that VSI still seem to be stuck in the old
mindset of how things were done in the old days of the 1980s/1990s
and don't seem to have adapted to how security issues are handled
in today's environment.

A really simple example: VSI _still_ didn't have a secure security
vulnerability reporting mechanism established the last time I checked
their website; they seem to be completely dismissing the possibility
that security issues may be reported by unrelated third parties who
may expect things to be done in a certain industry established way.

Another example; Do VSI have any plans in place to do coordinated
releases of patches with HP if a security vulnerability is found which
requires a patch to be created and released ? This coordination is
absolutely standard these days, but I've yet to hear VSI say anything
about this.

> Re: DECnet Phase IV - Hindsight is always 20-20.
>
> However, it's fair to say that those who developed a new
> networking architecture 35+ years ago (when the design started -
> not when it was released) had no idea of the chaotic world
> networks would evolve into today.
>

It's not really to do with hindsight - IP and friends have also had
to adapt to the changing security world as well, both in terms of
protocol changes and in terms of changes to the various code bases.

The question you should be asking is: is there anything in DECnet
Phase IV (or the other DEC network protocols) which require similar
changes and have those changes been implemented over the years or not ?

David Froble

unread,
Nov 28, 2016, 2:26:51 AM11/28/16
to
Simon Clubley wrote:
> On 2016-11-26, Kerry Main <kemain...@gmail.com> wrote:
>> [snip..]
>>
>> Regardless of the company logo, my experience (including often
>> working closely with CSSE - WW interface for DEC Field Services
>> to Engineering) with the culture in OpenVMS engineering was/is
>> that security was always a top priority. If the issue was OpenVMS
>> related, I highly doubt the statement "the security issue is
>> their problem" ever came up.
>>
>
> The problem Kerry is that VSI still seem to be stuck in the old
> mindset of how things were done in the old days of the 1980s/1990s
> and don't seem to have adapted to how security issues are handled
> in today's environment.

I think what Kerry has stated is that DEC never took security lightly. No, they
didn't see problems back then that are seen today. But if DEC was still around
today, it's my guess they would be above average in being aware of security.

As for VSI, you have no idea what they will be doing in the future, and they are
too new and small to have already done everything everyone is expecting. Now,
if you have some things you want them to concentrate upon, well, I think it's
been well stated that takes approaching them with some cash ....

> A really simple example: VSI _still_ didn't have a secure security
> vulnerability reporting mechanism established the last time I checked
> their website; they seem to be completely dismissing the possibility
> that security issues may be reported by unrelated third parties who
> may expect things to be done in a certain industry established way.

Ya know, before you mentioned it, I was unaware that "security researcher" was a
profession. I'm still a bit skeptical. "Industry established way", hmmm,
another declaration of standards I'm unaware of. Guess I REALLY don't get out
much ....


> Another example; Do VSI have any plans in place to do coordinated
> releases of patches with HP if a security vulnerability is found which
> requires a patch to be created and released ? This coordination is
> absolutely standard these days, but I've yet to hear VSI say anything
> about this.

What's standard for VSI is whatever they say is standard for VSI.

>> Re: DECnet Phase IV - Hindsight is always 20-20.
>>
>> However, it's fair to say that those who developed a new
>> networking architecture 35+ years ago (when the design started -
>> not when it was released) had no idea of the chaotic world
>> networks would evolve into today.
>>
>
> It's not really to do with hindsight - IP and friends have also had
> to adapt to the changing security world as well, both in terms of
> protocol changes and in terms of changes to the various code bases.
>
> The question you should be asking is: is there anything in DECnet
> Phase IV (or the other DEC network protocols) which require similar
> changes and have those changes been implemented over the years or not ?

As a product, DECnet is no longer being developed. If some can make use of it,
as it is now, fine, but, don't expect anything new. Or, approach VSI with some
cash.

Kerry Main

unread,
Nov 28, 2016, 8:00:04 AM11/28/16
to comp.os.vms to email gateway
> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Simon Clubley via Info-vax
> Sent: 27-Nov-16 10:31 PM
> To: info...@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-
> Earth.UFP>
> Subject: Re: [Info-vax] DECnet Phase IV and VMS code comments
>
Given VSI is already coordinating regular and ongoing patches
with HPE, why would coordinating security patches be any
different?

I can logon to the HPE patch system or VSI and get the same
patches.

> > Re: DECnet Phase IV - Hindsight is always 20-20.
> >
> > However, it's fair to say that those who developed a new
> networking
> > architecture 35+ years ago (when the design started - not
when
> it was
> > released) had no idea of the chaotic world networks would
> evolve into
> > today.
> >
>
> It's not really to do with hindsight - IP and friends have also
had to
> adapt to the changing security world as well, both in terms of
> protocol changes and in terms of changes to the various code
> bases.
>
> The question you should be asking is: is there anything in
DECnet
> Phase IV (or the other DEC network protocols) which require
> similar changes and have those changes been implemented over
> the years or not ?
>
> Simon.
>

Asking that question about DECnet Ph IV is like asking Microsoft
to keep NetBEUI current with today's TCPIP standards.

Imho, much as it has a place in some current environments, DECnet
is no longer a strategic technology. That does not mean it will
not receive any basic maint to keep up with OS changes, but do
not expect any new wiz bang enhancements without some Customer
stepping up to pay for them.

In a decade or two, perhaps this will change, but as we all know,
TCPIP is the way forward for now, so that is what VSI is doing
with the new standards based TCPIP stack.

If a security issue came up that was specific to DECnet, then
based on past experiences, VSI would address it.

Simon Clubley

unread,
Nov 28, 2016, 8:58:01 AM11/28/16
to
On 2016-11-28, Kerry Main <kemain...@gmail.com> wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
>> Of Simon Clubley via Info-vax
>> Sent: 27-Nov-16 10:31 PM
>> To: info...@rbnsn.com
>> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-
>> Earth.UFP>
>> Subject: Re: [Info-vax] DECnet Phase IV and VMS code comments
>>
>> Another example; Do VSI have any plans in place to do
>> coordinated releases of patches with HP if a security
> vulnerability
>> is found which requires a patch to be created and released ?
> This
>> coordination is absolutely standard these days, but I've yet to
>> hear VSI say anything about this.
>>
>
> Given VSI is already coordinating regular and ongoing patches
> with HPE, why would coordinating security patches be any
> different?
>
> I can logon to the HPE patch system or VSI and get the same
> patches.
>

Since I am no longer a HP support contract customer I was not
aware of this as I have not seen any public mention of this.

This is excellent news and is one thing that VSI have got right.

Simon Clubley

unread,
Nov 28, 2016, 9:04:29 AM11/28/16
to
On 2016-11-28, David Froble <da...@tsoft-inc.com> wrote:
> Simon Clubley wrote:
>> A really simple example: VSI _still_ didn't have a secure security
>> vulnerability reporting mechanism established the last time I checked
>> their website; they seem to be completely dismissing the possibility
>> that security issues may be reported by unrelated third parties who
>> may expect things to be done in a certain industry established way.
>
> Ya know, before you mentioned it, I was unaware that "security researcher" was a
> profession. I'm still a bit skeptical. "Industry established way", hmmm,
> another declaration of standards I'm unaware of. Guess I REALLY don't get out
> much ....
>

You _really_ need to get out more David. :-)

Google for "responsible disclosure" and do some reading; the world is
very different from the way that you appear to perceive it to be.

Basically, the security researcher tells the vendor via a secure
mechanism that the vendor has a problem and typically gives the
vendor around 60 days to fix it before the problem, including exploit
details, is made public.

That's the standard in today's world.

Robert A. Brooks

unread,
Nov 28, 2016, 1:27:50 PM11/28/16
to
On 11/26/2016 4:59 AM, johnwa...@yahoo.co.uk wrote:
> On Saturday, 26 November 2016 02:58:10 UTC, Robert A. Brooks wrote:

>> I suspect the code has not changed much in the past decade; what
>> would you like to know about OMNI and/or OSAP?

> When I last touched OMNI/OSAP and the correspoding automation
> kit, it was a decade and a half ago; apologies for any errors
> in my memory.

[...]

> Back in those days, an OSI transport (for OSAP) and an full 7
> layer OSI network (for OMNI) were required. Not because DEC
> evangelists wanted people to use them, but because that's what
> the automation equipment in the picture was using.

[...]

I'm in the process of getting the OMNI/OSAP code from HPE; once
I've gotten familiar with it, and can build it, I'll try to provide
some answers. May take a few weeks . . .

--

-- Rob

David Froble

unread,
Nov 28, 2016, 1:47:08 PM11/28/16
to
Simon Clubley wrote:
> On 2016-11-28, David Froble <da...@tsoft-inc.com> wrote:
>> Simon Clubley wrote:
>>> A really simple example: VSI _still_ didn't have a secure security
>>> vulnerability reporting mechanism established the last time I checked
>>> their website; they seem to be completely dismissing the possibility
>>> that security issues may be reported by unrelated third parties who
>>> may expect things to be done in a certain industry established way.
>> Ya know, before you mentioned it, I was unaware that "security researcher" was a
>> profession. I'm still a bit skeptical. "Industry established way", hmmm,
>> another declaration of standards I'm unaware of. Guess I REALLY don't get out
>> much ....
>>
>
> You _really_ need to get out more David. :-)
>
> Google for "responsible disclosure" and do some reading; the world is
> very different from the way that you appear to perceive it to be.

My perceptions are my reality ....

:-)

Stephen Hoffman

unread,
Nov 28, 2016, 6:17:17 PM11/28/16
to
On 2016-11-28 12:56:04 +0000, Kerry Main said:

> Given VSI is already coordinating regular and ongoing patches with HPE,
> why would coordinating security patches be any different?

That statement could be inferred to indicate some confusion over what
Simon is referencing with that particular terminology. Coordinated or
responsible disclosure arises among the reporting party, the vendor,
the users and parties — such as the relationship between VSI and HPE —
with other parties. Given the market Stark is aiming for, this is an
area you will want to become more familiar with, if you've not already
looked into it. Potentially including bug bounties, which is a method
for a vendor to try to set the pricing floor for security bugs.

https://technet.microsoft.com/en-us/security/dn467923
https://en.wikipedia.org/wiki/Responsible_disclosure
https://en.wikipedia.org/wiki/Full_disclosure_%28computer_security%29
https://blog.osvdb.org/tag/k8emo/ (old)

Given where you're headed with Stark, you may well want to look into
these policies and practices, as well as the issues around creating and
testing and deploying the patches, both in your servers as well as in
any remote software you might provide or document or interoperate with.
These are usual sorts of issues that arise, obviously.

> If a security issue came up that was specific to DECnet, then based on
> past experiences, VSI would address it.

Discussing and debating DECnet security is roughly equivalent to
discussing that of telnet or FTP. Barring recreating a DESNC-like
solution or using stunnel or similar shenanigans or otherwise involving
traffic via port 399, DECnet, telnet and FTP are not secure, and won't
ever be.

As for security and network vulnerabilities, VSI has been aware of at
least one, and for over a year. Less effort than finding a "new" bug,
it's trivial to locate lists of dozens existing bug reports that likely
or do apply to OpenVMS and go digging into those. I have a list of
several dozen that likely do apply to network-facing products and
components associated with OpenVMS and several of which I've reproduced
against OpenVMS, and I've not made a particular effort.



--
Pure Personal Opinion | HoffmanLabs LLC

Kerry Main

unread,
Nov 28, 2016, 8:05:03 PM11/28/16
to comp.os.vms to email gateway
> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 28-Nov-16 6:17 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] DECnet Phase IV and VMS code comments
>
I don't think anyone here views 35+ year old DECnet as a strategic network product.

Having stated this, there is some basic maint support provided by both HPE/VSI which in itself, is pretty impressive.

> As for security and network vulnerabilities, VSI has been aware of
> at
> least one, and for over a year. Less effort than finding a "new"
> bug,
> it's trivial to locate lists of dozens existing bug reports that likely
> or do apply to OpenVMS and go digging into those. I have a list
> of
> several dozen that likely do apply to network-facing products and
> components associated with OpenVMS and several of which I've
> reproduced against OpenVMS, and I've not made a particular
> effort.
>

I am certainly not in any position to speak for either VSI or HPE, so I will have to assume that you documented the network issue for one of them and it is under investigation.

For the benefits of others, the HPE security site is at:
http://www8.hp.com/us/en/business-services/it-services/security-vulnerability.html

Security Reporting:
https://www.hpe.com/h41268/live/index_e.aspx?qid=11503

No one should ever be under the impression that ANY OS platform (incl OpenVMS) is security bug free.

There will always be the next bug looming around the next corner.

Simon Clubley

unread,
Nov 29, 2016, 8:26:20 AM11/29/16
to
On 2016-11-28, Kerry Main <kemain...@gmail.com> wrote:
>
> I don't think anyone here views 35+ year old DECnet as a strategic network
> product.
>

Once again Kerry, I don't care about the protocol itself; it's obsolete
and insecure. I only care about the fact that it's still available and
enabled on VMS systems running today.

Here's an example of why this matters (from over a decade ago):

https://technet.microsoft.com/en-us/library/security/ms02-027.aspx

The Gopher protocol was also obsolete by the time the above vulnerability
was discovered but it was still enabled in the products in question and
allowed the systems in question to be compromised.

>
> I am certainly not in any position to speak for either VSI or HPE, so I will have to assume that you documented the network issue for one of them and it is under investigation.
>
> For the benefits of others, the HPE security site is at:
> http://www8.hp.com/us/en/business-services/it-services/security-vulnerability.html
>
> Security Reporting:
> https://www.hpe.com/h41268/live/index_e.aspx?qid=11503
>

It's a pity that you couldn't list VSI's secure security reporting
webpage alongside the HP one above.

Stephen Hoffman

unread,
Nov 29, 2016, 10:08:21 AM11/29/16
to
On 2016-11-29 13:25:01 +0000, Simon Clubley said:

> On 2016-11-28, Kerry Main <kemain...@gmail.com> wrote:
>>
>> I don't think anyone here views 35+ year old DECnet as a strategic
>> network product.
>
> ...I only care about the fact that it's still available and enabled on
> VMS systems running today...

Which is why I'd prefer to see telnet, FTP, DECnet and other giblets
with explicit security warnings and requiring the system manager to
override those to enable the mechanisms. Or entirely removed, and an
extra-cost add on.

In short, far less DECnet integration with OpenVMS. Vastly better IP
integration. TLS and certificate integration, too. It's long past
time to update what was started with OpenVMS V6.2.

Keeping utterly broken designs and interfaces around and accessible
"for compatibility" is short-sighted and hazardous, at best. But then
I'm being polite. Customers will always want to avoid making changes,
but they can and do need to make at least some. Customers — most of
them — aren't experts in this sort of stuff, and what is available is
hard to use, variously not used, and is poorly integrated. Even
within OpenVMS itself. Which is why we still see configurations where
DECnet, telnet and FTP are commonly used, if not the primary network
transports... Which means folks can get shellacked — and do, and have
gotten shellacked, and without attackers bothering to use ROP or
needing to bypass ASLR or otherwise...

clairg...@gmail.com

unread,
Nov 29, 2016, 10:08:29 AM11/29/16
to
On Tuesday, November 29, 2016 at 8:26:20 AM UTC-5, Simon Clubley wrote:
> On 2016-11-28, Kerry Main <kemain...@gmail.com> wrote:
> >
> > I don't think anyone here views 35+ year old DECnet as a strategic network
> > product.
> >
>
> Once again Kerry, I don't care about the protocol itself; it's obsolete
> and insecure. I only care about the fact that it's still available and
> enabled on VMS systems running today.
>
> Here's an example of why this matters (from over a decade ago):
>
> https://technet.microsoft.com/en-us/library/security/ms02-027.aspx
>
> The Gopher protocol was also obsolete by the time the above vulnerability
> was discovered but it was still enabled in the products in question and
> allowed the systems in question to be compromised.
>
> >
> > I am certainly not in any position to speak for either VSI or HPE, so I will have to assume that you documented the network issue for one of them and it is under investigation.
> >
> > For the benefits of others, the HPE security site is at:
> > http://www8.hp.com/us/en/business-services/it-services/security-vulnerability.html
> >
> > Security Reporting:
> > https://www.hpe.com/h41268/live/index_e.aspx?qid=11503
> >
>
> It's a pity that you couldn't list VSI's secure security reporting
> webpage alongside the HP one above.

Agree. It is still in the to-do queue. We have a ton of things to do but this one has a high priority. I'm hoping we will have something on the website by the end of the month.

Simon Clubley

unread,
Nov 29, 2016, 1:36:05 PM11/29/16
to
That's excellent news Clair, thanks.

Like I said previously, I hope it won't be needed all that often :-),
but when it is needed, then it's going to be _really_ needed.

Thanks,

David Froble

unread,
Nov 29, 2016, 2:24:38 PM11/29/16
to
I agree about doing better today. However, I'm a bit aware that there are
people using VMS for things that I've never imagined. For example, John Wallace
has mentioned factory controls that use the OSI stuff, (I seem to recall), and
therefore doing away with DECnet V might push such people away from VMS. I'll
bet there are more such instances.

That written, today there just isn't much use for DECnet, and there is a use for
IP, an IP that supports all (or most) of the DECnet utilities. As you've
suggested, tie the stuff tightly to the OS, and make it easy to use, and include
security.

So, if any work is to be done in this direction, much better to allocate the
resources to implementing the DECnet utilities that are useful using IP.

Stephen Hoffman

unread,
Nov 29, 2016, 7:06:17 PM11/29/16
to
Sure. Platform vendors are faced with these sorts of decisions.
Protect the installed base and applications entirely, or provide
extensive compatibility and force some specific application changes
where specifically necessary, or overhaul the platform and watch more
than a few folks migrate elsewhere. But the seemingly-safest approach
— rote upward-compatibility — means the vendor cannot fix actual latent
problems, and new system APIs and designs only get worse and
progressively more convoluted and more complex and more costly to
implement and deploy.

The lattermost choice — rewriting everything — is a non-starter for
many cases, or a nervy and rather longer-term business play. Work
such as HPE and The Machine lurks here, assuming it ships and meets or
exceeds expectations and can be adopted by enough folks. But — much
like the existing Bliss, Macro32 and C source code continues to exist
within OpenVMS — I just don't see OpenVMS development performing this
sort of a rewrite, or requiring extensive customer rewrites. Nor most
any other large software platform or major application, for that matter.

Which leaves the middle path of the three — forcing targeted upgrades
of applications using problematic interfaces and approaches, as — when
correctly managed and when the reasons and benefits for the changes are
clearly communicated — the cost of that remains lower than porting the
applications elsewhere. No amount of compatibility can fix
fundamentally broken or insecure interfaces. Preferably these changes
with a migration path to the newer APIs or transports or mechanisms, a
migration plan and window and deprecation plans, and the necessity and
the accrual of defined benefits for the effort involved.

Costly? 64-bit addressing is an impressive and upward-compatible
design, but writing new native 64-bit applications increasingly reminds
me of working on RSX-11M with its memory addressing shenanigans.
Flat address spaces are what made VAX so much nicer than PDP-11, after
all. This sort of complexity means more costs for everybody, when
you're forced to work within these upward-compatible designs, or when
you're faced with APIs and mechanisms which are known to be problematic
or insecure — the password hash, the use of MD5, etc — that are still
around for compatibility.

I don't like changing my application code. None of us do, after all.
But it's sometimes necessary.

This is a form of the game of "chicken". Making changes necessary to
better secure or to simplify or otherwise improve the system or the
platform, trading off the risks the loss of some customers that might
choose not to follow your changes, as compared with the folks that
might want or need the changes. Now if you aren't planning to try to
expand the installed base and the folks are mostly-happy with what they
have, then this whole discussion gets a whole lot easier. But some
number of folks have or find reasons to port. Which means the
long-term revenue trends just aren't in a good direction. Which can
make some of the current customers... nervous, too. Running a
business, there's no single right answer. Lots of wrong ones, though.

> That written, today there just isn't much use for DECnet, and there is
> a use for IP, an IP that supports all (or most) of the DECnet
> utilities. As you've suggested, tie the stuff tightly to the OS, and
> make it easy to use, and include security.
>
> So, if any work is to be done in this direction, much better to
> allocate the resources to implementing the DECnet utilities that are
> useful using IP.

Ayup. Which is part of why I've been having difficulty wrapping my
head around the EDT work, too.

Robert A. Brooks

unread,
Nov 29, 2016, 8:19:25 PM11/29/16
to
Sometimes, it's nice to do things just for fun on your own time.

Imagine that -- fun!

--
-- Rob

Michael Moroney

unread,
Nov 29, 2016, 11:43:58 PM11/29/16
to
Who would have thought taking a break from one nagging problem, a weird
mood, some caffeine and another nagging problem that needed dealing
with could be fun!

Scott Dorsey

unread,
Dec 3, 2016, 10:22:19 AM12/3/16
to
David Froble <da...@tsoft-inc.com> wrote:
>I think what Kerry has stated is that DEC never took security lightly. No, they
>didn't see problems back then that are seen today. But if DEC was still around
>today, it's my guess they would be above average in being aware of security.

Then why did they ship so many machines with the field accounts enabled?
You can't believe the number of machines I saw at customer sites where you
could just walk in (or dial in) and log in as field.

>As for VSI, you have no idea what they will be doing in the future, and they are
>too new and small to have already done everything everyone is expecting. Now,
>if you have some things you want them to concentrate upon, well, I think it's
>been well stated that takes approaching them with some cash ....

Granted. However, accepting SPRs isn't very expensive. Dealing with them
can be, but setting up a procedure to get bug reports from as many sources
as possible is part of making a better quality product.

I remember working for some folks who had bought an HP150 microcomputer,
a thing that ran MS-DOS but was totally incompatible with the PC. I had
found a problem with the software provided and had written a fix for it,
but when I called HP I was told that I couldn't submit any bug reports
without paying money for support. In essence, they wanted me to pay money
to tell them how to fix their broken product. That experience kept me from
buying anything from HP for many many years.

(And mind you the whole garbage with the HP Gen 9 servers not allowing use
of disks that weren't purchased through HP makes me suspect that a lot of
that attitude still remains at HP.)

>> A really simple example: VSI _still_ didn't have a secure security
>> vulnerability reporting mechanism established the last time I checked
>> their website; they seem to be completely dismissing the possibility
>> that security issues may be reported by unrelated third parties who
>> may expect things to be done in a certain industry established way.
>
>Ya know, before you mentioned it, I was unaware that "security researcher" was a
>profession. I'm still a bit skeptical. "Industry established way", hmmm,
>another declaration of standards I'm unaware of. Guess I REALLY don't get out
>much ....

And the mechanism doesn't need to be anything too sophisticated, just an
email address and someone to read it is sufficient. You do need to have
someone reading it... I have seen too many cases where a bug was reported
to a vendor, it was ignored, and then they exploded a few weeks later when
it was reported to the general public.

>> Another example; Do VSI have any plans in place to do coordinated
>> releases of patches with HP if a security vulnerability is found which
>> requires a patch to be created and released ? This coordination is
>> absolutely standard these days, but I've yet to hear VSI say anything
>> about this.
>
>What's standard for VSI is whatever they say is standard for VSI.

And that's the question. Actual urgent security patches should be a rare
thing, but they happen sometimes, and there needs to be a mechanism in place
to get them out there.

In the case of VSI/HP it gets interesting when you get into problems that
lie on the hardware/software boundary. "There's a bug in the IPMI processor
that is an HP bug, but if you're running VMS you will need to run this
program to update the firmware." Is that something HP handles or VSI?

>As a product, DECnet is no longer being developed. If some can make use of it,
>as it is now, fine, but, don't expect anything new. Or, approach VSI with some
>cash.

That seems a fair approach to the situation, although it would be nice to
have some extensions soon that provide decnet functionality with decnet syntax
over ip. It'll happen. It's not urgent because decnet users will have decnet
in the meantime, but the world has changed since decnet was new.
--scott


--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Dirk Munk

unread,
Dec 3, 2016, 1:27:00 PM12/3/16
to
What do you mean with DECnet functionality with DECnet syntax over IP?
Is that meant for VMS <> VMS communication? If so then you've had it for
ages, it's called DECnet Phase V over IP. Standard DECnet functionality
with IP as transport.

0 new messages