[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
transport vs network and ipsec syn
Subject: Re[2]: TO COMPRESS OR NOT TO CMPRS (please reply)
Author: Arthur Parkos at renpo
Date: 2/28/97 12:13 PM
i agree with your transport vs network security comments. i also agree that we
will see both forms of implementation for the particular situations that fit
them best.
one question (multipart), i was not sure how ipsec addresses the syn attack:
- it's not guaranteed that all connections will be attempted with ipsec
authentication instantiated. therefore a host will still need to respond to the
request for a connection. or will a host refuse all connect attempts from
non-ipsec host.
- if ipsec is implemented, the host will still need to perform an authentication
on the potential partner which would eat cpu cycles.
- if ipsec is there, the host receives the connect attempt and retrieves the
address, so what if it was signed. couldn't a bad entity sign fake ip addresses
and then send them on to a potential host to be attacked?
- when will the infrastructure be in place so that a host can authenticate a
connection attempt from the myriad potential connectees where certificates may
have been issued by different certificate authorities
______________________________ Reply Separator _________________________________
Subject: Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Author: Phil Karn <karn@qualcomm.com> at SMTPGWY
Date: 2/28/97 2:36 AM
>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
Follow-Ups: