draft-ietf-idr-bgp-open-policy-22.txt   draft-ietf-idr-bgp-open-policy-23.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: 14 August 2022 Qrator Labs Expires: 4 September 2022 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
10 February 2022 3 March 2022
Route Leak Prevention and Detection using Roles in UPDATE and OPEN Route Leak Prevention and Detection using Roles in UPDATE and OPEN
Messages Messages
draft-ietf-idr-bgp-open-policy-22 draft-ietf-idr-bgp-open-policy-23
Abstract Abstract
Route leaks are the propagation of BGP prefixes that violate Route leaks are the propagation of BGP prefixes that violate
assumptions of BGP topology relationships, e.g., announcing a route assumptions of BGP topology relationships, e.g., announcing a route
learned from one transit provider to another transit provider or a learned from one transit provider to another transit provider or a
lateral (i.e., non-transit) peer or announcing a route learned from lateral (i.e., non-transit) peer or announcing a route learned from
one lateral peer to another lateral peer or a transit provider. one lateral peer to another lateral peer or a transit provider.
These are usually the result of misconfigured or absent BGP route These are usually the result of misconfigured or absent BGP route
filtering or lack of coordination between autonomous systems (ASes). filtering or lack of coordination between autonomous systems (ASes).
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 14 August 2022. This Internet-Draft will expire on 4 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 9, line 25 skipping to change at page 9, line 25
receiving AS detects (based on the presence of the OTC Attribute) receiving AS detects (based on the presence of the OTC Attribute)
that the route is a leak. that the route is a leak.
The OTC Attribute might be set at the egress of the remote AS or at The OTC Attribute might be set at the egress of the remote AS or at
the ingress of the local AS, i.e., if the remote AS is non-compliant the ingress of the local AS, i.e., if the remote AS is non-compliant
with this specification, then the local AS will have to set the OTC with this specification, then the local AS will have to set the OTC
Attribute if it is absent. In both scenarios, the OTC value will be Attribute if it is absent. In both scenarios, the OTC value will be
the same. This makes the scheme more robust and benefits early the same. This makes the scheme more robust and benefits early
adopters. adopters.
If an eBGP speaker receives an UPDATE with an OTC Attribute with a The OTC Attribute is considered malformed if the length value is not
length different from 4 octets, then the UPDATE SHALL be considered 4. An UPDATE message with a malformed OTC Attribute SHALL be handled
malformed. If malformed, the UPDATE message SHALL be handled using using the approach of "treat-as-withdraw" [RFC7606].
the approach of treat-as-withdraw [RFC7606].
If an UPDATE with an OTC Attribute is received in iBGP, then the
Attribute or UPDATE SHALL NOT be considered malformed based on the
specified length. This avoids treat-as-withdraw error handling and
prevents the possibility of long-lived forwarding loops in iBGP
(Section 6 in [RFC7606]). It also avoids Attribute-discard error
handling [RFC7606] and hence route leak detection capability is not
compromised in case the route is propagated to eBGP neighbors.
The BGP Role negotiation and OTC Attribute based procedures specified The BGP Role negotiation and OTC Attribute based procedures specified
in this document are NOT RECOMMENDED to be used between autonomous in this document are NOT RECOMMENDED to be used between autonomous
systems in an AS Confederation [RFC5065]. If an OTC Attribute is systems in an AS Confederation [RFC5065]. If an OTC Attribute is
added on egress from the AS Confederation, its value MUST equal the added on egress from the AS Confederation, its value MUST equal the
AS Confederation Identifier. Also, on egress from the AS AS Confederation Identifier. Also, on egress from the AS
Confederation, an UPDATE MUST NOT contain an OTC Attribute with a Confederation, an UPDATE MUST NOT contain an OTC Attribute with a
value corresponding to any Member-AS Number other than the AS value corresponding to any Member-AS Number other than the AS
Confederation Identifier. Confederation Identifier.
skipping to change at page 10, line 39 skipping to change at page 10, line 30
prefix propagation. Further, this document does not specify any prefix propagation. Further, this document does not specify any
special handling of an incorrect AS number in the OTC Attribute. special handling of an incorrect AS number in the OTC Attribute.
In AS migration scenarios [RFC7705], a given router may represent In AS migration scenarios [RFC7705], a given router may represent
itself as any one of several different ASes. This should not be a itself as any one of several different ASes. This should not be a
problem since the egress procedures in Section 4 specify that the OTC problem since the egress procedures in Section 4 specify that the OTC
Attribute is to be attached as part of route transmission. Attribute is to be attached as part of route transmission.
Therefore, a router is expected to set the OTC value equal to the ASN Therefore, a router is expected to set the OTC value equal to the ASN
it is currently representing itself as. it is currently representing itself as.
Section 6 of [RFC7606] documents possible negative impacts of "treat-
as-withdraw" behavior. Such negative impacts may include forwarding
loops or blackholes. It also discusses debugging considerations
related to this behavior.
6. IANA Considerations 6. IANA Considerations
IANA has registered a new BGP Capability (Section 3.1) in the IANA has registered a new BGP Capability (Section 3.1) in the
"Capability Codes" registry's "IETF Review" range [RFC5492]. The "Capability Codes" registry's "IETF Review" range [RFC5492]. The
description for the new capability is "BGP Role". IANA has assigned description for the new capability is "BGP Role". IANA has assigned
the value 9 [to be removed upon publication: the value 9 [to be removed upon publication:
https://www.iana.org/assignments/capability-codes/capability- https://www.iana.org/assignments/capability-codes/capability-
codes.xhtml]. This document is the reference for the new capability. codes.xhtml]. This document is the reference for the new capability.
The BGP Role capability includes a Value field, for which IANA is The BGP Role capability includes a Value field, for which IANA is
skipping to change at page 14, line 16 skipping to change at page 14, line 7
BGP for Routing in Large-Scale Data Centers", RFC 7938, BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016, DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>. <https://www.rfc-editor.org/info/rfc7938>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>. 2017, <https://www.rfc-editor.org/info/rfc8205>.
Acknowledgments Acknowledgments
The authors wish to thank Alvaro Retana, Bruno Decraene, Ben The authors wish to thank Alvaro Retana, Bruno Decraene, Jeff Haas,
Maddison, Andrei Robachevsky, Daniel Ginsburg, Jeff Haas, Ruediger John Scudder, Sue Hares, Ben Maddison, Andrei Robachevsky, Daniel
Volk, Pavel Lunin, Gyan Mishra, Ignas Bagdonas, Sue Hares, and John Ginsburg, Ruediger Volk, Pavel Lunin, Gyan Mishra, and Ignas Bagdonas
Scudder for review, comments, and suggestions during the course of for review, comments, and suggestions during the course of this work.
this work. Thanks are also due to many IESG reviewers whose comments Thanks are also due to many IESG reviewers whose comments greatly
greatly helped improve the clarity, accuracy, and presentation in the helped improve the clarity, accuracy, and presentation in the
document. document.
Contributors Contributors
Brian Dickson Brian Dickson
Independent Independent
Email: brian.peter.dickson@gmail.com Email: brian.peter.dickson@gmail.com
Doug Montgomery Doug Montgomery
USA National Institute of Standards and Technology USA National Institute of Standards and Technology
 End of changes. 7 change blocks. 
22 lines changed or deleted 18 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/