[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issues from the bakeoff
>> Well-known CPI is not very friendly with PFKEY interface (RFC2367).
>> RFC2367 expects unique SPI per peer (which can embed CPI in lower
>> 2 bytes), but for well-known CPI we can't.
>Following the IPsec list, one must come to the realization that
>PFKEY-friendly isn't the characteristic of several protocols,
>nor it is a requirement. So, IPComp isn't alone.
I agree, I'm not questioning protocol quality (sorry if my English
leads you to misunderstand). I just would like to know how we should
update RFC2367 for IPComp.
>> What kind of userland API do you expect to see? I'm now using dummy
>> SPI (= CPI) to designate the SA database entry for compression,
>> and add a flag to force the use of well-known CPI on the packet.
>The RFC reflects the decision of the ippcp wg in the meeting
>in Washington, DC (Dec 97)
> It was also decided not to restrict the CPI values 0-63 only for manual
> setup but also use it for ISAKMP for well known algorithms.
>I don't recall any discussion in the wg or on the list regarding
>"userland API." If the API doesn't fit the protocols, shouldn't
>the API be adjusted?
Yes of course, but the question is, what kind of changes are necessary.
PFKEY is used for both manual key setups (from userland program to
manipulate manual keys) and autoconfigured keys (from IKE daemons).
I've described my quickhack above.
itojun
Follow-Ups:
References: