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

Unsupported DOI attributes and values

Black_David@emc.com writes:
> This appears to require that detection of an unsupported attribute or value
> causes the entire SA negotiation to fail.  This seems less than ideal,
> as it means that any use of an attribute or value unsupported by the
> recipient fails to create an SA, at which point one has to figure
> out why and formulate new proposals that don't contain the offending
> attribute or value.  At best this is inefficient, and could lead to
> lack of interoperability as I haven't found any guidance in the RFCs
> as to how to formulate such new proposals.

There is some text about that in my
draft-ietf-ipsec-ike-ext-meth-02.txt saying (see the 12.1 first
paragraph):
----------------------------------------------------------------------
12.  Data Attribute Types and Values

SA payloads and some other payloads in the ISAKMP contain data
attributes. Data attribute consists of an attribute type and a value.
The data attribute type and value number spaces are divided into two
parts: The IANA range and the private-use range.

The phase 1 data attribute types and values are defined in the IKE
document and ISAKMP documents. This part should probably be separated
from those documents to separate IKE DOI. The Phase 2 data attributes
are defined in the DOI [RFC-2407] document.

The private-use data attribute TYPES can be used anywhere, and when they
are used the sender SHOULD send vendor ID payload(s) specifying whose
private-use values the sender is using.

When adding new IANA registered data attribute TYPES the minor version
number of the protocol SHOULD NOT be updated. When adding new IANA
registered data attribute TYPES the phase 1 transform identifier MAY be
updated.

The private-use data attribute VALUES can also be used anywhere, and
when they are used the sender SHOULD send vendor ID payload(s)
specifying whose private-use values sender is using.

When adding new IANA registered data attribute VALUES the minor version
number of the protocol SHOULD NOT be updated. When adding new IANA
registered data attribute VALUE the phase 1 transform identifier MAY be
updated.

12.1.  Data Attributes, Protocol and Transform IDs

The proposal or transform payload MUST NOT be selected by the responder
if it contains unknown protocol IDs, transform IDs, data attribute
types, or data attribute values.

This means that an initiator SHOULD always include a proposal without
any private-use types or values so that if the other end does not
understand them then it may select the transform or proposal without
private-use types or values.
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
References: