draft-ietf-grow-route-leak-detection-mitigation-05.txt   draft-ietf-grow-route-leak-detection-mitigation-06.txt 
IDR and SIDR K. Sriram, Ed. IDR and SIDR K. Sriram, Ed.
Internet-Draft USA NIST Internet-Draft USA NIST
Intended status: Standards Track A. Azimov, Ed. Intended status: Standards Track A. Azimov, Ed.
Expires: October 30, 2021 Yandex Expires: 27 April 2022 Yandex
April 28, 2021 24 October 2021
Methods for Detection and Mitigation of BGP Route Leaks Methods for Detection and Mitigation of BGP Route Leaks
draft-ietf-grow-route-leak-detection-mitigation-05 draft-ietf-grow-route-leak-detection-mitigation-06
Abstract Abstract
Problem definition for route leaks and enumeration of types of route Problem definition for route leaks and enumeration of types of route
leaks are provided in RFC 7908. This document describes a new well- leaks are provided in RFC 7908. This document describes a new well-
known Large Community that provides a way for route-leak prevention, known Large Community that provides a way for route-leak prevention,
detection, and mitigation. The configuration process for this detection, and mitigation. The configuration process for this
Community can be automated with the methodology for setting BGP roles Community can be automated with the methodology for setting BGP roles
that is described in ietf-idr-bgp-open-policy draft. that is described in ietf-idr-bgp-open-policy draft.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 October 30, 2021. This Internet-Draft will expire on 27 April 2022.
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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 3 2. Peering Relationships . . . . . . . . . . . . . . . . . . . . 3
3. Community vs Attribute . . . . . . . . . . . . . . . . . . . 3 3. Community vs Attribute . . . . . . . . . . . . . . . . . . . 4
4. Down Only Community . . . . . . . . . . . . . . . . . . . . . 4 4. Down Only Community . . . . . . . . . . . . . . . . . . . . . 4
4.1. Route-Leak Mitigation . . . . . . . . . . . . . . . . . . 5 4.1. Route-Leak Mitigation . . . . . . . . . . . . . . . . . . 5
4.2. Only Marking . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Only Marking . . . . . . . . . . . . . . . . . . . . . . 6
5. Implementation Considerations . . . . . . . . . . . . . . . . 7 5. Implementation Considerations . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 3, line 18 skipping to change at page 3, line 24
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Peering Relationships 2. Peering Relationships
As described in [I-D.ietf-idr-bgp-open-policy] there are several As described in [I-D.ietf-idr-bgp-open-policy] there are several
common peering relations between eBGP neighbors: common peering relations between eBGP neighbors:
o Provider - sender is a transit provider of the neighbor; * Provider - sender is a transit provider of the neighbor;
o Customer - sender is a customer of the neighbor; * Customer - sender is a customer of the neighbor;
o Route Server (RS) - sender is route server at an internet exchange * Route Server (RS) - sender is route server at an internet exchange
(IX) (IX)
o RS-client - sender is client of an RS at an IX * RS-client - sender is client of an RS at an IX
o Peer - sender and neighbor are lateral (non-transit) peers; * Peer - sender and neighbor are lateral (non-transit) peers;
If a route is received from a provider, peer, or RS-client, it MUST If a route is received from a provider, peer, or RS-client, it MUST
follow the 'down only' rule, i.e., it MAY be advertised only to follow the 'down only' rule, i.e., it MAY be advertised only to
customers. If a route is sent to a customer, peer, or RS-client, it customers. If a route is sent to a customer, peer, or RS-client, it
also MUST follow the 'down only' rule at each subsequent AS in the AS also MUST follow the 'down only' rule at each subsequent AS in the AS
path. path.
A standardized transitive route-leak detection signal is needed that A standardized transitive route-leak detection signal is needed that
will prevent Autonomous Systems (ASes) from leaking and also inform a will prevent Autonomous Systems (ASes) from leaking and also inform a
remote ISP (or AS) in the AS path that a received route violates the remote ISP (or AS) in the AS path that a received route violates the
skipping to change at page 8, line 47 skipping to change at page 8, line 47
<https://www.rfc-editor.org/info/rfc8092>. <https://www.rfc-editor.org/info/rfc8092>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-idr-bgp-open-policy] [I-D.ietf-idr-bgp-open-policy]
Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K.
Sriram, "Route Leak Prevention using Roles in Update and Sriram, "Route Leak Prevention and Detection using Roles
Open messages", draft-ietf-idr-bgp-open-policy-15 (work in in UPDATE and OPEN Messages", Work in Progress, Internet-
progress), January 2021. Draft, draft-ietf-idr-bgp-open-policy-17, 13 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-idr-bgp-open-
policy-17.txt>.
[RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264, [RFC4264] Griffin, T. and G. Huston, "BGP Wedgies", RFC 4264,
DOI 10.17487/RFC4264, November 2005, DOI 10.17487/RFC4264, November 2005,
<https://www.rfc-editor.org/info/rfc4264>. <https://www.rfc-editor.org/info/rfc4264>.
[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>.
skipping to change at page 10, line 10 skipping to change at page 10, line 10
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
Email: randy@psg.com Email: randy@psg.com
Authors' Addresses Authors' Addresses
Kotikalapudi Sriram (editor) Kotikalapudi Sriram (editor)
USA National Institute of Standards and Technology USA National Institute of Standards and Technology
100 Bureau Drive 100 Bureau Drive
Gaithersburg, MD 20899 Gaithersburg, MD 20899
United States of America United States of America
Email: ksriram@nist.gov Email: ksriram@nist.gov
Alexander Azimov (editor) Alexander Azimov (editor)
Yandex Yandex
Ulitsa Lva Tolstogo 16 Ulitsa Lva Tolstogo 16
Moscow 119021 Moscow
Russia
Email: a.e.azimov@gmail.com Email: a.e.azimov@gmail.com
 End of changes. 13 change blocks. 
24 lines changed or deleted 24 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/