draft-ietf-idr-bgp-open-policy-12.txt   draft-ietf-idr-bgp-open-policy-13.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: January 4, 2021 Qrator Labs Expires: January 8, 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
July 3, 2020 July 7, 2020
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-12 draft-ietf-idr-bgp-open-policy-13
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 January 4, 2021. This Internet-Draft will expire on January 8, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 4, line 27 skipping to change at page 4, line 27
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, configuration of ingress and egress
prefix filters is still strongly advised. prefix filters is still strongly advised.
3. BGP Role 3. BGP Role
BGP Role is a new configuration option that can be configured on any BGP Role is a new configuration option that is configured on a per-
BGP session. 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 Role values 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;
 End of changes. 5 change blocks. 
6 lines changed or deleted 6 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/