[Info-vax] Still no IPSEC for TCP/IP services?

[Dirk Munk]

Doug Phillips wrote:
> On May 22, 1:11 pm, Dirk Munk<m... at home.nl>  wrote:
>> Doug Phillips wrote:
>>> On May 22, 2:23 am, Dirk Munk<m... at home.nl>    wrote:
>>>> Steven Underwood wrote:
>>
>>>>> "Dirk Munk" wrote in message
>>>>> news:4797c$4fbac358$5ed43999$22551 at cache60.multikabel.net...
>>
>>>>>> I'm planning to set up a couple of new OpenVMS systems, and I was
>>>>>> thinking of using IPSEC as well. I was amazed to find that IPSEC is
>>>>>> not included in the present version of TCP/IP services. It was
>>>>>> included in the Early Adopters Kit for TCP/IP services 5.7 in 2007
>>>>>> (!!!!), but it never made it to the final version and wasn't added
>>>>>> later on.
>>
>>>>>> As far as I know IPSEC is a mandatory part of IPv6, so the IPv6 stack
>>>>>> of TCP/IP services isn't complete either. It may well be that there is
>>>>>> more modern functionality missing in the IPv6 stack
>>
>>>>>> Does any one know what happened, why was HP not capable of producing a
>>>>>> full functional IPSEC stack in 5 years time? Even Windows Vista has
>>>>>> IPSEC........
>>
>>>>> Dirk: The EAK is still the only version of IPSEC as far as I have heard.
>>>>> There are very few people (one other, really) asking for it. Your
>>>>> arguments mirror his.
>>
>>>>> I personally have no use for IPSEC or IPv6 on VMS or not. That also
>>>>> seems to be the general consensus I seen here toward IPv6 and IPSEC on VMS.
>>
>>>>> Steven Underwood
>>
>>>> Thanks Steve.
>>
>>>> I never liked IP anyway. It seems to be one enormous hobby project where
>>>> lots of people and groups are producing solutions for many different
>>>> problems without any conceptional thinking. The result is mountains of
>>>> RFC's
>>
>>>> Encryption is a prime example. If you want to keep your data
>>>> communication secret then you will need encryption. But if you want to
>>>> encrypt your data transport between two nodes, then it looks obvious to
>>>> me that you should want to encrypt all data, and IPSEC does just that
>>>> for IP traffic.
>>
>>> I understand why HP wouldn't spend $$$$$$$ to develop something that
>>> can be had for $$. Moving data between two nodes via the internet
>>> requires an appliance at each end, so the connection is not node-to-
>>> node, it's appliance-to-appliance. Any of the appliances I would
>>> consider using for any full-time secure connection have IPsec built-
>>> in.
>>
>>> For some-time/part-time connections, SSL works just fine and is soooo
>>> much easier to manage.
>>
>> Interesting. So you don't believe in the 7-layer OSI model? I do, and
>> even if IP is not set up according to this model, and encryption is no
>> part of this model (AFAIK), I'm sure that encryption should be part of
>> the lower layers of this model, and should not be implemented in the
>> higher layers if possible.
>
> How are your nodes connected to the internet? Enterprise class devices
> that I know of come with IPsec and are made to do exactly what you're
> asking: securely connect sites by encrypting data at the OSI Internet
> Layer (i.e., they use IPsec).

It is not just for servers connected to the internet. Many large 
organizations demand encryption within their own network. In these 
organizations the network stuff is usually done by another group of 
people which means that setting up an encrypted connection would involve 
quite a lot of people. Believe me, you don't want to do that if possible.

>
> What do your mobile or off-site users need to do? All off-site users
> don't need IPsec, but, the last I looked an IPsec capable Home&  SB
> router can be bought for $100 - $200 or less. SSL, if you haven't
> looked lately, is gaining capability.  Do you need IPsec protecting
> your server from your intranet? Buy an inexpensive appliance that's
> made to do that. One benefit: no CPU cycles will be used.

The CPU cycles argument is an interesting point. IPsec works directly on 
IP, so it is situated between IP and the higher layers like TCP and UDP. 
All high end NICs have a TCP offload engine, and that would mean that 
the NIC should do the IPsec work as well. Sending the received data from 
IP to the IPsec layer in software and then back to the NIC for the TCP 
offload engine is rather silly. The alternative is that TCP and iSCSI 
are not handled by the NIC but instead by the TCP/IP stack of the system.

>
> Why spend millions (or even thousands) to develop something that
> competes with a relatively inexpensive appliance?

It has been developed, it just has to be finished and released.