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