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

Re: IKE attributes consistency.


The attached paragraph from rfc2393bis reflects the consensus of the
in the town hall meeting at the VPN/IPsec bakeoff in San Diego
in January 2000. In a long discussion, two attributes -- encapsulation
(transport/tunnel) and lifetime -- were identified as relevant to IPComp.

It was explicitly decided that not including non relevant attributes MUST
cause rejection of an IPComp proposal.  One of the reasons for the
was that _no_ implementation was expecting the non relevant attributes
in an IPComp proposal. Keeping the liberal spirit alive, receivers should

quietly ignore irrelevant attributes. The decision was posted to the
ippcp and ipsec lists and later reflected in the rfc2393bis I-D.

In the bakeoff of September 2000, the consensus was still to support
that understanding.


   When IPComp is negotiated as part of a Protection Suite, all the
   logically related offers must be consistent.  However, an IPComp
   proposal SHOULD NOT include attributes that are not applicable to
   IPComp.  An IPComp proposal MUST NOT be rejected because it does not
   include attributes of other protocols in the Protection Suite that
   are not relevant to IPComp.  When an IPComp proposal includes such
   attributes, those attributes MUST be ignored when setting the IPCA,
   and therefore ignored in the operation of IPComp.

Tero Kivinen wrote:

> Shoichi 'Ne' Sakane writes:
> > we need a consistent rule all over the attribute parsing, so:
> > (1) we always attach the same attributes, for all transforms.
> > (2) apply suggestion in ippcp draft section 4.1 to all transforms.
> >     if there's no attribute, ignore it (if it is mandatory, bark).
> The group parameter is attached to quick mode itself not to any
> protocol inside the SA proposals. Thats why it the RFC2409 says it
> MUST be included in all proposals. I think we should keep it that way,
> and fix the draft-shacham-ippcp-rfc2393bis-06 to say that at least
> group parameter MUST be accepted there.
> --
> kivinen@ssh.fi                               Work : +358 303 9870
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/