draft-ietf-grow-bgpopsecupd-02.txt | draft-ietf-grow-bgpopsecupd-03.txt | |||
---|---|---|---|---|
Global Routing Operations T. Fiebig | Global Routing Operations T. Fiebig | |||
Internet-Draft MPI-INF | Internet-Draft MPI-INF | |||
Obsoletes: 7454 (if approved) N. Hilliard | Obsoletes: 7454 (if approved) N. Hilliard | |||
Intended status: Best Current Practice INEX | Intended status: Best Current Practice INEX | |||
Expires: 29 December 2024 27 June 2024 | Expires: 4 January 2025 3 July 2024 | |||
Updated BGP Operations and Security | Updated BGP Operations and Security | |||
draft-ietf-grow-bgpopsecupd-02 | draft-ietf-grow-bgpopsecupd-03 | |||
Abstract | Abstract | |||
The Border Gateway Protocol (BGP) is the protocol is a critical | The Border Gateway Protocol (BGP) is the protocol is a critical | |||
component in the Internet to exchange routing information between | component in the Internet to exchange routing information between | |||
network domains. Due to this central nature, it is important to | network domains. Due to this central nature, it is important to | |||
understand the security and reliability requirements that can and | understand the security and reliability requirements that can and | |||
should be ensured to prevent accidental or intentional routing | should be ensured to prevent accidental or intentional routing | |||
disturbances. | disturbances. | |||
skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 29 December 2024. | This Internet-Draft will expire on 4 January 2025. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 2, line 30 ¶ | skipping to change at page 2, line 30 ¶ | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
2. Scope of the Document . . . . . . . . . . . . . . . . . . . . 3 | 2. Scope of the Document . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Protection of the BGP Speaker and Session . . . . . . . . . . 3 | 3. Protection of the BGP Speaker and Session . . . . . . . . . . 3 | |||
3.1. BGP Session Protection . . . . . . . . . . . . . . . . . 3 | 3.1. BGP Session Protection . . . . . . . . . . . . . . . . . 3 | |||
3.2. BGP Speaker Management Interface Protection . . . . . . . 4 | 3.2. BGP Speaker Management Interface Protection . . . . . . . 4 | |||
4. NLRI Filtering . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. NLRI Filtering . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.1. Importing NLRI . . . . . . . . . . . . . . . . . . . . . 4 | 4.1. Importing NLRI . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.2. Exporting NLRI . . . . . . . . . . . . . . . . . . . . . 4 | 4.2. Originating and Redistributing NLRI . . . . . . . . . . . 5 | |||
4.3. General Considerations for Altering NLRI . . . . . . . . 5 | 4.3. General Considerations for Altering NLRI . . . . . . . . 5 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . 6 | 7.2. Informative References . . . . . . . . . . . . . . . . . 6 | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
1. Introduction | 1. Introduction | |||
The Border Gateway Protocol (BGP), specified in [RFC4271], is the | The Border Gateway Protocol (BGP), specified in [RFC4271], is the | |||
protocol used in the Internet to exchange routing information between | protocol used in the Internet to exchange routing information between | |||
network domains. BGP does not directly include mechanisms that | network domains. BGP does not directly include mechanisms that | |||
control whether the routes exchanged conform to the various | control whether the routes exchanged conform to the various | |||
guidelines defined by the Internet community. Furthermore, the BGP | guidelines defined by the Internet community. Furthermore, the BGP | |||
protocol itself, by its design, does not have any direct way to | protocol itself, by its design, does not have any direct way to | |||
skipping to change at page 3, line 45 ¶ | skipping to change at page 3, line 45 ¶ | |||
measures: | measures: | |||
* Prevent off-path attackers from injecting BGP messages into | * Prevent off-path attackers from injecting BGP messages into | |||
existing sessions. | existing sessions. | |||
* Prevent off-path attackers from interrupting existing sessions. | * Prevent off-path attackers from interrupting existing sessions. | |||
* Prevent off-path attackers from preventing the establishment of | * Prevent off-path attackers from preventing the establishment of | |||
new sessions. | new sessions. | |||
* Ensure that the volume of ingested messages does not threaten the | * Prevent remote systems from overwhelming the BGP speaker by | |||
availability of BGP speakers within the network. | sending large volumes of unsolicited packets or BGP messages. | |||
* Ensure that unstable sessions do not threaten the availability of | ||||
BGP speakers within the network. | ||||
3.2. BGP Speaker Management Interface Protection | 3.2. BGP Speaker Management Interface Protection | |||
In addition to the control plane / exchange of BGP protocol messages, | In addition to the control plane / exchange of BGP protocol messages, | |||
the management plane of BGP speakers must be appropriately secured. | the management plane of BGP speakers must be appropriately secured. | |||
Hence, operators MUST ensure that: | Hence, operators MUST ensure that: | |||
* No unauthorized third-parties can obtain access or connect to the | * No unauthorized third-parties can obtain access or connect to the | |||
management interface of a BGP speaker in a way that allows | management interface of a BGP speaker in a way that allows | |||
tainting confidentiality, integrity, or availability. | tainting confidentiality, integrity, or availability. | |||
skipping to change at page 4, line 43 ¶ | skipping to change at page 4, line 43 ¶ | |||
* The AS originating NLRI for a prefix MUST be globally authorized | * The AS originating NLRI for a prefix MUST be globally authorized | |||
to originate that prefix. Operators MAY deviate from this for | to originate that prefix. Operators MAY deviate from this for | |||
default routes (::/0 and 0.0.0.0/0), if they granted the specific | default routes (::/0 and 0.0.0.0/0), if they granted the specific | |||
neighbor permission to announce default routes towards them. | neighbor permission to announce default routes towards them. | |||
* The AS_PATH of the NLRI MUST NOT violate the valley-free principle | * The AS_PATH of the NLRI MUST NOT violate the valley-free principle | |||
[RFC4012], i.e., all ASes left of the originating AS in the | [RFC4012], i.e., all ASes left of the originating AS in the | |||
AS_PATH MUST be authorized to advertise the NLRI to the AS | AS_PATH MUST be authorized to advertise the NLRI to the AS | |||
directly to their left. | directly to their left. | |||
* The AS_PATH MUST NOT contain an AS number reserved for private use | * The AS_PATH MUST NOT contain AS numbers reserved for private | |||
[RFC6996]. | [RFC6996] or special-use cases not necessitating their presence in | |||
the global routing table [IANAASNSpec]. | ||||
4.2. Exporting NLRI | * The number of NLRI received from a neighbor MUST NOT exceed the | |||
resources of the local router. | ||||
When exporting NLRI from a neighbor, an operator MUST ensure that all | 4.2. Originating and Redistributing NLRI | |||
NLRI they export conform to the following properties by implementing | ||||
technical or organizational measures: | When originating NLRI or redistributing NLRI received from a | |||
neighbor, an operator MUST ensure that all NLRI they export conform | ||||
to the following properties by implementing technical or | ||||
organizational measures: | ||||
* The AS_PATH of redistributed NLRI MUST NOT violate the valley-free | ||||
principle [RFC4012], i.e., the redistributing AS MUST be | ||||
authorized to redistribute NLRI for the specific prefix when | ||||
received from the AS directly to its right in the AS_PATH. | ||||
Additionally, each AS in the AS_PATH not originating the prefix | ||||
MUST be authorized to redistribute the prefix when receiving it | ||||
from the next AS to its right. | ||||
* The AS originating NLRI for a prefix MUST be globally authorized | * The AS originating NLRI for a prefix MUST be globally authorized | |||
to originate that prefix. Operators MAY deviate from this for | to originate that prefix. Operators MAY deviate from this for | |||
default routes (::/0 and 0.0.0.0/0), if they originate the default | default routes (::/0 and 0.0.0.0/0), if they originate the default | |||
route and the specific neighbor granted them permission to | route and the specific neighbor granted them permission to | |||
announce default routes towards. | announce default routes towards them. | |||
* The AS_PATH of the NLRI MUST NOT violate the valley-free principle | ||||
[RFC4012], i.e., the exporting AS MUST be authorized to export | ||||
NLRI for the specific prefix when received from the AS directly to | ||||
its right in the AS_PATH. | ||||
* The AS_PATH MUST NOT contain an AS number reserved for private use | * The AS_PATH MUST NOT contain AS numbers reserved for private | |||
[RFC6996]. | [RFC6996] or special-use cases not necessitating their presence in | |||
the global routing table [IANAASNSpec]. | ||||
4.3. General Considerations for Altering NLRI | 4.3. General Considerations for Altering NLRI | |||
When processing NLRI, an operator MUST ensure that some basic | When processing NLRI, an operator MUST ensure that some basic | |||
properties of these NLRI are not altered or set: | properties of these NLRI are not altered or set: | |||
* An operator MUST NOT change transitive BGP attributes, if the | * An operator MUST NOT change transitive BGP attributes, if the | |||
attribute is unknown to the operator. In selected cases, if a | attribute is unknown to the operator. In selected cases, if a | |||
specific attribute is known to be malicious, an operator MAY | specific attribute is known to be malicious, an operator MAY | |||
filter that specific attribute. | filter that specific attribute or the NLRI. | |||
* NLRI carried on BGP MUST NOT be enriched with transitive | * NLRI carried on BGP MUST NOT be enriched with transitive | |||
attributes subject to change independent of the underlying NLRI, | attributes subject to change independent of the underlying NLRI, | |||
e.g., encoding RPKI validation state in transitive attributes | e.g., encoding RPKI validation state in transitive attributes | |||
[I-D.spaghetti-sidrops-avoid-rpki-state-in-bgp]. | [I-D.spaghetti-sidrops-avoid-rpki-state-in-bgp]. | |||
5. IANA Considerations | 5. IANA Considerations | |||
This document does not require any IANA actions. | This document does not require any IANA actions. | |||
skipping to change at page 6, line 31 ¶ | skipping to change at page 6, line 47 ¶ | |||
2013, <https://www.rfc-editor.org/info/rfc6996>. | 2013, <https://www.rfc-editor.org/info/rfc6996>. | |||
[I-D.spaghetti-sidrops-avoid-rpki-state-in-bgp] | [I-D.spaghetti-sidrops-avoid-rpki-state-in-bgp] | |||
Snijders, J., Fiebig, T., and M. A. Stucchi, "Guidance to | Snijders, J., Fiebig, T., and M. A. Stucchi, "Guidance to | |||
Avoid Carrying RPKI Validation States in Transitive BGP | Avoid Carrying RPKI Validation States in Transitive BGP | |||
Path Attributes", Work in Progress, Internet-Draft, draft- | Path Attributes", Work in Progress, Internet-Draft, draft- | |||
spaghetti-sidrops-avoid-rpki-state-in-bgp-00, 8 February | spaghetti-sidrops-avoid-rpki-state-in-bgp-00, 8 February | |||
2024, <https://datatracker.ietf.org/doc/draft-spaghetti- | 2024, <https://datatracker.ietf.org/doc/draft-spaghetti- | |||
sidrops-avoid-rpki-state-in-bgp/>. | sidrops-avoid-rpki-state-in-bgp/>. | |||
[IANAASNSpec] | ||||
IANA, "Special-Purpose Autonomous System (AS) Numbers", | ||||
<https://www.iana.org/assignments/iana-as-numbers-special- | ||||
registry/iana-as-numbers-special-registry.xhtml>. | ||||
7.2. Informative References | 7.2. Informative References | |||
[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, | [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, | |||
"Routing Policy Specification Language next generation | "Routing Policy Specification Language next generation | |||
(RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005, | (RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005, | |||
<https://www.rfc-editor.org/info/rfc4012>. | <https://www.rfc-editor.org/info/rfc4012>. | |||
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations | [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations | |||
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, | and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, | |||
February 2015, <https://www.rfc-editor.org/info/rfc7454>. | February 2015, <https://www.rfc-editor.org/info/rfc7454>. | |||
skipping to change at page 7, line 4 ¶ | skipping to change at page 7, line 25 ¶ | |||
This document has been originally based on [RFC7454] and we thank the | This document has been originally based on [RFC7454] and we thank the | |||
original authors for their work. | original authors for their work. | |||
We thank the following people for reviewing this draft and suggesting | We thank the following people for reviewing this draft and suggesting | |||
changes: | changes: | |||
* Gert Doerring | * Gert Doerring | |||
* Jeff Haas | * Jeff Haas | |||
* Geng Nan | * Geng Nan | |||
* Martin Pels | * Martin Pels | |||
* Job Snijders | * Job Snijders | |||
* Berislav Todorovic | * Berislav Todorovic | |||
* Martin Pels | ||||
* Wolfgang Tremmel | ||||
Authors' Addresses | Authors' Addresses | |||
Tobias Fiebig | Tobias Fiebig | |||
Max-Planck-Institut fuer Informatik | Max-Planck-Institut fuer Informatik | |||
Campus E14 | Campus E14 | |||
66123 Saarbruecken | 66123 Saarbruecken | |||
Germany | Germany | |||
Phone: +49 681 9325 3527 | Phone: +49 681 9325 3527 | |||
Email: tfiebig@mpi-inf.mpg.de | Email: tfiebig@mpi-inf.mpg.de | |||
Nick Hilliard | Nick Hilliard | |||
Internet Neutral Exchange Association | Internet Neutral Exchange Association | |||
4027 Kingswood Road | 4027 Kingswood Road | |||
Citywest, Dublin | Citywest, Dublin | |||
D24 AX96 | D24 AX96 | |||
Ireland | Ireland | |||
Phone: +353 1 433 205 2 | Phone: +353 1 433 205 2 | |||
Email: nick@inex.ie | Email: nick@inex.ie | |||
End of changes. 17 change blocks. | ||||
26 lines changed or deleted | 47 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |