[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
I have always assumed that the reason is based on advice I have often
heard given by the Trasport ADs to Transport working groups... "Don't invent
a new protocol if an existing protocol can be adapted to meet the
requirements." If IKE was not used to negotiate IPcomp, then something else
would have needed to be developed to do so.
In addition (or maybe instead, see my disclaimer), there is a relationship
between compression and encryption in that compression needs to occur first if
both are to be used. Therefore, negotiating them at the same time seems more
efficient in terms of the number of handshakes required.
Disclaimer: I was not around when IPcomp was developed, so I do not know
for a fact that this reasoning is correct. And, I am not sure to which
working group mailing list to forward the question. I am pretty sure the work
was done in the Internet Area because the Internet ADs are the ones who took
an interest when I submitted an independent I-D for publication as an
Informational RFC for a specific IPComp protocol (V.44)...
John
Radia Perlman - Boston Center for Networking wrote:
>
> I don't quite understand why IKE is negotiating IPcomp, and it clutters
> up the IKE spec. Presumably IPcomp should exist outside of IPsec, as
> in you might want to send a compressed packet even if it isn't
> cryptographically protected. So presumably there's already some way
> of negotiating compression algorithms, or at least there would have
> to be in order to deploy IPcomp without IPsec. So would anyone object
> to removing all mention of IPcomp from the IKE spec?
>
> If anyone likes IPcomp and wants it
> to stay in IKE, perhaps they'd be willing to explain it to me? :-)
>
> Radia
Follow-Ups:
References: