Network Working Group G. Daley Internet-Draft NetStar Networks Intended status: Standards Track October 20, 2009 Expires: April 23, 2010 Secured Label Switch Path Problem Statement draft-daley-mpsec-secure-lsp-ps-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on April 23, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Delivering cryptographic security over MPLS networks currently requires insertion of extra IP Packet headers in the label stack. Daley Expires April 23, 2010 [Page 1] Internet-Draft Secured LSP Problem Statement October 2009 This document discusses encryption and authentication of datagrams by carriage of Encapsulating Security Payload directly inside a label header. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Comparable Technologies . . . . . . . . . . . . . . . . . . . . 3 4. Existing deployment models . . . . . . . . . . . . . . . . . . 4 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Secure Label Switch Path Request . . . . . . . . . . . . . 6 5.2. IKEv2 Negotiation of Security Associations . . . . . . . . 6 5.3. Encapsulating packets at Provider Edge . . . . . . . . . . 7 5.4. Decapsulating packets at Provider Edge . . . . . . . . . . 7 5.5. Session Tear-Down . . . . . . . . . . . . . . . . . . . . . 7 6. IKEv2 Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Daley Expires April 23, 2010 [Page 2] Internet-Draft Secured LSP Problem Statement October 2009 1. Introduction VPNs implemented using MPLS gain the advantage of simplified switching, and communication segregation, but do not typically gain encryption and authentication. While procedures exist which define encryption for sub-IP transport, these are not typically able to use the standard key exchange protocols. Issues which would impact specification of carriage and secured encapsulation of data over MPLS networks are discussed in this document. 2. Applicability Use of IPSec based protocols for non-IP environments precludes use of IP Authentication Header (AH) for protection of the data payload [RFC4302]. This is because AH performs authenticity calculations across an IP Pseudo Header containing the IP Source and Destination addresses from the exterior IPv4 or IPv6 packet. Authenticity operations for carriage in MPLS environments may be performed instead by using the Encapsulating Security Payload, which also allows payload encryption [RFC4303]. At this stage, while data plane communications are intended not to require IP packet encapsulation, communications for initial key exchange and peer-to-peer Label signalling may require IP addressing in the control plane. Considerations for ssytems without IP addressing on the control plane are out-of-scope for this document. 3. Comparable Technologies Provision of secured transport at sub-IP layers has been specified using IP or GRE for transport of MPLS Labels [RFC4023], but this specification requires carriage of MPLS Labels over IP. To allow Label switched transport and traffic engineering, this requires insertion of IP and ESP or AH headers between the two stacked labels [RFC3209]. 802.1AE provides an encryption mechanism for Link-Layer communications in IEEE LAN/MAN environments [DOT1AE]. The initial specification does not contain key derivation mechanisms, although these are being specified in revisions to the 802.1X specification [DOT1XREV]. PWsec is a specification of security for pseudo-wires between Daley Expires April 23, 2010 [Page 3] Internet-Draft Secured LSP Problem Statement October 2009 attachment circuits, making use of modern encryption and authentication algorithms, without specification of a key derivation and algorithm extensible packet format [PWSEC][PWSECREQ]. In comparison with the above three technologies, the mechanism discussed here aims to require no data plane IP Headers before the carried payload. It also intends to make use of Internet Key Exchange (IKEv2) rather than IEEE key derivation protocols, and uses existing pseudo-wire transport secured over Encapsulating Security Payload [RFC4448][RFC4303]. 4. Existing deployment models Several different security association models may be applicable, depending on the MPLS VPN architecture. It remains to be determined which of these should be supported, and which should be explicitly signalled (for example with Route Descriptors for VRF aware associations. PE1 P PE2 Ingress Egress +-----+--------+ | +--------+-----+ |VRF A| | | |VRF A| CUST A | | | | | | | CUST A -------| | | | | |------- | | | | | | | | | | | | | +-----+ | | | +-----+ | /-Label555------------------------\ | +-----+ / |========ESP=SA10=======| \ +-----+ | | / |--Label22--|--Label33--| \ | | -------| |/ | | \| |------- CUST B | | | | | | | CUST B | | | | | | |VRF B| | | | |VRF B| +-----+--------+ +--------+-----+ Common Security Association Using a common ESP Security association between PE pairs, a secured LSP can be provided for all communications with the same Forwarding Equivalence Class. By using IPSec traffic selectors that reflect Label semantics, it is possible to provide VPN/VRF associated inner label encapsulation for each customer over the same SA. Daley Expires April 23, 2010 [Page 4] Internet-Draft Secured LSP Problem Statement October 2009 PE1 P PE2 Ingress Egress +-----+--------+ | +--------+-----+ |VRF A| | | |VRF A| CUST A | | | | | | | CUST A -------| | | | | |------- | | | | | | | | | | | | | +-----+ | | +-----+ | | | | | +-----+ | | +-----+ | | | | | | | -------| |==ESP=SA9================================| |------- CUST B | |--Label324-------------------------------| | CUST B | | |--Label22--|--Label33--| | | |VRF B| | | |VRF B| +-----+--------+ | +--------+-----+ Label Tunnelled Security Association As shown above, it is plausible to carry upper-layer datagrams over a VRF associated LSP. This would potentially allow VRF to VRF signalling as well, although this is not explicitly investigated. PE1 P PE2 Ingress Egress +-----+--------+ | +--------+-----+ |VRF A| | | |VRF A| CUST A | | | | | | | CUST A -------| | | | | |------- | |=ESP=SA2=================================| | | | |--Label22--|--Label33--| | | +-----+ | | +-----+ | | | | | +-----+ | | +-----+ | | | | | | | -------| | | | | |------- CUST B | |=ESP=SA5=================================| | CUST B | | |--Label22--|--Label33--| | | |VRF B| | | |VRF B| +-----+--------+ | +--------+-----+ VRF Aware Security Associations Daley Expires April 23, 2010 [Page 5] Internet-Draft Secured LSP Problem Statement October 2009 With in a specific Label switched path, it may be necessary to maintain a particular label mapping solely for encapsulating ESP payloads. This would allow communications to be VRF aware, presenting Traffic multiplexed based on its security parameters index. Similarly with previous scenarios, the ESP SA may itself encapsulate MPLS Labels, or pseudo-wires [I-D.daley-mpsec-label-ts]. 5. Operations Five primary operations occur specific to life span of a secured LSP. These are outlined below. 5.1. Secure Label Switch Path Request In order to set up a secured Label switch path, it is necessary to perform PE to PE signalling, which requests binding of an LSP to a future security association. It is expected that no Provider routers other than participating PE routers will require knowledge of the secured LSP. As such, while a VPN route may exist between PE devices, requests for secured LSP signalling are performed using Targetted LDP signalling [RFC3036]. Where the Secured Label switch path is associated with a Virtual Routing Function, this requires that the Tunnelled LSP is established using a targetted LDP request with information elements representing the tunnel Label. For environments where no inner tunnel is constructed, and encryption is required over the base label, the targetted LDP may specify an implicit-NULL in label request signalling. This would have the effect of running the IPSec packets directly over the exterior LSP. This creates challenges for service multiplexing though, so a single LSP would need to be dedicated to SA Multiplexing. Finally, it may be valuable for the LDP session itself to be protected using IPSec protocols. 5.2. IKEv2 Negotiation of Security Associations Negotiation of the Security Association Parameters makes use of IKEv2, and at this stage requires the implementation to be able to infer from the Targetted LDP and IKE exchange, where Encapsulating Security Payload packets should be encapsulated onto and decapsulated from. Daley Expires April 23, 2010 [Page 6] Internet-Draft Secured LSP Problem Statement October 2009 5.3. Encapsulating packets at Provider Edge Encapsulation of packets over a secured LSP at the Provider Edge relies upon the correct construction of the Security Association Data Base (SADB), and the ability to forward transported packet payloads onto Tunnel pseudo interfaces or apply security transformations on packets. 5.4. Decapsulating packets at Provider Edge Decapsulation of packets at the provider edge requires the same checks as is typical for an ESP SA. Upon decapsulation of the contents at the provider edge, packet forwarding depends on the function of the upper-layer protocol, as in any other MPLS operation. Since it is not possible to strip the ESP encapsulation on the prior hop though using penultimate hop popping, it may be necessary to perform two operations, the decryption associated with the ESP header removal, and the end forwarding instance's task. 5.5. Session Tear-Down Unlike typical LDP operations, sending a Shutdown message is not sufficient to remove a secured LSP, unless the LDP exchange itself was protected via IPSec. Local tear-down procedures will affect the IKE session though, which will identify that the session is terminating via a DELETE Exchange. 6. IKEv2 Considerations MPLS labels typically can contain one of many upper layer protocol elements, including IPv4 or IPv6 headers, Further stacked labels, or Pseudo-wires [RFC4798][I-D.daley-mpsec-label-ts]. It is envisioned that in order to support secured versions of MPLS LSPs, IKEv2 traffic selectors will have to be constructed for all of the above elements. 7. IANA Considerations No IANA actions are currently described in thsi document. 8. Security Considerations Identities based on IP Addressing are not necessarily valid when applied in Sub-IP networks, such as MPLS. As such, identifiers of the form ID_IPV4_ADDR, ID_IPV6_ADDR may not be consequently validated Daley Expires April 23, 2010 [Page 7] Internet-Draft Secured LSP Problem Statement October 2009 by out-of-band communications. 9. Acknowledgments Thanks to Simon DeLord and Raymond Key for their contributions and discussions on the concepts underlying this document. 10. References 10.1. Normative References [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009. 10.2. Informative References [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [IANAIKEV2] IANA, "http://www.iana.org/assignments/ikev2-parameters". Daley Expires April 23, 2010 [Page 8] Internet-Draft Secured LSP Problem Statement October 2009 [DOT1AE] "http://standards.ieee.org/getieee802/download/ 802.1AE-2006.pdf". [DOT1XREV] "http://www.ieee802.org/1/pages/802.1x-rev.html". [PWSEC] Stein, Y(J)., "Pseudowire Security (PWsec)", draft-stein-pwe3-pwsec-00 (work in progress), October 2006. [PWSECREQ] Stein, Y(J)., "Requirements for PW Security", draft-stein-pwe3-sec-req-01 (work in progress), February 2007. [I-D.daley-mpsec-label-ts] Daley, G., "MPLS Label Traffic Selectors for Internet Key Exchange Version 2", draft-daley-mpsec-label-ts-00.txt (work in progress), October 2009. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, July 2006. [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007. Author's Address Greg Daley NetStar Australia Pty Ltd Lvl 9/636 St Kilda Rd Melbourne, Victoria 3004 Australia Phone: +61 401 772 770 Email: gdaley@netstarnetworks.com Daley Expires April 23, 2010 [Page 9]