Authenticating L3VPN Origination Signaling
draft-ymbk-l3vpn-origination-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Randy Bush , Keyur Patel , Pranav Mehta , Arjun Sreekantiah , Luay Jalil | ||
| Last updated | 2012-10-15 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ymbk-l3vpn-origination-00
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]