An Overview of BGPsec
draft-ietf-sidr-bgpsec-overview-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Matt Lepinski , Sean Turner | ||
| Last updated | 2015-01-15 | ||
| Replaces | draft-lepinski-bgpsec-overview | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-sidr-bgpsec-overview-06
Network Working Group M. Lepinski
Internet Draft BBN Technologies
Intended status: Informational S. Turner
Expires: July 15, 2015 IECA
January 15, 2015
An Overview of BGPsec
draft-ietf-sidr-bgpsec-overview-06
Abstract
This document provides an overview of a security extension to the
Border Gateway Protocol (BGP) referred to as BGPsec. BGPsec improves
security for BGP routing.
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), 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 July 15, 2015.
Copyright Notice
Copyright (c) 2015 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
Lepinski and Turner Expires July 2015 [Page 1]
Internet-Draft BGPsec Overview January 2014
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.
Table of Contents
1. Introduction...................................................2
2. Background.....................................................3
3. BGPsec Operation...............................................4
3.1. Negotiation of BGPsec.....................................4
3.2. Update signing and validation.............................5
4. Design and Deployment Considerations...........................6
4.1. Disclosure of topology information........................7
4.2. BGPsec router assumptions.................................7
4.3. BGPsec and consistency of externally visible data.........8
5. Security Considerations........................................8
6. IANA Considerations............................................8
7. References.....................................................9
7.1. Normative References......................................9
7.2. Informative References....................................9
1. Introduction
BGPsec (Border Gateway Protocol Security) is an extension to the
Border Gateway Protocol (BGP) that provides improved security for BGP
routing [RFC 4271]. This document contains a brief overview of BGPsec
and its envisioned usage.
A more detailed discussion of BGPsec is provided in the following set
of documents:
. [RFC7132]:
A threat model describing the security context in which BGPsec
is intended to operate.
. [RFC7353]:
A set of requirements for BGP path security, which BGPsec is
intended to satisfy.
. [I-D.sidr-bgpsec-protocol]:
A standards track document specifying the BGPsec extension to
Lepinski and Turner Expires July 2015 [Page 2]
Internet-Draft BGPsec Overview January 2014
BGP.
. [I-D.sidr-as-migration]:
A standards track document describing how to implement an AS
Number migration while using BGPsec.
. [I-D.sidr-bgpsec-ops]:
An informational document describing operational considerations.
. [I-D.turner-sidr-bgpsec-pki-profiles]:
A standards track document specifying a profile for X.509
certificates that bind keys used in BGPsec to Autonomous System
numbers, as well as associated Certificate Revocation Lists
(CRLs), and certificate requests.
. [I-D.turner-sidr-bgpsec-algs]
A standards track document specifying suites of signature and
digest algorithms for use in BGPsec.
In addition to this document set, some readers might be interested in
[I-D.sriram-bgpsec-design-choices], an informational document
describing the choices that were made the by the author team prior to
the publication of the -00 version of draft-ietf-sidr-bgpsec-
protocol. Discussion of design choices made since the publication of
the -00 can be found in the archives of the SIDR working group
mailing list.
2. Background
The motivation for developing BGPsec is that BGP does not include
mechanisms that allow an Autonomous System (AS) to verify the
legitimacy and authenticity of BGP route advertisements (see for
example, [RFC 4272]).
The Resource Public Key Infrastructure (RPKI), described in
[RFC6480], provides a first step towards addressing the validation of
BGP routing data. RPKI resource certificates are issued to the
holders of AS number and IP address resources, providing a binding
between these resources and cryptographic keys that can be used to
verify digital signatures. Additionally, the RPKI architecture
specifies a digitally signed object, a Route Origination
Authorization (ROA), that allows holders of IP address resources to
authorize specific ASes to originate routes (in BGP) to these
resources. Data extracted from valid ROAs can be used by BGP speakers
o AGGREGATE-VPN-IPv6 SESSION object: Class = 1, C-Type = 22
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | Reserved | DSCP |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 DestAddress (respectively, VPN-IPv6 DestAddress) field
contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address
family encoded as specified in [RFC4364] (respectively, [RFC4659]).
The content of this field is discussed in Sections 3.2 and 3.3.
The flags and DSCP are identical to the same fields of the AGGREGATE-
IPv4 and AGGREGATE-IPv6 SESSION objects ([RFC3175]).
The Reserved field MUST be set to zero on transmit and ignored on
receipt.
o GENERIC-AGGREGATE-VPN-IPv4 SESSION object:
Class = 1, C-Type = 23
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 DestAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
Davie, et al. Standards Track [Page 25]
RFC 6016 RSVP for L3VPNs October 2010
o GENERIC-AGGREGATE-VPN-IPv6 SESSION object:
Class = 1, C-Type = 24
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 DestAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
| Reserved | Flags | PHB-ID |
+-------------+-------------+-------------+-------------+
| Reserved | vDstPort |
+-------------+-------------+-------------+-------------+
| Extended vDstPort |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 DestAddress (respectively, VPN-IPv6 DestAddress) field
contains an address of the VPN-IPv4 (respectively, VPN-IPv6) address
family encoded as specified in [RFC4364] (respectively, [RFC4659]).
The content of this field is discussed in Sections 3.2 and 3.3.
The flags, PHB-ID, vDstPort, and Extended vDstPort are identical to
the same fields of the GENERIC-AGGREGATE-IPv4 and GENERIC-AGGREGATE-
IPv6 SESSION objects ([RFC4860]).
The Reserved field MUST be set to zero on transmit and ignored on
receipt.
8.6. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 SENDER_TEMPLATE Objects
The usage of Aggregated VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE object
is described in Section 7.3. The AGGREGATE-VPN-IPv4 (respectively,
AGGREGATE-VPN-IPv6) SENDER_TEMPLATE object appears in RSVP messages
that ordinarily contain a AGGREGATE-IPv4 (respectively, AGGREGATE-
IPv6) SENDER_TEMPLATE object as defined in [RFC3175] and [RFC4860],
and are sent between ingress PE and egress PE in either direction.
These objects MUST NOT be included in any RSVP messages that are sent
outside of the provider's backbone (except in the inter-AS Option-B
and Option-C cases, as described above, when it may appear on
inter-AS links). The processing rules for these objects are
otherwise identical to those of the VPN-IPv4 (respectively, VPN-IPv6)
SENDER_TEMPLATE object defined in Section 8.2. The format of the
object is as follows:
Davie, et al. Standards Track [Page 26]
RFC 6016 RSVP for L3VPNs October 2010
o AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object:
Class = 11, C-Type = 16
+-------------+-------------+-------------+-------------+
| |
+ +
| VPN-IPv4 AggregatorAddress (12 bytes) |
+ +
| |
+-------------+-------------+-------------+-------------+
o AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object:
Class = 11, C-Type = 17
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ VPN-IPv6 AggregatorAddress (24 bytes) +
/ /
. .
/ /
| |
+-------------+-------------+-------------+-------------+
The VPN-IPv4 AggregatorAddress (respectively, VPN-IPv6
AggregatorAddress) field contains an address of the VPN-IPv4
(respectively, VPN-IPv6) address family encoded as specified in
[RFC4364] (respectively, [RFC4659]). The content and processing
rules for these objects are similar to those of the VPN-IPv4
SENDER_TEMPLATE object defined in Section 8.2.
The flags and DSCP are identical to the same fields of the AGGREGATE-
IPv4 and AGGREGATE-IPv6 SESSION objects.
8.7. AGGREGATE-VPN-IPv4 and AGGREGATE-VPN-IPv6 FILTER_SPEC Objects
The usage of Aggregated VPN-IPv4 FILTER_SPEC object is described in
Section 7.3. The AGGREGATE-VPN-IPv4 FILTER_SPEC object appears in
RSVP messages that ordinarily contain a AGGREGATE-IPv4 FILTER_SPEC
object as defined in [RFC3175] and [RFC4860], and are sent between
ingress PE and egress PE in either direction. These objects MUST NOT
be included in any RSVP messages that are sent outside of the
provider's backbone (except in the inter-AS Option-B and Option-C
cases, as described above, when it may appear on inter-AS links).
Davie, et al. Standards Track [Page 27]
RFC 6016 RSVP for L3VPNs October 2010
The processing rules for these objects are otherwise identical to
those of the VPN-IPv4 FILTER_SPEC object defined in Section 8.3. The
format of the object is as follows:
o AGGREGATE-VPN-IPv4 FILTER_SPEC object:
Class = 10, C-Type = 16
Definition same as AGGREGATE-VPN-IPv4 SENDER_TEMPLATE object.
o AGGREGATE-VPN-IPv6 FILTER_SPEC object:
Class = 10, C-Type = 17
Definition same as AGGREGATE-VPN-IPv6 SENDER_TEMPLATE object.
9. IANA Considerations
Section 8 defines new objects. Therefore, IANA has modified the RSVP
parameters registry, 'Class Names, Class Numbers, and Class Types'
subregistry, and:
o assigned six new C-Types under the existing SESSION Class (Class
number 1), as follows:
Class
Number Class Name Reference
------ ----------------------- ---------
1 SESSION [RFC2205]
Class Types or C-Types:
.. ... ...
19 VPN-IPv4 [RFC6016]
20 VPN-IPv6 [RFC6016]
21 AGGREGATE-VPN-IPv4 [RFC6016]
22 AGGREGATE-VPN-IPv6 [RFC6016]
23 GENERIC-AGGREGATE-VPN-IPv4 [RFC6016]
24 GENERIC-AGGREGATE-VPN-IPv6 [RFC6016]
o assigned four new C-Types under the existing SENDER_TEMPLATE Class
(Class number 11), as follows:
Davie, et al. Standards Track [Page 28]
RFC 6016 RSVP for L3VPNs October 2010
Class
Number Class Name Reference
------ ----------------------- ---------
11 SENDER_TEMPLATE [RFC2205]
Class Types or C-Types:
.. ... ...
14 VPN-IPv4 [RFC6016]
15 VPN-IPv6 [RFC6016]
16 AGGREGATE-VPN-IPv4 [RFC6016]
17 AGGREGATE-VPN-IPv6 [RFC6016]
o assigned four new C-Types under the existing FILTER_SPEC Class
(Class number 10), as follows:
Class
Number Class Name Reference
------ ----------------------- ---------
10 FILTER_SPEC [RFC2205]
Class Types or C-Types:
.. ... ...
14 VPN-IPv4 [RFC6016]
15 VPN-IPv6 [RFC6016]
16 AGGREGATE-VPN-IPv4 [RFC6016]
17 AGGREGATE-VPN-IPv6 [RFC6016]
o assigned two new C-Types under the existing RSVP_HOP Class (Class
number 3), as follows:
Class
Number Class Name Reference
------ ----------------------- ---------
3 RSVP_HOP [RFC2205]
Class Types or C-Types:
.. ... ...
5 VPN-IPv4 [RFC6016]
6 VPN-IPv6 [RFC6016]
Davie, et al. Standards Track [Page 29]
RFC 6016 RSVP for L3VPNs October 2010
In addition, a new PathError code/value is required to identify a
signaling reachability failure and the need for a VPN-IPv4 or VPN-
IPv6 RSVP_HOP object as described in Section 5.2.2. Therefore, IANA
has modified the RSVP parameters registry, 'Error Codes and Globally-
Defined Error Value Sub-Codes' subregistry, and:
o assigned a new Error Code and sub-code, as follows:
37 RSVP over MPLS Problem [RFC6016]
This Error Code has the following globally-defined Error
Value sub-codes:
1 = RSVP_HOP not reachable across VPN [RFC6016]
10. Security Considerations
[RFC4364] addresses the security considerations of BGP/MPLS VPNs in
general. General RSVP security considerations are discussed in
[RFC2205]. To ensure the integrity of RSVP, the RSVP Authentication
mechanisms defined in [RFC2747] and [RFC3097] SHOULD be supported.
Those protect RSVP message integrity hop-by-hop and provide node
authentication as well as replay protection, thereby protecting
against corruption and spoofing of RSVP messages. [RSVP-KEYING]
discusses applicability of various keying approaches for RSVP
Authentication. First, we note that the discussion about
applicability of group keying to an intra-provider environment where
RSVP hops are not IP hops is relevant to securing of RSVP among PEs
of a given Service Provider deploying the solution specified in the
present document. We note that the RSVP signaling in MPLS VPN is
likely to spread over multiple administrative domains (e.g., the
service provider operating the VPN service, and the customers of the
service). Therefore the considerations in [RSVP-KEYING] about inter-
domain issues are likely to apply.
Since RSVP messages travel through the L3VPN cloud directly addressed
to PE or ASBR routers (without IP Router Alert Option), P routers
remain isolated from RSVP messages signaling customer reservations.
Providers MAY choose to block PEs from sending datagrams with the
Router Alert Option to P routers as a security practice, without
impacting the functionality described herein.
Beyond those general issues, four specific issues are introduced by
this document: resource usage on PEs, resource usage in the provider
backbone, PE route advertisement outside the AS, and signaling
exposure to ASBRs and PEs. We discuss these in turn.
Davie, et al. Standards Track [Page 30]
RFC 6016 RSVP for L3VPNs October 2010
A customer who makes resource reservations on the CE-PE links for his
sites is only competing for link resources with himself, as in
standard RSVP, at least in the common case where each CE-PE link is
dedicated to a single customer. Thus, from the perspective of the
CE-PE links, the present document does not introduce any new security
issues. However, because a PE typically serves multiple customers,
there is also the possibility that a customer might attempt to use
excessive computational resources on a PE (CPU cycles, memory, etc.)
by sending large numbers of RSVP messages to a PE. In the extreme,
this could represent a form of denial-of-service attack. In order to
prevent such an attack, a PE SHOULD support mechanisms to limit the
fraction of its processing resources that can be consumed by any one
CE or by the set of CEs of a given customer. For example, a PE might
implement a form of rate limiting on RSVP messages that it receives
from each CE. We observe that these security risks and measures
related to PE resource usage are very similar for any control-plane
protocol operating between CE and PE (e.g., RSVP, routing,
multicast).
The second concern arises only when the service provider chooses to
offer resource reservation across the backbone, as described in
Section 4. In this case, the concern may be that a single customer
might attempt to reserve a large fraction of backbone capacity,
perhaps with a coordinated effort from several different CEs, thus
denying service to other customers using the same backbone.
[RFC4804] provides some guidance on the security issues when RSVP
reservations are aggregated onto MPLS tunnels, which are applicable
to the situation described here. We note that a provider MAY use
local policy to limit the amount of resources that can be reserved by
a given customer from a particular PE, and that a policy server could
be used to control the resource usage of a given customer across
multiple PEs if desired. It is RECOMMENDED that an implementation of
this specification support local policy on the PE to control the
amount of resources that can be reserved by a given customer/CE.
Use of the VPN-IPv4 RSVP_HOP object requires exporting a PE VPN-IPv4
route to another AS, and potentially could allow unchecked access to
remote PEs if those routes were indiscriminately redistributed.
However, as described in Section 3.1, no route that is not within a
customer's VPN should ever be advertised to (or be reachable from)
that customer. If a PE uses a local address already within a
customer VRF (like PE-CE link address), it MUST NOT send this address
in any RSVP messages in a different customer VRF. A "control-plane"
VPN MAY be created across PEs and ASBRs and addresses in this VPN can
be used to signal RSVP sessions for any customers, but these routes
MUST NOT be advertised to, or made reachable from, any customer. An
implementation of the present document MAY support such operation
using a "control-plane" VPN. Alternatively, ASBRs MAY implement the
Davie, et al. Standards Track [Page 31]
RFC 6016 RSVP for L3VPNs October 2010
signaling procedures described in Section 5.2.1, even if admission
control is not required on the inter-AS link, as these procedures do
not require any direct P/PE route advertisement out of the AS.
Finally, certain operations described herein (Section 3) require an
ASBR or PE to receive and locally process a signaling packet
addressed to the BGP next hop address advertised by that router.
This requirement does not strictly apply to MPLS/BGP VPNs [RFC4364].
This could be viewed as opening ASBRs and PEs to being directly
addressable by customer devices where they were not open before, and
could be considered a security issue. If a provider wishes to
mitigate this situation, the implementation MAY support the "control
protocol VPN" approach described above. That is, whenever a
signaling message is to be sent to a PE or ASBR, the address of the
router in question would be looked up in the "control protocol VPN",
and the message would then be sent on the LSP that is found as a
result of that lookup. This would ensure that the router address is
not reachable by customer devices.
[RFC4364] mentions use of IPsec both on a CE-CE basis and PE-PE
basis:
Cryptographic privacy is not provided by this architecture, nor by
Frame Relay or ATM VPNs. These architectures are all compatible
with the use of cryptography on a CE-CE basis, if that is desired.
The use of cryptography on a PE-PE basis is for further study.
The procedures specified in the present document for admission
control on the PE-CE links (Section 3) are compatible with the use of
IPsec on a PE-PE basis. The optional procedures specified in the
present document for admission control in the Service Provider's
backbone (Section 4) are not compatible with the use of IPsec on a
PE-PE basis, since those procedures depend on the use of PE-PE MPLS
TE Tunnels to perform aggregate reservations through the Service
Provider's backbone.
[RFC4923] describes a model for RSVP operation through IPsec
Gateways. In a nutshell, a form of hierarchical RSVP reservation is
used where an RSVP reservation is made for the IPsec tunnel and then
individual RSVP reservations are admitted/aggregated over the tunnel
reservation. This model applies to the case where IPsec is used on a
CE-CE basis. In that situation, the procedures defined in the
present document would simply apply "as is" to the reservation
established for the IPsec tunnel(s).
Davie, et al. Standards Track [Page 32]
RFC 6016 RSVP for L3VPNs October 2010
11. Acknowledgments
Thanks to Ashwini Dahiya, Prashant Srinivas, Yakov Rekhter, Eric
Rosen, Dan Tappan, and Lou Berger for their many contributions to
solving the problems described in this document. Thanks to Ferit
Yegenoglu for his useful comments. We also thank Stefan Santesson,
Vijay Gurbani, and Alexey Melnikov for their review comments. We
thank Richard Woundy for his very thorough review and comments
including those that resulted in additional text discussing scenarios
of admission control reject in the MPLS VPN cloud. Also, we thank
Adrian Farrel for his detailed review and contributions.
Davie, et al. Standards Track [Page 33]
RFC 6016 RSVP for L3VPNs October 2010
Appendix A. Alternatives Considered
At this stage, a number of alternatives to the approach described
above have been considered. We document some of the approaches
considered here to assist future discussion. None of these have been
shown to improve upon the approach described above, and the first two
seem to have significant drawbacks relative to the approach described
above.
Appendix A.1. GMPLS UNI Approach
[RFC4208] defines the GMPLS UNI. In Section 7, the operation of the
GMPLS UNI in a VPN context is briefly described. This is somewhat
similar to the problem tackled in the current document. The main
difference is that the GMPLS UNI is primarily aimed at the problem of
allowing a CE device to request the establishment of a Label Switched
Path (LSP) across the network on the other side of the UNI. Hence,
the procedures in [RFC4208] would lead to the establishment of an LSP
across the VPN provider's network for every RSVP request received,
which is not desired in this case.
To the extent possible, the approach described in this document is
consistent with [RFC4208], while filling in more of the details and
avoiding the problem noted above.
Appendix A.2. Label Switching Approach
Implementations that always look at IP headers inside the MPLS label
on the egress PE can intercept Path messages and determine the
correct VRF and RSVP state by using a combination of the
encapsulating VPN label and the IP header. In our view, this is an
undesirable approach for two reasons. Firstly, it imposes a new MPLS
forwarding requirement for all data packets on the egress PE.
Secondly, it requires using the encapsulating MPLS label to identify
RSVP state, which runs counter to existing RSVP principle and
practice where all information used to identify RSVP state is
included within RSVP objects. RSVP extensions such as COPS/RSVP
[RFC2749] which re-encapsulate RSVP messages are incompatible with
this change.
Appendix A.3. VRF Label Approach
Another approach to solving the problems described here involves the
use of label switching to ensure that Path, Resv, and other RSVP
messages are directed to the appropriate VRF on the next RSVP hop
(e.g., egress PE). One challenge with such an approach is that
[RFC4364] does not require labels to be allocated for VRFs, only for
customer prefixes, and that there is no simple, existing method for
Davie, et al. Standards Track [Page 34]
RFC 6016 RSVP for L3VPNs October 2010
advertising the fact that a label is bound to a VRF. If, for
example, an ingress PE sent a Path message labelled with a VPN label
that was advertised by the egress PE for the prefix that matches the
destination address in the Path, there is a risk that the egress PE
would simply label-switch the Path directly on to the CE without
performing RSVP processing.
A second challenge with this approach is that an IP address needs to
be associated with a VRF and used as the PHOP address for the Path
message sent from ingress PE to egress PE. That address needs to be
reachable from the egress PE, and to exist in the VRF at the ingress
PE. Such an address is not always available in today's deployments,
so this represents at least a change to existing deployment
practices.
Appendix A.4. VRF Label Plus VRF Address Approach
It is possible to create an approach based on that described in the
previous section that addresses the main challenges of that approach.
The basic approach has two parts: (a) define a new BGP Extended
Community to tag a route (and its associated MPLS label) as pointing
to a VRF; (b) allocate a "dummy" address to each VRF, specifically to
be used for routing RSVP messages. The dummy address (which could be
anything, e.g., a loopback of the associated PE) would be used as a
PHOP for Path messages and would serve as the destination for Resv
messages but would not be imported into VRFs of any other PE.
References
Normative References
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert
Option", RFC 2711, October 1999.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B.
Davie, "Aggregation of RSVP for IPv4 and IPv6
Reservations", RFC 3175, September 2001.
Davie, et al. Standards Track [Page 35]
RFC 6016 RSVP for L3VPNs October 2010
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le
Faucheur, "BGP-MPLS IP Virtual Private Network (VPN)
Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4804] Le Faucheur, F., "Aggregation of Resource ReSerVation
Protocol (RSVP) Reservations over MPLS TE/DS-TE
Tunnels", RFC 4804, February 2007.
Informative References
[ALERT-USAGE] Le Faucheur, F., Ed., "IP Router Alert Considerations
and Usage", Work in Progress, July 2010.
[LER-OPTIONS] Smith, D., Mullooly, J., Jaeger, W., and T. Scholl,
"Requirements for Label Edge Router Forwarding of IPv4
Option Packets", Work in Progress, May 2010.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan,
R., and A. Sastry, "The COPS (Common Open Policy
Service) Protocol", RFC 2748, January 2000.
[RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan,
R., and A. Sastry, "COPS usage for RSVP", RFC 2749,
January 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
F., and S. Molendini, "RSVP Refresh Overhead Reduction
Extensions", RFC 2961, April 2001.
Davie, et al. Standards Track [Page 36]
RFC 6016 RSVP for L3VPNs October 2010
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value",
RFC 3097, April 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C.,
and M. Davenport, "Generic Aggregate Resource
ReSerVation Protocol (RSVP) Reservations", RFC 4860,
May 2007.
[RFC4923] Baker, F. and P. Bose, "Quality of Service (QoS)
Signaling in a Nested Virtual Private Network",
RFC 4923, August 2007.
[RFC5824] Kumaki, K., Zhang, R., and Y. Kamite, "Requirements
for Supporting Customer Resource ReSerVation Protocol
(RSVP) and RSVP Traffic Engineering (RSVP-TE) over a
BGP/MPLS IP-VPN", RFC 5824, April 2010.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General
Internet Signalling Transport", RFC 5971,
October 2010.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Signaling Layer Protocol (NSLP) for Quality-of-Service
Signaling", RFC 5974, October 2010.
[RSVP-KEYING] Behringer, M., Faucheur, F., and B. Weis,
"Applicability of Keying Methods for RSVP Security",
Work in Progress, September 2010.
Davie, et al. Standards Track [Page 37]
RFC 6016 RSVP for L3VPNs October 2010
Authors' AddressesLepinski and Turner Expires July 2015 [Page 3]
Internet-Draft BGPsec Overview January 2014
to determine whether a received route was actually originated by an
AS authorized to originate that route (see [RFC6483] and [RFC7115]).
By instituting a local policy that prefers routes with origins
validated using RPKI data (versus routes to the same prefix that
cannot be so validated) an AS can protect itself from certain mis-
origination attacks. However, use of RPKI data alone provides little
or no protection against a sophisticated attacker. Such an attacker
could, for example, conduct a route hijacking attack by appending an
authorized origin AS to an otherwise illegitimate AS path. (See [I-
D.sidr-bgpsec-threats] for a detailed discussion of the BGPsec threat
model.)
BGPsec extends the RPKI by adding an additional type of certificate,
referred to as a BGPsec router certificate, that binds an AS number
to a public signature verification key, the corresponding private key
of which is held by one or more BGP speakers within this AS. Private
keys corresponding to public keys in such certificates can then be
used within BGPsec to enable BGP speakers to sign on behalf of their
AS. The certificates thus allow a relying party to verify that a
BGPsec signature was produced by a BGP speaker belonging to a given
AS. The goal of BGPsec is to use such signatures to protect the AS
path data in BGP update messages so that a BGP speaker can assess the
validity of the AS path data in update messages that it receives.
3. BGPsec Operation
The core of BGPsec is a new optional (non-transitive) attribute,
called BGPsec_Path. This attribute includes both AS Path data as well
as a sequence of digital signatures, one for each AS in the path.
(The use of this new attribute is formally specified in [I-D.sidr-
bgpsec-protocol].) A new signature is added to this sequence each
time an update message leaves an AS. The signature is constructed so
that any tampering with the AS path data or Network Layer
Reachability Information (NLRI) in the BGPsec update message can be
detected by the recipient of the message.
3.1. Negotiation of BGPsec
The use of BGPsec is negotiated using BGP capability advertisements
[RFC 5492]. Upon opening a BGP session with a peer, BGP speakers who
support (and wish to use) BGPsec include a newly-defined capability
in the OPEN message.
The use of BGPsec is negotiated separately for each address family.
This means that a BGP speaker could, for example, elect to use BGPsec
for IPv6, but not for IPv4 (or vice versa). Additionally, the use of
BGPsec is negotiated separately in the send and receive directions.
Lepinski and Turner Expires July 2015 [Page 4]
Internet-Draft BGPsec Overview January 2014
This means that a BGP speaker could, for example, indicate support
for sending BGPsec update messages but require that messages it
receives be traditional (non-BGPsec) update message. (To see why such
a feature might be useful, see Section 4.2.)
If the use of BGPsec is negotiated in a BGP session (in a given
direction, for a given address family) then both BGPsec update
messages (ones that contain the BGPsec_Path_Signature attribute) and
traditional BGP update messages (that do not contain this attribute)
can be sent within the session.
If a BGPsec-capable BGP speaker finds that its peer does not support
receiving BGPsec update messages, then the BGP speaker must remove
existing BGPsec_Path attribute from any update messages it sends to
this peer.
3.2. Update signing and validation
When a BGP speaker originates a BGPsec update message, it creates a
BGPsec_Path attribute containing a single signature. The signature
protects the Network Layer Reachability Information (NLRI), the AS
number of the originating AS, and the AS number of the peer AS to
whom the update message is being sent. Note that the NLRI in a BGPsec
update message is restricted to contain only a single prefix.
When a BGP speaker receives a BGPsec update message and wishes to
propagate the route advertisement contained in the update to an
external peer, it adds a new signature to the BGPsec_Path attribute.
This signature protects everything protected by the previous
signature, plus the AS number of the new peer to whom the update
message is being sent.
Each BGP speaker also adds a reference, called a Subject Key
Identifier (SKI), to its BGPsec Router certificate. The SKI is used
by a recipient to select the public key (and associated router
certificate data) needed for validation.
As an example, consider the following case in which an advertisement
for 192.0.2/24 is originated by AS 1, which sends the route to AS 2,
which sends it to AS 3, which sends it to AS 4. When AS 4 receives a
BGPsec update message for this route, it will contain the following
data:
. NLRI : 192.0.2/24
. AS path data: 3 2 1
. BGPsec_Path contains 3 signatures :
Lepinski and Turner Expires July 2015 [Page 5]
Internet-Draft BGPsec Overview January 2014
o Signature from AS 1 protecting
192.0.2/24, AS 1 and AS 2
o Signature from AS 2 protecting
Everything AS 1's signature protected, and AS 3
o Signature from AS 3 protecting
Everything AS 2's signature protected, and AS 4
When a BGPsec update message is received by a BGP speaker, the BGP
speaker can validate the message as follows. For each signature, the
BGP speaker first needs to determine if there is a valid RPKI Router
certificate matching the SKI and containing the appropriate AS
number. (This would typically be done by looking up the SKI in a
cache of data extracted from valid RPKI objects. A cache allows
certificate validation to be handled via an asynchronous process,
which might execute on another device.)
The BGP speaker then verifies the signature using the public key from
this BGPsec router certificate. If all the signatures can be verified
in this fashion, the BGP speaker is assured that the update message
it received actually came via the AS path specified in the update
message.
In the above example, upon receiving the BGPsec update message, a BGP
speaker for AS 4 would do the following. First, it would look at the
SKI for the first signature and see if this corresponds to a valid
BGPsec Router certificate for AS 1. Next, it would verify the first
signature using the key found in this valid certificate. Finally, it
would repeat this process for the second and third signatures,
checking to see that there are valid BGPsec router certificates for
AS 2 and AS 3 (respectively) and that the signatures can be verified
with the keys found in these certificates. Note that the BGPsec
speaker for AS 4 should additionally perform origin validation as per
RFC 6483 [RFC6483]. However, such origin validation is independent of
BGPsec.
4. Design and Deployment Considerations
In this section we provide a brief overview of several additional topics that
commonly arise in the discussion of BGPsec.
4.1. Disclosure of topology information
A key requirement in the design of BGPsec was that BGPsec not
Lepinski and Turner Expires July 2015 [Page 6]
Internet-Draft BGPsec Overview January 2014
disclose any new information about BGP peering topology. Since many
ISPs feel peering topology data is proprietary, further disclosure of
it would inhibit BGPsec adoption.
In particular, the topology information that can be inferred from
BGPsec update messages is exactly the same as that which can be
inferred from equivalent (non-BGPsec) BGP update messages.
4.2. BGPsec router assumptions
In order to achieve its security goals, BGPsec assumes additional
capabilities in routers. In particular, BGPsec involves adding
digital signatures to BGP update messages, which will significantly
increase the size of these messages. Therefore, an AS that wishes to
receive BGPsec update messages will require additional memory in its
routers to store (e.g., in ADJ RIBs) the data conveyed in these
larger update messages. Additionally, the design of BGPsec assumes
that an AS that elects to receive BGPsec update messages will do some
cryptographic signature verification at its edge router. This
verification may require additional capability in these edge routers.
Additionally, BGPsec requires that all BGPsec speakers will support
4-byte AS Numbers [RFC4893]. This is because the co-existence
strategy for 4-byte AS numbers and legacy 2-byte AS speakers that
gives special meaning to AS 23456 is incompatible with the security
the security properties that BGPsec seeks to provide.
For this initial version of BGPsec, optimizations to minimize the
size of BGPsec updates or the processing required in edge routers
have not been considered. Such optimizations may be considered in the
future.
Note also that the design of BGPsec allows an AS to send BGPsec
update messages (thus obtaining protection for routes it originates)
without receiving BGPsec update messages. An AS that only sends, and
does not receive, BGPsec update messages will require much less
capability in its edge routers to deploy BGPsec. In particular, a
router that only sends BGPsec update messages does not need
additional memory to store larger updates and requires only minimal
cryptographic capability (as generating one signature per outgoing
update requires less computation than verifying multiple signatures
on each incoming update message). See [I-D.sidr-bgpsec-ops] for
further discussion related to Edge ASes that do not provide transit.
4.3. BGPsec and consistency of externally visible data
Finally note that, by design, BGPsec prevents parties that propagate
route advertisements from including inconsistent or erroneous
Lepinski and Turner Expires July 2015 [Page 7]
Internet-Draft BGPsec Overview January 2014
information within the AS-Path (without detection). In particular,
this means that any deployed scenarios in which a BGP speaker
constructs such an inconsistent or erroneous AS Path attribute will
break when BGPsec is used.
For example, when BGPsec is not used, it is possible for a single
autonomous system to have one peering session where it identifies
itself as AS 111 and a second peering session where it identifies
itself as AS 222. In such a case, it might receive route
advertisements from the first peering session (as AS 111) and then
add AS 222 (but not AS 111) to the AS-Path and propagate them within
the second peering session.
Such behavior may very well be innocent and performed with the
consent of the legitimate holder of both AS 111 and 222. However, it
is indistinguishable from the following man-in-the-middle attack
performed by a malicious AS 222. First, the malicious AS 222
impersonates AS 111 in the first peering session (essentially
stealing a route advertisement intended for AS 111). The malicious AS
222 then inserts itself into the AS path and propagates the update to
its peers.
Therefore, when BGPsec is used, such an autonomous system would
either need to assert a consistent AS number in all external peering
sessions, or else it would need to add both AS 111 and AS 222 to the
AS-Path (along with appropriate signatures) for route advertisements
that it receives from the first peering session and propagates within
the second peering session. See [I-D.sidr-as-migration] for a
detailed discussion of how to reasonably manage AS number migrations
while using BGPsec.
5. Security Considerations
This document provides an overview of BPSEC; it does not define the
BGPsec extension to BGP. The BGPsec extension is defined in [I-
D.sidr-bgpsec-protocol]. The threat model for the BGPsec is
described in [I-D.sidr-bgpsec-threats].
6. IANA Considerations
None.
7.1. Normative References
Lepinski and Turner Expires July 2015 [Page 8]
Internet-Draft BGPsec Overview January 2014
[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Numbers", RFC 4893, May 2007.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, February 2009.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", February 2012.
[RFC6483] Huston, G., and G. Michaelson, "Validation of Route
Origination using the Resource Certificate PKI and ROAs", February
2012.
[RFC7132] Kent, S., and A. Chi, "Threat Model for BGP Path Security",
RFC 7132, February 2014.
[RFC7115] Bush, R., "RPKI-Based Origin Validation Operation", RFC
7115, January 2014.
[I-D.sidr-bgpsec-protocol] Lepinski, M., Ed., "BPSEC Protocol
Specification", draft-ietf-sidr-bgpsec-protocol, work-in-progress.
[I-D.sidr-bgpsec-ops] Bush, R., "BGPsec Operational Considerations",
draft-ietf-sidr-bgpsec-ops, work-in-progress.
[I-D.sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, &
Signature Formats", draft-ietf-sidr-bgpsec-algs, work-in-progress.
[I-D.sidr-bgpsec-pki-profiles] Reynolds, M. and S. Turner, "A Profile
for BGPsec Router Certificates, Certificate Revocation Lists, and
Certification Requests", draft-sidr-bgpsec-pki-profiles, work-in-
progress.
[I-D.sidr-as-migration] George, W. and S. Murphy, "BGPSec
Considerations for AS Migration", draft-ietf-sidr-as-migration, work-
in-progress.
7.2. Informative References
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
4272, January 2006
[I-D.sriram-bgpsec-design-choices] Sriram, K., "BGPsec Design Choices
and Summary of Supporting Discussions", draft-sriram-bgpsec-design-
choices, work-in-progress.
Lepinski and Turner Expires July 2015 [Page 9]
Internet-Draft BGPsec Overview January 2014
[RFC7353] Bellovin, S., R. Bush, and D. Ward, "Security Requirements
for BGP Path Validation", RFC 7353, August 2014.
Author's' Addresses
Matt Lepinski
BBN Technologies
10 Moulton Street
Cambridge MA 02138
Email: mlepinski.ietf@gmail.com
Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
Email: turners@ieca.com
Lepinski and Turner Expires July 2015 [Page 10]