[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Proposal for IP Peer protocol




Paul, to continue this interesting (to me anyway :)) discussion, I was
wondering if there has been any thought about using TCP/IP header
compression with IPSEC tunnels?

Having a quick play with Van Jacobson on my ISDN link, I can reduce the PPP
payload for a single byte of telnet from 41bytes to approximately 10bytes.

If an IPCP-like negotiation could take place between hosts or between tunnel
end-points, then this could deliver the best return on throughput for ACKs
and telnet data:

IP2 ESP { IP1 TCP Data } ESP-auth-pad

For a TCP ACK, the payload inside ESP could be reduced by 75% (4:1). I don't
know what the theoretical maximum compression of VJ is, so this could be
more I guess with various PPP-like optimisation. 

I think this would be of particular use to client systems connecting over
remote-access VPN tunnels. As I understand it, it is less useful for UDP and
Web-page retrieval for different reasons.

Would it be possible to add the equivalent of the VJ flags used with PPP in
the IPCOMP header (in the reserved 'Flags' octet?).

surprisingly, this approach even seems to offer reduction from host to host
:

IP1 TCP data  : 41 bytes
IP2 IPCOMP { IP1 TCP data } : with VJ only could be 34 bytes.

So,

1) Is VJ worth adding to IPCOMP header for tunnel mode?
2) Is this another option for would-be 'IPP' exchange?
3) Is it worth adding to IKE IPCOMP proposal in some way?

Cheers, Steve.
  



-----Original Message-----
From: Paul Koning [mailto:pkoning@xedia.com]
Sent: Monday, June 07, 1999 5:19 PM
To: Stephen.Waters@cabletron.com
Cc: 
Subject: Re: Proposal for IP Peer protocol


>>>>> "Waters," == Waters, Stephen <Stephen.Waters@cabletron.com> writes:

 Waters,> What I'm suggesting is that we construct a draft to propose
 Waters,> a generic IP Peer Protocol that can be used to negotiate
 Waters,> between IP Peers.  I'm am suggesting that this protocol is
 Waters,> general purpose enough to be easily added to over time and
 Waters,> an initial use would be to allow IP peers to negotiate which
 Waters,> IPCOMP algorithm will be used.

I can imagine that an IPPP could someday be useful.  

 Waters,> It would be useful for IP peers to be able to negotiate
 Waters,> IPCOMP without using IKE. IKE is over the top if you want to
 Waters,> just negotiate which compression algorithm you are going to
 Waters,> use.

True, but how likely is that?  The typical use for compression is
dialup lines, but those already DO have compression (X.42mumble,
MNP10, whatever).  The issue that made IPCOMP important and caused it
to appear as part of IKE is that modem based compression doesn't work
when you have encryption.

So IPCOMP together with IPSEC has an obvious use; IPCOMP alone is not
so clear.  Can you give an example?

 Waters,> As a side effect, such a protocol would allow us to draw a
 Waters,> close on the IKE RFCs. Anything that is not concerned with
 Waters,> the secure exchange of keys and negotiation of cryptography
 Waters,> algorithms could then be moved to a more general purpose
 Waters,> protocol.

Sorry, my idiom recognizer doesn't get a match on "draw a close".
Does that mean "stop adding new things to..."?

When you say "...could then be moved to..." are you proposing to
remove the ability to negotiate IPCOMP from IKE?  If so, I'm sure you
will receive a lot of objection (starting right here), given that it's
a capability that is currently defined, implemented, and used, over
IKE.

If you're proposing to allow IPCOMP to be negotiated using an
additional control protocol, that's less harmful, though it seems to
add extra complexity for no obvious benefit.  For example, would an
IPCOMP-supporting IPSEC node then be required to support negotation of 
IPCOMP both over IKE and over this new protocol?  That too is going to 
meet with objections.

 Waters,> Another side effect could be that hosts can negotiate
 Waters,> compression between themselves, and Security Gateways can
 Waters,> concern themselves with security.  In time, this could
 Waters,> remove the need for Security Gateways to worry about
 Waters,> high-spec. data compression hardware and all the problems
 Waters,> that come with it.

I don't think so.

Again, the best IPCOMP scenario is a road warrior using crypto, and
not wanting to suffer the performance hit of no longer having
meaningful link level compression.  So at that end IPSEC and IPCOMP
would both terminate.

Similarly, they would at the other end (the security gateway back at
the office).  The existence of crypto is what forces IPCOMP to be
used; innocent third parties don't want to go to the hassle of dealing 
with compression at all.

Also, there are several good implementations of high speed crypto plus 
compression available, so it's not clear to me that attempting to
remove "high spec data compression hardware" from the picture is at
all interesting.  It's not additional hardware, merely additional
gates in existing high speed crypto/compression silicon.

 Waters,> Yet another side effect is that compression is not more
 Waters,> useful since the is used from source to sink, not just over
 Waters,> VPN tunnels:

 Waters,> Host1---(IPCOMP)---SG1---(ESP
 Waters,> Encryption)---SG2---(IPCOMP)---Host2

I still don't see when that's interesting.  And of course, you can do
that today.  Still, if enough people want to go to the effort of
defining a new protocol that will be used specifically for the
IPCOMP-without-IPSEC case, I suppose that's ok.

	paul


Follow-Ups: