Tom,
The draft-ietf-ipsec-arch-sec-04.txt (Security Architecture
for IP) defines three _not_ two approaches to implementing IPSec. The
integration of IPsec into the native IP stack. A Bump-In-The-Stack
(BITS) (or packet shim) which seats underneath the native IP stack and
above the local drivers and, a Bump-in-the-Wire (BITW) which is a
crypto processor implementation (hardware). The document clearly
states that these three approaches apply to both hosts and security
gateways although some (for instance a BITS implementation) are
preferred for host implementations as opposed to security gateways
implementations and viceversa.
All IPSec compliant implementations MUST encrypt the interior
IP header when using the Encapsulating Security Payload (ESP) in
tunnel mode with most of the encryption transforms defined with the
exception of the null-encryption transform. Where in the stack one
implements IPSec has no implication on protocol behavior, as expected.
One can use the null-encryption transform end2end with
authentication in either tunnel or transport mode. THis will allow any
box en-route to "peak" at the content of the TCP header and payload
for that matter. However, one can not altered the content because in
doing so one will be altering the Integrity Check Value (ICV) hence,
authentication will fail. The same applies to the use of the
Authentication Header (AH) regardless if one applies it in Transport
or tunnel mode. It would seem that we all understand this.
Provided that an end host doesn't need to protect the privacy
of its traffic end2end, it is entirely feasible to perform TCP
Spoofing within your own private net since there is an implicit trust
between the "spoofing" box and the end host. However, if the end host
requires confidentiality end2end this will not work. Link encryption
that happens underneath a specific level of assurance is non-intrusive
(unless it is deteriorating the performance of the communication and
therefore could be considered a denial of service attack) and no
explicit trust is required between the end hosts and the link
encryption device. However, when end hosts require end2end traffic
confidentiality, what assurance does the end host have that the keying
material used to protect his/her traffic has not been compromised due
to either a poor key management system design or weak security
practices?
Luis
ps: There are several IPSec compliant implementations that
interoperate (please refer to the IPsec mailing list archive for the
full list). This includes your favorite firewall and router vendors.
> Let me first say that, while tweaking TCP to perform better in long BW-delay
> environments is certainly helpful, I believe that TCP spoofing/proxying will
> continue to outperform having satellite-optimized implementations at both ends, mainly because there are RTT-related problems (fairness, slow-start, timers)
> that spoofing overcomes much better.
>
> Regarding IP security and TCP spoofing, as I understand it, there will be two
> types of security deployed: security firewalls that encrypt and tunnel IP
> layer and above (so-called "bump-in-the-wire"), and host implementations that
> encrypt layer 4 and above ("bump-in-the-stack") but that leave the IP header
> unencrypted. I don't see much hope for TCP spoofing in the first case unless
> the gateway/proxy is part of the trust infrastructure. However, for
> direct-to-user satellite networks, if the TCP header were also left unencrypted
> in the host IPsec application, this would permit spoofing at a satellite
> gateway. Now of course SSL and other approaches could be used to provide a
> similar service for TCP connections, but what if IPsec catches on and
> customers demand IPsec? The security risks of this are probably not as great
> as one might assume because satellite networks will most likely run link
> encryption.
>
> So for those of you in the satellite community who value spoofing (in addition
> to other wireless network providers who would like to use transport-aware
> TCP enhancements), it seems to me that you ought to at least raise a serious
> discussion of a "TCP header unencrypted" option in the IPsec group, before
> vendors get too far down the implementation path.
>
> Tom Henderson
> UC Berkeley
>
>
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:38 EST