Impact of BGP Filtering on Inter-Domain Routing Policies
RFC 7789
|
| Document |
Type |
|
RFC - Informational
(April 2016; No errata)
|
|
Last updated |
|
2016-04-06
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
Submitted to IESG for Publication
|
|
Document shepherd |
|
Peter Schoenmaker
|
|
Shepherd write-up |
|
Show
(last changed 2015-04-08)
|
| IESG |
IESG state |
|
RFC 7789 (Informational)
|
|
Consensus Boilerplate |
|
Yes
|
|
Telechat date |
|
|
|
Responsible AD |
|
Joel Jaeggli
|
|
Send notices to |
|
(None)
|
| IANA |
IANA review state |
|
Version Changed - Review Needed
|
|
IANA action state |
|
No IANA Actions
|
Internet Engineering Task Force (IETF) C. Cardona
Request for Comments: 7789 IMDEA Networks/UC3M
Category: Informational P. Francois
ISSN: 2070-1721 P. Lucente
Cisco Systems
April 2016
Impact of BGP Filtering on Inter-Domain Routing Policies
Abstract
This document describes how unexpected traffic flows can emerge
across an autonomous system as the result of other autonomous systems
filtering or restricting the propagation of more-specific prefixes.
We provide a review of the techniques to detect the occurrence of
this issue and defend against it.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7789.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Cardona, et al. Informational [Page 1]
RFC 7789 Impact of BGP Filtering April 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Unexpected Traffic Flows . . . . . . . . . . . . . . . . . . 4
2.1. Local Filtering . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Unexpected Traffic Flows Caused by Local Filtering of
More-Specific Prefixes . . . . . . . . . . . . . . . 5
2.2. Remote Filtering . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Unexpected Traffic Flows Caused by Remotely Triggered
Filtering of More-Specific Prefixes . . . . . . . . . 7
3. Techniques to Detect Unexpected Traffic Flows Caused by
Filtering of More-Specific Prefixes . . . . . . . . . . . . . 8
3.1. Existence of Unexpected Traffic Flows within an AS . . . 8
3.2. Contribution to the Existence of Unexpected Traffic Flows
in Another AS . . . . . . . . . . . . . . . . . . . . . . 9
4. Techniques to Traffic Engineer Unexpected Flows . . . . . . . 10
4.1. Reactive Traffic Engineering . . . . . . . . . . . . . . 11
4.2. Proactive Measures . . . . . . . . . . . . . . . . . . . 12
4.2.1. Access Lists . . . . . . . . . . . . . . . . . . . . 12
4.2.2. Neighbor-Specific Forwarding . . . . . . . . . . . . 13
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
It is common practice for network operators to propagate a more-
specific prefix in the BGP routing system along with the less-
specific prefix that they originate. It is also possible for some
Autonomous Systems (ASes) to apply different policies to the more
specific and the less-specific prefix.
Although BGP makes independent, policy-driven decisions for the
selection of the best path to be used for a given IP prefix, routers
must forward packets using the longest-prefix-match rule, which
"precedes" any BGP policy [RFC1812]. The existence of a prefix p
that is more specific than a prefix p' in the Forwarding Information
Base (FIB) will let packets whose destination matches p be forwarded
Show full document text