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

RE: Proposal for IP Peer protocol



-----Original Message-----
From: Paul Koning [mailto:pkoning@xedia.com]
Sent: Monday, June 07, 1999 5:19 PM
To: Stephen.Waters@cabletron.com
Cc: ipsec@lists.tislabs.com; ippcp@external.cisco.com
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.

Paul>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.

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


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

In the absence of IKE, IPCOMP gives end-to-end compression, not just over
each data-link. I guess, as you say, the modem link is the sweet spot, but
it does reduce traffic across the entire network without the need to
re-compress over each WAN on the way as well as reducing LAN traffic. 

 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.

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

Yes, that's what I should have said.

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

Paul> If you're proposing to allow IPCOMP to be negotiated using an
Paul> additional control protocol, that's less harmful, though it seems to
Paul> add extra complexity for no obvious benefit.  For example, would an
Paul> IPCOMP-supporting IPSEC node then be required to support negotation of

Paul> IPCOMP both over IKE and over this new protocol?  That too is going to

Paul> meet with objections.

As you say, it's too late to pull things from IKE. Any other way to
negotiate IPCOMP would need to be an either/or.  


 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.

Paul> I don't think so.

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



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

Paul> with compression at all.

But an alternative is that the client negotiates a tunnel with the security
gateway, and then, within that tunnel, negotiates IPCOMP (or any other
'useful' thing) with each node it will communicate with. 
 
Paul> Also, there are several good implementations of high speed crypto plus

Paul> compression available, so it's not clear to me that attempting to
Paul> remove "high spec data compression hardware" from the picture is at
Paul> all interesting.  It's not additional hardware, merely additional
Paul> gates in existing high speed crypto/compression silicon.

Good point, although we have been hitting some design issues in scaling
hardware compression.

 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

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

So far, it's just me, so I'll go to sleep again. Thanks for the well
considered comments Paul, very helpful.
Steve.

Paul> 	paul