Internet Draft Network Working Group Tissa Senevirathne Internet Draft Nortel Networks Document: draft-tsenevir-smpls-00.txt January 2001 Category: Informational Secure MPLS - Encryption and Authentication of MPLS payloads 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 present use of ISAKMP to establish required security association for secure MPLS. Two methods are presented to transport ISAKMP messages between edge LSR. New RSVP object is defined to exchange security association messages as part of the LSP setup messages. Also discussed are the extensions to IKE to establish required security association for Secure MPLS using a separate IP channel between edge LSR. It is thought that use of separate IP channel facilitates scaling, especially in the environment where multiple LSP terminate between same two edge LSRs. In addition, use of dedicated IP channel does not require a definition of new DOI for Secure MPLS, rather few new definitions to IPSec DOI. Required encapsulation formats are presented for encryption and authentication of MPLS payloads. Senevirathne Expiration June 2001 1 draft-tsenevir-smpls-00.txt January 2001 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]. Table of Contents 1.0 Introduction:....................................................2 2.0 Use of IKE for Secure MPLS.......................................4 2.1 Security Protocol Identifier.....................................4 2.2 Identification Types.............................................5 2.2.1 Identification Payload.........................................6 3.0 Use of RSVP-TE to transport ISAKMP messages......................7 3.0.1 RSVP Transport Message.........................................7 3.1 Secure_MPLS_Message Object.......................................7 4.0 Placement of Secure MPLS, ISAKMP and RSVP-TE....................10 4.1 ISAKMP messages and Secure MPLS DOI.............................10 5.0 Secure MPLS payload encapsulation...............................11 5.1 Possible SMPLS encapsulation formats............................11 5.2 SMPLS Encapsulation header types................................12 5.2.1 SMPLS Authentication Header SMPLS-AH..........................12 5.2.2 Security Association Lookup...................................13 5.2.3 Integrity Check Value Calculation.............................14 5.2.4 Inbound Packet Processing.....................................14 5.3 SMPLS Encrypting Security Payload (SMPLS-ESP)...................15 5.3.1 Outbound Packet Processing....................................16 5.3.2 Security Association Lookup...................................17 5.3.3 MPLS Payload Encryption.......................................17 5.3.4 Inbound Packet Processing.....................................17 6.0 Other Issues....................................................18 6.1 Path MTU discovery..............................................18 6.2 LSP Setup Requirements..........................................18 6.3 Intermediate LSR................................................19 6.4 Label merging...................................................19 6.5 Penultimate Hop popping.........................................19 7.0 Security Considerations.........................................19 8.0 Acknowledgment..................................................19 9.0 References......................................................19 10.0 Author's Addresses.............................................20 Full Copyright Statement............................................20 1.0 Introduction: MPLS is gaining popularity as a protocol that provide traffic engineering and other service capabilities beyond the strength of traditional routing. There are several deployments that use MPLS for wide area application or VPN services. However, at present, there are no established method to provide MPLS payload encryption and authentication. In addition, MPLS is gaining popularity in transport of non-IP traffic (Layer 2) over long haul Wide Area Network. Hence, definition of protocol agnostic (as opposed to IPSec) security Senevirathne Expiration June 2001 2 draft-tsenevir-smpls-00.txt January 2001 architecture for MPLS is becoming more and more important. This paper presents possible methods to establish security association for MPLS payload encryption and authentication. Encryption and authentication of IP packets are performed using suite of well-established protocols. This protocol suite is collectively known as IPSec. Internet Security Association and Key Management Protocol (ISAKMP)[2] defines the messaging protocol that is used to establish required security association for key distribution. ISAKMP is a very generic messaging protocol that can be used for variety of protocols. Internet Key Exchange (IKE) [3] defines specific details of adaptation of ISAKMP for IPSec DOI[4]. In IPSec, IKE use a separate IP Control channel between end points to negotiate and establish security associations. Constrained routed Label Switched paths are used in MPLS to setup traffic engineered tunnels. RSVP-TE [5] or CR-LDP[6] is used for setting up such constrained LSP. The fact that there is a security association with the LSP can be considered as a constrain on the LSP. The ISAKMP is a generic protocol that could be exchanged using any transport protocol. Hence, ability to perform ISAKMP over RSVP- TE or CR-LDP negates the need of a separate IP control channel. In this paper we present the methods to exchange ISAKMP messages using RSVP-TE extensions. CR-LDP can be easily extended for the purpose. Use of CR-LDP for the purpose will be presented in a separate paper. Security Associations (SA) constructed using ISAKMP is uni- directional in nature. MPLS LSP are uni-directional in nature. Hence, ISAKMP and Secure MPLS complements with each other without any changes to existing concepts. In practice, there are multiple LSP between two edge LSR. Suppose these LSP require secure MPLS services. If Secure MPLS services are implemented using RSVP-TE extensions, there need to be a separate Phase 1 Security Association for each LSP. On the other hand if there is a separate control channel to negotiate and establish security association, that channel may be used for key distribution and management of multiple secure LSP. This can be achieved with few additions to the existing IKE definition and will be able to reuse the same ISAKMP code base used for IPSec. In this document we present extension to IPSec DOI to establish secure MPLS services. Secure MPLS need to address all the well-known security considerations such as replay attacks, connection hijacking etc. IPSec encapsulation is designed to address these issues. However, some of the IPSec encapsulation methods become trivial in MPLS. As an example, tunnel mode in IPSec is essentially MPLS LSP. In this document we present Secure MPLS encapsulation format. Secure MPLS encapsulation format is similar to IPSec, but only address specific needs of MPLS. This document is broadly classified in to two parts. Part one presents use of ISAKMP for Security Association establishment for Senevirathne Expiration June 2001 3 draft-tsenevir-smpls-00.txt January 2001 secure MPLS. Use of RSVP-TE or dedicated IP control channel for ISAKMP message transport is also discussed. Also additions required to the IPSec DOI to implement Secure MPLS are presented in this document. The part two of this document presents the Secure MPLS payload encapsulation formats. Also it defines various Secure MPLS operational modes. In future, it may require dividing this document to multiple documents to cover the full scope of the Secure MPLS. Such work may at least include following documents o Secure MPLS Architecture o Secure MPLS Domain of Interpretation (DOI) o Secure MPLS message transport (Use of RSVP-TE or separate control channel) o Secure MPLS payload encryption 2.0 Use of IKE for Secure MPLS IKE [3] is designed to negotiate security parameters for multiple applications over a single Phase I security association. In practice, between two LSR there may be multiple LSP. As suggested earlier, when using RSVP-TE to transport IKE messages, there is no common session between all LSP. Each RSVP session is unique for that LSP and bound to the life of the LSP. Thus inhibiting the ability to use a single Phase I session for multiple LSP. As a result it is possible that edge LSR are required to maintain large amount of individual Security associations that could have been avoided if a separate control channel was used for the purpose. Hence use of IKE as a proxy to establish Security Associations for MPLS appears a logical approach. This approach also allows reusing the existing ISAKMP/IKE code base and allows to implement Secure MPLS with few new definitions to IPSec DOI. However, a separate IP control channel is required between edge LSR to carry IKE messages. Within the IPSec DOI we propose to define the following additions. The values presented here are suggestions only, exact values require approval from IANA. Such approval will be sort. 2.1 Security Protocol Identifier Section 4.4.1 of IPSec DOI [4] defines various IPSec related Protocol Identifier. We suggest including three more definitions. The suggested definition are presented below: Protocol ID Value PROTO_SMPLS_AH 5 Senevirathne Expiration June 2001 4 draft-tsenevir-smpls-00.txt January 2001 PROTO_SMPLS_ESP 6 PROTO_SMPLS_COMP 7 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. For export consideration, SMPLS-AH transform must not provide any payload confidentiality. 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 conserve 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.2 Identification Types Identification payload in the ISAKMP message helps 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 large number of LSP between two edge LSR. The LSP may not necessarily carry IP payloads. In order to distinguish between different LSP between two given LSR, a unique Tunnel ID is assigned to the LSP [5]. Also [5] suggest to use the extended Tunnel ID to further narrow the scope of the LSP. It is suggested in [5] that the extended Tunnel ID is set to the ingress node IP address. Here we propose to use {Ingress Node Addrss::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 [5] implementation always use unique values for Extended Tunnel ID. ID Type value ID_SMPLS_IPV4 12 ID_SMPLS_IPV6 13 The values presented above are only suggestions. Exact values need approval from IANA. Section 4.6.2.1 of IPsec DOI [4] explains the definition of other ID Types. Senevirathne Expiration June 2001 5 draft-tsenevir-smpls-00.txt January 2001 2.2.1 Identification Payload Here we present the format of the identification data payload that will be carried in ISAKMP identification messages for IPSec 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. Extended Tunnel ID The extended Tunnel ID or the Ingress node ID. The length of this field depend on the ID type is ID_SMPLS_IPV4 or ID_SMPLS_IPv6. NOTE: Here ID_SMPLS_IPV4 or ID_SMPLS_IPV6 only represent the end point addressing. Other DOI definitions All other definitions are the same as IPSec DOI [4] definitions. Senevirathne Expiration June 2001 6 draft-tsenevir-smpls-00.txt January 2001 3.0 Use of RSVP-TE to transport ISAKMP messages Constrained driven LSP are setup using either CR-LDP or RSVP-TE. Most often there is a separate CR-LDP or RSVP-TE session per LSP. These LSP signaling sessions can be used to transport other messages. In this section we present use of RSVP-TE to exchange required ISAKMP messages between edge LSR. The reuse of the RSVP-TE channel to exchange ISAKMP messages negate the need of a separate IP control channel for the purpose. Thus creating a cleaner design with single control channel. However, RSVP-TE sessions are closely tied to the LSP. The Phase 1 security associations established for one LSP may not be reused for another LSP. As a result, end LSR may require maintaining multiple Phase 1 security associations. We propose to define a new RSVP-TE object to carry ISAKMP messages. The new object is called Secure_MPLS_message Object. ISAKMP messages are exchanged end-to-end. RSVP messages are exchanged hop by hop. Hence all transit nodes MUST pass the Secure_MPLS_message Object unmodified to the downstream node. Object Name Applicable RSVP messages ----------- ------------------------ Secure_MPLS_Message Transport (see below) 3.0.1 RSVP Transport Message ISAKMP messages are sent from end-to-end. Intermediate nodes MUST forward the message downstream without modifications. In this regard, RSVP is functioning as a transport protocol for ISAKMP. More established RSVP messages such as Path Message require hop-by-hop processing and are sent with the route alert option in the IP header. This in turn triggers hop by hop processing. As mentioned earlier, when transporting RSVP messages, only the end nodes are required to process the message. On the other hand RSVP transport messages should not be subjected to the RSVP state machine. Hence, we propose to define a new RSVP message type to provide end-to-end message transport ability for RSVP. The payload of the RSVP Transport message can be any of the RSVP objects such as Secure_MPLS_Message Object. Processing of Transport message payloads are considered a local policy. Hence, applications that require transport service from the RSVP MUST register the application with the RSVP module. RSVP Message Type Value ----------------- ------- Transport 8 Message type 1 to 7 are defined in [7]. RSVP Transport message MUST NOT be encoded with route alert option. 3.1 Secure_MPLS_Message Object Senevirathne Expiration June 2001 7 draft-tsenevir-smpls-00.txt January 2001 The Secure MPLS Message object is assigned with Class value of 25 (TBD). Presently, there are two C_Type. C_Type 1 indicates that this is an ISAKMP message with Extended tunnel ID in IP V4 format. C_Type 2 indicates that, this is an ISAKMP message with extended tunnel ID in IP V6 format. All other C_Type values are unused. Class=25, C_Type=1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Node Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Node Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ISAKMP message (variable length..) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Receiver Node Address Receiver IP V4 Address Sender Node Address Sender IP V4 Address Extended Tunnel ID Extended Tunnel ID in IP V4 format Tunnel ID Unique number assigned to this LSP. See [5] for details. Message Type Indicates the type of the payload. Message type 1 is assigned to indicate that payload is ISAKMP. All other values are presently reserved. Length Senevirathne Expiration June 2001 8 draft-tsenevir-smpls-00.txt January 2001 Length of the ISAKMP message in octets. Value zero (0) indicates that there is no message in the payload. Class=25, C_Type=2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Node Address | ~ (16 bytes) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Node Address | ~ (16 bytes) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | ~ (16 bytes) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ISAKMP message (variable length..) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Receiver Node Address Receiver IP V6 Address Sender Node Address Sender IP V6 Address Extended Tunnel ID Extended Tunnel ID in IP V6 format Tunnel ID Unique number assigned to this LSP. See [5] for details. Message Type Indicates the type of the payload. Message type 1 is assigned to indicate that payload is ISAKMP. All other values are presently reserved. Senevirathne Expiration June 2001 9 draft-tsenevir-smpls-00.txt January 2001 Length Length of the ISAKMP message in octets. Value zero (0) indicates that there is no message in the payload. 4.0 Placement of Secure MPLS, ISAKMP and RSVP-TE ISAKMP by design is not tied to a specific transport protocol. ISAKMP security associations are unidirectional in nature. MPLS LSP are unidirectional in nature as well. Hence, Secure MPLS concepts and ISAKMP complements, without any changes to the original concepts. In fact, ISAKMP architecture suites better with unidirectional transport protocol like MPLS. +----------+ +------------ | DOI |<----------->| ISAKMP | |Definition| +---->| | +----------+ | +------------+ | ^ ^ | | | | | v +----------+ | | +-----------+ |Key Exch |<------+ | | RSVP-TE | |Definition| | +->| | +----------+ | | +-----------+ +----------------------+ | ^ | +------------------+ | v | | +-------+ | | | API | | | +-------+ | v ^ | +-------------------------------+ | | | Transport Layer (TCP/UDP) | v v +-------------------------------+ +------------+ | IP | | Secure MPLS| +-------------------------------+ | Controller |<-------->| Link Layer Protocol | +------------+ +-------------------------------+ 4.1 ISAKMP messages and Secure MPLS DOI ISAKMP messages carried in RSVP-TE payloads are defined for Secure MPLS DOI. In order for ISAKMP to properly handle Secure MPLS messages, it is important that Secure MPLS define it own DOI. It is suggested that specific value for Domain Identifier for Secure MPLS DOI be requested from IANA. Within the Secure MPLS DOI, the required parameters are defined. At present most of the definitions are in line with the IPSec DOI [4] with few exceptions. It is suggested, if this proposal receive enough interest, to generate a separate document for the Secure MPLS DOI. Senevirathne Expiration June 2001 10 draft-tsenevir-smpls-00.txt January 2001 5.0 Secure MPLS payload encapsulation Secure MPLS payload encryption, in addition to providing authentication and confidentiality provide variety of security services such as, replay protection, protection against connection hijacking etc. IPSec community has performed extensive work in this area. In this paper we adapt concepts used IPSec to provide authentication and encryption services to MPLS payloads. Authentication, encryption and authentication-encryption are mutually exclusive requirements. Authentication-encryption is a hybrid of authentication and encryption. Thus we define two- encapsulation header format. Borrowing the names used in IPSec community we define these headers as SMPLS-AH and SMPLS-ESP. We propose to use SHIM encapsulation method for SMPLS-AH and SMPLS- ESP. SMPLS-AH, if present, MUST be immediately after the Data Link Layer. SMPLS-ESP, if present, MUST be immediately after the Data Link Layer if SMPL-AH is not present. If SMPLS-AH present, SMPLS-ESP MSUT be immediately after the SMPLS-AH. 5.1 Possible SMPLS encapsulation formats 1. SMPLS-AH -------------------------------------------------- |DA | SA | MPLS | SMPLS-AH| MPLS Payload | | | | Type | | | -------------------------------------------------- <---------------------> Authenticated 2. SMPLS-ESP ----------------------------------------------------------------- |DA | SA | MPLS | SMPLS-ESP| MPLS Payload |SMPLS-ESP |SMPLS-ESP | | | | Type | | |Trailer | Auth(**) | ----------------------------------------------------------------- <-------------------------> Encrypted <------------------------------------> Authenticated (**) 3. SMPLS-AH-ESP -------------------------------------------------------- |DA | SA | MPLS |SMPLS|SMPLS-ESP| MPLS Payload |SMPLS-ESP| | | | Type |AH | | |Trailer | -------------------------------------------------------- <------------------------> Encrypted <---------------------------------> Senevirathne Expiration June 2001 11 draft-tsenevir-smpls-00.txt January 2001 Authenticated (**) Indicates optional fields Note: Above diagrams are not to a scale. Above encapsulation formats are presented to cover all possible combinations. However, one may implement authentication using ESP with NULL encryption as presented in RFC 2410 [8]. When requiring authentication and encryption one may choose to use format in above 2 with SMPLS-ESP authentication. Hence, it may be possible to cover all case with a single SMPLS-ESP encapsulation format. However, use of null encryption with ESP for authentication, instead of SMPLS-AH is open for discussion and suggestions. 5.2 SMPLS Encapsulation header types There are two SMPLS encapsulations defined; Type Value Last Header 0 SMPLS-AH 1 SMPLS-ESP 2 unused 3-255 5.2.1 SMPLS Authentication Header SMPLS-AH 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=SMPLS-AH | Length | Next Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameter Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (64 bits ) ? | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data (variable..) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type of this header. It is set to one (1) to indicate that it is SMPLS-AH. Length Length including Type/Length field in octets. Senevirathne Expiration June 2001 12 draft-tsenevir-smpls-00.txt January 2001 Next Type Type of the next header. This is either 2 to indicate that the next header is SMPLS-ESP or 0 to indicates that MPLS payload follows immediately. Security Parameter Index (SPI) The SPI is an arbiter 32-bit integer. SPI combined with, {Extended Tunnel ID::Tunnel ID} uniquely identify the security association for this datagram. All other interpretation of the SPI including the range of value is as defined in [9]. Sequence Number This unsigned 64-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti- replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when a SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.2 of [9] for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^64nd packet on a SA. In this paper we have chosen a 64-bit sequence number as opposed to 32-bit number in [9]. It is anticipated that more and more 10Gig pipes using MPLS. In such situation traffic may be aggregated to a single MPLS LSP and 32-bit counter may not be adequate. Authentication Data This is a variable length field and contains the Integrity Check Value (ICV) for this packet. The Authentication Data field is a multiple of 32 bits and determined by the ICV computation method. See [9] for details of the authentication field. 5.2.2 Security Association Lookup SMPLS-AH is applied to an outbound packet only after the MPLS implementation determines that the packet is associated with a SA that calls SMPPLS-AH processing. SMPLS-AH requirement may be derived by FEC (Forward Equivalence Class) lookup. The exact procedure is Senevirathne Expiration June 2001 13 draft-tsenevir-smpls-00.txt January 2001 beyond the scope of this document. However, if enough interest is generated a separate document may be created for the purpose. 5.2.3 Integrity Check Value Calculation The calculation of ICV for MPLS payload is quite similar to the calculation of ICV of IP packets in [9], except that SMPLS-AH treat the data as a random bit sequence and no attempt is made to identify the payload protocol type or mutable fields. In theory there are no mutable fields in the MPLS payload as all packet forwarding is performed based on a label. Thus simplifying some of the overheads in IPSec encapsulations. See section 3.3.3 of [9] for detail procedure in ICV calculation and sequence number generation. 5.2.4 Inbound Packet Processing Inbound packet processing follows through following steps o Perform Label Lookup o Security Association Lookup o Sequence Number Verification o Integrity Check Value Verification Label Lookup Egress LSR performs a label lookup on the incoming packet. If that indicates this router is the Egress LSR and the associated LSP is carrying Secure MPLS data, Secure MPLS module is invoked. Security Association Lookup Security Association Lookup is performed within the Secure MPLS module. The incoming Label provides a mapping for the {Extended Tunnel ID::Tunel ID} tuple. Combined with this identifier, Security Parameter Index (SPI) and Header Type (AH) determines a unique Security Association (SA). Note that Header Type (ESP) combined with the same LSP ID and numerically similar SPI is required to generate a different Security association. Hence, Header Type is considered in resolving the SA. If there is no SA present for this flow, the packet MUST be discarded. As specified in [9] the event may be audited. In addition to the information required in [9], log event SHOULD contain the SMPLS-ESP as the flow type. Instead of the end station IP address it SHOULD display the Extended Tunnel ID:: Tunnel ID tuple. Sequence Number verification Senevirathne Expiration June 2001 14 draft-tsenevir-smpls-00.txt January 2001 Sequence number verification is performed using methods specified in [9] Integrity Check Value Verification ICV is verified using the methods specified in section 3.4.4 of [9]. Only difference, that ICV is calculated and verified over the entire payload and there are no mutable fields. 5.3 SMPLS Encrypting Security Payload (SMPLS-ESP) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- | Type=SMPLS-ESP | Length | Next Type |^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|1* | Security Parameter Index (SPI) || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | Sequence Number (64 bits ) ? || | || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|- | Initialization Vector (IV) ||^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|| | Payload Data (variable) ||2* ~ ||| | ||| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|| | | Padding (0-255 bytes) ||| +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+|| | | Pad Length |vv +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- | Authentication Data (variable..) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1* - represents Authentication coverage 2* - represents Confidentiality coverage. NOTE: IV is not encrypted, though considered as part of crypto text. Type Type of this header. It is set to two (2) to indicate that it is SMPLS-ESP Length Length including Type/Length field in octets. Next Type Type of the next header. This is always set to zero (0) for SMPLS- ESP header. Senevirathne Expiration June 2001 15 draft-tsenevir-smpls-00.txt January 2001 Security Parameter Index (SPI) The SPI is an arbiter 32-bit integer. SPI combined with, Extended Tunnel ID::Tunnel ID uniquely identify the security association for this datagram. All other interpretation of the SPI including the range of value is as defined in [10]. Sequence Number This unsigned 64-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti- replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below). The sender's counter and the receiver's counter are initialized to 0 when a SA is established. (The first packet sent using a given SA will have a Sequence Number of 1; see Section 3.3.3 of [10] for more details on how the Sequence Number is generated.) If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^64nd packet on a SA. In this paper we have chosen a 64-bit sequence number as opposed to 32-bit number in [10]. It is anticipated that more and more 10Gig pipes using MPLS. In such situation traffic may be aggregated to a single MPLS LSP and 32-bit counter may not be adequate. Authentication Data This is a variable length field and contains the Integrity Check Value (ICV) for this packet. The Authentication Data field is a multiple of 32 bits and determined by the ICV computation method. See [10] for details of the authentication field. Note: In ESP [10] the Next Header field contains the protocol ID of the IP payload. This was necessary in [10] as the original IP header was replaced with AH/ESP header. However, in MPLS, unmodified IP header is contained in the payload or the payload is non-IP. Hence, in Secure MPLS such explicit denotation of the payload protocol ID is not required. 5.3.1 Outbound Packet Processing In Secure MPLS sender encapsulate the MPLS payload in the suggested format above. Sender is also required to construct the SMPLS-ESP header as specified this document where applicable or according to Senevirathne Expiration June 2001 16 draft-tsenevir-smpls-00.txt January 2001 corresponding IPSec document where there is no explicit reference in this document. 5.3.2 Security Association Lookup SMPLS-ESP is applied to an outbound packet only after the MPLS implementation determines that the packet is associated with a SA that calls SMPPLS-ESP processing. SMPLS-ESP requirement may be derived by FEC (Forward Equivalence Class) lookup. The exact procedure is beyond the scope of this document. However, if enough interest is generated a separate document may be created for the purpose. 5.3.3 MPLS Payload Encryption The encryption of MPLS payload is quite similar to the encryption procedure of IP packets in [10], except that SMPLS-ESP treat the data as a random bit sequence and no attempt is made to identify the payload protocol type. See section 3.3.2 of [10] for detail procedure in encryption and sequence number generation. 5.3.4 Inbound Packet Processing Inbound packet processing follows through following steps o Perform Label Lookup o Security Association Lookup o Sequence Number Verification o Integrity Check Value Verification o Payload decryption Label Lookup Egress LSR performs a label lookup on the incoming packet. If that indicates this router is the Egress LSR and the associated LSP is carrying Secure MPLS data, Secure MPLS module is invoked. Security Association Lookup Security Association Lookup is performed within the Secure MPLS module. The incoming Label provide a mapping to the {Extended Tunnel ID::Tunel ID} tuple. Combined with this identifier and Security Parameter Index (SPI) and Header Type (ESP) determines a unique Security Association (SA). Note that Header Type (AH) combined with the same LSP ID and numerically similar SPI is required to generate a different Security association. Hence, Header Type is considered in resolving the SA. Senevirathne Expiration June 2001 17 draft-tsenevir-smpls-00.txt January 2001 If there is no SA present for this flow, the packet MUST be discarded. As specified in [10] the event may be audited. In addition to the information required in [10], log event SHOULD contain the SMPLS-ESP as the flow type. Instead of the end station IP address it SHOULD display the Extended Tunnel ID:: Tunnel ID tuple. Sequence Number verification Sequence number verification is performed using methods specified in [10] Integrity Check Value Verification ICV is verified using the methods specified in section 3.4.4 of [10]. MPLS Payload Decryption Packet decryption procedure is similar to [10]. However, in secure MPLS there are no attempts made to reconstruct the IP header. During the setup time it is indicated that the corresponding LSP is either IP or Layer 2 packet. Accordingly, decrypted payload is handed over to the appropriate forwarding module. 6.0 Other Issues 6.1 Path MTU discovery As MPLS payloads are encrypted, intermediate LSR are unable to perform fragmentation upon MTU size violations. Hence it is essential that ingress LSR performs path MTU discovery and performs necessary fragmentation before encapsulation. There are several documents published on this. MTU path discovery in Layer 2 MPLS tunnels are presented in [11]. We suggest taking a similar approach in discovering path MTU size for Secure MPLS LSP. 6.2 LSP Setup Requirements Secure MPLS paths require different handling. Hence the LSP signaling protocol MUST carry indication to the effect that this LSP is secure MPLS. At present, either CR-LDP or RSVP-TE is used to setup constrained LSP. In RSVP-TE we propose to define a new flag in Session Attribute object. The new flag is called Secure MPLS. All intermediate nodes MUST pass this flag downstream. Flag 0x08 Secure MPLS This flag indicate that this LSP is carrying encrypted payload and no attempt be made to interpret payload Senevirathne Expiration June 2001 18 draft-tsenevir-smpls-00.txt January 2001 data, except by the end routers. All intermediate nodes must pass this parameter to the downstream routers. See [5] for details on the format of the Session Attribute object. 6.3 Intermediate LSR Intermediate LSR MUST not attempt to interpret data, Upon errors intermediate LSR SHOULD silently discard the packets. If RSVP-TE is used to transport ISKMP messages, they should transparently forward such messages to downstream node. 6.4 Label merging Secure MPLS presented in this document is a derivative of IKE. As such it can only establish security association with point-to-point LSP. Label merged LSP may be considered as a point-to-multi-point LSP. In such situation concepts presented in secure multicast documents may be used. Security implementation in Label merge LSP are considered beyond the scope of this document. 6.5 Penultimate Hop popping As explained above, incoming Label and subsequently {Extended Tunnel ID::Tunnel ID} is used to perform Security Parameter Database lookup. Penultimate hop popping eliminate the ability of such lookup and MUST not be performed in secure MPLS LSP. 7.0 Security Considerations The methods presented in this document is not known to alter the security level of ISAKMP or IKE. The Secure MPLS architecture presented here improves the level of security offered in MPLS implementation. 8.0 Acknowledgment The work presented in this document has been influenced significantly by the work presented in sited references and on going work at the IETF. 9.0 References 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 Maughan, D., and et.al., Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, November 1998. 3 Harkins, D., and Carrel, D., The Internet Key Exchange (IKE), RFC 2409, November 1998. Senevirathne Expiration June 2001 19 draft-tsenevir-smpls-00.txt January 2001 4 Piper, D., The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407, November 1998. 5 Awduche, D., and et. al., RSVP-TE: Extensions to RSVP for LSP Tunnels, Work in Progress, August 2000. 6 Jamoussi, Bilel., and et. al., Constrained-Based LSP setup using LDP, Work in Progress, July 2000. 7 Braden, R., and et.al., Resource ReSerVation Protocol (RSVP), RFC 2205, September 1997. 8 Glenn, R., and Kent, S., The NULL Encryption Algorithm and Its Use with IPSec, RFC 2410, November 1998. 9 Kent, S., and Atkinson R, IP Authentication Header, RFC 2402, November 2000. 10 Kent, S., and Atkinsoon, R., IP Encapsulating Security Payload (ESP), RFC 2406, November 1998. 11 Senevirathne, T., and Billinghurst, P., Use of CR-LDP or RSVP-TE to Extend 802.1Q Virtual LANs across MPLS Networks, Work In Progress, October 2000. 10.0 Author's Addresses Tissa Senevirathne Nortel Networks 2305 Mission College Blvd, Santa Clara CA 95054 Email:tsenevir@nortelnetworks.com Tel:408-565-2571 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 Expiration June 2001 20 draft-tsenevir-smpls-00.txt January 2001 Senevirathne Expiration June 2001 21