License: Other
This is the working area for the IETF GROW Working Group Internet-Draft, "Updated BGP Operations and Security".
See the guidelines for contributions.
Contributions can be made by creating pull requests. The GitHub interface supports creating pull requests using the Edit (✏) button.
Formatted text and HTML versions of the draft can be built using make.
$ makeCommand line usage requires that you have the necessary software installed. See the instructions.
2. The meanings of "upstream" in this draft and the ASPA draft are different. According to the term definition in this draft, the ASPA upstream verification should be conducted for the routes from *downstream* or peer.
In section 3: "
Upstream:
In a direct relationship between two ASes the one providing
upstream to the other. (See: [RFC9234], also known as the
provider in a customer-provider relationship.)
"
In section 7.2.2: "
In [I-D.ietf-sidrops-aspa-verification], see following sections based
on the neighbor relationship:
* Section 6.1 for routes received from upstreams and lateral peers.
* Section 6.2 for routes received from downstreams and mutual-
transits.
"
As noted by GD, it is still a "my network, my rules" thing. The introduction should explicitly mention that the BP should be considered by individual operators, and there may be very good reasons to deviate, e.g., limited vendor support.
appending a community to signal the validation status of a prefix is generally considered a bad idea
Adding a note on the use of lpref on IXPs that prevent draining traffic (related to #1) might make sense.
With RS MED can lead to route oscillation overloading speakers. This is discussed in RFC7964, and a note on monitoring for that/precautions might be useful.
Currently, there is no note on running one's own RPKI validator; This may, however, be prudent, see: job/draft-rpki-communities-harmful#3
Additionally, there was a comment regarding the citation of bgpq4, which caches from NTT, usually. Similar notes may apply there, and--as noted re: irrd--features currently needing bgpq4 should be part of irrd soon.
Martin Pels notes:
"operators MAY opt to scrub all BGP attributes known to cause service
disruptions"
I would suggest replacing the word "all" with "specific", or to add a
line explicitly clarifying not to scrub unknown transitive attributes.
Martin Pels notes:
At the moment the draft does not discuss honoring GSHUT on IXPs.
As this is crucial for being able to drain traffic, adding a note might be useful.
On 26/10/2023 15:10, Tobias Fiebig wrote:
> [..]
>
>> The global limits seem to offer no real benefit in addition to
>> per-session limits. The referenced paper mentions Per-Origin AS
>> limits, not the per-Neighbor AS limits mentioned in the draft. This
>> also seems to be unimplementable, given that routers act
>> independently on prefixes they receive.
>
> I think there are two points in here:
> - The paper mentions per-origin, which i consider even more un-
> implementable than per-neighbor, which is why I restricted it to
> direct neighbors (similar to the idea of BCP38, that things 'should'
> be fine if everyone filters their downstreams.)
> - Your implementability point is very valid.
>
> To address both points, it might make sense to move this to a softer
> recommendation to "Monitoring the global number of prefixes ingested
> from each peer/downstream, and alerting if that number increases too
> quickly" or something similar;
I think a recommendation for prefix limit monitoring and alerting for
all peers would be a good replacement of section 8.2.2.
Section 8.2.1 already mentions placing a prefix limit on upstreams, so
this should limit the risk of the attack described in 8.2.2 somewhat.
But it will have to be combined with monitoring, so that a customer AS
does not cut itself off if the BGP table on all of their upstreams
eventually grows too large.
Kind regards,
Martin
There is still a pending comment saying:
Some terms should be unified, e.g., "upstream" "upstream provider"; "Internet peer" "lateral peer" "peer"; etc.
Additionally, terms like NLRI etc need a full clean-run.
However, this should be postponed until the document is feature-complete.
# 1. Introduction
#
# The Border Gateway Protocol (BGP), specified in [RFC4271], is the
# protocol used in the Internet to exchange routing information between
# network domains. BGP does not directly include mechanisms that
# control whether the routes exchanged conform to the various
# guidelines defined by the Internet community.
ADD HERE:
Besides, BGP by its design does not have any direct way to protect itself
against possible security-related threats.
# This document intends
# to both summarize common existing guidelines and help operators apply
# coherent BGP policies.
ADD HERE:
and apply recommended security measures to protect the operation of BGP
protocol on their BGP-speaking routers.
# 4.1. BGP Network Layer Protection
#
# To protect a BGP speaker on the network layer, the ability to connect
# to TCP port 179 on the local device should be restricted to known
# addresses that are permitted to become a BGP neighbor. Experience
# has shown that the natural protection TCP should offer is not always
# sufficient, as it is sometimes run in control-plane software.
REMARK (AUTHOR ONLY): this depends on the implementation. Cisco uses listen() calls on explicitly
configured neighbor IP addresses only, while not allowing multiple TCP sessions
between BGP endpoints. They had it like that from Day 0. OTOH, Juniper, relying on
FreeBSD socket interface, initialy in 1998 had BGP listen on (INADDR_ANY, 179/tcp).
Therefore, on Junipers, supplemental firewall filters were needed from Day 0.
Later on, I think in Junos 9 or so, this was fixed, but still having firewall filters
is highly recommended.
# 4.2. BGP Speaker Management Interface Protection
REMARK (AUTHOR ONLY): I think this whole section should be removed. At least the 1st
paragraph. Or you can remove the story about VRFs and just keep the reference to
[RFC6192]. The reason is that the management traffic story is quite complex, in the
way that it really requires a new RFC. Seriously. :-)
The full taxonomy of routing contexts used for network management can be summarized as
follows:
1. Out-of-Band (OOB) Management - routers have a dedicated interface for mgmt traffic.
2. In-band (IB) Management - mgmt traffic uses normal, revenue interfaces.
3. BOTH - combined (e.g. IB as the default method, OOB as a backup - yes, nightmare!)
And then, each of the above has two flavors:
A) Management traffic in the default routing context (a.k.a. "GRT context"), or:
B) Management traffic in a separate routing context (a.k.a. "Management VRF"):
(i) Mgmt VRF signaled automatically outside the routers (e.g. MPLS L3 VPN), or:
(ii) Mgmt VRF local-only to the router (e.g. VRF-Lite, Virtual Router)
So, you have 1A, 1B, 2A, 2B ... plus 2 sub-flavors of the B-option (i, ii).
Not all vendors can do all of those.
# 5.1.1. Integrity Verification and Authentication
#
# MD5 protection of the TCP session header, described in [RFC5925], was
# the first available mechanism to protect the integrity of a BGP
# session. It has been obsoleted by the TCP Authentication Option
# (TCP-AO; [RFC5925]), which offers stronger protection. While MD5 is
# still the most used mechanism due to its availability in vendors'
# equipment, TCP-AO SHOULD be preferred when implemented by both sides
# of a session.
ADD TEXT: Optionally, if TCP-AO is not supported, while both sides of the BGP
session can support a stronger authentication algorithm than MD5, such as
SHA-1 or SHA-256, using the stronger method SHOULD be considered. Aside of that,
using keychain-based cryptographic keys lifecycle management, as suggested in
[RFC6518], is highly RECOMMENDED.
# The drawback of TCP session protection is additional configuration
# and management overhead for the maintenance of authentication
# information (for example, MD5 passwords). Protection of TCP sessions
# used by BGP hence MAY be enabled even when BGP sessions are
# established over shared networks where spoofing can be done (like
# IXPs), but operators are RECOMMENDED to consider the trade-offs and
# to apply TCP session protection where appropriate.
REWRITE:
The drawback of TCP session protection is additional configuration and management overhead for the
maintenance of authentication information (for example, MD5 passwords). In either case, protection
of TCP sessions used by BGP MUST be enabled when BGP sessions are established over shared networks
where risk of spoofing is high (like IXPs). Operators are RECOMMENDED to consider the trade-offs
and apply BGP session protection on all other external BGP sessions as well.
Aside of this, most vendors use simple, reverse-decryptable password hash algorithm to store
shared secret keys for BGP (and other routing protocols) in the device configuration files. While
this practice simplifies password management tasks, since the passwords can always easily be
deciphered, a risk of information leak, by incidental sharing of router configuration snippets,
is high. Some vendors have an option to protect those passwords using a stronger altorithm, with
the option to show cleartext passwords upon entering a master key. Using such mechanisms, where
possible, is highly RECOMMENDED.
# Furthermore, operators SHOULD block spoofed packets (packets with a
# source IP address not belonging to their IP address space) at all
# edges of their network (see [RFC2827] and [RFC3704] ). This protects
# the TCP session used by Internal BGP (iBGP) from attackers outside
# the Autonomous System. Similarly, the considerations for using non
# globally reachable addresses for links handling BGP sessions from
# Section 4.1 apply accordingly.
ADD:
Aside of that, as an additional security measure, iBGP sessions SHOULD also be protected using
the authentication mechanisms discussed above.
# 5.1.2. Defending Against PMTUD Related Attacks
#
# In 2018 an attack on BGP was described in the literature which claims
# to enable BGP route injection without Layer 2 adjacency by leveraging
# PMTUD, see ([FENG-22]). The attack leverages packet fragmentation to
# bypass standard TCP protection mechanisms, so routes can be injected
# into an established BGP session. While the attack would be mitigated
# by the integrity mechanisms suggested in Section 5.1.1, operators
# SHOULD additionally take precautions to defend against these attacks,
# especially if authentication mechanisms are not in use. To mitigate
# this attack, BGP speakers should not allow packet fragmentation on
# the control plane for BGP traffic between themselves and their
# neighbors. This is feasible, as even on multi-hop sessions, the path
# MTU should be known to the operators, meaning that it can be
# statically and consistently configured for both speakers involved in
# a session to prevent the need for fragmentation. Hence, operators
# SHOULD ensure that fragmentation is neither allowed nor necessary for
# BGP packets between two BGP speakers. If this is not possible, a
# strict lower limit for the MTU SHOULD be configured. Given that IPv6
# requires an MTU of at least 1280b, this value is the RECOMMENDED
# minimum.
REMARK (AUTHOR ONLY): actually, it's not MTU, it's MSS. This feature is well-known
as "TCP MSS Clamping". MSS is calculated as:
tcp.mss = (ip.mtu - 40) if (ip.version == 4) else (ip.mtu - 60)
See:
https://bgp.tools/kb/understanding-tcp-mss
# 7. Dynamic Prefix Filtering
#
# In this section, we discuss dynamic prefix filters, i.e., filters
# that decide whether a prefix should be im- or exported or not based
# on frequently changing parameters and external resources.
REMARK (AUTHOR ONLY): Maybe at this point of text you should already provide a short
reference to 7.2, where ROV/RPKI is discussed. Just to say something like:
"Using Route Origin Validation (ROV), wherever possible, SHOULD be preferred over
using IRR information. ROV is discussed in Chapter 7.2.
# 7.1.3. Recursively Computing Filters
REMARK (AUTHOR ONLY): With the new version of IRRd, that will soon become used by
all major IRRs, the need for recursion will become obsolete. Even now, IRRd offers
a simple query to grab prefixes from AS-SETs (!i, !g). Also, I'm not sure whether
to refer to [bgpq4] - the tool might not exist in the future, especially having in
mind that IRRd v4 has a JSON-based interface, which makes things much easier to
grab from IRRs.
You might want to get in touch with NTT guys & girls that maintain IRRd (they
presented on RIPE87).
# 7.3. Inbound Filtering Prefixes Belonging to the Local AS
REMARK (AUTHOR ONLY): This depends on the neighbor roles - whether they are customers,
peers, transits. This section requires a bit of rework too. Or a reference to Chapter
7.5.1 where BGP roles are discussed.
# 7.6.2. Prefixes on Routers Connected to an IXP
#
# It is suggested (see also [APNICTRN-17]), that operators dedicate
# routers for connections to an IXP that SHOULD only carry routes from
# the ASes cone, and not a full-table or default-route. This reduces
# the chance of accidental route leaks and prevents other IXP members
# from pointing default routes via the IXP LAN to such a router.
ADD TEXT: alternatively, using a separate routing context (e.g. VRF) for IXP peerings,
containing only routes form the local AS cone, is a good option too.
# 8.3. AS Path Filtering
TITLE CHANGE: AS_PATH Filtering
REMARK: AS_PATH is being used in [RFC4271] as the official abbreviation of that attribute.
ADD THE FOLLOWING AT THE END OF THIS CHAPTER - with the following text:
Some BGP implementations offer various advanced AS_PATH manipulation features, such as overriding or rewriting a part of the AS_PATH.
For instance, a very commonly used mechanism is the so-called "AS Override" feature, primarily intended for use in MPLS L3 VPNs,
where the customer's AS number is overriden with the provider's AS number, to allow site-to-site communication where both customer
sites use the same AS number. Some vendors went even further, offering a possibility to fully rewrite or even delete the AS_PATH
Attribute from the incoming our outgoing BGP Update messages. In principle, use of any AS_PATH modification mechanism except
AS_PATH prepend in the public Internet SHOULD be avoided at all! Also, as discussed already, AS_PATH prepend SHOULD NOT be too
excessive. The "AS Override" feature MAY still be used in closed environments, such as VPNs not directly exchanging any NLRIs with
the Internet. AS_PATH rewriting/deleting SHOULD be avoided.
# 8.5. BGP Community Scrubbing
ADD TEXT: Extended BGP communities received from other ASNs SHOULD in principle be scrubbed. In the outbound direction,
Extended BGP communities SHOULD be scrubbed.
EXPLANATION (AUTHOR ONLY): when BGP routes are enclosed in an MPLS VRF, some vendors send route-target communities along
with advertisements to the external parties, that are treated as CE routers. While this may be useful in some cases
(e.g. [RFC4364] - Inter-AS VPN Option B), using those communities in the Internet peering context is NOT RECOMMENDED.
# 8.6. BGP Attribute Scrubbing
#
# Over the past years several instances of network disruptions due to
# routers being unable to process specific BGP attributes were
# encountered. As such, operators MAY opt to scrub all BGP attributes
# known to cause service disruptions on their infrastructure.
#
ADD TEXT:
While being a very useful tool, BGP attribute scrubbing features MAY cause undesired effects and sometimes even large-scale outages.
Therefore, this needs to be used with extreme care and treated as a last-resort temporary workaround - not a permanent solution.
This configuration SHOULD be removed when the problem, causing it to be introduced, is solved by a more stable means - e.g. by
hardware and/or software replacement or upgrade. Besides, Mandatory BGP attributes and Optional Attributes commonly used in the
Internet, such as AS_PATH, Communities, MED and so on MUST NOT be scrubbed ever!
NEW CHAPTER:
8.7. BGP Attribute Header Correction
BGP attributes are stored within BGP UPDATE messages as a vector of Type-Length-Value (TLV) fields, while the Attribute Type field
contains a set of control bits, such as Optional Bit (set to 1 for Optional Attributes and 0 for Well-Known), Transitive Bit
(specifying whether the attribute is Transitive - i.e. propagated outside the local AS or Non-Transitive - the opposite) and so on.
While [RFC4271] mandates that the BGP speaker, receiving even a single UPDATE message containing a malformed combination of
Attribute TLV headers, tears the BGP session down immediately, [RFC7606] allows the BGP implementors to optionally add various
features to the code, providing self-correction of malformed attributes in a limited number of cases.
Wherever possible, self-correcting mechanisms for BGP Attribute TLV headers SHOULD be used.
# 9.1.1. Order of Prefixfilters
PROPOSAL: Chapter 9.1.1 should become 9.1.2. And the new Chapter 9.1.1, preceding 9.1.2, should be:
9.1.1. Implicit Policies and Default Behavior
Almost all BGP implementations have a default, implicit all-permissive export/import behavior for BGP sessions, when no specific
routing policies are configured on the router. In other words, when a BGP session is configured without any explicit import and
export policy, BGP neighbors will send and accept any and all route announcements exchanged between them. Some vendors decided to
do exactly the opposite, having an implicit all-restrictive export/import behavior, denying NLRI exchange by default if no
explicit export/import policies are conofigured. While [RFC8212] finally standardized the default behavior of to be all-restrictive,
denying advertisements and acceptance of routes when no import/export policies are configured, many vendors kept their traditional
implicit behavior as-is.
Having in mind that most large networks nowadays are multi-vendor environments, while network owners very often change their
preferred eqiupment vendors and suppliers, relying on vendor-specific implicit behavior is a bad idea. What one vendor allows by
default, the other one precisely denies. Therefore, it is always RECOMMENDED to create an explicit import and
export policy on the BGP session, even if it is simple one, having a single, unconditional all-permissive rule. Aside of making
the router configuration clean, such a practice helps simplifying automation of router configurations, especially when migrating
the functionality of the router from one vendor to the other.
# Chapter 9 - Chapter 9.1.2 (existing 9.1.1)
# Most vendors apply filters and changes (route maps, prefix filters,
# and other actions) to imported and exported NLRIs following a pre-
# defined sequence, while allowing redirection to other rules.
REMARK - replace by the following:
BGP is a policy-based routing protocol. [RFC4272] - 9.1 assumes the existence of export/import routing policies, controlling
advertisement/acceptance of NLRI. And [RFC8212] standardizes the all-denying behavior of BGP sessions where no explicit
import/export policies are configured. Most vendors implement import/export policies in a myriad of ways - from very basic
prefix-based or AS_PATH-based filters, up to complex IF-THEN-like policy structures (typical names are: "route maps", "route
policies", "policy statements").
Regardless of their complexities, all BGP policies consist of one or more rule sets, that are executed in a sequence, one
after another. The first rule set will scan the complete content of Adj-RIBs-in or Adj-RIBs-out; NLRIs matching the conditions
of that rule set will be considered for further checks by the subsequent rule sets, while prefixes being denied will simply
be discarded. Therefore, each subsequent rule set should deal with a smaller subset of NLRIs than the previous ones. However,
if the first rule set does not discard any prefix, the next rule set will scan the full content of the BGP routing tables again.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.