[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issues from the bakeoff
Dan,
First, thanks for providing the IPComp-related information from
the recent bakeoff. Are there more details available regarding
implementations, interoperability, etc?
Inline comments are embedded.
avram
At 12:54 PM 6/15/99 -0700, Dan Harkins wrote:
> There was an IPSec + L2TP (and PPoE too) bakeoff the week of May 24th.
>As usual there were issues in interoperability that came up and I'm
>presenting them to the list. Not too surprisingly there were no issues
>with interoperability of the IPSec protocols, it's all IKE. Also there
>were several IPPCP issues that I'll summarize although they're being
>taken care of in a different working group in a different area.
As was noted earlier, the ippcp wg has concluded. The mailing-list
is (dusty, sure, but) still alive, and CC-ed.
>IP Payload Compresion Protocol (PCP) Issues:
>
> As I said, these aren't IPSec WG issues but people are using IKE to negotiate PCP and
>these things came up. The appropriate WG needs to deal with these.
>
> - IKE requires consistent attributes accross Quick Mode negotiation. For instance,
> when doing PFS the group must be in all offers and it has to be the same group.
> What about PCP? Since it has no keys does it need a group definition if the
> accompanying IPSec SAs will have PFS?
>
> - Do lifetimes in PCP SAs make sense to negotiate? If so, does a KB lifetime
> expire on pre- or post-compressed data?
Lifetime has no meaning in the context of compression, imo.
> - Is it valid to pass a SPI (actually a CPI in PCP) of zero?
Currently, no, as the value 0 is defined to be RESERVED.
> Is this the "well known CPI"?
Yes, 0 is in the "well known" range.
RFC2393 specifies the range 0-63 as pre-defined (3.3) but points
the reader to RFC2407 "The Internet IP Security Domain of
Interpretation for ISAKMP" for the defined values. There (4.4.5),
as with so many other instances in that RFC, 0 is defined to be
RESERVED.
> - A CPI is two bytes. Is it OK to send a 4 byte one and have the upper two bytes
> be zero?
RFC2393 sets the CPI field in the header to be 2 octets, so the question
seems to be related to the negotiation of CPI via the Internet Key
Exchange. Could implementations support both ways, i.e. negotiate
using just 2-byte field or using the LS 2-bytes of a 4-byte field?
> - A PCP RFC seems to say that tunnel mode processing is not possible. Is this true?
No.
Follow-Ups:
References: