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

Proposal for IP Peer protocol


This is an old existing thread that has a bad subject line..

Paul,

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

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

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

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


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

Host1---(IPCOMP)---SG1---(ESP Encryption)---SG2---(IPCOMP)---Host2

Any co-authors out there?
Cheers, Steve. 


-----Original Message-----
From: Paul Koning [mailto:pkoning@xedia.com]
Sent: Friday, June 04, 1999 7:32 PM
To: Stephen.Waters@cabletron.com
Cc: shacham@cisco.com; 
Subject: RE: New MIB Drafts Submitted


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

 Waters,> I'm not sure I would use the words 'very natural' when
 Waters,> describing the negotiation of IPCOMP in IKE, and I would
 Waters,> suggest that IKE was not the right wheel to use in the first
 Waters,> place, so perhaps invention was required, not reinvention.

Perhaps if you were starting with a clean slate, IKE would not have
been the place to put IPCOMP.  Then again, a major reason for having
IPCOMP is to cope with the loss of link-level compression that result
when you start encrypting above there.

Meanwhile, we do have IPCOMP negotiation in IKE, and it works fine
(modulo a detail or two that people have noticed and the new draft is
working to clear up).

So what are you proposing?  To create another protocol to do what IKE
already does?  Or to take it out of IKE and put it elsewhere?  Or was
it just an observation with no protocol change intended?

	paul
Follow-Ups: