[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
>
>
>
>