[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: rfc2393bis - request for developers' insight

Sankar,

[The thread-in-progress is now CC-ed to the ippcp and ipsec lists.]

See my comments inline.

Regards,
avram

>>At 03:48 PM 9/28/99 -0700, Sankar Ramamoorthi wrote:
>>>
>>>My 2 cents.
>>>
>>>During the Santa Barbara bakeoff one of the interoperability issues was
>>>with with the attributes that must be sent with the IPCOMP protocol when
>>>negotiating a SA bundle.
>>>
>>>Section 4.1 of your draft seems to imply that only attribute that needs to
>>>be set with IPCOMP protocol is 'Encapsulation mode'. 
>>
>>Yes, that attribute seems the only one required to define IPCOMP.
>
>Agreed.
>
>>
>>However, the same section starts with the overall statement:
>>   For IPComp in the context of IP security, ISAKMP provides the
>>   necessary mechanisms and guidelines for establishing IPCA.
>>
>>The generic phrase 'and guidelines' was added to let implementations
>>comply with requirements, set by the negotiation-protocol, such as
>>those that you quoted, but without duplicating the content of other RFCs.
>>
>>>What about other attributes
>>>like lifetime, PFS? Should they be specified as well? 
>>
>>imo, these attributes have no relation to IPCOMP. 
>>To rephrase the issue, if a compression algorithm requires
>>an attribute, say DICTIONARY_SIZE, are AH and ESP expected
>>to include that attribute in their proposals?
>>
>>That said, if -- in reality -- without those attributes it is going to be
>>impossible to negotiate IPCOMP in IPSec, then see my remark above 
>>regarding 'guidelines'.
>>
>>>This confusion arises because IKE RFC states in section 5.5
>>>'All offers made during a Quick mode are logically related and must be
>>>consistent. For example, if a KE payload is sent, the attribute describing
>>>the
>>>Diffe-Hellman group MUST be included in every transform of every SA being
>>>negotiated'.
>>
>>Indeed, RFC2409 states the above in section 5.5, and almost the very same
>>statement is included in the latest version
>><http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-01.txt>
>> 
>>   All offers made during a Quick Mode are logically related and MUST be
>>   consistent. For example, if a KE payload is send the attribute
>>   describing the Diffie-Hellman group (see section 5 and [Pip98]) MUST
>>   be included in every transform of every proposal of every SA being
>>   negotiated.
>> 
>>The only difference is that 'must' became 'MUST' .
>>
>>>Later Dan Harkins clarfied the above statement applies only to AH and ESP,
>>>and it is upto IPCOMP document to specify the attributes that need be sent
>>>with the transform payload.
>>
>>Could you point me to Dan's clarifications in that matter?
>
>I think it was disucssed in the meeting held during the bakeoff.
>I have pulled out the mail that Dan posted after the bakeoff.
>
>
>----------------------------------------------------------------------------
>----
>
>To: ipsec@lists.tislabs.com 
>Subject: issues from the bakeoff 
>From: Dan Harkins <dharkins@network-alchemy.com> 
>Date: Tue, 15 Jun 1999 12:54:40 -0700 
>Sender: owner-ipsec@lists.tislabs.com 
>
>----------------------------------------------------------------------------
>----
>
>  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.
>
>  I'll mention the general consensus of people at the bakeoff but that's
>just as a starting point for discussion. The resolution (if any) of these
>issues is work for this group. Please comment to the list.
>
>  thanks,
>
>  Dan.
>
>--------------------------------------------------------------------------
>
>...
>... Lots of lines deleted
>...
>
>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?
>
>	- Is it valid to pass a SPI (actually a CPI in PCP) of zero? Is this
>the "well known CPI"?
>
>	- A CPI is two bytes. Is it OK to send a 4 byte one and have the
>upper two bytes be zero?
>
>	- A PCP RFC seems to say that tunnel mode processing is not
>possible. Is this true?

The clarifications in rfc23943bis are addressing the above issues,
among other questions that were discussed on the lists.
(btw, I did answer most of these points in a reply to the list.)

However, the 'waiver' for non AH/ESP protocols, i.e. IPCOMP,
isn't included there.

>----------------------------------------------------------------------------
>----
>
>
>>
>>>It would be nice if the document can clarify how IPCOMP is supposed to
>>>be set up along with ESP and AH when negotiating an IPSEC SA bundle.
>>
>>If the above clarifications aren't enough, what else is needed?
>
>IMO,
>
>Explicit statement in IKE document to say that attributes specific
>to protocols other than AH and ESP should be refered to the appropritate
>protocol specific document. 

Agreed. But, will that change to IKE occur?

>In IPPCP document state explicitly the attributes that are relevant
>to IPPCP while using ISAKMP. 

The new Encapsulation Mode clause in rfc2393bis is addressing 
that exact concern.

>A few lines about the transform attributes
>to be set while using SA bundles along with reference to IKE
>document would be nice.

OK.

>As it stands IPCOMP with IKE is confusing w.r.to SA bundles.
>I believe that IKE document is the right place for some of the 
>explanation about attributes in a SA bundle. 
>Otherwise it leads to differing implementations.

Agreed, with the same question mark as before.

>Some flavors of SA bundle negotiation seen during the bakeoff were
>
>On sending side
>
>. Some implementations duplicate all attributes for AH, ESP and IPCOMP
>. Some set only Encapsulation mode for IPCOMP transform
>. Some implementations duplicate all attributes for AH and ESP and
>  do not set any for IPCOMP. The reason for that was no attribute
>  for IPCOMP was defined.
>
>On receiving side.
>
>. Some implementations were ignoring attributes for IPCOMP, instead
>  relying on the attributes from the AH/ESP transform in the SA bundle
>
>. Some implementations were rejecting the negotiation if encapsualtion
>  mode was not set and if not the same as the attributes in other
>  transforms.

If the IKE doc is changed to reflect the suggested IPCOMP waiver, 
most of the above issues are going to be resolved without modifying
rfc2393bis.

If IKE's language stays, I'd suggest adding the following content 
to the existing section 4.1 -
(a) When IPCOMP is part of SA bundle, the sending side MUST 
duplicate all attributes for AH, ESP, and IPCOMP, in order to comply 
with IKE.
(b) The receiver MUST ignore all attributes that are not required
for IPCOMP, i.e. all but Encapsulation Mode.

Alternatives? Comments? 

====