Unsupported DOI attributes and values
Tero Kivinen <kivinen@ssh.fi> Mon, 27 September 1999 23:02 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA09695; Mon, 27 Sep 1999 16:02:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21977 Mon, 27 Sep 1999 17:16:36 -0400 (EDT)
Date: Tue, 28 Sep 1999 00:18:28 +0300
Message-Id: <199909272118.AAA24594@torni.ssh.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: Tero Kivinen <kivinen@ssh.fi>
To: Black_David@emc.com
Cc: ipsec@lists.tislabs.com
Subject: Unsupported DOI attributes and values
In-Reply-To: <729D927EF825D311961000E029101CCC258CB1@mxclsa>
References: <729D927EF825D311961000E029101CCC258CB1@mxclsa>
X-Mailer: VM 6.34 under Emacs 19.34.2
Organization: SSH Communications Security Oy
X-Edit-Time: 0 min
X-Total-Time: 2 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
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/
- Unsupported DOI attributes and values Black_David
- Re: Unsupported DOI attributes and values Derrell D. Piper
- Unsupported DOI attributes and values Tero Kivinen
- RE: Unsupported DOI attributes and values Black_David