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