Network Working Group Tissa Senevirathne Internet Draft Document: draft-tsenevir-smpls-doi-01.txt Expires: December 2002 July 2002 Secure MPLS Domain of Interpretation for ISAKMP 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 defines the Secure MPLS Domain of Interpretation for ISAKMP. Presented in the discussion are various definitions needed to fully define the parameters required by SMPLS. The discussion closely follows the IPSec DOI and where appropriate cross-references are made to IPSec DOI. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Seneviratne 1 draft-tsenevir-smpls-doi-01.txt Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions used in this document..................................1 1.0 Introduction...................................................3 1.0.1 Overview of IKE..............................................4 2.0 SMPLS DOI......................................................5 2.1 SMPLS Naming Scheme............................................5 2.2 SMPLS Situation bit map........................................5 2.3 SMPLS Policy requirements......................................6 2.4 SMPLS assigned numbers.........................................6 2.4.1 SMPLS Security Protocol Identifier...........................6 2.4.2 SMPLS ISAKMP Transform Identifiers...........................7 2.4.3 SMPLS AH Transform Identifiers...............................7 2.4.3.1 SMPLS_AH_MD5...............................................8 2.4.3.2 SMPLS_AH_SHA...............................................8 2.4.3.3 SMPLS_AH_DES...............................................8 2.4.4 SMPLS ESP Transform Identifiers..............................8 2.4.4.1 SMPLS_ESP_DES_IV64.........................................8 2.4.4.2 SMPLS_ESP_DES..............................................8 2.4.4.3 SMPLS_ESP_3DES.............................................9 2.4.4.4 SMPLS_ESP_RC5..............................................9 2.4.4.5 SMPLS_ESP_IDEA.............................................9 2.4.4.6 SMPLS_ESP_CAST.............................................9 2.4.4.7 SMPLS_ESP_BLOWFISH.........................................9 2.4.4.8 SMPLS_ESP_3IDEA............................................9 2.4.4.9 SMPLS_ESP_DES_IV32.........................................9 2.4.4.10 SMPLS_ESP_RC4.............................................9 2.4.4.11 SMPLS_ESP_NULL............................................9 2.4.5 SMPLS COMP Transform Identifiers.............................9 2.4.5.1 SMPLS_COMP_OUI.............................................9 2.5 SMPLS Security Association Attributes.........................10 2.6 SMPLS Payload definitions.....................................10 2.6.1 SMPLS_ID_IPV4...............................................10 2.6.2 SMPLS_ID_IPV6...............................................11 2.6.3 SMPLS_LSP_ID_IPV4 and SMPLS_LSP_ID_IPV6.....................11 3.0 Security Considerations.......................................13 4.0 Acknowledgment................................................13 5.0 References....................................................13 6.0 Author's Addresses............................................14 Full Copyright Statement..........................................14 Senevirathne 2 draft-tsenevir-smpls-doi-01.txt 1.0 Introduction Multiprotocol Label Switching (MPLS) is attracting lots of attention as a versatile protocol that can provide services such as end-to-end Traffic engineering that were beyond the capabilities of classical routing. MPLS is being target as a core network protocol that carry traffic in both Metropolitan Area Networks and Wide Area Networks. In spite of being used as a WAN/MAN protocol MPLS lacks well-defined security architecture, both in terms of payload encryption and authentication. [2] has presented methods of MPLS payload encryption and authentication, together with an overview of the possible use of IKE to achieve key management for Secure MPLS. Within the context of IKE, definition of a Domain of Interpretation (DOI) is the first requirement of any established security protocol. In this document, we define the Secure MPLS (SMPLS) Domain of Interpretation for ISAKMP[3]. The ISAKMP protocol [3] is a key management framework for transferring key and authentication data independent of the key generation process. IKE builds on this generic ISAKMP protocol framework to precisely define a set of protocol exchanges that set up a secure channel for key management, as well as the exchange of key and authentication data. Generalized payloads for exchanging key generation and authentication data are defined by ISAKMP [3]. IKE [4] specifies a precise usage of these generic payloads for setting up a secure channel (phase 1 SA). This channel can then be used to securely achieve key management for a specific security protocol (so-called a Domain of Interpretation - DOI) such as IPsec (IPsec DOI). The combination of IKE/ISAKMP with a Domain of Interpretation (DOI) defines the specifics of key exchange in the context of a specific security protocol such as IPsec. In the case of Secure MPLS the DOI is the SMPLS DOI. IKE is intended to support the negotiation of SAs for Security Protocols at all layers of the network stack, although in practice it is commonly used at the network layer. A generalized protocol such as ISAKMP has a tendency towards complexity. This complicates security reviews of the protocol. Protocol complexity may also lead to implementation errors. However, there are several advantages associated with IKE due to its well-defined messaging format and application independent nature. It is primarily used as a key exchange protocol for IPSEC, but can be used for other security protocols as well. The [2] propose methods of adopting IKE to establish SA and Key exchange for Secure MPLS. IPSEC protocols have been deployed in the majority of all internetworking devices as well as end-user host products. As Senevirathne 3 draft-tsenevir-smpls-doi-01.txt IPSEC support has grown, support for the IKE protocol has proliferated as well. There are many advantages to making use of this existing support for IKE as a key management framework and a secure channel setup mechanism. a. Re-using much of the existing key management protocol promotes a single key management framework. b. Systems that provide network-layer protection of unicast and multicast data will have the same market needs to provide protection for transport layer protocol such as MPLS. c. Using the same underlying protocol will reduce both complexity and size of the key management code. d. Implementation can be achieved more expediently. 1.0.1 Overview of IKE IKE is logically divided into two exchanges, referred to as Phase 1 and Phase 2. A Phase 1 exchange must be completed before any Phase 2 exchanges are attempted. Once the Phase 1 exchange has completed, there is no limit to the number of Phase 2 exchanges that can take place, and there may be simultaneous Phase 2 exchanges occurring between IKE peers. In Phase 1, two peers establish a bi-directional secure authenticated channel using payloads and semantics defined in ISAKMP [3]. Several different authentication methods are defined for use in IKE, i.e. manually shared keys, digital signatures, or public key encryption. The two peers negotiate a mutually acceptable set of cryptographic policies, and derive keying material using the Diffie- Hellman or public key encryption algorithms. At the end of Phase 1, the two peers have fully authenticated each other and have exchanged adequate keying material used to create a secure authenticated channel for Phase 1 and Phase 2. In Phase 2, the two peers negotiate Security Associations on behalf of IPSEC (or other security protocols if another DOI has been defined). IKE Phase 1 provides the following protections for and defined Phase 2 protocol: a. Confidentiality. All messages are protected using an encryption protocol negotiated during Phase 1. b. Integrity. Each message contains a per-message authentication obtained with the use of an HMAC protocol which signs hashes taken over the Phase 2 payloads and other relevant data. c. Replay protection. If the Phase 2 protocol uses nonces, they can be included in the hashed data for Phase 2 messages. Senevirathne 4 draft-tsenevir-smpls-doi-01.txt d. Generation of key exchange protocol keying material. If the key exchange protocol requires keying material to be generated, it can be generated using the keying material exchanged during Phase 1. Use of IKE Phase 1 as a Secure Channel The secure channel defined by an IKE Phase 1 protects SMPLS DOI keying material. It can directly provide confidentiality and integrity. IKE exchanges protect against man-in-the middle, connection hijacking, reflection and replay attacks. IKE offers some protection against denial-of-service attacks as well. The SMPLS DOI is similar in definition to IPSec DOI [4]. However, there are additional definitions needed to support SMPLS. On the other hand, ISAKMP places the following requirements on a DOI definition. o defines the naming scheme for DOI-specific protocol identifiers. o define the interpretation for situation fields o define set of applicable security policies. o define the syntax for DOI-specific SA attributes (phase II) o define the syntax for DOI-specific payload contents o define additional key exchange types if needed o define additional Notification Message types, if needed In this document we present the SMPLS DOI specific definition. In spite the fact some of these definitions are duplication of IPSec DOI definition, they are presented here. The main reason for this duplication is the stringent requirements of DOI definitions mentioned below. Unlike most other protocols, security protocols demand explicit definition and any lapse in this definition may be considered as a compromise in the strength of the security protocol. 2.0 SMPLS DOI In this section, SMPLS DOI definitions are presented. It may be noted that SMPLS DOI closely follows the format of IPSec DOI. However, due to ISAKMP requirements and sake of completeness all the required fields for SMPLS DOI are presented here, where appropriate cross-references are made to the IPSec DOI [4]. 2.1 SMPLS Naming Scheme Within ISAKMP, all DOI's must be registered with the IANA in the "Assigned Numbers" RFC 1700 [5]. At present the values presented in this paper are not IANA approved. IANA approval is being sort for the value at the moment. The suggested value for the Secure Multiprotocol Label Switch Protocol DOI (SMPLS DOI) is two (2). Within the SMPLS DOI, all well-known identifiers are being sort for registration with IANA under the SMPLS DOI. 2.2 SMPLS Situation bit map Senevirathne 5 draft-tsenevir-smpls-doi-01.txt In SMPLS, the situation bit map is a four (4) octet value. The following situations are defined for SMPLS DOI. All other values are reserved. Situation Value --------- ----- SMPLS_SIT_SRC_ID 0x01 SMPLS_SIT_LSP_ID 0x02 SMPLS_SIT_SRC_ID indicates that the IKE message contains an Identification payload that identifies the source of this phase I SA exchange message (ie the edge LSR). SMPLS_SIT_SRC_ID MUST be included in at least one of the Phase 1 exchanges.A LSR MUST abort any associations that do not present SMPLS_SIT_SRC_ID during the Phase 1 exchange. See section 6 for ID payload definitions. SMPLS_SIT_LSP_ID indicates that the IKE message contains an Identification payload that identifies the LSP for which this Phase 2 exchange is performed. An SMPLS DOI implementation must abort any Phase 2 negotiation that does not contain a SMPLS_SIT_LSP_ID. SMPLS_SIT_LSP_ID allows to establish a Security Association for an LSP and perform key exchange for that LSP. See section 6 for ID payload definition. 2.3 SMPLS Policy requirements SMPLS security policies may be implemented in variety of different methods. Details of such implementations are outside the scope of this document. 2.4 SMPLS assigned numbers Within the SMPLS DOI, several identifications are required to define the SMPLS specific exchanges and payloads. In this section we present the SMPLS specific identifications. These values are required to be registered with IANA under the SMPLS DOI. 2.4.1 SMPLS Security Protocol Identifier It is important that SMPLS is capable of negotiating multiple Phase II security protocols over a given Phase I security association. Here, we present SMPLS specific Protocol Identifiers. Protocol ID Value RESERVED 0 PROTO_SMPLS_AH 1 PROTO_SMPLS_ESP 2 PROTO_SMPLS_COMP 3 All other values unused. Senevirathne 6 draft-tsenevir-smpls-doi-01.txt PROTO_SMPLS_AH The PROTO_SMPLS_AH type specifies the MPLS payload authentication. The default SMPLS-AH transform provides data origin authentication, integrity protection and replay detection. PROTO_SMPLS_ESP The PROTO_SMPLS_ESP type specifies the MPLS payload confidentiality (encryption). Authentication, if required, must be provided as part of the ESP. The default SMPLS-ESP transform provides data origin authentication, integrity protection and replay detection. PROTO_SMPLS_COMP The PROTO_SMPLS_COMP type specifies MPLS payload compression. The exact algorithms for MPLS payload encryption are under study. Use of payload compression may have at least two direct benefits. Firstly, it eliminates redundancies in the payload data and reduces repetitive patterns in the payload. Secondly it conserves bandwidth on the network by reducing the payload size. The time spent in compressing the payload and time gained in encrypting the reduced payload may increase the total throughput. 2.4.2 SMPLS ISAKMP Transform Identifiers Within ISAKMP and the SMPLS DOI, IKE is used as the key establishment protocol. However, it is possible for the end systems to define other key establishment protocols. At present, the only Key Exchange protocol supported (and ever defined) is IKE. Transform Value ---------- ------ RESERVED 0 KEY_IKE 1 2.4.3 SMPLS AH Transform Identifiers. SMPLS Authentication Header (SMPLS-AH) provides one mandatory and several optional transforms used to authenticate the MPLS payloads. SMPLS-AH transforms are presented during IKE proposal payloads for SMPLS DOI. The definition, meaning and identification of SMPLS AH transforms are similar to those of IPSec AH transforms. However, in compliant with the Security requirement documentation the specific values assigned to SMPLS-AH transforms MUST be registered with IANA under the SMPLS DOI. Operation and meaning of the transforms are similar to IPSec DOI [4] and where appropriate cross-reference is cited. Transform ID value ------------ ----- RESERVED 0-1 SMPLS_AH_MD5 2 SMPLS_AH_SHA 3 Senevirathne 7 draft-tsenevir-smpls-doi-01.txt SMPLS_AH_DES 4 2.4.3.1 SMPLS_AH_MD5 See section 4.4.3.1 of IPSec DOI[4] for details. AH_MD5 MUST be implemented in every SMPLS DOI compliant implementation. 2.4.3.2 SMPLS_AH_SHA See section 4.4.3.2 of IPSec DOI[4] for details. 2.4.3.3 SMPLS_AH_DES See Section 4.4.3.3 of IPSec DOI[4] for details. 2.4.4 SMPLS ESP Transform Identifiers The Encapsulation Security Payload (SMPLS-ESP) defines several transforms that are required to provide data confidentiality. When authentication, integrity protection and replay detection are required, such requirements are presented as Security Association Attributes. The list of such possible transforms in the context of SMPLS is equivalent to the one defined in the context of the IPsec DOI [5]. Additional transforms can also be registered with IANA. In the context of SMPLS, the DES transform (identification 2) MUST be implemented. However, in compliant with the Security requirement documentation the specific values assigned to SMPLS-ESP transforms MUST be registered with IANA under the SMPLS DOI. Operation and meaning of the transforms are similar to IPSec DOI [4] and where appropriate cross-reference is cited. Transform ID value ------------ ----- RESERVED 0 SMPLS_ESP_DES_IV64 1 SMPLS_ESP_DES 2 SMPLS_ESP_3DES 3 SMPLS_ESP_RC5 4 SMPLS_ESP_IDEA 5 SMPLS_ESP_CAST 6 SMPLS_ESP_BLOWFISH 7 SMPLS_ESP_3IDEA 8 SMPLS_ESP_DES_IV32 9 SMPLS_ESP_RC4 10 SMPLS_ESP_NULL 11 2.4.4.1 SMPLS_ESP_DES_IV64 See section 4.4.4.1 of IPSec DOI[4] for details. 2.4.4.2 SMPLS_ESP_DES See section 4.4.4.2 of IPSec DOI[4] for details. SMPLSESP_DES MUST be implemented in all SMPLS DOI compliant implementations. Senevirathne 8 draft-tsenevir-smpls-doi-01.txt 2.4.4.3 SMPLS_ESP_3DES See section 4.4.4.3 of IPSec DOI[4] for details. 2.4.4.4 SMPLS_ESP_RC5 See section 4.4.4.4 of IPSec DOI [4] for details. 2.4.4.5 SMPLS_ESP_IDEA See section 4.4.4.5 of IPSec DOI [4] for details. 2.4.4.6 SMPLS_ESP_CAST See section 4.4.4.6 of IPSec DOI [4] for details. 2.4.4.7 SMPLS_ESP_BLOWFISH See section 4.4.4.7 of IPSec DOI [4] for details. 2.4.4.8 SMPLS_ESP_3IDEA See section 4.4.4.8 of IPSec DOI [4] for details. 2.4.4.9 SMPLS_ESP_DES_IV32 See section 4.4.4.9 of IPSec DOI [4] for details. 2.4.4.10 SMPLS_ESP_RC4 See section 4.4.4.10 of IPSec DOI [4] for details. 2.4.4.11 SMPLS_ESP_NULL See section 4.4.4.11 of IPSec DOI [4] for details. 2.4.5 SMPLS COMP Transform Identifiers Secure MPLS compression Transform identifier (SMPLS COMP) defines an optional transform that allows end devices to negotiate for a compression algorithm that could be used for MPLS payload compression. At the time of this writing only proprietary methods are used for the purpose. Transform ID Value ------------ ----- RESERVED 0 SMPLS_COMP_OUI 1 2.4.5.1 SMPLS_COMP_OUI The SMPLS_COMP_OUI specifies a proprietary compression transform. Senevirathne 9 draft-tsenevir-smpls-doi-01.txt Within the transform other attributes must be specified to identify the specific vendor compression algorithm. 2.5 SMPLS Security Association Attributes The security association attributes for the SMPLS Phase II negotiations are the same as the Security attributes defined in section 4.5 of [4]. The security attributes for Phase I are the same as the Security attributes definition in Appendix A of [4]. 2.6 SMPLS Payload definitions There are no new payload definitions required for SMPLS. Payloads types defined in IPSec DOI [4] can be used for SMPLS DOI. However, two new definitions are needed for the Identification payload in order to identify the end station ID during Phase 1 negotiation and LSP ID during Phase II negotiation. ID Type value RESERVED 0 SMPLS_ID_IPV4 1 SMPLS_ID_IPV6 2 SMPLS_LSP_ID_IPV4 3 SMPLS_LSP_ID_IPV6 4 2.6.1 SMPLS_ID_IPV4 SMPLS_ID_IPV4 allows the IKE entity to identify the negotiating party, that uses IPV4 addressing, during the phase I. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | Reserved | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End station IPV4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Payload Type of the next payload after this. Value of zero (0) indicates that this is the last payload. Reserved All reserved fields are set to zero on transmission and ignored on receipt. Payload Length Senevirathne 10 draft-tsenevir-smpls-doi-01.txt Length of the payload in octets, including the generic header. ID Type Value describing the Identification data. For Secure MPLS, this is ID_SMPLS_IPV4. IPV4 address IP V4 address of the negotiator. 2.6.2 SMPLS_ID_IPV6 SMPLS_ID_IPV4 allows the IKE entity to identify the negotiating party, that uses IPV6 addressing, during the phase I. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | Reserved | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | End station IPV6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Payload Type of the next payload after this. Value of zero (0) indicates that this is the last payload. Reserved All reserved fields are set to zero on transmission and ignored on receipt. Payload Length Length of the payload in octets, including the generic header. ID Type Value describing the Identification data. For Secure MPLS, this is ID_SMPLS_IPV6. IPV6 address IP V6 address of the negotiator. 2.6.3 SMPLS_LSP_ID_IPV4 and SMPLS_LSP_ID_IPV6 Senevirathne 11 draft-tsenevir-smpls-doi-01.txt Identification payload in the ISAKMP message helps the responder to identify the appropriate LSP and apply correct security policies. In IPSec this is defined as end station address and a port number. In MPLS, there may be a large number of LSPÆs between two edge LSRÆs. The LSP may not necessarily carry IP payloads. In order to distinguish between different LSPÆs between two given LSRÆs, a unique Tunnel ID is assigned to the LSP [6]. Also [6] suggests to use the extended Tunnel ID to further narrow the scope of the LSP. It is suggested in [6] that the extended Tunnel ID is set to the ingress node IP address. Here we propose to use {Ingress Node Address::Tunnel ID} as the node identifier. This may also be considered as {Extended Tunnel ID::Tunnel ID}. If Extended Tunnel ID is used as part of the ISAKMP identification, it is important that RSVP-TE [6] implementations always use unique values for Extended Tunnel ID. Here we present the format of the identification data payload for identification types SMPLS_LSP_ID_IPV4 and SMPLS_LSP_ID_IPV6 that will be carried in ISAKMP Identification payloads for SMPLS DOI. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | Reserved | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | Reserved=0 | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Extended Tunnel ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Payload Type of the next payload after this. Value of zero (0) indicates that this is the last payload. Reserved All reserved fields are set to zero on transmission and ignored on receipt. Payload Length Length of the payload in octets, including the generic header. ID Type Value describing the Identification data. For Secure MPLS, this is either ID_SMPLS_IPV4 or ID_SMPLS_IPV6. Tunnel ID A unique number assigned for this LSP by the ingress node. Senevirathne 12 draft-tsenevir-smpls-doi-01.txt Extended Tunnel ID The extended Tunnel ID or the Ingress node ID. The length of this field depends on the ID type and is either ID_SMPLS_IPV4 or ID_SMPLS_IPv6. NOTE: Here ID_SMPLS_IPV4 or ID_SMPLS_IPV6 only represent the end point addressing. 3.0 Security Considerations The discussion presented in this document defines required parameters for IKE to establish a security association on behalf of SMPLS DOI. The SA's established during Phase I are used to protect SMPLS DOI related Phase II exchanges. Security Association established during Phase II is used for SMPLS payload encryption, authentication and protection against various attacks such as connection hijacking, replay, man-in-the-middle etc. 4.0 Acknowledgment Activities at IP Security working group has greatly influenced work presented in this document. Oilvier Paradence of Alcatel provided valuable commenst and suggestion during early versions of this publication. 5.0 References 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 Senevirathne, T. and Paridaens, O., "Secure MPLS - Encryption and Authentication of MPLS payloads", January 2001. 3 Maughan, D. and et,al., "Internet Security Association and Key Managment Protocol (ISAKMP)", RFC 2408, November 1998. 4 Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. 5 Reynolds, J., and J., Postel, "Assigned Numbers", RFC 1700, October 1994. 6 Awduche, D., and et.al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", Work In Progress, August 2000. Senevirathne 13 draft-tsenevir-smpls-doi-01.txt 6.0 Author's Addresses Tissa Senevirathne 1567 Bellevile Way Sunnyvale, CA 94087 Tel: 408-245-5897 Email:tsenevir@hotmail.com Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Senevirathne 14