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

IKE attributes consistency.

Are all of IKE attributes always consistent ?  No, there is one exception.
IPCOMP proposal does not convey PFS group number in its attribute even if
phase 2 needs PFS, although RFC2409 5.5 Phase 2 - Quick Mode says the

   All offers made during a Quick Mode are logically related and must be
   consistant. For example, if a KE payload is sent, the attribute
   describing the Diffie-Hellman group (see section 6.1 and [Pip97])
   MUST be included in every transform of every proposal of every SA
   being negotiated. Similarly, if client identities are used, they MUST
   apply to every SA in the negotiation.

To circumvent the issue, draft-shacham-ippcp-rfc2393bis-06.txt has the folowing
text in section 4.1.

   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.

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).

//KAME Project