Network Working Group R. Bush Internet-Draft Internet Initiative Japan Intended status: Standards Track K. Patel Expires: April 02, 2013 P. Mehta A. Sreekantiah Cisco Systems L. Jalil Verizon October 2012 Authenticating L3VPN Origination Signaling draft-ymbk-l3vpn-origination-00 Abstract A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are subject to unintentional errors, both by the legitimate originator and by non-legitimate origins. This is of special concern if the VPN traverses untrusted networks. This document describes how the sender of the VPN/Prefix binding may sign it so that recipient of the binding may authenticate it. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case as English words, without normative meaning. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 02, 2013. Copyright Notice Bush, et al. Expires April 02, 2013 [Page 1] Internet-Draft Authenticating L3VPN Origination Signaling October 2012 Copyright (c) 2012 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 (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. NLRI Deaggregation . . . . . . . . . . . . . . . . . . . . . . 2 3. L3VPN Origination BGP Path Attribute . . . . . . . . . . . . . 3 4. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction RFC 4364 [RFC4364] Section 7.4 describes how a Customer Edge (CE) router uses eBGP to announce to a Provider Edge (PE) router the address prefix(es) the customer provides to an L3VPN. It is possible that the originator of such an announcement could unintentionally announce prefixes they do not own. Cust(West)-CE--PE-Provider(West)--TransitA-~ ~-TransitB--Provider(East)-PE--CE-Cust(East) This document describes how the originating PE, West, may sign the announcement so that the destination PE, East, may authenticate the NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] Section 4.3.1. Alternatively, the originating CE router may sign the announcement so that the destination CE router may authenticate the NLRI. It is assumed that the Providers already have the key creation, storage, and distribution infrastructure needed. For example, the Resource Public Key Infrastructure (RPKI) could be used, see RFC 6480 [RFC6480]. 2. NLRI Deaggregation Bush, et al. Expires April 02, 2013 [Page 2] Internet-Draft Authenticating L3VPN Origination Signaling October 2012 Normally, a BGP Update may contain multiple NLRI which all share the identical set of attributes. As L3VPN Origin Signalling Updates sign over the NLRI, and NLRI can become separated as they transit the network, separation would break the signature. Therefore, an L3VPN Origin Signalling MUST contain one and only one NLRI. 3. L3VPN Origination BGP Path Attribute The L3VPN Origination Path Attribute is a BGP optional transitive Path Attribute RFC 4271 [RFC4271]. BGP Path Attributes are Type/ Length/Value tuples. .-------------------------------------------. | | | Attribute Header, see RFC 4271 S. 4.3 | | | +-------------------------------------------+ | | | | | | +---- Key Identifier ----+ | | | | | | +-------------------------------------------+ | Alg | Reserved | | | Suite | MUST be | Signature Length | | 1 | zero | | +-------------------------------------------+ | | | Signature | | | `-------------------------------------------' The Attribute Type is two octets, the first of which, Attribute Flags, MUST have the two high order bits set to signify that attribute is optional and transitive. The second octet of the Attribute Flags, Attribute Type, MUST be set to 0xXX, as assigned by the IANA, see Section 6, to signal that this is an L3VPN Origination BGP Path Attribute. The Length field is one or two octets with a value of the number of octets in the entire attribute. If the length of the Path Attribute is less than 256 octets, only the first octet of the length field is used. Otherwise, both octets are used to represent the Length.. See RFC 4271 [RFC4271] Section 4.2 for another explation of this byte saving. The Key Identifier is an eight octet nonce identifying the key (pair) used for the Signature. It is used when the keying is not implied by the NLRI, as it would be if the RPKI was used. If not used to identify the key, it MUST be zero. Bush, et al. Expires April 02, 2013 [Page 3] Internet-Draft Authenticating L3VPN Origination Signaling October 2012 The Algorithm Suite is a one-octet identifier specifying the digest algorithm and digital signature algorithm used to produce the Signature. The values reference the IANA regietry for Algorithm Identifiers from BGPsec, see [I-D.ietf-sidr-bgpsec-algs]. The Signature Length is two octets and is the number of octets in the Signature field. The Signature field is a digital signature that covers the NLRI, the RD, and the Key Identifier. If the L3VPN Origination Path Attribute is generated by a CE router, eight zero octets MUST be used as the value of the RD. To compute the Signature, the digest algorithm for the specified Algorithm Suite is applied to the catenation of the NLRI, the RD, and the Key Identifier. This is then fed to the signature algorithm for the specified algorithm suite and the resulting value is the Signature. Signature = sign ( hash ( NLRI || RD || Key Identifier ) ) 4. Notes The keying could either come from the Global RPKI or the customer or carrier running their own PKI. The keying is assumed to be asymmetric, but possibly could be symmetric. If the RPKI is used, and the public key is taken from the CA certificate which owns the NLRI, the classic problem arises where all the NLRI on that certificate share fate. I.e. if one causes the need for a re-key, then all must re-key. RPKI-based origin validation solves this problem by a level of indirection, the CA certificate is used to sign an End Entity (EE) certificate which signs a Route Origin Authorization (ROA), see RFC 6480 [RFC6480] and RFC 6482 [RFC6482]. As the RD of an L3VPN signal is larger than the four octets of a ROA, a new RPKI object, for the moment let's call it a VOA, would have to be defined and then it would have to be carried in the RPKI-Router Protocol [I-D.ietf-sidr-rpki-rtr]. Validation needs detail. E.g. what should be done if the relying party can not find the matching key. 5. Security Considerations Signing (NLRI||RD||Key Identifier) with the key of the NLRI-owner or some other pre-agreed key, only says that the contents were produced by the owner of the key (NLRI or other), and that no one in between has changed the (NLRI||RD||Key Identifier). That is the threat model, which seems trivial. If we were trying to protect against an attacking PE replaying a signed (NLRI||RD||Key Identifier) it has no business announcing, this design does not help. Bush, et al. Expires April 02, 2013 [Page 4] Internet-Draft Authenticating L3VPN Origination Signaling October 2012 It would be quite ill-advised to use the Key Identifier method with the same keying used for more than one VPN. Adding a VOA which binds ( NLRI || ND || Key Identifier ) still could be replayed from anywhere so really offers nothing. Like RPKI-based origin validation, this only catches fat fingers, not black hats. 6. IANA Considerations This document requests the IANA create a new entry in the BGP Path Attributes Registry as follows: Value Code Reference ----- ----------------- --------- TBD L3VPN Origination This Document 7. Acknowledgements The authors would like to thank John Scudder, Russ Housley, and Sandy Murphy. 8. References 8.1. Normative References [I-D.ietf-sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", Internet-Draft draft-ietf-sidr-bgpsec-algs-03, September 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012. 8.2. Informative References [I-D.ietf-sidr-rpki-rtr] Bush, R. and R. Austein, "The RPKI/Router Protocol", Internet-Draft draft-ietf-sidr-rpki-rtr-26, February 2012. [RFC6482] Lepinski, M., Kent, S. and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012. Authors' Addresses Bush, et al. Expires April 02, 2013 [Page 5] Internet-Draft Authenticating L3VPN Origination Signaling October 2012 Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 US Email: randy@psg.com Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: keyupate@cisco.com Pranav Mehta Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: pmehta@cisco.com Arjun Sreekantiah Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: asreekan@cisco.com Luay Jalil Verizon 1201 E Arapaho Rd. Richardson, TX 75081 USA Email: luay.jalil@verizon.com Bush, et al. Expires April 02, 2013 [Page 6]