[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (more#4 fwd from ipsec) Re: Handling of IPcomp in IKEv2
Paul,
Not sure how to read
> the CPI was just 2 unnecessary bytes.
The protocol is built to answer the generic scenarios, and a private case,
where the system supports a single compression algorithm and uses no
params, is, ahem, a private case, which, as you stated, works.
Regards,
avram
> Date: Mon, 9 Dec 2002 15:46:40 -0500
> From: Paul Koning <pkoning@equallogic.com>
> To: henry@spsystems.net
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Handling of IPcomp in IKEv2
>
> >>>>> "Henry" == Henry Spencer <henry@spsystems.net> writes:
>
> Henry> On Sun, 8 Dec 2002, Avram Shacham wrote:
> >> Even with that option available, the vast majority of IPComp
> >> implementations use the negotiated CPI (range 256-61439) rather
> >> than the well-known numbers...
>
> Henry> Most of the motive for this, I think, is that it's convenient
> Henry> to have a local object to hold state for compression -- the
> Henry> compression proper is usually stateless, but choice of
> Henry> algorithm, intelligent decision on whether to attempt
> Henry> compression, etc. require local state -- and negotiated CPIs
> Henry> let you give that state a number (although not very
> Henry> conveniently so, since the decompressor picks the CPI but it's
> Henry> the compressor that wants to keep state).
>
> Speaking as one former implementer: I used CPI == 256 always, because
> I didn't think I was allowed to pick a "well known" value on my own.
> But the compression state was simply bundled with the IPsec state,
> because for processing purposes you use all that stuff together. So
> the CPI was just 2 unnecessary bytes.
>
> paul
>
>
>
>