Tom,
> 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.
Your explanation of IPSEC is incorrect. There are indeed two modes of
IPSEC operation: transport mode and tunnel mode. However, the
bump-in-the-wire and the bump-in-the-stack notions have to do with how
and where IPSEC is implemented in a system - not how IPSEC operates
with respect to layering. IPSEC consists of two protocols - AH
(authentication header) and ESP (encapsulating security protocol). In
their simplest, purest forms AH provides only message integrity while
ESP provides confidentiality (aka, encryption). However, there are
also ways to use ESP for both confidentiality and integrity. ESP
always encrypts Layer 4 (TCP) and above.
In Transport Mode, at a high level, the end-system knows how to apply
IPSEC security mechanisms. Therefore, an emitted packet will have a
(clear text) IP header followed by an IPSEC header (e.g., AH, ESP),
followed by an encrypted payload consisting of the TCP header and the
user data.
Tunnel mode is used at a security gateway (e.g., an IPSEC firewall, a
guard device, a security controlled-interface, etc) where the packets
from an end-system that doesn't implement IPSEC are entirely
encapsulated into an IPSEC envelope. The security gateway emits a
packet that has a clear-text IP header (addressed to a peer security
gateway) followed by an IPSEC header, followed by an encrypted payload
consisting of the original packet's IP hdr, TCP hdr, and payload.
SSL (which, in the IETF is called TLS (transport layer security) only
encrypts the payload data since it operates in the application (above
TCP).
> 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 will *never* fly. IPSEC is moving to last call in the WG and
there is lots of pressure to move it to the IESG. The WG does not
want any last minute changes - especially ones that violate the
security premises on which IPSEC has been based! The whole idea
behind IPSEC security is to hide as much information from the casual
observer as is possible and to make unauthorized changing of any of the
information, without detection, as hard as possible. There was just
a proposal in the last two weeks to the IPSEC mailing list to move the
TCP port information into the clear so as to allow Internet management
systems that gather stats on the types of flows running across the
'net to continue to operate. It was seriously rejected by the WG
despite the understanding for flow stats.
Its incredulous to me that proposals are being made to *break* the
security protocol to allow a hacked up kludge that violates all of the
Internet to work end-to-end layering concepts to work. And just
remember, the IPSEC work has been in conception for 5 years, is
finally ready to pop out of the oven, and there is a pent up need for
such mechanisms (with lots of vendors itching to ship products).
Howie Weiss
--
___________________________________________________________________
| |
|Howard Weiss phone (410) 381-9400 x201 |
|SPARTA, Inc. (301) 621-8145 x201 (DC) |
|9861 Broken Land Parkway fax: (410) 381-5559 |
|Columbia, MD 21046 email: [email protected] |
|___________________________________________________________________|
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:38 EST