Network Working Group Tissa Senevirathne (Force10) Internet Draft Document: draft-tsenevir-mpls-lauth-01.txt Olivier Paridaens Category: Informational (Alcatel) July 2001 MPLS Label Stack Authentication methods and algorithms Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document provides methods to protect MPLS Label stack from security related attacks such as label spoofing. Two HMAC based label stack authentication methods are provided. Applicable deployment scenarios are presented. Methods presented in this document are intended for label stack authentication. Senevirathne Informational - January 2002 1 draft-tsenevir-mpls-lauth-01.txt July 2001 1.0 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 [2]. 2.0 Introduction Multiprotocol Label Switching (MPLS) is getting popular as a wide area networking protocol. In the same time MPLS is becoming popular amongst service providers who wish to provision services to customer networks. When connecting un-trusted MPLS domains, label stack authentication is required to prevent any Denial of Service attack by label spoofing or connection hijacking by malicious label insertion. The label stack used in MPLS packets can be from a single label to several labels. In other words, from 32-bits to 100's of bits. The label stack authentication methods must be able to cover either part or the entire stack. The selected authentication algorithm should not generate arbitrarily large Message Authentication Code values. Ideally the MAC length should be a multiple of 32-bits. In the first part of this document we present the use of HMAC for label stack authentication. HMAC-SHA-1-96 [5] and HMAC-MD5-96 [4] are presented as possible HMAC algorithms that could be used for the authentication purpose. HMAC algorithms take the data stream and a secret key and generate a message digest. The cryptographic strength of HMAC based algorithms depends on the computational difficulty of regeneration of the digest without possessing the secret key. Both SHA-1 and MD5 take the data stream as a block input of 512-bits and generate a message digest of either 160-bits (SHA-1) or 128-bits (MD5). The goal of MPLS label stack authentication is to provide a fast and secure authentication method. Commercially available hardware solutions are capable of performing SHA-1 and MD5 algorithms at high speeds. MPLS label stack authentication is enabled on a per interface basis. At configuration time, the MAC algorithm and related parameters are defined. It is possible that the authentication algorithm is negotiated during the adjacency formation. However, the exact implementation depends on the label distribution protocol used. Hence, the negotiation of label stack authentication and the mechanism used to securely share the secret key are considered out of scope of this document. 3.0 Requirements and Scenarios Threats Senevirathne Informational - January 2002 2 draft-tsenevir-mpls-lauth-01.txt July 2001 Because LSRs take routing decisions based on label values in MPLS packets, labels are an attractive resource for entities that wish to fraudulently use the MPLS network. For example, an entity can try and insert MPLS data traffic with a label that it should not be authorized to use. This brings two issues: network resources (bandwidth, LSR processing time, etc) are being misused and normal usage of resources can be hijacked to the point where denial of service can take place. Such threats are common when users are routing traffic across public or shared MPLS networks. 1. General deployment -o-o-o-o-o-o-o- ---- | Public MPLS network ---- | |1 1o----------------o2 2| | |LSR |-----------------------------------------|LSR | ---- o----------------o ---- | (A) | -o-o-o-o-o-o-o- 1, 1 Authenticated Interfaces 2,2 Authenticated Interfaces (A) Public MPLS network, may not have authentication NOTE: at 1 labels required to forward via (A) is pushed. at 2 labels used to forward in (A) is popped thus trimming the outer tunnel. 2. Simple deployment | ------ ----- |---------| LSR | | LSR |1 | 1| | | |------------| ------ ----- | Network 1,1 Authenticated Interface Simple deployment scenario above depicts two LSR that are connected via a common access network such as Ethernet. The common network may be either a LAN or a MAN that use some Layer 2 technology. The Label stack authentication methods presented here facilitates end LSR to protect data packets from above discussed security attacks. 3.0 Use of HMAC for Label stack authentication In this section, label stack authentication based on Hash Message Authentication (HMAC) is presented. HMAC is presented in RFC 2104 [3]. HMAC generates a message digest based on a secret key and the Senevirathne Informational - January 2002 3 draft-tsenevir-mpls-lauth-01.txt July 2001 message. HMAC proposes to use hash functions to generate the required message digest. Presently MD5 and SHA-1 are the most popular hash functions used within HMAC. Hardware based implementations of SHA-1 and MD5 are commonly available. In the native form, MD5 generates a 128 bits message digest and SHA- 1 generates a message digest of 160 bits as the message digest. RFC 2104 [3] has identified that only sending a subset of the message digest is sufficient to maintain the required cryptographic strength. RFC 2403 [4] specifies HMAC-MD5-96 algorithm as applicable to IPsec. RFC 2404 [5] specifies HMAC-SHA-1-96 algorithm as applicable to IPsec. In this section we propose to extend the work presented in [4] and [5] to authenticate MPLS label stack over each hop. Hardware solutions that could perform HMAC authentication at 1Gbps rates are widely available in the market. Several vendors have announced product plans to develop such features for 10Gps rates. 3.0.1 Configuration of Authentication Algorithm Label stack authentication is configured on a per interface basis. Before two systems can start exchanging MPLS traffic with authenticated label stacks, they must have agreed upon which MAC algorithm to use and upon the shared secret key to be used (this is broadly speaking setting up a Security Association û SA - between both partners). This SA can be set up manually or automatically using some protocol. This document does not address the automatic setup of such Security Associations, which could be achieved during LDP adjacency formation or via a dedicated IKE channel. At this stage, this document only covers the use of HMAC-SHA-1-96 and HMAC-MD5-96 as authentication algorithms for label stacks. Other MAC algorithms could well be envisaged. 3.0.2 Use of HMAC to authenticate the Label Stack Let the Label Stack with n labels (32*n bits) be L(n) Let the secret key be k Let the HMAC operation be H Note: See [3], [4] and [5] for details. Let the message digest (truncated to 96 bits) be ICV ICV = H(L(n) , k) 3.0.3 Label stack validation Senevirathne Informational - January 2002 4 draft-tsenevir-mpls-lauth-01.txt July 2001 The message digest is transmitted with the packet. At the destination the ICV is calculated over the label stack using the same procedure. The re-generated ICV is compared against the ICV that was embedded in the message. If the ICVs are equal, the message can be accepted as authenticated. If the ICVs are not equal, the message MUST be discarded. 3.0.4 Encoding of ICV In hierarchical MPLS tunnels, one may wish to authenticate some parts of the label stack. Hence, it is important to identify the start and the end of the authenticated portion of the label stack. For this purpose we propose to use reserved label from the range 0- 15. We have arbitrarily selected value 7 (seven) for the purpose. 1. General Encoding format ----------------------------------------------------------------- | M-H | Lbl(clear)| Lbl(Rsv)| ICV | Lbl(auth)| Lbl(Rsv)|Lbl(clear)| ----------------------------------------------------------------- 2. Simple Encoding format ------------------------------------------- | M-H | Lbl(Rsv)| ICV | Lbl(auth)|Payload | ------------------------------------------- M-H Media dependant header for the MPLS packet Lbl(Clear) Labels that are not authenticated Lbl(Rsv) Reserved Label that identifies the start and end of Authenticated label stack. If the Label(auth) contain the bottom of stack label then Label(Rsv) MUST not be inserted after Lbl(auth). ICV Integrity check value generated according to the authentication algorithm that has been agreed upon between both partners. This field length depends on the MAC algorithm (currently 96-bits for the MAC algorithms mentioned above). Senevirathne Informational - January 2002 5 draft-tsenevir-mpls-lauth-01.txt July 2001 4.0 Security Considerations The work presented in this document affects the security of the MPLS data plane. Security analysis of the methods provided here has not yet been performed 5.0 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Krawczyk, H., and et.al., HMAC: Keyed-Hashing for Message Authentication, RFC 2104, February 1997. 4 Madson, C., and Glenn, R., The Use of HMAC-MD5-96 within ESP and AH, RFC 2403, November 1998. 5 Madson, C., and Glenn, R., The Use of HMAC-SHA-1-96 within ESP and AH, RFC 2404, November 1998. 6.0 Author's Addresses Tissa Senevirathne Force10 Networks 1440 McCarthy Blvd Milpitas, CA 95035-7438 Phone: 408-965-5103 Email: tsenevir@hotmail.com Olivier Paridaens Alcatel Francis Wellesplein, 1 B-2018 Antwerpen Belgium Phone: +32 (0)3 240 9320 Email: olivier.paridaens@alcatel.be Senevirathne Informational - January 2002 6 draft-tsenevir-mpls-lauth-01.txt July 2001 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 implementation 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 Informational - January 2002 7