[Info-vax] Kernel Transplantation

[Simon Clubley]

On 2024-01-10, Mark Berryman <mark at theberrymans.com> wrote:
> On 1/10/24 6:40 AM, Simon Clubley wrote:
>> On 2024-01-09, Lawrence D'Oliveiro <ldo at nz.invalid> wrote:
>>> On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
>>>
>>>> And again, what you are interested here in has been available for many
>>>> years via Sector 7.
>>>
>>> I?m not sure they did a comprehensive enough job. For instance, I remember
>>> the previous time this came up, reading between the lines in one of their
>>> case studies, the original customer scenario mentioned using DECnet, but
>>> that was missiong from the description of the solution.
>> 
>> DECnet should not be in use in today's security world and a customer
>> should have been forced away from using DECnet anyway due to external
>> auditing and security standards.
>> 
> .
> .
> .
>
> Hogwash.  DECnet can be made just as secure as any IP communication by 
> simply using IP transports.  A couple of simple examples:
>
> 1. Run DECnet phase V.  Use DECnet-over-IP, and encrypt it with IPSEC 
> before it ever leaves your host.  This not only encrypts all of your 
> DECnet traffic but it means that DECnet proxies are now as secure as 
> your IPSEC profile.
>
> 1a. If you are running OpenVMS on x86, TCP/IP Services does not 
> currently provide IPSEC and Multinet is not yet available.  However, 
> VMware ESXi does support IPSEC.  You can configure your ESXi host to do 
> the encryption for you.  You just need to do your DECnet-over-IP traffic 
> using IPv6.
>
> 2. Run DECnet phase IV.  Install pyDECnet on any host in your LAN that 
> supports python (I use a dedicated raspberry pi).  This will be your 
> DECnet router.  Isolate DECnet traffic to its own VLAN.  All off-LAN 
> DECnet traffic is encrypted by the pyDECnet host, again, likely using IPSEC.
>
> More security that this is possible.  If you have a security requirement 
> this doesn't meet, let me know.
>

I am amused and saddened that whenever I raise this issue, people immediately
assume that I am talking about MITM attacks only and address that only.

The fact is that MITM attacks are only a small part of the attack surface.
Far more common are attacks against the listening services themselves from
connections you initiate, not those you intercept.

For example, in 2) above, how does this address clients on an authorised
VLAN being able to send malformed packets to a server with an inappropriately
fully-privileged EVL listener that has a dodgy message parser built into it ?

TCP/IP (and its higher-level protocols) have been heavily probed and issues
are still being found. Goodness knows what a serious probing of DECnet will
reveal if I can find the following things with a quick probing:

https://groups.google.com/g/comp.os.vms/c/Bjp0hRkSnh4

I also find it amusing that whenever I raise this issue, there is nothing
in the DECnet world that protects data in motion and you all have to
suggest a protocol that came from the rival TCP/IP world instead. :-)

Simon.

PS: I wonder if, 2 years on, whether VSI has got around to fixing those
issues in DECnet Phase IV yet ?

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.