ASPA-based AS_PATH Validation for BGP Export
draft-zhang-sidrops-aspa-egress-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Jia Zhang | ||
| Last updated | 2024-07-24 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| 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-zhang-sidrops-aspa-egress-00
SIDR Operations Working Group J. Zhang
Internet-Draft Zhongguancun Laboratory
Intended status: Standards Track 24 July 2024
Expires: 25 January 2025
ASPA-based AS_PATH Validation for BGP Export
draft-zhang-sidrops-aspa-egress-00
Abstract
This document describes that a BGP speaker may perform AS_PATH
verification on the routes it sends to BGP neighbors at external BGP
(eBGP) egress based on Autonomous System Provider Authorization
(ASPA) objects in the Resource Public Key Infrastructure (RPKI).
Before BGP speakers advertise routes to external peers at eBGP
egress, performing ASPA-based AS_PATH verification can prevent route
leaks to external peers.
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 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 25 January 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang Expires 25 January 2025 [Page 1]
Internet-Draft ASPA validation for BGP Export July 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3
3. ASPA-based AS_PATH Verification at eBGP Egress . . . . . . . 3
3.1. Procedure of Verification . . . . . . . . . . . . . . . . 3
3.2. Scenarios that do not require egress verification . . . . 4
4. Operational Considerations . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Autonomous System Provider Authorization (ASPA) objects in the RPKI
can be used to verify BGP AS_PATH for detection and mitigation of
route leaks and certain prefix hijacks involving forged origins or
forged path-segments with some improbable AS paths. The ASPA object
profile is defined in [I-D.ietf-sidrops-aspa-profile].
In the procedures of ASPA-based BGP AS_PATH verification defined in
[I-D.ietf-sidrops-aspa-verification], ingress external BGP (eBGP)
router of an AS receives routes from its BGP peers, and perform ASPA-
based BGP AS_PATH verification and mitigation at eBGP ingress, as
recomendations specified in Section 8.1 in
[I-D.ietf-sidrops-aspa-verification]. BGP AS_PATH verification at
eBGP ingress can detect and prevent the route leaks in the routes
received from BGP neighbors, but route leaks could occur at the local
AS where a BGP speaker exports routes to its external peer at eBGP
egress. It lacks the ability to prevent route leaks from occuring at
the local AS.
This document describes ASPA-based BGP AS_PATH verification at eBGP
egress. It does not change the semantics or procedures of ASPA-based
BGP AS_PATH verification defined in
Zhang Expires 25 January 2025 [Page 2]
Internet-Draft ASPA validation for BGP Export July 2024
[I-D.ietf-sidrops-aspa-verification]. It explains an important use
case and specifics of correct implementation of ASPA-based path
verification in eBGP egress policies, as [RFC8893] did with RPKI
origin validation for BGP export. ASPA-based BGP AS_PATH
verification at eBGP egress is a little bit different from the
process at the eBGP ingress. By AS_PATH verification before sending
routes to BGP neighbors at eBGP egress, a BGP speaker can detect and
prevent imporper route propagation of route leaks.
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.
2. Suggested Reading
It is assumed that the reader understands BGP[RFC4271],
RPKI[RFC6480], ASPA object profile[I-D.ietf-sidrops-aspa-profile],
ASPA-based BGP AS_PATH
verification[I-D.ietf-sidrops-aspa-verification], and RPKI-ROV for
BGP export[RFC8893].
3. ASPA-based AS_PATH Verification at eBGP Egress
When a BGP speaker advertises a route to an external peer through
eBGP egress, the BGP speaker prepends its own AS number to the
AS_PATH of the route, and performs ASPA-based AS_PATH verification
before sending the route to the external peer.
3.1. Procedure of Verification
Suppose the BGP speaker is at AS X, and its external peer is at AS Y,
and the AS_PATH P of the route to be advertised to external peer by
the BGP speaker is represented by {AS X, AS(N), ..., AS(2), AS(1)},
where AS(1) is the origin AS, and AS X is the local AS number added
by the BGP speaker of AS X at eBGP egress.
Zhang Expires 25 January 2025 [Page 3]
Internet-Draft ASPA validation for BGP Export July 2024
+------------------------+
| AS X |
| |
+-------+ eBGP | +----+ iBGP +----+ | eBGP +--------+
| AS(N) |-------->>| R1 |------>>| R2 |-------->>| AS Y |
+-------+ | +----+ +----+ \| +--------+
| \
+------------------------+\
\ eBGP egress
Figure 1: Illustration of the eBGP egress.
The method of ASPA-based AS_PATH verification at the eBGP egress of
the BGP speaker is described as follows:
1. Regard the external neighbor AS Y as the virtual receiving/
validating AS point.
2. The BGP roles of AS X and AS Y, including Customer, Provider,
Route Server (RS), Route Server Client (RS-client) and Peer, are
defined in [RFC9234], and they can be configured locally and used for
the path verification.
3. If AS X is the Customer or Peer to AS Y, or, AS Y is a
(transparent or non-transparent) Route Server (RS) and AS X is a RS-
client, use the upstream path verification algorithm (described in
[I-D.ietf-sidrops-aspa-verification]) to verify the AS_PATH P.
4. If AS X is the Provider to AS Y, use the downstream path
verification algorithm (described in
[I-D.ietf-sidrops-aspa-verification]) to verify the AS_PATH P.
3.2. Scenarios that do not require egress verification
In some scenarios, there is no requirement to perform egress ASPA-
based path verification.
1. Mutual-transit. If the relation between two ASes is mutual-
transit, they MAY export all kinds of routes to each other
([I-D.ietf-sidrops-aspa-verification]). There is no route leak
violating valley-free route policy.
2. A Route Server exports to a RS-client. The functionality of a
Route Server is to exchange routes among member ASes at an Internet
Exchange Provider (IXP) according to pre-configured rules. The
responsibility of route leak happened at an IXP is at member ASes,
not at Route Servers. Therefore, there is no need to do path
Zhang Expires 25 January 2025 [Page 4]
Internet-Draft ASPA validation for BGP Export July 2024
verification at RS egress, regardless of whether the RS is a
transparent RS or a non-transparent RS. Additionally, even if
verification is performed at the egress, as shown in Figure 2, both
the egress and ingress verification are upstream. Therefore, if the
verification result at the ingress is not "Invalid", the verification
result at the egress should also not be "Invalid". Therefore, ASPA
verification is not performed at the egress of the Route Server to
the RS-client.
RS Client RS RS Client
AS(N) -> AS X -> AS Y
| |
| |
+-----------------------------------------+ +-----------------------+
| R1(Ingress) -IBGP-> R2(Egress) | | R3(Ingress) |
+-----------------|-----------------------+ +-----------------------+
| AS_PATH | AS_PATH | | AS_PATH |
| AS(N) ... AS(1) | AS X AS(N) ... AS(1) | | AS X AS(N) ... AS(1) |
+-----------------|-----------------------+ +-----------------------+
| Upstream | Upstream | | Upstream |
+-----------------------------------------+ +-----------------------+
Figure 2: The verification at both the egress and ingress are
upstream.
4. Operational Considerations
The peering relationships between the local AS and its external
neighbor ASes, including Customer-Provider/Provider-Customer, Peer-
Peer, Route Server (RS) and RS-client, mutual-transit, are used in
path verification procedures to determine whether upstream or
downstream procedures should be applied. There are the following
possible ways to know the relations between the local AS and its
external neighbor AS: (1) The first way is to use the BGP Role
Capabilities exchanged in the BGP OPEN message as specified in
[RFC9234]. (2) The second way is to use ASPA objects registered by
the local AS and its external neighbor AS. (3) Another possible way
is to use local configuration. When the relation of two neighboring
ASes is mutual-transit, they are Customers of each other in BGP
roles. It can be confirmed by BGP roles advertised in the BGP OPEN
message, or configuration in local file. If a mutual-transit
relation is identified as Cutomer-Provider, a false positive of route
leak may be generated in path verification.
Zhang Expires 25 January 2025 [Page 5]
Internet-Draft ASPA validation for BGP Export July 2024
5. Security Considerations
The security considerations that apply to ASPA-based AS_PATH
verification (see [I-D.ietf-sidrops-aspa-verification]) also apply to
the procedure described in this document.
6. IANA Considerations
This document has no IANA actions
7. References
7.1. 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/info/rfc2119>.
[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/info/rfc8174>.
[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/info/rfc6480>.
[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/info/rfc4271>.
[RFC8893] Bush, R., Volk, R., and J. Heitz, "Resource Public Key
Infrastructure (RPKI) Origin Validation for BGP Export",
RFC 8893, DOI 10.17487/RFC8893, September 2020,
<https://www.rfc-editor.org/info/rfc8893>.
[RFC9234] Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K.
Sriram, "Route Leak Prevention and Detection Using Roles
in UPDATE and OPEN Messages", RFC 9234,
DOI 10.17487/RFC9234, May 2022,
<https://www.rfc-editor.org/info/rfc9234>.
7.2. Informative References
[I-D.ietf-sidrops-aspa-profile]
Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley,
R., and B. Maddison, "A Profile for Autonomous System
Zhang Expires 25 January 2025 [Page 6]
Internet-Draft ASPA validation for BGP Export July 2024
Provider Authorization", Work in Progress, Internet-Draft,
draft-ietf-sidrops-aspa-profile-18, 25 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-profile-18>.
[I-D.ietf-sidrops-aspa-verification]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
J., and K. Sriram, "BGP AS_PATH Verification Based on
Autonomous System Provider Authorization (ASPA) Objects",
Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
verification-17, 29 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-verification-18>.
Author's Address
Jia Zhang
Zhongguancun Laboratory
Beijing
China
Email: zhangj@mail.zgclab.edu.cn
Zhang Expires 25 January 2025 [Page 7]