Network Working Group Michael Richardson mcr@sandelman.ottawa.on.ca INTERNET-DRAFT Sandelman Software Works ipsec-vendorid.txt v1.0, February 1999 Expires in six months Use of ISAKMP VendorID payload to provide proprietary extensions Status of This memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the problem of adding new features to an ISAKMP implementation without causing a flag day for deployed code. This tech- nique is appropriate for use within a vendor's product line either for the purpose of introducing new proprietary extensions, or for getting limited field experience with new proposal prior to standardization. Michael Richardson mcr@sandelman.ottawa.on.ca [page 1] INTERNET-DRAFT v1.0, February 1999 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. A Concrete example . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Configuration . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. Packet trace 1 . . . . . . . . . . . . . . . . . . . . . . . 4 5. References: . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Author's Address . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Expiration and File Name . . . . . . . . . . . . . . . . . . 4 1. Introduction RFC2408, defines the Internet Security Association Key Management Protocol, which along with RFC2409, provide a way for two hosts that share a pre-shared secret, or for which a trusted certificate can be retrieved to establish sessions keys. The ISAKMP protocol provides a mechanism to accomodate extensions: the payload number space contains a large number of "private use" values which can be used by consenting parties to convey any additional information required. The private use values are distinct from the unallocated (reserved) values in that they are guaranteed to never be allocated by IANA. In addition, the IPsec DOI also contains a private use space for nearly all parameters. The use of these values for extensions is difficult for two reasons: 1. a compliant implementation must fail negotiation in most cases when it sees a parameter that it does not understand. The implementation may not silently ignore the extension value, as it may be a critical extension, and silence may imply consent to use the extension. 2. when two implementations that make use of extensions communicate, they take the risk that they will have used identical extension values to mean non-identical things. As such, rather than fail the ISAKMP exchange, they may each agree to do different things due. This document describes a way to use the Vendor ID payload to communicate a willingness to use the private spaces. Further, recognition by the party receiving the vendor ID payload of the remote vendor provides information to the local party about what the definitions of the private vendor spaces are. 2. Definition Section 3.16 of RFC2408 says: Michael Richardson mcr@sandelman.ottawa.on.ca [page 2] INTERNET-DRAFT v1.0, February 1999 "The Vendor ID payload is not an announcement from the sender that it will send private payload types. A vendor sending the Vendor ID MUST not make any assumptions about private payloads that it may send unless a Vendor ID is received as well. Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to understand any Vendor ID payloads. An implementation is NOT REQUIRED to send any Vendor ID payload at all. If a private payload was sent without prior agreement to send it, a compliant implementation may reject a proposal with a notify message of type INVALID-PAYLOAD-TYPE." To expand, the Vendor ID payload is important when RECEIVED. When an implementation receives a Vendor ID payload that it recognizes, then it may SEND using the private space payloads of the Vendor whose ID it has just received. If the local machine has sent a vendor ID payload, then it can expect that the remote end MAY send it private space payloads in the LOCAL end's private space. Typically, an implementation recognizes the Vendor ID by virtue of the fact that it is identical to its own, or it matches a small set of codes that represent previous revisions of the same vendor's product. (The vendor may want to use this information to work around bugs in previous revisions of their products until they can all be upgraded) 3. Alternatives The alternative to using the Vendor ID payload to have configuration options to enable/disable the private extensions based upon IP address. This is not very scalable, is prone to operator errors, and does not work for the case where one end does not have a fixed IP address (i.e. the client IPsec or road warrior situation). 4. A Concrete example 4.1. Configuration org1 org2 C1-\ /-S1 +--{G1}--+--{G2}---+ C2-/ | \-S2 \ \--{G3}--Q1 C1 is a host. C2 is another host. G1/G3 are security gateways from vendor ID "A" G2 is a security gateway from vendor ID "B" S1 is a host. S2 is a host. R1 is a router. Q1 is a host. Michael Richardson mcr@sandelman.ottawa.on.ca [page 3] INTERNET-DRAFT v1.0, February 1999 4.2. Scenario 1 Vendor ID "A" has defined a new extension, e.g. "Super-Reliable RSA- signed Notify". It has used a private number (128) from the ISAKMP space. Vendor ID "B" has also defined a new extension, e.g. "Explicitely ranked/negotiated Proposal". It has also used a private number (128) from the ISAKMP private use space. 4.3. Packet trace 1 G1 -> G2 HDR; SA; NONCE; VID"A" G2 -> G1 HDR; SA; NONCE; VID"B" G1 -> G2 HDR; IDii; AUTH; Notify G2 -> G1 HDR; IDir; AUTH; Notify G1 -> G3 HDR; SA; NONCE; VID"A" G3 -> G1 HDR; SA; NONCE; VID"A" G1 -> G2 HDR; IDii; AUTH; RSA-signed Notify(#128) G2 -> G1 HDR; IDir; AUTH; RSA-signed Notify(#128) 5. References: RFC-2408 Internet Security Association and Key Management Protocol (ISAKMP), D. Maughan, M. Shertler, M. Schneider, J. Turner. 1998. 5.1. Author's Address Michael C. Richardson Sandelman Software Works Corp. 152 Rochester Street Ottawa, ON K1R 7M4 Canada Telephone: +1 613 276-6809 EMail: mcr@sandelman.ottawa.on.ca 5.2. Expiration and File Name This draft expires September 1, 1999 Its file name is draft-richardson-ipsec-vendorid-00.txt, also at http://www.sandelman.ottawa.on.ca/ Michael Richardson mcr@sandelman.ottawa.on.ca [page 4]