< draft-ietf-idr-bgp-open-policy-15.txt | draft-ietf-idr-bgp-open-policy.txt > | |||
---|---|---|---|---|
Network Working Group A. Azimov | Network Working Group A. Azimov | |||
Internet-Draft Qrator Labs & Yandex | Internet-Draft Qrator Labs & Yandex | |||
Intended status: Standards Track E. Bogomazov | Intended status: Standards Track E. Bogomazov | |||
Expires: July 20, 2021 Qrator Labs | Expires: December 11, 2021 Qrator Labs | |||
R. Bush | R. Bush | |||
Internet Initiative Japan & Arrcus, Inc. | Internet Initiative Japan & Arrcus, Inc. | |||
K. Patel | K. Patel | |||
Arrcus | Arrcus | |||
K. Sriram | K. Sriram | |||
USA NIST | USA NIST | |||
January 16, 2021 | June 9, 2021 | |||
Route Leak Prevention using Roles in Update and Open messages | Route Leak Prevention using Roles in Update and Open messages | |||
draft-ietf-idr-bgp-open-policy-15 | draft-ietf-idr-bgp-open-policy-16 | |||
Abstract | Abstract | |||
Route leaks are the propagation of BGP prefixes which violate | Route leaks are the propagation of BGP prefixes which violate | |||
assumptions of BGP topology relationships; e.g. passing a route | assumptions of BGP topology relationships; e.g. passing a route | |||
learned from one lateral peer to another lateral peer or a transit | learned from one lateral peer to another lateral peer or a transit | |||
provider, passing a route learned from one transit provider to | provider, passing a route learned from one transit provider to | |||
another transit provider or a lateral peer. Existing approaches to | another transit provider or a lateral peer. Existing approaches to | |||
leak prevention rely on marking routes by operator configuration, | leak prevention rely on marking routes by operator configuration, | |||
with no check that the configuration corresponds to that of the eBGP | with no check that the configuration corresponds to that of the eBGP | |||
skipping to change at page 2, line 12 ¶ | skipping to change at page 2, line 12 ¶ | |||
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 July 20, 2021. | This Internet-Draft will expire on December 11, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 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 | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 36 ¶ | skipping to change at page 2, line 36 ¶ | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 3 | 2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 3 | |||
3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. BGP Role Capability . . . . . . . . . . . . . . . . . . . . . 5 | 4. BGP Role Capability . . . . . . . . . . . . . . . . . . . . . 5 | |||
5. Role correctness . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Role correctness . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5.1. Strict mode . . . . . . . . . . . . . . . . . . . . . . . 6 | 5.1. Strict and Non-strict Modes . . . . . . . . . . . . . . . 6 | |||
6. BGP Only to Customer (OTC) Attribute . . . . . . . . . . . . 6 | 6. BGP Only to Customer (OTC) Attribute . . . . . . . . . . . . 6 | |||
7. Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 7. Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
8. Additional Considerations . . . . . . . . . . . . . . . . . . 7 | 8. Additional Considerations . . . . . . . . . . . . . . . . . . 7 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 9 | 11.2. Informative References . . . . . . . . . . . . . . . . . 10 | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
1. Introduction | 1. Introduction | |||
A BGP route leak occurs when a route is learned from a transit | A BGP route leak occurs when a route is learned from a transit | |||
provider or lateral peer and then announced to another provider or | provider or lateral peer and then announced to another provider or | |||
lateral peer. See [RFC7908]. These are usually the result of | lateral peer. See [RFC7908]. These are usually the result of | |||
misconfigured or absent BGP route filtering or lack of coordination | misconfigured or absent BGP route filtering or lack of coordination | |||
between two eBGP speakers. | between two eBGP speakers. | |||
The mechanism proposed in | The mechanism proposed in | |||
skipping to change at page 3, line 47 ¶ | skipping to change at page 3, line 47 ¶ | |||
Despite the use of terms such as "customer", "peer", etc. in this | Despite the use of terms such as "customer", "peer", etc. in this | |||
document, these are not necessarily business relationships based on | document, these are not necessarily business relationships based on | |||
payment agreements. These terms are used to represent restrictions | payment agreements. These terms are used to represent restrictions | |||
on BGP route propagation, sometimes known as the Gao-Rexford model | on BGP route propagation, sometimes known as the Gao-Rexford model | |||
[Gao]. The following is a list of various roles in eBGP peering and | [Gao]. The following is a list of various roles in eBGP peering and | |||
the corresponding rules for route propagation: | the corresponding rules for route propagation: | |||
Provider: MAY send to a customer all available prefixes. | Provider: MAY send to a customer all available prefixes. | |||
Customer: MAY send to a provider prefixes which the sender | Customer: MAY send to a provider prefixes which the sender | |||
originates and prefixes learned from any of their customers. A | originates and prefixes learned from any of its customers. A | |||
customer MUST NOT send to a provider prefixes learned from its | customer MUST NOT send to a provider prefixes learned from its | |||
peers, from other providers, or from Route Servers. | peers, from other providers, or from Route Servers. | |||
Route Server (RS): MAY send to an Route Server client (RS-client) | Route Server (RS): MAY send to a Route Server client (RS-client) all | |||
all available prefixes. | available prefixes. | |||
RS-client: MAY send to an RS prefixes which the sender originates | RS-client: MAY send to an RS prefixes which the sender originates | |||
and prefixes learned from its customers. An RS-client MUST NOT | and prefixes learned from its customers. An RS-client MUST NOT | |||
send to an RS prefixes learned from its peers or providers, or | send to an RS prefixes learned from its peers or providers, or | |||
from another RS. | from another RS. | |||
Peer: MAY send to a peer prefixes which the sender originates and | Peer: MAY send to a peer prefixes which the sender originates and | |||
prefixes learned from its customers. A peer MUST NOT send to a | prefixes learned from its customers. A peer MUST NOT send to a | |||
peer prefixes learned from other peers, from its providers, or | peer prefixes learned from other peers, from its providers, or | |||
from RS(s). | from RS(s). | |||
Of course, any BGP speaker may apply policy to reduce what is | Of course, any BGP speaker may apply policy to reduce what is | |||
announced, and a recipient may apply policy to reduce the set of | announced, and a recipient may apply policy to reduce the set of | |||
routes they accept. Violation of the above rules may result in route | routes they accept. Violation of the above rules may result in route | |||
leaks and MUST NOT be allowed. Automatic enforcement of these rules | leaks and MUST NOT be allowed. Automatic enforcement of these rules | |||
should significantly reduce route leaks that may otherwise occur due | should significantly reduce route leaks that may otherwise occur due | |||
to manual configuration mistakes. While enforcing the above rules | to manual configuration mistakes. While enforcing the above rules | |||
will address most BGP peering scenarios, their configuration is not | will address most BGP peering scenarios, their configuration is not | |||
part of BGP itself; therefore, configuration of ingress and egress | part of BGP itself; therefore, the configuration of ingress and | |||
prefix filters is still strongly advised. | egress prefix filters is still strongly advised. | |||
3. BGP Role | 3. BGP Role | |||
BGP Role is a new configuration option that is configured on a per- | BGP Role is a new configuration option that is configured on a per- | |||
session basis. BGP Roles reflect the agreement between two BGP | session basis. BGP Roles reflect the agreement between two BGP | |||
speakers about their relationship. One of the Roles described below | speakers about their relationship. One of the Roles described below | |||
SHOULD be configured on each eBGP session between ISPs that carry | SHOULD be configured on each eBGP session between ISPs that carry | |||
IPv4 and(or) IPv6 unicast prefixes. | IPv4 and(or) IPv6 unicast prefixes. | |||
Allowed Role values for eBGP sessions between ISPs are: | Allowed Roles for eBGP sessions between ISPs are: | |||
o Provider - sender is a transit provider to neighbor; | o Provider - sender is a transit provider to neighbor; | |||
o Customer - sender is a transit customer of neighbor; | o Customer - sender is a transit customer of neighbor; | |||
o RS - sender is a Route Server, usually at an Internet exchange | o RS - sender is a Route Server, usually at an Internet exchange | |||
point (IX); | point (IX); | |||
o RS-client - sender is client of an RS; | o RS-client - sender is client of an RS; | |||
skipping to change at page 5, line 23 ¶ | skipping to change at page 5, line 23 ¶ | |||
o Value - integer corresponding to speaker's BGP Role (see Table 1). | o Value - integer corresponding to speaker's BGP Role (see Table 1). | |||
+-------+---------------------+ | +-------+---------------------+ | |||
| Value | Role name | | | Value | Role name | | |||
+-------+---------------------+ | +-------+---------------------+ | |||
| 0 | Sender is Provider | | | 0 | Sender is Provider | | |||
| 1 | Sender is RS | | | 1 | Sender is RS | | |||
| 2 | Sender is RS-client | | | 2 | Sender is RS-client | | |||
| 3 | Sender is Customer | | | 3 | Sender is Customer | | |||
| 4 | Sender is Peer | | | 4 | Sender is Peer | | |||
| 5-255 | Reserved | | ||||
+-------+---------------------+ | +-------+---------------------+ | |||
Table 1: Predefined BGP Role Values | Table 1: Predefined BGP Role Values | |||
5. Role correctness | 5. Role correctness | |||
Section 3 described how BGP Role encodes the relationship between two | Section 3 described how BGP Role encodes the relationship between two | |||
eBGP speakers. But the mere presence of BGP Role doesn't | eBGP speakers. But the mere presence of BGP Role doesn't | |||
automatically guarantee role agreement between two BGP peers. | automatically guarantee role agreement between two BGP peers. | |||
skipping to change at page 6, line 5 ¶ | skipping to change at page 6, line 17 ¶ | |||
+---------------+-----------------+ | +---------------+-----------------+ | |||
| Provider | Customer | | | Provider | Customer | | |||
| Customer | Provider | | | Customer | Provider | | |||
| RS | RS-client | | | RS | RS-client | | |||
| RS-client | RS | | | RS-client | RS | | |||
| Peer | Peer | | | Peer | Peer | | |||
+---------------+-----------------+ | +---------------+-----------------+ | |||
Table 2: Allowed Pairs of Role Capabilities | Table 2: Allowed Pairs of Role Capabilities | |||
If the role of the receiving speaker for the eBGP session in | If the observed Role pair is not in the above table, then the | |||
consideration is included in Table 1 and the observed Role pair is | receiving speaker MUST reject the eBGP connection, send a Role | |||
not in the above table, then the receiving speaker MUST reject the | Mismatch Notification (code 2, subcode <TBD2>), and also send a | |||
eBGP connection, send a Role Mismatch Notification (code 2, subcode | Connection Rejected Notification [RFC4486] (Notification with error | |||
<TBD2>), and also send a Connection Rejected Notification [RFC4486] | code 6, subcode 5). | |||
(Notification with error code 6, subcode 5). | ||||
5.1. Strict mode | 5.1. Strict and Non-strict Modes | |||
A new BGP configuration option "strict mode" is defined with values | A new BGP configuration option "strict mode" is defined with values | |||
of true or false. If set to true, then the speaker MUST refuse to | of true or false. If set to true, then the speaker MUST refuse to | |||
establish a BGP session with a neighbor which does not announce the | establish a BGP session with a neighbor which does not announce the | |||
BGP Role capability in the OPEN message. If a speaker rejects a | BGP Role capability in the OPEN message. If a speaker rejects a | |||
connection, it MUST send a send a Role Mismatch Notification (code 2, | connection, it MUST send a Role Mismatch Notification (code 2, | |||
subcode <TBD2>), and also send a Connection Rejected Notification | subcode <TBD2>), and also send a Connection Rejected Notification | |||
[RFC4486] (Notification with error code 6, subcode 5). By default, | [RFC4486] (Notification with error code 6, subcode 5). By default, | |||
strict mode SHOULD be set to false for backward compatibility with | strict mode SHOULD be set to false (i.e. non-strict mode is used) for | |||
BGP speakers that do not yet support this mechanism. | backward compatibility with BGP speakers that do not yet support this | |||
mechanism. | ||||
In the case of a neighbor who doesn't participate, the BGP Role is | ||||
configured unilaterally based on local knowledge of the peering | ||||
relationship. (Note: This applies only to the default non-strict | ||||
mode; remember that in strict mode, the BGP connection is rejected | ||||
for any non-participating neighbor.) The only thing lacking would be | ||||
a mutual confirmation with the neighbor about BGP Role (this is | ||||
permissible for backward compatibility in partial deployment). The | ||||
OTC attribute processing (Section 6) remains unaffected. | ||||
6. BGP Only to Customer (OTC) Attribute | 6. BGP Only to Customer (OTC) Attribute | |||
Newly defined here, the Only to Customer (OTC) is an optional, 4 | Newly defined here, the Only to Customer (OTC) is an optional, 4 | |||
bytes long, transitive BGP Path attribute with the Type Code <TBD3>. | bytes long, transitive BGP Path attribute with the Type Code <TBD3>. | |||
The purpose of this attribute is to guarantee that once a route is | The purpose of this attribute is to guarantee that once a route is | |||
sent to customer, peer, or RS-client, it will subsequently go only to | sent to customer, peer, or RS-client, it will subsequently go only to | |||
customers. The value of OTC is an AS number determined by policy as | customers. The value of OTC is an AS number determined by policy as | |||
described below. The semantics and usage of the OTC attribute are | described below. The semantics and usage of the OTC attribute are | |||
made clear by the ingress and egress policies described below. | made clear by the ingress and egress policies described below. | |||
skipping to change at page 7, line 5 ¶ | skipping to change at page 7, line 25 ¶ | |||
3. If a route is received from a Provider, Peer, or RS and the OTC | 3. If a route is received from a Provider, Peer, or RS and the OTC | |||
attribute is not present, then it MUST be added with value equal | attribute is not present, then it MUST be added with value equal | |||
to the sending neighbor's AS number. | to the sending neighbor's AS number. | |||
The egress policy MUST be: | The egress policy MUST be: | |||
1. A route with the OTC attribute set MUST NOT be sent to Providers, | 1. A route with the OTC attribute set MUST NOT be sent to Providers, | |||
Peers, or RS(s). | Peers, or RS(s). | |||
2. If route is sent to a Customer or Peer, or an RS-client (when the | 2. If a route is sent to a Customer or Peer, or an RS-client (when | |||
sender is an RS) and the OTC attribute is not present, then it | the sender is an RS) and the OTC attribute is not present, then | |||
MUST be added with value equal to AS number of the sender. | it MUST be added with a value equal to AS number of the sender. | |||
Once the OTC attribute has been set, it MUST be preserved unchanged. | Once the OTC attribute has been set, it MUST be preserved unchanged. | |||
7. Enforcement | 7. Enforcement | |||
Having the relationship unequivocally agreed between the two peers in | Having the relationship unequivocally agreed between the two peers in | |||
BGP OPEN is critical; BGP implementations MUST enforce the | BGP OPEN is critical; BGP implementations MUST enforce the | |||
relationship/role establishment rules (see Section 5) in order to | relationship/role establishment rules (see Section 5) in order to | |||
ameliorate operator policy configuration errors (if any). | ameliorate operator policy configuration errors (if any). | |||
skipping to change at page 7, line 38 ¶ | skipping to change at page 8, line 10 ¶ | |||
There are peering relationships that are 'complex', i.e., both | There are peering relationships that are 'complex', i.e., both | |||
parties are intentionally sending prefixes received from each other | parties are intentionally sending prefixes received from each other | |||
to their non-transit peers and/or transit providers. If multiple BGP | to their non-transit peers and/or transit providers. If multiple BGP | |||
peerings can segregate the 'complex' parts of the relationship, the | peerings can segregate the 'complex' parts of the relationship, the | |||
complex peering roles can be segregated into different normal BGP | complex peering roles can be segregated into different normal BGP | |||
sessions, and BGP Roles MUST be used on each of the resulting normal | sessions, and BGP Roles MUST be used on each of the resulting normal | |||
(non-complex) BGP sessions. | (non-complex) BGP sessions. | |||
No Roles SHOULD be configured on a 'complex' BGP session (assuming it | No Roles SHOULD be configured on a 'complex' BGP session (assuming it | |||
is not segregated) and in that case, OTC MUST be set by configuration | is not segregated) and in that case, the OTC attribute processing | |||
on a per-prefix basis. However, there are no built-in measures to | MUST be done relying on configuration on a per-prefix basis. (Note: | |||
check correctness of OTC use if BGP Role is not configured. | The per-prefix configuration of peering relationship is currently | |||
done to handle 'complex' BGP sessions.) However, there are no built- | ||||
in measures to check the correctness of OTC use if BGP Role is not | ||||
configured. | ||||
The incorrect setting of BGP Roles and/or OTC attributes may affect | The incorrect setting of BGP Roles and/or OTC attributes may affect | |||
prefix propagation. Further, this document doesn't specify any | prefix propagation. Further, this document doesn't specify any | |||
special handling of incorrect/private ASNs in OTC attribute; such | special handling of incorrect/private ASNs in the OTC attribute; such | |||
errors should not happen with proper configuration. | errors should not happen with proper configuration. | |||
As the BGP Role reflects the peering relationship between neighbors, | As the BGP Role reflects the peering relationship between neighbors, | |||
it might have other uses beyond the route leak solution discussed so | it might have other uses beyond the route leak solution discussed so | |||
far. For example, BGP Role might affect route priority, or be used | far. For example, BGP Role might affect route priority, or be used | |||
to distinguish borders of a network if a network consists of multiple | to distinguish borders of a network if a network consists of multiple | |||
ASs. Though such uses may be worthwhile, they are not the goal of | ASs. Though such uses may be worthwhile, they are not the goal of | |||
this document. Note that such uses would require local policy | this document. Note that such uses would require local policy | |||
control. | control. | |||
The use of BGP Roles are specified for unicast IPv4 and IPv6 address | The use of BGP Roles is specified for unicast IPv4 and IPv6 address | |||
families. While BGP roles can be configured on other address | families. While BGP roles can be configured on other address | |||
families its applicability for these cases is out of scope of this | families its applicability for these cases is out of the scope of | |||
document. | this document. | |||
As BGP role configuration results in automatic creation of inbound/ | As BGP role configuration results in the automatic creation of | |||
outbound filters, existence of roles should be treated as existence | inbound/outbound filters, the existence of roles should be treated as | |||
of Import and Export policy [RFC8212]. | the existence of Import and Export policy [RFC8212]. | |||
9. IANA Considerations | 9. IANA Considerations | |||
This document defines a new Capability Codes option [to be removed | This document defines a new Capability Codes option [to be removed | |||
upon publication: https://www.iana.org/assignments/capability-codes/ | upon publication: https://www.iana.org/assignments/capability-codes/ | |||
capability-codes.xhtml ] [RFC5492], named "BGP Role" with an assigned | capability-codes.xhtml ] [RFC5492], named "BGP Role" with an assigned | |||
value <TBD1>. The length of this capability is 1. | value <TBD1>. The length of this capability is 1. | |||
The BGP Role capability includes a Value field, for which IANA is | The BGP Role capability includes a Value field, for which IANA is | |||
requested to create and maintain a new sub-registry called "BGP Role | requested to create and maintain a new sub-registry called "BGP Role | |||
Value". Assignments consist of Value and corresponding Role name. | Value". Assignments consist of Value and corresponding Role name. | |||
Initially this registry is to be populated with the data contained in | Initially, this registry is to be populated with the data contained | |||
Table 1 found in Section 4. Future assignments may be made by a | in Table 1 found in Section 4. Future assignments may be made by a | |||
Standard Action procedure [RFC8126]. The allocation policy for new | Standard Action procedure [RFC8126]. The allocation policy for new | |||
entries up to and including value 127 is "Expert Review" [RFC8126]. | entries up to and including value 127 is "Expert Review" [RFC8126]. | |||
The allocation policy for values 128 through 251 is "First Come First | The allocation policy for values 128 through 251 is "First Come First | |||
Served". The values from 252 through 255 are for "Experimental Use". | Served". The values from 252 through 255 are for "Experimental Use". | |||
This document defines a new subcode, "Role Mismatch" with an assigned | This document defines a new subcode, "Role Mismatch" with an assigned | |||
value <TBD2> in the OPEN Message Error subcodes registry [to be | value <TBD2> in the OPEN Message Error subcodes registry [to be | |||
removed upon publication: http://www.iana.org/assignments/bgp- | removed upon publication: http://www.iana.org/assignments/bgp- | |||
parameters/bgp-parameters.xhtml#bgp-parameters-6] [RFC4271]. | parameters/bgp-parameters.xhtml#bgp-parameters-6] [RFC4271]. | |||
This document defines a new optional, transitive BGP Path Attributes | This document defines a new optional, transitive BGP Path Attributes | |||
option, named "Only to Customer (OTC)" with an assigned value <TBD3> | option, named "Only to Customer (OTC)" with an assigned value <TBD3> | |||
[To be removed upon publication: http://www.iana.org/assignments/bgp- | [To be removed upon publication: http://www.iana.org/assignments/bgp- | |||
parameters/bgp-parameters.xhtml#bgp-parameters-2] [RFC4271]. The | parameters/bgp-parameters.xhtml#bgp-parameters-2] [RFC4271]. The | |||
length of this attribute is four bytes. | length of this attribute is four bytes. | |||
10. Security Considerations | 10. Security Considerations | |||
This document proposes a mechanism for prevention of route leaks that | This document proposes a mechanism for the prevention of route leaks | |||
are the result of BGP policy misconfiguration. | that are the result of BGP policy misconfiguration. | |||
A misconfiguration in OTC setup may affect prefix propagation. But | A misconfiguration in the OTC setup may affect prefix propagation. | |||
the automation that is provided by BGP roles should make such | But the automation that is provided by BGP roles should make such | |||
misconfiguration unlikely. | misconfiguration unlikely. | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
skipping to change at page 9, line 42 ¶ | skipping to change at page 10, line 20 ¶ | |||
[Gao] Gao, L. and J. Rexford, "Stable Internet routing without | [Gao] Gao, L. and J. Rexford, "Stable Internet routing without | |||
global coordination", IEEE/ACM Transactions on | global coordination", IEEE/ACM Transactions on | |||
Networking, Volume 9, Issue 6, pp 689-692, DOI | Networking, Volume 9, Issue 6, pp 689-692, DOI | |||
10.1109/90.974523, December 2001, | 10.1109/90.974523, December 2001, | |||
<https://ieeexplore.ieee.org/document/974523>. | <https://ieeexplore.ieee.org/document/974523>. | |||
[I-D.ietf-grow-route-leak-detection-mitigation] | [I-D.ietf-grow-route-leak-detection-mitigation] | |||
Sriram, K. and A. Azimov, "Methods for Detection and | Sriram, K. and A. Azimov, "Methods for Detection and | |||
Mitigation of BGP Route Leaks", draft-ietf-grow-route- | Mitigation of BGP Route Leaks", draft-ietf-grow-route- | |||
leak-detection-mitigation-04 (work in progress), October | leak-detection-mitigation-05 (work in progress), April | |||
2020. | 2021. | |||
[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., | [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., | |||
and B. Dickson, "Problem Definition and Classification of | and B. Dickson, "Problem Definition and Classification of | |||
BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June | BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June | |||
2016, <https://www.rfc-editor.org/info/rfc7908>. | 2016, <https://www.rfc-editor.org/info/rfc7908>. | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
<https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
End of changes. 27 change blocks. | ||||
46 lines changed or deleted | 59 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |