Re: TO COMPRESS OR NOT TO CMPRS (please reply)

[Phil Karn <[e-mail]>]

>consumers -- want to conduct transactions over it. With a reasonable
>IPSec in place, SSL wouldn't have been necessary. SSL is used every

I used to say this too, but not any more. I now believe it's desirable
to have multiple, complementary architectural approaches to
security. SSL represents a transport layer approach while IPSEC
represents the network layer approach.  Each has its advantages and
disadvantages, and I suspect that each will find their niches.

Advantages of transport layer security (e.g., SSL, SSH):

1. Can operate on an end-to-end basis with existing TCP/IP stacks with
existing APIs (winsock, BSD sockets, streams, etc).  This is a VERY
important issue with turnkey object-only systems like Windows 95.

2. More efficient over slow speed links. VJ header compression still
works, and various congestion-control schemes that peek at TCP/IP
headers (e.g., my TCP ack-dropping scheme) still work.

3. No special problems with fragmentation, path MTU discovery, etc.

4. Compression combined with encryption at this layer is much more
effective than compression at the packet layer.

Advantages of network layer security (e.g., IPSEC)

1. Can support completely unmodified end systems, though in this case
encryption is no longer strictly end-to-end.

2. Particularly suitable for building virtual private networks across
untrusted networks.

3. Can support transport protocols other than TCP (e.g., UDP).

4. Hides the transport layer headers from eavesdropping, providing
somewhat greater protection against traffic analysis.

5. With AH and replay detection, protects against certain
denial-of-service attacks based on swamping (e.g., TCP SYN attacks).

I think it likely that IPSEC will find its niche in building virtual
private networks, while SSL and SSH (though they may merge) will
continue to be used for many end-to-end applications such as web
commerce, remote login, file transfer, etc.

Phil