Internet DRAFT - draft-wang-sidrops-fcbgp-framework
draft-wang-sidrops-fcbgp-framework
Secure Inter-Domain Routing K. Xu
Internet-Draft X. Wang
Intended status: Standards Track Z. liu
Expires: 6 January 2024 L. Qi
J. Wu
Tsinghua University
5 July 2023
Framework of Forwarding Commitment BGP
draft-wang-sidrops-fcbgp-framework-00
Abstract
This document defines a standard profile for the framework of
Forwarding Commitment BGP (FC-BGP). Forwarding Commitment（FC）is a
cryptographically signed code to certify an AS's routing intent on
its directly connected hops. Based on FC, the goal of FC-BGP is to
build a secure inter-domain system that can simultaneously
authenticate AS_PATH attribute in BGP-UPDATE and validate network
forwarding on the dataplane.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://LucasWang86.github.io/fcbgp--framework/draft-wang-sidr-
fcbgpframework.html. Status information for this document may be
found at https://datatracker.ietf.org/doc/draft-wang-sidrops-fcbgp-
framework/.
Discussion of this document takes place on the Secure Inter-Domain
Routing Working Group mailing list (mailto:sidr@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/sidr/.
Subscribe at https://www.ietf.org/mailman/listinfo/sidr/.
Source for this draft and an issue tracker can be found at
https://github.com/LucasWang86/fcbgp--framework.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Xu, et al. Expires 6 January 2024 [Page 1]
Internet-Draft fcbgp-framework July 2023
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 https://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 6 January 2024.
Copyright Notice
Copyright (c) 2023 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Threat Model and Assumptions . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Forwarding Commitment . . . . . . . . . . . . . . . . . . . . 6
5. BGP Path Validation . . . . . . . . . . . . . . . . . . . . . 6
6. Forwarding Validation . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Xu, et al. Expires 6 January 2024 [Page 2]
Internet-Draft fcbgp-framework July 2023
1. Introduction
The fundamental cause of the path manipulation attacks in Internet
inter-domain routing is that the de facto Border Gateway Protocol
(BGP) [RFC4271] does not have built-in mechanisms to authenticate
routing announcements. As a result, an adversary can announce
virtually arbitrary paths to a prefix while the network cannot
effectively verify the authenticity of the route announcements.
In addition to the lack of control plane authentication, ensuring
that the actual forwarding paths in the dataplane comply with the
control plane decisions is also missing in today's inter-domain
routing system. This fundamentally limits ASes from filtering
unwanted traffic which takes an unauthorized AS path.
The representative schemes to secure inter-domain routing are RPKI
[RFC6480] and BGPsec [RFC8205]. RPKI provides a foundation for
validating the origins of BGP routes. Meanwhile, BGPsec directly
builds the path authentication of BGP routes into the BGP path
construction itself, where an AS is required to iteratively verify
the signatures of each prior AS hop before extending the verification
chain with its own approval. As a result, a single legacy or
malicious AS can terminate the verification chain, preventing the
downstream ASes from reinstating the verification process. This
creates the well-known chicken-and-egg problem where the early
adopters receive no deployment benefits which further limits new
adoption.
Finally, due to the lack of practical protocols to check the
consistency between the dataplane forwarding and control-plane
decisions, enforcing path authorization in the inter-domain
forwarding has been not possible to date.
This document specifies a framework named FC-BGP, an incrementally
deployable security augment to the Internet inter-domain routing and
forwarding. FC-BGP relies on the Resource Public Key Infrastructure
(RPKI) certificates that attest to the allocation of AS number and IP
address resources. To support FC-BGP, a BGP speaker needs to possess
a private key associated with an RPKI router certificate [RFC8209]
that corresponds to the BGP speaker's AS number.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Xu, et al. Expires 6 January 2024 [Page 3]
Internet-Draft fcbgp-framework July 2023
2. Threat Model and Assumptions
We assume that ASes participating in FC-BGP have access to RPKI,
which stores authoritative information about the mapping between AS
numbers and their owned IP prefixes, as well as ASes' public keys.
Given the above assumptions, we consider the following adversary:
1. On the control plane, the adversary can launch path manipulation
attacks. This means that the adversary will try to manipulate
the routing paths to victim ASes or prefixes by sending bogus BGP
updates. For example, the adversary might try to reroute traffic
to the victim ASes/prefixes through ASes that they control, in
order to perform (encrypted) traffic analysis.
2. On the dataplane, the adversary can spoof source addresses and
send unwanted network traffic to the victim ASes prefixes.
3. Overview
| 1.BGP Announcement Path |
+---------------------+------------->|
Control | ^ | |
Plane | 1.1 | | 1.2 |
| Generation | v Validation |
+----+---+ +-+----------+ +----+---+
| | | Forwarding | | |
| AS A | | Commitment | | AS B |
| | | (FC) | | |
+----+---+ +----------+-+ +----+---+
| ^ | |
Data | 2.2 | | 2.1 |
Plane | Validation | | Binding |
| | v |
|<-----------+-----------------------+
| 2.Forwarding Path |
Figure 1: Overview of FC-BGP.
An overview of FC-BGP is shown in Figure 1. The key primitive in FC-
BGP is the Forwarding Commitment (FC), which is a publicly verifiable
code that certifies an AS's routing intent on one of its directly
connected hops, i.e., an FC indicates whether the AS is willing to
carry traffic for a specific prefix over the hop. Upon receiving a
BGP announcement, if AS A decides to accept the route and extends the
path to its (selected) neighbor AS B, AS A commits its routing intent
by generating a cryptographically-signed FC. Therefore, downstream
on-path ASes (such as AS B) can validate the correctness of a BGP
update by checking the FCs associated with the individual hops on the
Xu, et al. Expires 6 January 2024 [Page 4]
Internet-Draft fcbgp-framework July 2023
AS-path. Because the FCs are designed to be hop-specific and path-
agnostic, a deployed AS can immediately certify its routing intent
regardless of the deployment status of other ASes. This is
fundamentally different from existing path-level BGP authentication
protocol (e.g., BGPsec) where an on-path AS cannot approve any form
of routing intent unless all on-path ASes are upgraded.
FC-BGP is not bound to a specific FC propagation method and can use,
but is not limited to, the following mechanisms:
1. Extend BGP Update Message. Assign a new BGP Update Path
Attribute to carry FCs.
2. Propose a new propagation protocol that guarantees consistent FC
propagation.
3. Use existing network infrastructure, such as extending RPKI to
add a new signed object to store FCs.
Meanwhile, the flexibility of FCs further enables efficient
forwarding validation on the dataplane. Specifically, because the
FCs are self-proving, an AS can conceptually construct a certified
AS-path using a list of consecutive per-hop FCs, and then binds its
network traffic (identified by < src-AS, dst-AS, prefix >) to the
path, such as < AS B, AS A, P(B) >, where P(B) is the prefix owned by
AS B destined to AS A. This binding information essentially defines
the authorized forwarding path for the traffic < AS B, AS A, P(B) >.
Therefore, by advertising the binding information globally, both on-
path and off-path ASes are aware of the desired forwarding paths so
that they can collaboratively discard unwanted traffic that takes
unauthorized paths.
Similar to FC propagation, the propagation of binding messages in FC-
BGP is not restricted to specific methods and can be, but is not
limited to, the following:
1. Propose a new propagation protocol that guarantees the
consistency of binding messages.
2. Use existing network infrastructure, such as extending RPKI to
add a new signed object to store binding messages.
Xu, et al. Expires 6 January 2024 [Page 5]
Internet-Draft fcbgp-framework July 2023
4. Forwarding Commitment
FC-BGP enhances the security of inter-domain routing and forwarding
by building a publicly verifiable view of the forwarding commitments.
At a high level, a routing commitment (FC) of an AS is a
cryptographically-signed primitive that binds the AS's routing
decisions (e.g. willing to forward traffic for a prefix via one of
its directly-connected hops). With this view, ASes are able to:
1. Evaluate the authenticity (or security) of the control plane BGP
announcements based on committed routing decisions from relevant
ASes.
2. Ensure that the dataplane forwarding is consistent with the
routing decisions committed in the control plane.
Upon receiving a BGP announcement, an upgraded AS generates a
corresponding FC that contains the core information of the
announcement, such as prefixes, sending AS, and receiving AS, and
will be signed with the sender's private key for security.
5. BGP Path Validation
FClist:F(C,D,P)
FClist:F(B,C,P) F(B,C,P)
FClist:F(A,B,P) F(A,B,P) F(A,B,P)
| AS Path:A | AS Path:A-B | AS Path:A-B-C |
+---------------->+----------------->+----------------->|
| | | |
| | | |
| | | |
+----+---+ +----+---+ +----+---+ +----+---+
| AS A +--------+ AS B +---------+ AS C +---------+ AS D |
+----+---+ +----+---+ +----+---+ +----+---+
| | | |
| F(C,D,P)-(src:P(D),dst:P(A))+<-----------------+
| | | |
| | | |
| |<-----------------+------------------+
| | F(B,C,P)-(src:P(D),dst:P(A)) |
| | | |
| | | |
|<----------------+------------------+------------------+
F(A,B,P)-(src:P(D),dst:P(A))
Figure 2: Example of FC-BGP.
Xu, et al. Expires 6 January 2024 [Page 6]
Internet-Draft fcbgp-framework July 2023
Consider an illustrative example using the four-AS topology shown in
Figure 2. In this process, FC-BGP generates the corresponding FC and
propagates to downstream ASes (e.g., adding it to the Path Attributes
of the BGP updates), so that the receiving AS can validate the
authenticity of the announcement. Suppose AS C receives a BGP
announcement P(A): A->B->C from its neighbor B. If AS C decides to
further advertise this path to its neighbor D based on its routing
policy, it generates a FC F(C,D,P), propagates it to AS D, and
forwards the BGP update message to D.
When AS D receives the route from C, it can determine the
authenticity of the current AS path by verifying the list of FCs
correctly reflects the AS path.
6. Forwarding Validation
AS shown in Figure 2, to enable forwarding validation, ASes need to
announce the traffic-FCs binding relationships. Specifically,
suppose AS D confirms that the AS-path C->B->A for reaching prefix
P(A) is legitimate, it binds the traffic (src:P(D),dst:P(A)) (where
P(D) is the prefix owned by AS D) with the FC list F(C,D,P)-F(B,C,P)-
F(A,B,P), and then publicly announces the binding relationship.
Upon receiving the relationship, other ASes can build traffic
filtering rules based on the relationship to enable forwarding
validation on dataplane. For instance, by interpreting the binding
relationship produced by AS D, AS C confirms that the traffic
(src:P(D), dst:P(A)) shall be forwarded over the link L(CD), and AS B
confirms that the traffic shall be forwarded on link L(BC). Network
traffic violating these binding rules is considered to take
unauthorized paths.
To enable network-wide forwarding verification, these binding rules
may be further broadcast globally (instead of just informing the ASes
on the AS-path) so that off-path ASes can also discard unauthorized
flows.
7. Security Considerations
7.1. Security Guarantees
When FC-BGP used in conjunction with origin validation, the following
security guarantees can be achieved:
1. The source AS in a route announcement is authorized.
2. FC-BGP speakers on the AS-Path are authorized to propagate the
route announcements.
Xu, et al. Expires 6 January 2024 [Page 7]
Internet-Draft fcbgp-framework July 2023
3. The forwarding path of packets is consistent with the routing
path announced by the FC-BGP speakers.
FC-BGP is designed to enhance the security of control plane routing
and dataplane forwarding in the Internet at the network layer.
Specifically, FC-BGP allows an AS to independently prove its BGP
routing decisions with publicly verifiable cryptography commitments,
based on which any on-path AS can verify the authenticity of a BGP
path; meanwhile FC-BGP ensures the consistency between the control
plane and dataplane, i.e., the network traffic shall take the
forwarding path that is consistent with the control plane routing
decisions, or otherwise be discarded. More crucially, the above
security guarantees offered by FC-BGP are not binary, i.e., secure or
non-secure. Instead, the security benefits are strictly
monotonically increasing as the deployment rate of FC-BGP (i.e., the
percentage of ASes that are upgraded to support FC-BGP) increases.
8. IANA Considerations
This document has no IANA actions.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/rfc/rfc4271>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/rfc/rfc6480>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/rfc/rfc8205>.
Xu, et al. Expires 6 January 2024 [Page 8]
Internet-Draft fcbgp-framework July 2023
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", RFC 8209,
DOI 10.17487/RFC8209, September 2017,
<https://www.rfc-editor.org/rfc/rfc8209>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Ke Xu
Tsinghua University
Beijing
China
Email: xuke@tsinghua.edu.cn
Xiaoliang Wang
Tsinghua University
Beijing
China
Email: wangxiaoliang@cnu.edu.cn
Zhuotao liu
Tsinghua University
Beijing
China
Email: zhuotaoliu@tsinghua.edu.cn
Li Qi
Tsinghua University
Beijing
China
Email: qli01@tsinghua.edu.cn
Jianping Wu
Tsinghua University
Beijing
China
Email: jianping@cernet.edu.cn
Xu, et al. Expires 6 January 2024 [Page 9]
