Internet DRAFT - draft-ietf-grow-bgpopsecupd

draft-ietf-grow-bgpopsecupd







Global Routing Operations                                      T. Fiebig
Internet-Draft                                                   MPI-INF
Obsoletes: 7454 (if approved)                            26 January 2024
Intended status: Best Current Practice                                  
Expires: 29 July 2024


                  Updated BGP Operations and Security
                     draft-ietf-grow-bgpopsecupd-01

Abstract

   The Border Gateway Protocol (BGP) is the protocol almost exclusively
   used in the Internet to exchange routing information between network
   domains.  Due to this central nature, it is important to understand
   the security and reliability measures that can and should be deployed
   to prevent accidental or intentional routing disturbances.

   Previously, security considerations for BGP have been described in
   RFC7454 / BCP194.  Since the publications of RFC7454 / BCP194,
   several developments and changes in operational practice took place
   that warrant an update of these best current practices.  This
   document replaces RFC7454 / BCP194, reiterating the best practices
   for BGP security from that document and adding new practices and
   recommendations that emerged since its publication.

   This document provides a comprehensive list of Internet specific BGP
   security and reliability related best practices as of the time of
   publication.  It specifically does not cover other uses of BGP, e.g.,
   in a datacenter context.

   While the recommendations in this document are, in general, best
   practices, operators still need to carefully weigh individual
   measures vs. their local network requirements before implementing
   them.  Also, as with BCP194, best practices outlined in this document
   may have changed since its publication.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.





Fiebig                    Expires 29 July 2024                  [Page 1]

Internet-Draft                  BGP OPSEC                   January 2024


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 29 July 2024.

Copyright Notice

   Copyright (c) 2024 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 (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Scope of the Document . . . . . . . . . . . . . . . . . . . .   4
   3.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   5
   4.  Protection of the BGP Speaker . . . . . . . . . . . . . . . .   7
     4.1.  BGP Network Layer Protection  . . . . . . . . . . . . . .   7
     4.2.  BGP Speaker Management Interface Protection . . . . . . .   8
   5.  Protection of the BGP Sessions  . . . . . . . . . . . . . . .   8
     5.1.  Protection of TCP Sessions Used by BGP  . . . . . . . . .   9
       5.1.1.  Integrity Verification and Authentication . . . . . .   9
       5.1.2.  Defending Against PMTUD Related Attacks . . . . . . .  10
     5.2.  BGP TTL Security (GTSM) . . . . . . . . . . . . . . . . .  11
   6.  Static Prefix Filtering . . . . . . . . . . . . . . . . . . .  11
     6.1.  Special-Purpose Prefixes  . . . . . . . . . . . . . . . .  11
       6.1.1.  IPv4 Special-Purpose Prefixes . . . . . . . . . . . .  12
       6.1.2.  IPv6 Special-Purpose Prefixes . . . . . . . . . . . .  12
     6.2.  Unallocated Prefixes  . . . . . . . . . . . . . . . . . .  12
       6.2.1.  IANA-Allocated Prefix Filters . . . . . . . . . . . .  12
     6.3.  Prefixes That Are Too (Un)Specific  . . . . . . . . . . .  13
     6.4.  The Default Route . . . . . . . . . . . . . . . . . . . .  14
       6.4.1.  IPv4  . . . . . . . . . . . . . . . . . . . . . . . .  14
       6.4.2.  IPv6  . . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Dynamic Prefix Filtering  . . . . . . . . . . . . . . . . . .  14
     7.1.  Prefix Filters Created from Internet Routing Registries
           (IRRs)  . . . . . . . . . . . . . . . . . . . . . . . . .  14



Fiebig                    Expires 29 July 2024                  [Page 2]

Internet-Draft                  BGP OPSEC                   January 2024


       7.1.1.  Route Objects . . . . . . . . . . . . . . . . . . . .  15
       7.1.2.  AS-SETs . . . . . . . . . . . . . . . . . . . . . . .  15
       7.1.3.  Recursively Computing Filters . . . . . . . . . . . .  16
     7.2.  SIDR - Secure Inter-Domain Routing: RPKI and ASPA . . . .  17
       7.2.1.  Route Origin Validation (ROV) . . . . . . . . . . . .  17
       7.2.2.  Autonomous System Provider Authorization (ASPA) . . .  18
     7.3.  Inbound Filtering Prefixes Belonging to the Local AS  . .  19
     7.4.  Inbound Filtering Prefixes Belonging to Downstreams . . .  19
     7.5.  Outbound Filtering Prefixes Based on Learned-From . . . .  20
       7.5.1.  Outbound Filtering Prefixes Using BGP Roles . . . . .  20
       7.5.2.  Outbound Filtering Using Large-Communities  . . . . .  21
     7.6.  IXP LAN Prefixes  . . . . . . . . . . . . . . . . . . . .  22
       7.6.1.  IXP LAN Prefix Filtering  . . . . . . . . . . . . . .  22
       7.6.2.  Prefixes on Routers Connected to an IXP . . . . . . .  23
       7.6.3.  PMTUD and the Loose uRPF Problem  . . . . . . . . . .  23
   8.  Filtering and Cleaning Based on Other BGP Aspects . . . . . .  23
     8.1.  BGP Route Flap Dampening  . . . . . . . . . . . . . . . .  23
     8.2.  Maximum Prefixes  . . . . . . . . . . . . . . . . . . . .  24
       8.2.1.  Maximum Prefixes on a Single Session  . . . . . . . .  24
       8.2.2.  Maximum Prefixes per Neighboring AS . . . . . . . . .  25
     8.3.  AS_PATH Handling  . . . . . . . . . . . . . . . . . . . .  25
       8.3.1.  AS_PATH Filtering . . . . . . . . . . . . . . . . . .  25
       8.3.2.  AS_PATH Manipulation  . . . . . . . . . . . . . . . .  27
     8.4.  Next-Hop Filtering  . . . . . . . . . . . . . . . . . . .  28
     8.5.  BGP Community Scrubbing . . . . . . . . . . . . . . . . .  29
       8.5.1.  Inbound BGP Community Scrubbing . . . . . . . . . . .  30
       8.5.2.  Outbound BGP Community Scrubbing  . . . . . . . . . .  30
     8.6.  Handling BGP Attributes . . . . . . . . . . . . . . . . .  31
       8.6.1.  BGP Attribute Scrubbing . . . . . . . . . . . . . . .  31
       8.6.2.  BGP Attribute Header Correction . . . . . . . . . . .  32
     8.7.  Preventing MED Oscilation . . . . . . . . . . . . . . . .  32
     8.8.  Behavior when Connecting via an IXP . . . . . . . . . . .  33
       8.8.1.  Not Setting a Higher LOCAL_PREF for NLRI received via
               an IXP  . . . . . . . . . . . . . . . . . . . . . . .  33
       8.8.2.  Honoring GSHUT on an IXP  . . . . . . . . . . . . . .  34
   9.  Prefix Filtering Recommendations  . . . . . . . . . . . . . .  34
     9.1.  Prefix Filter Implementation Considerations . . . . . . .  34
       9.1.1.  Implicit Policies and Default Behavior  . . . . . . .  34
       9.1.2.  Order of Prefixfilters  . . . . . . . . . . . . . . .  35
       9.1.3.  Ensuring Consistency when Changing Prefixfilters  . .  36
       9.1.4.  Ensuring Idempotency for Prefixfilter Changes . . . .  37
       9.1.5.  Ruleset Size Considerations . . . . . . . . . . . . .  38
       9.1.6.  Ruleset Generation Failure  . . . . . . . . . . . . .  38
     9.2.  Prefix Filtering Recommendations in Full Routing
           Networks  . . . . . . . . . . . . . . . . . . . . . . . .  39
       9.2.1.  Filters with Internet Peers . . . . . . . . . . . . .  39
       9.2.2.  Filters with Customers  . . . . . . . . . . . . . . .  41
       9.2.3.  Filters with Upstream Providers . . . . . . . . . . .  44



Fiebig                    Expires 29 July 2024                  [Page 3]

Internet-Draft                  BGP OPSEC                   January 2024


     9.3.  Prefix Filtering Recommendations for Leaf Networks  . . .  45
       9.3.1.  Inbound Filtering . . . . . . . . . . . . . . . . . .  45
       9.3.2.  Outbound Filtering  . . . . . . . . . . . . . . . . .  45
     9.4.  Prefix Filtering Recommendations for Mutual Transit . . .  45
     9.5.  Prefix Filtering Recommendations for iBGP . . . . . . . .  46
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  47
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  47
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  47
     12.2.  Informative References . . . . . . . . . . . . . . . . .  50
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  54
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  55

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.  Besides, BGP itself,
   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 and recommended security guidelines to their
   BGP-speaking routers.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Scope of the Document

   The guidelines defined in this document are intended for BGP sessions
   carrying generic Internet routing information within the DFZ.  It
   specifically does not cover other uses of BGP, e.g., when using BGP
   for NLRI exchange in a data-center context.  The nature of the
   Internet is such that Autonomous Systems can always agree on
   exceptions to a common framework for relevant local needs, and
   therefore configure a BGP session in a manner that may differ from
   the recommendations provided in this document.  While this is
   perfectly acceptable, every configured exception might have an impact
   on the entire inter-domain routing environment, and operators SHOULD
   carefully appraise this impact before implementation.




Fiebig                    Expires 29 July 2024                  [Page 4]

Internet-Draft                  BGP OPSEC                   January 2024


3.  Definitions and Acronyms

   The following terms are used in this document:

   ACL:
      Access Control List

   ASN:
      Autonomous System Number

   DFZ:
      Default Free Zone

   GRT:
      Global Routing Table

   IRR:
      Internet Routing Registry

   IXP:
      Internet Exchange Point

   LIR:
      Local Internet Registry

   NLRI:
      Network Layer Reachability Information

   OTC:
      Only To Customer BGP Attribute

   PMTUD:
      Path MTU Discovery

   uRPF:
      Unicast Reverse Path Forwarding

   In addition to the list above, the following terms are used with a
   specific meaning.

   BGP Speaker:
      A device exchanging routes with other BGP speakers using the BGP
      protocol

   BGP Neighbor:
      Also just 'Neighbor'.  Two BGP speakers that communicate using the
      BGP protocols are neighbors.




Fiebig                    Expires 29 July 2024                  [Page 5]

Internet-Draft                  BGP OPSEC                   January 2024


   Cone:
      The set of ASes who are either direct downstreams of an AS, or in
      the cone of any of those ASes; Depending on the context this also
      includes the joint set of prefixes that may be originated by ASes
      in a cone.

   Downstream:
      In a direct relationship between two ASes the one receiving
      upstream from the other.  (See: [RFC9234], also known as the
      customer in a customer-provider relationship.)

   Exporting a Prefix:
      Advertising a prefix to a neighbor.

   Full Table:
      A routing table containing a route to all prefixes in the GRT but
      not the default route.

   Importing a Prefix:
      Accepting a prefix advertised by a neighbor and considering it for
      route selection and import into the local AS' routing table.

   Network edge:
      Last routers under the control of an operator.

   Mutual Transit:
      When two directly connected ASes both advertise a BGP fulltable to
      each other.  (See: [I-D.ietf-sidrops-aspa-verification])

   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.)

   Operator:
      Individual, group of people, or organizational unit responsible
      for operating BGP speakers, i.e., making administrative changes,
      as well as defining and setting policies for all BGP speakers
      within an organization.

   Originating a Prefix:
      Advertising a prefix with an empty AS-Path.

   Peer:
      Two directly connected ASes who only advertise routes they
      originate or learned from their downstreams to each other.  (See:
      [RFC9234])




Fiebig                    Expires 29 July 2024                  [Page 6]

Internet-Draft                  BGP OPSEC                   January 2024


   Providing Transit:
      Forwarding packets destined for addresses in an advertised prefix,
      while advertising a full BGP table or default route to the
      neighbor.

   Providing Upstream:
      See: Providing Transit

   Router:
      In this document, router always refers to a BGP speaker.

4.  Protection of the BGP Speaker

   The BGP speaker needs to be protected from external attempts to
   subvert the BGP session.  Furthermore, access to management services
   of the BGP speaker should be limited to neighbors, as these services
   usually share resources with the control plane and, e.g., automated
   attacks on management ports may impact the BGP speaker's ability to
   execute BGP related tasks.

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.  In the
   absence of ACLs, it is possible to attack a BGP speaker by simply
   sending a high volume of connection requests to it.  This protection
   SHOULD be implemented by using an Access Control List (ACL) to limit
   access to TCP port 179 to authorized hosts.

   If supported, an ACL specific to the control plane of the router
   SHOULD be used (receive-ACL, control-plane policing, etc.), to avoid
   configuration of data-plane filters for packets transiting through
   the router (and therefore not reaching the control plane).  If the
   hardware cannot do that, interface ACLs can be used to block packets
   addressed to the local router.

   Some routers automatically program such an ACL upon BGP
   configuration.  On other devices, this ACL should be configured and
   maintained manually or using scripts.









Fiebig                    Expires 29 July 2024                  [Page 7]

Internet-Draft                  BGP OPSEC                   January 2024


   In addition to strict filtering, rate-limiting MAY be configured for
   accepted BGP traffic.  Rate-limiting BGP traffic consists in
   permitting only a certain quantity of bits per second (or packets per
   second) of BGP traffic to the control plane.  This protects the BGP
   router control plane in case the amount of BGP traffic surpasses
   platform capabilities.

   Furthermore, it is possible to use non-gloablly reachable addresses
   for BGP session links.  Options include using IPv4 routes with an
   IPv6 next hop in IPv4 sessions (see [RFC9229]), using prefixes not
   advertised in the GRT ([TBD]), using unnumbered BGP/Link-Local
   addresses (also using [RFC9229]), or using [RFC1918] addresses for
   IPv4 sessions.  Even though routing based network layer protection
   MAY be implemented, it SHOULD only be done in addition to deploying
   ACLs.  If any of these approaches is utilized, it MUST be ensured
   that the BGP speaker originates Path MTU Discovery related packets
   (see [RFC1191] for IPv4 and [RFC8201] for IPv6) from a globally
   reachable address, to ensure that Reverse Path Filtering of external
   parties does not interfere with PMTUD discovery for transiting
   traffic.

4.2.  BGP Speaker Management Interface Protection

   Usually, a BGP speaker's management interface is also reachable in-
   band, i.e., via the default routing domain / VRF (Virtual Routing
   Fabric) of the control plane.  To make it easier to separate BGP and
   management related control plane traffic, management traffic SHOULD
   be exclusively handled via dedicated out-of-band management.  This
   network SHOULD be protected from unauthorized connections by ACLs not
   handled on the BGP speaker itself to ensure that the control plane
   cannot be overloaded by attacks on the management interfaces of the
   BGP speaker.

   Please note that, in general, filtering and rate-limiting of control-
   plane traffic is a wider topic than "just for BGP".  For further
   recommendations on how to protect the router's control plane, see
   [RFC6192] )

5.  Protection of the BGP Sessions

   Current security issues of TCP-based protocols (therefore including
   BGP) have been documented in [RFC6952].  The following subsections
   list the major points raised in this document and give the best
   practices related to TCP session protection for BGP operation.







Fiebig                    Expires 29 July 2024                  [Page 8]

Internet-Draft                  BGP OPSEC                   January 2024


5.1.  Protection of TCP Sessions Used by BGP

   Attacks on TCP sessions used by BGP (aka BGP sessions), for example,
   sending spoofed TCP RST packets, could bring down a BGP session.
   Following a successful ARP spoofing attack (or other similar man-in-
   the-middle attack), the attacker might even be able to inject packets
   into the TCP stream (routing attacks).

   BGP sessions can be secured with a variety of mechanisms.

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.

   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 from that, using keychain-based cryptographic keys
   lifecycle management, as suggested in [RFC6518] is highly
   RECOMMENDED.

   Additionally, IPsec could also be used for session protection.  At
   the time of publication, there has been no wide-spread adoption of
   using IPsec for BGP sessions, and further analysis is required to
   define guidelines.

   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 SHOULD be enabled when BGP sessions are
   established over shared networks where the risk of spoofing is high
   (like IXPs).  Operators are also RECOMMENDED to consider the trade-
   offs and apply BGP session protection on all other external BGP
   sessions as well.











Fiebig                    Expires 29 July 2024                  [Page 9]

Internet-Draft                  BGP OPSEC                   January 2024


   Aside of this, most vendors use simple, reverse-decryptable password
   hash algorithm to store shared secrets keys for BGP (and other
   routing protocols) in devices' configuration files.  While this
   practice simplifies password management tasks, since the passwords
   can always easily be deciphered, it carries the risk of leaking this
   information if a configuration is shared, e.g., with a vendor for a
   support case, or if the device is decommissioned and later resold
   without having been wiped.  Hence, if a device offers more secure
   storage mechanisms for secrets, these SHOULD be used.

   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.

   Furthermore, 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.  This is usually
   done for TCP packets like those for a BGP session using MSS (Maximum
   Segment Size) clamping.  Given that IPv6 requires an MTU of at least
   1280b [RFC8200], and to keep clamping consistent between IPv4 and
   IPv6, an MTU of 1280b, i.e., an MSS of 1240b for IPv4 and 1220b for
   IPv6, is the RECOMMENDED minimum.





Fiebig                    Expires 29 July 2024                 [Page 10]

Internet-Draft                  BGP OPSEC                   January 2024


5.2.  BGP TTL Security (GTSM)

   BGP sessions can be made harder to spoof with the Generalized TTL
   Security Mechanisms (GTSM aka TTL security), defined in [RFC5082].
   Instead of sending TCP packets with TTL value of 1, the BGP speakers
   send the TCP packets with TTL value of 255, and the receiver checks
   that the TTL value equals 255.  Since it's impossible to send an IP
   packet with TTL of 255 to an IP host that is not directly connected,
   BGP TTL security effectively prevents all spoofing attacks coming
   from third parties not directly connected to the same subnet as the
   BGP-speaking routers.  Operators SHOULD implement TTL security on
   directly connected BGP neighbors.

   GTSM could also be applied to multi-hop BGP session as well.  To
   achieve this, TTL needs to be configured with a proper value
   depending on the distance between BGP speakers (using the principle
   described above).  Nevertheless, it is not as effective because
   anyone inside the TTL diameter could spoof the TTL.

   Like MD5 protection, TTL security has to be configured on both ends
   of a BGP session.

6.  Static Prefix Filtering

   The main aspect of securing BGP resides in controlling the prefixes
   that are received and advertised on the BGP session.  Prefixes
   exchanged between BGP neighbors are controlled with inbound and
   outbound filters that can match on well-known/statically typed IP
   prefixes (as described in this section), a combination of Prefix and
   AS paths (see ), BGP roles as (see Section 7.5.1), or any other
   attributes of a BGP prefix (for example, BGP communities, as
   described in Section 7.5.2).

   This section lists the most commonly used static prefix filters.  We
   define static prefixes as prefixes that are published via an
   authoritative list which changes, on average, not more frequently
   than every 12 months.  We will utilize these definitions of static
   prefixes in Section 9 to clarify where and how these filters should
   be applied.

6.1.  Special-Purpose Prefixes










Fiebig                    Expires 29 July 2024                 [Page 11]

Internet-Draft                  BGP OPSEC                   January 2024


6.1.1.  IPv4 Special-Purpose Prefixes

   The IANA IPv4 Special-Purpose Address Registry [IANAv4Spec] maintains
   the list of IPv4 special-purpose prefixes and their routing scope,
   and it SHOULD be used for prefix-filter configuration.  Prefixes with
   value "False" in column "Global" SHOULD be discarded on Internet BGP
   sessions (eBGP).

6.1.2.  IPv6 Special-Purpose Prefixes

   The IANA IPv6 Special-Purpose Address Registry [IANAv6Spec] maintains
   the list of IPv6 special-purpose prefixes and their routing scope,
   and it SHOULD be used for prefix-filter configuration.  Only prefixes
   with value "False" in column "Global" SHOULD be discarded on Internet
   BGP sessions.

6.2.  Unallocated Prefixes

   IANA allocates prefixes to RIRs that in turn allocate prefixes to
   LIRs (Local Internet Registries).  While it is in general sensible to
   not accept routing table prefixes that are not allocated by IANA and/
   or RIRs, it is important to understand that filtering unallocated
   prefixes requires constant updates, as prefixes are continually
   allocated.  Therefore, automation of such prefix filters is key for
   the success of this approach.  Operators SHOULD NOT consider
   solutions described in this section if they are not capable of
   maintaining updated prefix filters: the damage would probably be
   worse than the intended security policy.  In this section we focus on
   IP address space allocated to RIRs by IANA.  Allocations by RIRs are
   generally more dynamic.  Therefore, we will discuss using RIR level
   data in Section 7.1.

6.2.1.  IANA-Allocated Prefix Filters

   IANA has allocated all the IPv4 available space.  Therefore, there is
   no reason why operators would keep checking that prefixes they
   receive from BGP neighbors are in the IANA-allocated IPv4 address
   space [IANAv4Reg].  No specific filters need to be put in place by
   operators who want to make sure that IPv4 prefixes they receive in
   BGP updates have been allocated by IANA.

   For IPv6, given the size of the address space, it can be seen as wise
   to accept only prefixes derived from those allocated by IANA.
   Operators can dynamically build this list from the IANA- allocated
   IPv6 space [IANAv6Reg].  As IANA keeps allocating prefixes to RIRs,
   the aforementioned list should be checked regularly against changes,
   and if they occur, prefix filters should be computed and pushed on
   network devices.  The list could also be pulled directly by routers



Fiebig                    Expires 29 July 2024                 [Page 12]

Internet-Draft                  BGP OPSEC                   January 2024


   when they implement such mechanisms.  As there is delay between the
   time an RIR receives a new prefix and the moment it starts allocating
   portions of it to its LIRs, there is no need for doing this step
   quickly and frequently.  However, operators SHOULD ensure that all
   IPv6 prefix filters are updated within a maximum of one month after
   any change in the list of IPv6 prefixes allocated by IANA.

   If the process in place (whether manual or automatic) cannot
   guarantee that the list is updated regularly, then it's better not to
   configure any filters based on allocated networks.  The IPv4
   experience has shown that many network operators implemented filters
   for prefixes not allocated by IANA but did not update them on a
   regular basis.  This created problems for the latest allocations, and
   required extra work for RIRs that had to "de-bogonize" the newly
   allocated prefixes.  (See [RIPE-351] for information on de-
   bogonizing.)

6.3.  Prefixes That Are Too (Un)Specific

   Most ISPs will not accept advertisements beyond a certain level of
   specificity (and in return, they do not announce prefixes they
   consider to be too specific).  That acceptable specificity is decided
   for each session between two BGP neighbors.  Some ISP communities
   have tried to document acceptable specificity.  This document does
   not make any judgement on what the best approach is, it just notes
   that there are existing practices on the Internet and recommends that
   the reader refer to them.  As an example, the RIPE community has
   documented that, at the time of writing of this document, IPv4
   prefixes longer than /24 and IPv6 prefixes longer than /48 are
   generally neither announced nor accepted in the Internet [RIPE-399]
   [RIPE-532].  These values may change in the future.

   Some operators MAY choose to allow customers to additionally announce
   more specifics than commonly used on the Internet (see Section 6.3).
   This can be to allow customers more fine-grained traffic steering in
   case of multiple BGP sessions between the AS and its customer in
   multiple locations, and/or to sub-delegate IPv4 address space smaller
   than a /24 from the AS' allocation to the customer.

   In that case, the operators SHOULD add a specific accept rule for
   these exact prefixes before Rule 11.  Routes of this type SHOULD be
   annotated in away that ensures they are not re-exported to other
   neighbors (see Section 7.5.2).  Furthermore, in case of using more
   specifics for traffic steering, the customer SHOULD also announce at
   least the covering /24 to ensure global reachability of the prefix
   and prevent issues with uRPF (see also [RFC8704] and Section 7.6.3).





Fiebig                    Expires 29 July 2024                 [Page 13]

Internet-Draft                  BGP OPSEC                   January 2024


   Similar to too specific routes, most ISPs will not accept
   advertisements beyond a certain level of aggregation.  The general
   guideline here are the least specific allocations commonly handed out
   by RIRs to LIRs.  At the moment, the largest allocations for IPv4 are
   continuous /8.  For IPv6, one /13 allocation exists, followed by
   several LIRs holding /19.  Several operators currently limit the
   smallest prefix size for IPv6 to /16.  This document does not make
   any judgement on what the best approach is, it just notes that there
   are existing practices on the Internet and recommends that the reader
   refer to them.  These values may change in the future.

6.4.  The Default Route

6.4.1.  IPv4

   Typically, the 0.0.0.0/0 prefix is not intended to be accepted or
   advertised except in specific customer/provider configurations;
   general filtering outside of these is RECOMMENDED.

6.4.2.  IPv6

   Typically, the ::/0 prefix is not intended to be accepted or
   advertised except in specific customer/provider configurations;
   general filtering outside of these is RECOMMENDED.

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.

7.1.  Prefix Filters Created from Internet Routing Registries (IRRs)

   A more precise check can be performed when one would like to make
   sure that received prefixes are being originated or transited by
   Autonomous Systems (ASes) entitled to do so.  It has been observed in
   the past that an AS could easily advertise someone else's prefix (or
   more specific prefixes) and create black holes or security threats.
   To partially mitigate this risk, administrators would need to make
   sure BGP advertisements correspond to information located in the
   existing registries.

   An Internet Routing Registry (IRR) is a database containing Internet
   routing information, described using Routing Policy Specification
   Language objects as described in [RFC4012].  Operators are given
   privileges to describe routing policies of their own networks in the
   IRR, and that information is published, usually publicly.  A majority
   of Regional Internet Registries do also operate an IRR and can



Fiebig                    Expires 29 July 2024                 [Page 14]

Internet-Draft                  BGP OPSEC                   January 2024


   control whether registered routes conform to the prefixes that are
   allocated or directly assigned.  However, it should be noted that the
   list of such prefixes is not necessarily a complete list, and as such
   the list of routes in an IRR is not the same as the set of RIR-
   allocated prefixes.  Furthermore, especially IRRs not operated by
   RIRs regularly list conflicting information, see Section 7.1.

7.1.1.  Route Objects

   The corner stone of IRR based information are ROUTE (IPv4) and ROUTE6
   (IPv6) objects.  These document, for a given prefix, the AS/ASes
   allowed to originate the prefix.  Note that for a given prefix also
   more specific objects may exist.  However, technically, the semantic
   of a ROUTE/ROUTE6 object is that of an exact match.

   Operators SHOULD create ROUTE/ROUTE6 objects for all prefixes they do
   or do plan to originate.

7.1.2.  AS-SETs

   An AS-SET is an object that contains AS numbers or other AS-SETs.
   The purpose of AS-SETs is creating a recursively queryable structure
   documenting the cone of an AS.  An operator may create an AS-SET
   defining all AS numbers of its customers.  A transit provider might
   create an AS-SET listing the AS numbers or AS-SETS of those ASes it
   provides upstream to.  In turn, these ASes describe the AS numbers/
   AS-SETS of their customers, etc.  Using recursion, it is possible to
   retrieve from an AS-SET the complete list of AS numbers that the
   neighbor is likely to announce.  For each of these AS numbers, it is
   also easy to look in the corresponding IRR for all associated
   prefixes.

   Please note that different IRR may provide conflicting data,
   especially on AS-SETs.  Recently, an attack was observed where a
   malicious party created an empty AS-SET for a large transit provider
   (see [NLNOG-22]).  As it was created in an RIR database often taking
   precedent over other IRR sources, several ASes imported this empty
   AS-SET, and hence filtered all prefixes advertised by this transit
   provider.  To mitigate this issue, hierarchical AS-SETs reside in the
   IRR of the RIR and explicitly list the ASN to which they pertain,
   e.g., AS65536:AS-EXAMPLE.  Additionally, the IRR source may also be
   referenced: RIPE::AS65536:AS-EXAMPLE.

   Operators SHOULD create a hierarchical AS-SET representing their
   cone.  If AS-SETs are included in another AS-SET, they SHOULD be
   hierarchical.





Fiebig                    Expires 29 July 2024                 [Page 15]

Internet-Draft                  BGP OPSEC                   January 2024


7.1.3.  Recursively Computing Filters

   Using AS-SETs and ROUTE/ROUTE6 objects, it is possible to use the IRR
   information to build, for a given neighbor AS, a list of prefixes the
   neighbor is authorized to originated or transited.  This can be done
   relatively easily using scripts and existing tools capable of
   retrieving this information from the registries.  This approach is
   exactly the same for both IPv4 and IPv6.

   The macro-algorithm for the script is as follows.  For the neighbor
   that is considered, the distant operator has provided the AS and may
   be able to provide a hierarchically named AS-SET object (aka AS-
   MACRO).  With these two mechanisms, a script can build, for a given
   neighbor, that lists allowed prefixes and the AS number from which
   they should be originated.  One could decide not to use the origin
   information and only build monolithic prefix filters from fetched
   data combining prefixes a neighbor is authorized to transit and
   originate.

   As prefixes, AS numbers, and AS-SETs may not all be under the same
   RIR authority, it is difficult to choose for each object the
   appropriate IRR to poll.  Some IRRs have been created and are not
   restricted to a given region or authoritative RIR.  They allow RIRs
   to publish information contained in their IRR in a common place.
   They also make it possible for any subscriber (probably under
   contract) to publish information too.  When doing requests inside
   such an IRR, it is possible to specify the source of information in
   order to have the most reliable data.  One could check a popular IRR
   containing many sources (such as RADb [RADb], the Routing Assets
   Database) and only select as sources some desired RIRs and trusted
   major ISPs (Internet Service Providers).

   As objects in IRRs may frequently vary over time, it is important
   that prefix filters computed using this mechanism are refreshed
   regularly.  Refreshing the filters on a daily basis SHOULD be
   considered because routing changes must sometimes be done in an
   emergency and registries may be updated at the very last moment.
   Note that this approach significantly increases the complexity of the
   router configurations, as it can quickly add tens of thousands of
   configuration lines for some important neighbors, e.g., large peers
   or downstreams.  To manage this complexity, operators could use, for
   example, bgpq4 [bgpq4], a set of tools making it possible to simplify
   the creation of automated filter configuration from policies stored
   in an IRR.







Fiebig                    Expires 29 July 2024                 [Page 16]

Internet-Draft                  BGP OPSEC                   January 2024


7.2.  SIDR - Secure Inter-Domain Routing: RPKI and ASPA

   SIDR (Secure Inter-Domain Routing), described in [RFC6480], has been
   designed to secure Internet advertisements.  Even though technically
   incorrect, as it is only the name of an important component, the use
   of techniques entailed in SIDR is commonly referred to as RPKI
   (Resource Public Key Infrastructure).

   There are basically two services that SIDR offers:

   *  Origin validation, described in [RFC6811], seeks to make sure that
      attributes associated with routes are correct, see Section 7.2.1.
      (The major point is the validation of the AS number originating a
      given route.)  Origin validation is now operational (Internet
      registries, protocols, implementations on some routers), and in
      theory it can be implemented knowing that the number of signed
      resources is still low at the time of writing this document.

   *  Path validation provided by BGPsec [RFC7353] seeks to make sure
      that no one announces fake/wrong BGP paths that would attract
      traffic for a given destination; see [RFC7132].  Even though the
      work on BGPsec has been concluded, adoption is still limited.
      Instead, the use of ASPA (Autonomous System Provider
      Authorization) [I-D.ietf-sidrops-aspa-verification] objects, see
      also Section 7.2.2, is likely to be more relevant within the
      context of BGP.  Even though the draft on ASPA has not been
      finalized, first adoption of ASPA can be observed, and first
      implementations started to support it, following the development
      of [I-D.ietf-sidrops-aspa-verification], see [OpenBGPd] and
      [rpki-client].

   Implementing SIDR mechanisms is expected to solve many of the BGP
   routing security problems in the long term, but it may take time for
   deployments to be made and objects to become signed.  Also, note that
   the SIDR infrastructure is complementing (not replacing) the security
   best practices listed in this document.  Therefore, operators SHOULD
   implement any SIDR proposed mechanism (for example, route origin
   validation) on top of the other existing mechanisms even if they
   could sometimes appear to be targeting the same goal.

7.2.1.  Route Origin Validation (ROV)

   If route origin validation is implemented, the reader SHOULD refer to
   the rules described in [RFC7115].  In short, each external route
   received on a router SHOULD be checked against the Resource Public
   Key Infrastructure (RPKI) data set:





Fiebig                    Expires 29 July 2024                 [Page 17]

Internet-Draft                  BGP OPSEC                   January 2024


   *  If a corresponding ROA (Route Origin Authorization) is found and
      is valid, then the prefix SHOULD be accepted.

   *  If the ROA is found and is INVALID, then the prefix SHOULD be
      discarded.

   *  If a ROA is not found, then the prefix SHOULD be accepted, but the
      corresponding route SHOULD be given a low preference.

   In addition to this, operators SHOULD sign their routing objects so
   their routes can be validated by other networks running origin
   validation.  Please note that, when signing routing objects,
   operators SHOULD strive to create minimally covering ROAs for their
   intended announcements, see [RFC7115] and [RFC9319], to reduce the
   attack surface of forged-origin hijacks and attempts to exhaust
   routers' route processing capacity in terms of memory and CPU
   [KIRIN-22].  For example, if an operator received a /29 allocation
   and intends to announce it in a deaggregation of /32, the
   corresponding ROA should cover the /29 with a longest allowed prefix
   of /32, instead of signing for a deaggregation up until /48.

   One should understand that the RPKI model brings new, interesting
   challenges.  The paper "On the Risk of Misbehaving RPKI Authorities"
   [hotRPKI] explains how the RPKI model can impact the Internet if
   authorities don't behave as they are supposed to.  Further analysis
   is certainly required on RPKI, which carries part of BGP security.

7.2.2.  Autonomous System Provider Authorization (ASPA)

   If autonomous system provider authorization is implemented, the
   reader SHOULD refer to the rules described in
   [I-D.ietf-sidrops-aspa-verification].  In short, each external route
   received on a router SHOULD be checked against the ASPA record found
   in the Resource Public Key Infrastructure (RPKI) based on the
   relationship to the neighbor.

   In [I-D.ietf-sidrops-aspa-verification], see following sections based
   on the neighbor relationship:

   *  Section 6.1 for routes received from customer, lateral peer, by an
      RS from an RS-client, or by an RS-client from an RS.

   *  Section 6.2 for routes received from an upstream or mutual-transit
      neighbor.

   ASPA validation can result in one of three outcomes, VALID, INVALID,
   and UNKNOWN.




Fiebig                    Expires 29 July 2024                 [Page 18]

Internet-Draft                  BGP OPSEC                   January 2024


   *  If a route's AS_PATH is evaluated as VALID, then the prefix SHOULD
      be accepted.

   *  If a route's AS_PATH is evaluated as INVALID, then the prefix
      SHOULD be discarded, and the event logged.

   *  If a route's AS_PATH is evaluated as UNKNOWN, then the prefix
      SHOULD be accepted, and the event logged.  The corresponding route
      MAY be given a low preference.

7.3.  Inbound Filtering Prefixes Belonging to the Local AS

   A network SHOULD filter its own prefixes on BGP sessions with all its
   neighbors (inbound direction).  This prevents local traffic (from a
   local source to a local destination) from leaking over an external
   BGP session, in case someone else is announcing the prefix over the
   Internet.  This also protects the infrastructure that may directly
   suffer if the backbone's prefix is suddenly preferred over the
   Internet.

   In some cases, for example, multihoming scenarios, such filters
   SHOULD NOT be applied, as this would break the desired redundancy.

7.4.  Inbound Filtering Prefixes Belonging to Downstreams

   Filtering prefixes belonging to multi-homed downstreams on sessions
   with other ASes is NOT RECOMMENDED.  This practice may lead to
   blackholing of traffic if the filter is semi-statically configured,
   i.e., not removed upon withdrawal of the specific prefix by a
   downstream.  Downstreams may choose to not advertise prefixes to an
   upstream for a variety of reasons, including traffic engineering and
   Denial-of-Service attack response.  Instead, operators SHOULD assign
   downstreams' prefixes learned from other neighbors a lower priority
   than those routes directly learned from downstreams.  This can be
   done, e.g., by adding additional path prepends or using local
   preference settings.  Please note, though, that using local
   preferences for this purpose may lead to a situation where a
   downstream is unable to perform traffic engineering apart from
   withdrawing a route towards its upstream in case of, e.g., a
   congested link in a multi-homed setup.











Fiebig                    Expires 29 July 2024                 [Page 19]

Internet-Draft                  BGP OPSEC                   January 2024


   Even though filtering prefixes belonging to single-homed downstreams
   on sessions with other ASes carries less risk of immediate negative
   impact, it is crucial that operators coordinate closely with their
   downstream if such practices are applied.  Otherwise, if a downstream
   becomes multi-homed connectivity issues may appear.  Hence, assuming
   that other appropriate filters are in place ensuring, e.g., validity
   of the announcing AS and the AS-PATH, see Section 9.2, not filtering
   prefixes originated by downstreams on sessions with other ASes solely
   based on the prefix is NOT RECOMMENDED.

7.5.  Outbound Filtering Prefixes Based on Learned-From

   TODO: Make more general about annotating routes, also include BGP
   neighbor roles.

   Prefixes learned from BGP neighbors may technically conform to static
   metrics and filter types discussed above.  For example, when learning
   prefixes from peers and/or upstreams which have been originally
   announced by downstreams of an AS, it is crucial to not leak these
   routes to upstreams and peers in case they are preferred over those
   learned directly from a downstream.  This may occur, for example, if
   a downstream uses path prepending with an upstream, while the
   upstream has a peering session with another AS which is also an
   upstream of said downstream.  With the route advertised by the peer
   being shorter, the AS may export the learned route via the peer if:

   *  The outbound filter only checks whether a prefix is in a prefix
      list.

   *  The outbound filter only checks whether a prefix is in a prefix
      list and has been originated by the downstream AS.

   To counteract this issue, outbound filtering should consider the
   source type, i.e., relationship to the neighbor from whom a route was
   originally learned.

7.5.1.  Outbound Filtering Prefixes Using BGP Roles

   To ensure that no prefixes leak via AS relationships (routes learned
   from peers or upstreams to other peers or upstreams), [RFC9234]
   introduces BGP roles and the BGP Only to Customer (OTC) attribute.
   The OTC attribute forms a tandem with ASPA, see Section 7.2.2.
   Operators SHOULD configure appropriate roles according to Section 3
   of [RFC9234] to enable prefix filtering based on BGP relationships.
   Furthermore, for prefixes imported from upstreams, the OTC attribute
   SHOULD be set and evaluated according to [RFC9234], Section 5:





Fiebig                    Expires 29 July 2024                 [Page 20]

Internet-Draft                  BGP OPSEC                   January 2024


7.5.1.1.  Route Import

   When OTC is being used, and a route is received, it should be handled
   as follows:

   *  If OTC is set, and it is received from a customer or RS-Client, it
      is a routeleak and MUST be discarded.

   *  If OTC is set, and it is received from a peer and its value is not
      equal to the peer's AS number, it is a routeleak and MUST be
      discarded.

   *  If OTC is not set, and it is received from an upstream, a peer, or
      an RS, it MUST be set to the AS number of the remote AS.

7.5.1.2.  Route Export

   *  When advertising a route to a customer, peer, or (as a
      Routeserver) to an RS-Client, the OTC attribute MUST be set if it
      is not already present.

   *  Routes that have the OTC attribute set MUST NOT be exported to
      upstreams, peers, or routeservers.

7.5.2.  Outbound Filtering Using Large-Communities

   Despite a fall-back mechanism being implemented to support one-sided
   BGP roles, they must be supported by both neighbors in a BGP session
   to be fully effective.  To completely cover an AS, all neighbors
   should utilize BGP roles on their sessions.  Hence, if at least one
   neighbor does not yet utilize BGP roles, or if the operator cannot
   deploy BGP roles and/or use the OTC attribute on their own
   infrastructure, operators SHOULD additionally utilize BGP large-
   communities to annotate where they learned prefixes and filter
   accordingly on sessions where they re-announce these prefixes, see
   [RFC8195].  While technically possible, standard BGP communities (see
   [RFC1997]) SHOULD NOT be used for this purpose due to the prevalence
   of 32bit ASNs which can only be represented in large-communities (see
   [RFC8092]).












Fiebig                    Expires 29 July 2024                 [Page 21]

Internet-Draft                  BGP OPSEC                   January 2024


   Operators SHOULD designate a large community namespace for each
   neighbor relationship, for example, OPERATOR_ASN:100:NEIGHBOR_ASN for
   upstreams, OPERATOR_ASN:101:NEIGHBOR_ASN for peers,
   OPERATOR_ASN:102:NEIGHBOR_ASN for downstreams, etc.  These
   communities SHOULD cover all relationships documented in Section 3 of
   [RFC9234].  Additionally, if operators allow downstreams to announce
   more specifics than generally accepted in the GRT (see [CCR-22]),
   they should dedicate a large-community list to that purpose as well,
   to ensure they can effectively prevent re-announcements of these
   prefixes.

   For information on how these annotations SHOULD be included in filter
   sets, please see Section 9.

7.6.  IXP LAN Prefixes

7.6.1.  IXP LAN Prefix Filtering

   Within the IXP community, most IXPs prefer the IXP LAN prefix to not
   be advertised to the GRT ([TBD]).  While some IXPs may opt to
   advertise the IXP LAN prefix, e.g., with the route server's ASN,
   operators present on an IXP MUST respect the choice of the IXP
   regarding the advertisement state of the IXP LAN prefix.
   Furthermore, e.g., the RIPE region now reached consensus on reducing
   the initial IXP allocation size for IPv4 (see [RIPE-804]) above their
   own limits on maximum prefix lengths acceptable in the GRT (see
   [RIPE-399] and [RIPE-532]).  When a network is present on an IXP and
   has sessions with other IXP members over a common subnet (IXP LAN
   prefix), it SHOULD NOT accept exact matches or more-specific prefixes
   for the IXP LAN prefix from any of its external BGP neighbors.
   Accepting these routes may create a black hole for connectivity to
   the IXP LAN.  To reduce the risk of accidental route leaks of IXP LAN
   prefixes for which the corresponding IXP opted to not have them in
   the GRT, operators MAY choose to use "BGP next-hop-self" on all
   routes learned on that IXP to not be required to distribute the IXP
   LAN Prefix within their IGP.  Furthermore, IXPs may opt to create
   ROAs indicating AS0 as the only valid origin AS if they want to
   prevent their prefixes from being announced on the Internet.

   If the IXP LAN prefix is accepted at all, it SHOULD only be accepted
   from the ASes that the IXP authorizes to announce it -- this will
   usually be automatically achieved by filtering announcements using
   RPKI and/or IRR database.








Fiebig                    Expires 29 July 2024                 [Page 22]

Internet-Draft                  BGP OPSEC                   January 2024


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.
   Alternative, MAY use a separate routing context (e.g.  VRF) for IXP
   peerings, which only containins routes form the local AS cone.

7.6.3.  PMTUD and the Loose uRPF Problem

   Originally, in order to have PMTUD working in the presence of loose
   uRPF, it would be necessary that all the networks that may source
   traffic that could flow through the IXP have a route for the IXP LAN
   prefix.  This relates to "packet too big" ICMP messages sent by IXP
   members' routers potentially being sourced using an address of the
   IXP LAN prefix.  In the presence of loose uRPF, this ICMP packet is
   dropped if there is no route for the IXP LAN prefix or a less
   specific route covering the IXP LAN prefix.

   Hence, similar to considerations in Section 4 regarding non globally
   routable transit networks, IXP members SHOULD ensure that "packet too
   big" ICMP messages sent by their routers have a source address in IP
   address space advertised to the GRT, e.g., the router's loopback
   address.  Note that this issue causes service interruption in case of
   lost "packet too big" messages, but may also reduce debuggability in,
   e.g., traceroutes.  If they decide to implement this behavior for all
   ICMP messages, operators SHOULD ensure that this address is only used
   for ICMP messages egressing via the interface connected to the IXP
   LAN.  Otherwise, readability of traceroutes will be significantly
   reduced, as the specific interface a packet passed through is no
   longer visible in traceroutes.

8.  Filtering and Cleaning Based on Other BGP Aspects

8.1.  BGP Route Flap Dampening

   The BGP route flap dampening mechanism makes it possible to give
   penalties to routes each time they change in the BGP routing table
   [RFC2439].  Initially, this mechanism was created to protect the
   entire Internet from multiple events that impact a single network.
   Studies have shown that implementations of BGP route flap dampening
   could cause more harm than benefit; therefore, in the past, the RIPE
   community has recommended against using BGP route flap dampening
   [RIPE-378].  Later, studies were conducted to propose new route flap
   dampening thresholds in order to make the solution "usable"; see
   [RFC7196] and [RIPE-580] (in which RIPE reviewed its



Fiebig                    Expires 29 July 2024                 [Page 23]

Internet-Draft                  BGP OPSEC                   January 2024


   recommendations).  Following IETF and RIPE recommendations and using
   BGP route flap dampening with the adjusted configured thresholds is
   RECOMMENDED.

8.2.  Maximum Prefixes

   A spike in the number of received and imported prefixes can be a
   threat to the availability of a BGP speaker.  Furthermore, a
   significant increase in the number of prefixes received from a
   neighbor might indicate a misconfiguration, e.g., a failure in
   outbound filtering for the advertising neighbor, or a failure in
   inbound filtering in the ingesting neighbor.  Finally, it is
   important to limit the overall GRT growth given theoretical attacks
   utilizing deaggregation of IPv6 prefixes to globally exhaust routers'
   memory and CPU capacity (see [KIRIN-22]), the number of prefixes
   accepted to be originated by a neighboring AS across all BGP sessions
   should be limited.

8.2.1.  Maximum Prefixes on a Single Session

   It is RECOMMENDED to configure a limit on the number of routes to be
   accepted from a neighbor.  The following rules are generally
   RECOMMENDED:

   *  For peers, it is RECOMMENDED to have a limit lower than the number
      of routes in the Internet.  This will shut down the BGP session if
      the neighbor suddenly advertises the full table.  Operators can
      also configure different limits for each neighbor to which they
      have a peering relationshipt, according to the number of routes
      they are supposed to advertise, plus some headroom to permit
      growth.  However, please note that these limits may change over
      time.  Hence, it is RECOMMENDED that both neighbors clearly
      communicate the number of prefixes they expect to announce to each
      other and agree on a way to automatically update this information
      in the future.  At the time of writing, ([PeeringDB]) is a common
      source for programmatically obtaining suggested prefix limits for
      neighbors.  In the absence of communicated prefix limits, the
      number of expected prefixes can be inferred from the AS-SET, see
      Section 7.1.2.  It is RECOMMENDED to include additional headroom
      of 20% when utilizing an inferred prefix limit.

   *  From upstreams that provide full routing, it is RECOMMENDED to
      have a limit higher than the number of routes in the Internet.  A
      limit is still useful in order to protect the network (and in
      particular, the routers' memory) if too many routes are sent by
      the upstream.  The limit should be chosen according to the number
      of routes that can actually be handled by routers.




Fiebig                    Expires 29 July 2024                 [Page 24]

Internet-Draft                  BGP OPSEC                   January 2024


   It is important to regularly review the limits that are configured as
   the Internet can quickly change over time.  Some vendors propose
   mechanisms to have two thresholds: while the higher number specified
   will shut down the session, the first threshold will only trigger a
   log and can be used to passively adjust limits based on observations
   made on the network.

8.2.2.  Maximum Prefixes per Neighboring AS

   With RPKI allowing operators to sign ROAs specifying a minimum and
   maximum prefix length (contrary to ROUTE/ROUTE6 objects), researchers
   noted that this allows deaggregation attacks ([KIRIN-22]).  By
   configuring a ROA that cover an, e.g., /32, one can effectively
   authorize an AS to announce 65536 unique prefixes.  Leveraging the by
   now large availability of free and/or cheap opportunities to obtain
   IPv6 upstream, a malicious party could leverage this to cause
   significant Internet wide route churn and GRT growth.  By constantly
   advertising and withdrawing prefixes, churn exceeding the size of the
   IPv6 fulltable at the time of writing (around 200k prefixes) could be
   created by constantly announcing and withdrawing prefixes to upstream
   ASes at various PoPs.

   It is therefore RECOMMENDED that operators, in addition to per-
   session prefix limits, implement a global limit to the number of
   prefixes they accept per neighboring AS.  As with the per-session
   limits, these SHOULD be sensible and regularly updated in
   coordination with operators from neighboring ASes.

8.3.  AS_PATH Handling

   This section discusses filtering AS_PATHs, as well as recommendations
   for AS_PATH manipulation, and which practices to avoid there.

8.3.1.  AS_PATH Filtering

   This section lists the RECOMMENDED practices when processing BGP
   AS_PATHs in addition the considerations from Section 7.














Fiebig                    Expires 29 July 2024                 [Page 25]

Internet-Draft                  BGP OPSEC                   January 2024


   *  Operators SHOULD should follow Section 7.1 to only accept 2-byte
      or 4-byte AS_PATHs from customers containing ASNs belonging to (or
      authorized to transit through) the customer.  If operators cannot
      build and generate filtering expressions to implement this, they
      SHOULD consider accepting only path lengths relevant to the type
      of customer they have (as in, if these customers are a leaf or
      have customers of their own) and SHOULD try to discourage
      excessive prepending in such paths.  This loose policy SHOULD be
      combined with filters for specific 2-byte or 4-byte AS_PATHs that
      must not be accepted if advertised by the customer, such as
      upstream transit providers or peer ASNs.

   *  Operators SHOULD NOT accept prefixes with private AS numbers in
      the AS_PATH unless the prefixes are from customers.  In any case,
      operators SHOULD NOT re-export prefixes with AS_PATHs containing
      private AS numbers.  An exception could occur when an upstream is
      offering some particular service like black-hole origination based
      on a private AS number: in that case, prefixes SHOULD be accepted.
      Customers should be informed by their upstream in order to put in
      place ad hoc policy to use such services.

   *  Operators SHOULD NOT accept prefixes when the first AS number in
      the AS_PATH is not the one of the neighbor unless the BGP session
      is setup towards a BGP route server [RFC7947] (for example, on an
      IXP) with transparent AS_PATH handling.  In that case, this
      verification needs to be deactivated, as the first AS number will
      be the one of an IXP member, whereas the neighbor's AS number will
      be the one of the BGP route server.

   *  Operators SHOULD NOT advertise prefixes with a nonempty AS_PATH
      unless they are either announcing prefixes from the GRT to
      downstreams, or if the whole AS_PATH is within their cone.

   *  Operators SHOULD NOT advertise prefixes with upstream AS numbers
      in the AS_PATH to any AS except to those to which they provide
      upstream transit.

   *  Private AS numbers are conventionally used in contexts that are
      "private" and SHOULD NOT be used in advertisements to BGP
      neighbors that are not party to such private arrangements, and
      they SHOULD be stripped when received from BGP neighbors that are
      not party to such private arrangements.  Additionally, operators
      MAY decide to not accept prefixes with private AS numbers in their
      AS_PATH at all.







Fiebig                    Expires 29 July 2024                 [Page 26]

Internet-Draft                  BGP OPSEC                   January 2024


   *  Operators SHOULD NOT accept their own AS number in the AS_PATH by
      overriding BGP's default behavior.  When considering an exception,
      the impact (which may be severe on routing) should be evaluated
      carefully.

   *  Overly long AS_PATH, i.e., longer than 64 entries, may cause
      issues for some older routing hardware.  Hence, operators SHOULD
      NOT use excessive prepending when advertising prefixes.  Excessive
      prepending is defined as any prepending that leads to an AS_PATH
      exceeding 64 entries across the GRT.  Additionally, it is
      RECOMMENDED that operators filter any prefix advertised with an
      AS_PATH of more than 64 entries.

8.3.2.  AS_PATH Manipulation

   This section lists the RECOMMENDED practices when manipulating BGP
   AS_PATHs, to limit chances of accidentally producing AS_PATHs that
   would have to be filtered by neighbors according to Section 8.3.1.

   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 overridden 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 incoming or outgoing BGP Update messages.

   Furthermore, AS_PATH filtering is an option when ASN renumbering is
   done.  Such an operation is common, and mechanisms exist to allow
   smooth ASN migration [RFC7705].  The usual migration technique, local
   to a router, consists of modifying the AS_PATH so it is presented to
   a neighbor with the previous ASN, as if no renumbering was done.
   This makes it possible to change the ASN of a router without
   reconfiguring all eBGP neighbors at the same time (as that operation
   would require synchronization with all neighbors attached to that
   router).  During this renumbering operation, the rules described
   above may be adjusted.












Fiebig                    Expires 29 July 2024                 [Page 27]

Internet-Draft                  BGP OPSEC                   January 2024


   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 prepends SHOULD NOT be excessive.
   Operators are RECOMMENDED to not prepend more than five times.  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.  Especially the practice of
   providing upstream to customers using a private ASN and then using
   rewriting on either side is strongly NOT RECOMMENDED.

8.4.  Next-Hop Filtering

   When establishing sessions via a shared network, like an IXP, BGP can
   advertise prefixes with a third-party next hop, thus directing
   packets not to the neighbor announcing the prefix but somewhere else.

   This is a desirable property for BGP route-server setups [RFC7947],
   where the route server will relay routing information but has neither
   the capacity nor the desire to receive the actual data packets.  So,
   the BGP route server will announce prefixes with a next-hop setting
   pointing to the router that originally announced the prefix to the
   route server.

   In direct sessions between ASes via an IXP LAN, this is undesirable,
   as one of the neighbors could trick the other one into sending
   packets into a black hole (unreachable next hop) or to an
   unsuspecting third party who would then have to carry the traffic.
   Especially for black-holing, the root cause of the problem is hard to
   see without inspecting BGP prefixes at the receiving router of the
   IXP.

   Therefore, an inbound route policy SHOULD be applied on direct
   sessions via an IXP LAN in order to set the next hop for accepted
   prefixes to the BGP neighbor's IP address (belonging to the IXP LAN)
   that sent the prefix (which is what "next-hop-self" would enforce on
   the sending side).

   This policy SHOULD NOT be used on sessions with route-servers or on
   sessions where operators intentionally permit the other side to send
   third-party next hops.

   This policy also SHOULD be adjusted if the best practice of Remote
   Triggered Black Holing (aka RTBH as described in [RFC6666]) is
   implemented.  In that case, operators would apply a well-known BGP
   next hop for routes they want to filter (if an Internet threat is
   observed from/to this route, for example).  This well-known next hop
   will be statically routed to a null interface.  In combination with a
   unicast RPF check, this will discard traffic from and toward this



Fiebig                    Expires 29 July 2024                 [Page 28]

Internet-Draft                  BGP OPSEC                   January 2024


   prefix.  BGP speakers can exchange information about black holes
   using, for example, particular BGP communities, see [RFC6666].
   Operators could propagate black-hole information to their neighbors
   using an agreed-upon BGP community: when receiving a route with that
   community, a configured policy could change the next hop in order to
   create the black hole.

8.5.  BGP Community Scrubbing

   For BGP, BGP communities [RFC1997], extended BGP communities
   [RFC4360], and BGP large-communities [RFC8092] have been defined for
   additional inband signaling.  In the remainder of this section, we
   use the term 'BGP communities' to mean [RFC1997] and [RFC8092] BGP
   communities alike, while we explicitly refer to [RFC4360] as
   'extended BGP communities'.

   Communities are useful in iBGP and eBGP alike.  For example, BGP
   communities are often used by operators to allow neighbors to signal
   additional traffic engineering requirements, e.g., asking an upstream
   not to announce a specific NLRI to one of its neighbors.  Similarly,
   BGP communities are essential for proper filtering of downstreams'
   prefixes in the absence of ASPA/OTC.  While usually more focused on
   L2VPN and L3VPN scenarios, extended BGP communities may also find
   specific use when interacting with external neighbors, see, e.g.,
   [RFC4364], Inter-AS VPN Option B.

   However, as they may carry instructive information, external
   unauthorized neighbors should not be allowed to send NLRI with AS
   specific BGP communities.  Similarly, internally used BGP communities
   may reveal non-public information or cause disturbance in
   misconfigured networks.  The in- and outbound filtering rules for all
   forms of BGP communities in Section 8.5.1 and Section 8.5.2 are
   RECOMMENDED

   Additionally, please note the following general recommendations for
   community scrubbing:

   *  Networks administrators SHOULD NOT remove other BGP communities
      applied on received routes (BGP communities not removed after
      application of the previous statement).  In particular, they
      SHOULD keep original BGP communities when they apply a community.

   *  Operators SHOULD NOT remove the no-export community, as it is
      usually announced by their neighbor for a certain purpose.

   *  Network operators SHOULD NOT remove RTBH related BGP communities
      if sent by the customer for a prefix of routable size.




Fiebig                    Expires 29 July 2024                 [Page 29]

Internet-Draft                  BGP OPSEC                   January 2024


   *  In case where BGP communities / extended BGP communities / BGP
      large-communities specific to the own AS are not scrubbed, it is
      strongly RECOMMENDED to maintain a strict allow-list of
      permissible BGP communities, and still scrub those BGP communities
      not contained in that list, even if these BGP communities are not
      in use.

8.5.1.  Inbound BGP Community Scrubbing

   *  Operators SHOULD scrub inbound BGP communities with their ASN in
      the high-order bits, unless they have been documented and
      communicated to neighbors to be used as a signaling mechanism.  If
      a received NLRI contains an excessive amount of BGP communities,
      i.e., more than 100, operators MAY truncate the list of BGP
      communities.  When truncating BGP communities, operators SHOULD
      prioritize retaining BGP communities of their neighbors.

   *  Extended BGP communities (see [RFC4360]) received from external
      neighbors SHOULD be scrubbed.  However, there are operational
      circumstances where it MAY be reasonable to accept extended BGP
      communities from neighbors, see, e.g., [RFC4364], Inter-AS VPN
      Option B.

   *  When known, BGP communities used to signal RPKI ROV state (see
      Section 7.2.1) received from eBGP neighbors MUST be scrubbed.
      This is done to prevent BGP update storms in case a neighbor
      looses the connection to its validator, changing the validation
      state of previously valid NLRI, and thereby the applied community
      for those NLRI, triggering an update message.  For further details
      on why BGP communities MUST NOT be used to signal RPKI ROV state,
      please see [TBD].

8.5.2.  Outbound BGP Community Scrubbing

   *  Operators SHOULD scrub outbound BGP communities with their ASN in
      the high-order bits, unless their semantics have been documented
      and communicated to neighbors.  Even if the semantics of BGP
      communities has been documented, operators SHOULD be mindful of
      the number of BGP communities they add to NLRI.  When sending NLRI
      to neighbors, operators SHOULD limit the number of BGP communities
      they communicate to the outside, i.e., not overload NLRI with an
      excessive amount of BGP communities by outbound filtering all non-
      externally useful BGP communities they added for use within their
      own network.  Furthermore, when defining BGP communities,
      operators MUST be careful not to define redundant BGP communities
      or using multiple BGP communities to express properties that could
      sensibly be represented with a single community.




Fiebig                    Expires 29 July 2024                 [Page 30]

Internet-Draft                  BGP OPSEC                   January 2024


   *  Extended BGP communities (see [RFC4360]) SHOULD NOT be sent to
      eBGP neighbors.  However, there are operational circumstances
      where it MAY be reasonable to send extended BGP communities to
      neighbors, see, e.g., [RFC4364], Inter-AS VPN Option B.

   *  Operators MUST NOT use BGP communities to signal RPKI ROV state,
      see [TBD].  If an operator is still in a migration phase
      discontinuing this practice, they MUST scrub any such community
      they use for signaling RPKI-ROV state before sending NLRI to their
      external neighbors.  This is done to prevent the propagation of
      BGP update storms in case one of their BGP speakers looses the
      connection to its validator, changing the validation state of
      previously valid NLRI, and thereby the applied community for those
      NLRI, triggering an update message.  For further details on why
      BGP communities MUST NOT be used to signal RPKI ROV state, please
      see [TBD].

8.6.  Handling BGP Attributes

   While there is a list of well-known and defined transitive BGP
   attributes, operators sometimes accidentally or intentionally use
   undocumented BGP attributes.  Similarly, newly introduced attributes
   may not yet be known to a specific implementation.

   In general, unknown transitive BGP attributes SHOULD NOT be filtered.
   However, sometimes bugs may occur in implementations that require
   filtering or correction of attributes on the border to protect BGP
   speakers before a patch for the implementation is available.

   This section documents practices for scrubbing and normalizing BGP
   attribute related data in received NLRI.

8.6.1.  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 temporarily scrub
   specific BGP attributes known to cause service disruptions on their
   infrastructure.  Operators SHOULD NOT scrub unknown transitive
   attributes in general.











Fiebig                    Expires 29 July 2024                 [Page 31]

Internet-Draft                  BGP OPSEC                   January 2024


   However, while being a very useful tool, BGP attribute scrubbing
   features may cause undesired effects and sometimes even large-scale
   outages as well.  Therefore, they MUST NOT be used as a permanent
   solution, but only as a last-resort temporary workaround.
   Furthermore, removing mandatory BGP attributes and optional
   attributes commonly used in the Internet, such as AS_PATH,
   Communities, MED etc. may have a significant negative impact beyond
   an operator's own AS.  Hence, it is RECOMMENDED that such attributes
   are never removed when importing NLRI.

   When sending NLRI to external neighbors, operators SHOULD avoid
   sending not yet standardized or only internally used attributes,
   i.e., scrub attributes they added which are not in public use before
   exporting NLRI.

8.6.2.  BGP Attribute Header Correction

   BGP attributes are stored within BGP UPDATE messages as a vector of
   Type-Length-Value (TLV) fields.  The Attribute Type field contains a
   set of control bits, such as the Optional Bit (set to 1 for Optional
   Attributes and 0 for Well-Known), the Transitive Bit (specifying
   whether the attribute is Transitive, i.e., should be propagated
   outside the local AS or, Non-Transitive, i.e., should not be
   propagated outside the local AS) etc.  Initially, [RFC4271] mandated
   that a BGP speaker tears down a BGP session when receiving even a
   single UPDATE message containing a malformed combination of Attribute
   TLV headers.  However, [RFC7606] allows BGP implementers to
   optionally add features providing self-correction of malformed
   attributes in a limited number of cases.

   Operators MAY use such, self-correcting mechanisms for BGP Attribute
   TLV headers.  However, they SHOULD consider the operational impact
   such features have, SHOULD monitor for cases where such self-
   correction is necessary, and SHOULD follow up on such cases to ensure
   that root-causes are identified and addressed.

8.7.  Preventing MED Oscilation

   As documented in [RFC3345], the use of BGP Route Reflection [RFC4456]
   and BGP Confederation [RFC5065] can lead to route oscilation,
   especially in conjunction with the MULTI_EXIT_DISC (MED) attribute
   (see [RFC4271]).  If BGP route oscilation occurs, routes may be
   blackholed if dampening is implemented by neighbors, or individual
   BGP speakers may become overloaded, further aggravating the
   oscilation issue.






Fiebig                    Expires 29 July 2024                 [Page 32]

Internet-Draft                  BGP OPSEC                   January 2024


   Hence, operators SHOULD familiarize themselves with [RFC7964], which
   describes methods and approaches to counteract MED related route-
   oscilation.  Operators SHOULD carefully evaluate their network's
   requirements and implement the practices documented in [RFC7964] as
   appropriate.

8.8.  Behavior when Connecting via an IXP

   IXPs are an essential aspect of the modern Internet, and contribute
   to keeping local traffic local.  As such, IXP fabrics often handle a
   significant amount of traffic, providing challenges for traffic
   engineering.  Hence, this section documents best practices when
   connecting to an IXP that inflict on the reliability of the global
   routing ecosystem.

8.8.1.  Not Setting a Higher LOCAL_PREF for NLRI received via an IXP

   Given that traffic forwarded via an IXP can be more cost-efficient
   than sending that same traffic via an upstream, many operators set a
   higher LOCAL_PREF for NLRI received via an IXP.  This means that all
   traffic from the AS and all members of its cone routing via this AS
   will preferentially be routed via these paths (see [RFC4271]),
   effectively overriding the effect of AS_PATH prepending, see also
   [I-D.ietf-grow-as-path-prepending].

   As noted in [I-D.ietf-grow-as-path-prepending], setting a higher
   LOCAL_PREF on IXP links means that neighbors on the IXP can no longer
   use AS_PATH prepending for, e.g., traffic engineering.  More
   crucially, it prevents operators from draining traffic flowing via an
   IXP when necessary, e.g., prior to a scheduled maintenance.
   Especially when NLRI are exchanged via an RS, simply terminating the
   session is usually not possible without also impacting other
   neighbors.

   Hence, operators SHOULD NOT set a higher local preference for NLRI
   received via an IXP RS.  Instead, other non-transitive methods, e.g.,
   setting a corresponding MED on imported routes, should be preferred.

   If, when trying to drain traffic on an IXP link via AS_PATH
   prepending of NLRI sent to the RS, an operator encounters an IXP
   member ignoring these prepends, they may be able to selectively
   widthdraw routes from being announced to that member by using
   communities documented by the IXP to prevent the RS from exporting
   their NLRI to that specific IXP member.







Fiebig                    Expires 29 July 2024                 [Page 33]

Internet-Draft                  BGP OPSEC                   January 2024


8.8.2.  Honoring GSHUT on an IXP

   Graceful BGP Session Shutdown (GSHUT) as defined in [RFC8326] is a
   formalized method for draining traffic from sessions gracefully
   before, e.g., maintenance.  However, while AS_PATH prepending does
   not have to be supported by two neighbors, GSHUT requires all
   neighbors to implement it by implementing a policy that assigns a
   lower LOCAL_PREF to NLRI matching the GRACEFUL_SHUTDOWN BGP
   community.

   GSHUT is a more effective method of traffic draining than, e.g.,
   AS_PATH prepending.  Hence, in general, GSHUT SHOULD be supported on
   all eBGP sessions.  However, as an IXP member, when ignoring the
   previous recommendation and setting a higher LOCAL_PREF for sessions
   via an IXP LAN, GSHUT MUST be supported.

9.  Prefix Filtering Recommendations

9.1.  Prefix Filter Implementation Considerations

   Besides the overall generation of prefix filters and to which
   relationships these should be applied, the way how these can be
   implemented needs to be considered.

9.1.1.  Implicit Policies and Default Behavior

   Almost all BGP implementations have specific default behavior,
   including behavior when reaching the end of a policy, behavior when
   no policy is defined (even though [RFC8212] now requires a default-
   deny in the absence of policy), etc.  However, default behavior and
   matching characteristics may differ between vendors and
   implementations.  Implicitly relying on vendor-specific default
   behavior can pose issues if a network operator migrates from one
   vendor to the other, or when operating a mixed-vendor environment.
   Furthermore, implicit defaults may change, requiring intervention by
   operators.  Therefore, it is RECOMMENDED that operators create
   explicit policy statements, even for behavior covered by defaults.
   Such a practice helps simplifying automation of router
   configurations, and prevents incidents due to changing or differing
   implicit defaults, especially when migrating between vendors and in
   interoperability scenarios.










Fiebig                    Expires 29 July 2024                 [Page 34]

Internet-Draft                  BGP OPSEC                   January 2024


9.1.2.  Order of Prefixfilters

   BGP is a policy-based routing protocol with import/export policies
   controlling advertisements/acceptance of NLRI (see [RFC4272] Sec.
   9.1), and BGP sessions without policy being applied should default to
   a deny-all stance (see [RFC8212]).  The specific implementation of
   import/export policies varies between vendors in terms of complexity
   and naming, from basic prefix-based / AS_PATH-based filters, to
   complex IF-THEN-like policy structures (typical names are: "route
   maps", "route policies", "policy statements").

   Independent of the implementation, 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 permitted by a rule set will be passed to
   subsequent rule sets, while denied prefixes are discarded.

   Policies SHOULD avoid computationally expensive setups, or setups of
   rules that apply computation to NLRI that will subsequently be
   discarded.  Hence, the more prefixes a rule is likely to discard, the
   earlier it SHOULD be evaluated.

   To further illustrate this, you can find an (incomplete) example for
   a simple inbound filter for a session with a neighbor in a peer
   relationship who has 60 prefixes in its cone creating additional
   load.  We assume that, accidentally, an IPv4 fulltable of 1,000,000
   entries is being sent.  2,500 NLRI contain unregistered/private AS
   numbers, 500 NLRI relate to bogon prefixes, and 5,000 NLRI are RPKI
   invalid, with none of the routes in the neigbor's cone falling in any
   of these categories.  The number of operations per line are given in
   parentheses.

   *  1.  Add community imported from peer (1,000,000)

   *  2.  Add community imported in LOCATION (1,000,000)

   *  3.  Reject NLRI with private AS numbers in the AS path (1,000,000)

   *  4.  Reject bogon prefixes (997,500)

   *  5.  Reject RPKI invalid NLRI (997,000)

   *  6.  Accept only prefixes in the neighbor's cone (992,000)

   In this list, rules 1-5 will be executed for most NLRI seen from the
   neighbor.  In total, 5,986,500 operations are executed on the
   received NLRI, even though ultimately only 60 prefixes should be
   imported.



Fiebig                    Expires 29 July 2024                 [Page 35]

Internet-Draft                  BGP OPSEC                   January 2024


   While most hardware implementations of BGP speakers should be
   sufficiently equipped with resources to handle such individual
   spikes, practice shows that operators can not always use BGP speakers
   with an abundance of resources.  Furthermore, even more well equipped
   platforms may suffer if multiple neighbors coordinate and utilize
   this mechanic to induce load.  Ultimately, it is also desirable to
   reduce unnecessary computation independent of security
   considerations.

   Hence, it is RECOMMENDED that operators structure rulesets in a way
   that prioritized early decisions on the majority of routes.  For the
   example above, this would mean, again noting the number of operations
   per rule:

   *  1.  Reject prefixes not in the neighbor's cone (1,000,000)

   *  2.  Reject bogon prefixes (60)

   *  3.  Reject NLRI with private AS numbers in the AS path (60)

   *  4.  Reject RPKI invalid NLRI (60)

   *  5.  Add community imported from peer (60)

   *  6.  Add community imported in LOCATION (60)

   Overall, this reduces the number of operations for our hypothetical
   full-table from 5,986,500 operations to 1,000,300.  Similar effects
   can occur when not filtering on, e.g., the OTC attribute first when
   sending prefixes to customers.

9.1.3.  Ensuring Consistency when Changing Prefixfilters

   As discussed in Section 9.1.2, many BGP implementations use a
   sequential order for applying different prefix filters to ingested
   routes.  However, at the same time, several implementations do not
   perform atomic operations when applying rules.  This means that,
   especially on resource constraint BGP speakers or BGP speakers under
   load consistency of a ruleset may be lost during a rule-set update.

   For example, consider the following simplified export rule-set
   towards a peer:

   *  1.  Reject prefixes learned from upstreams

   *  2.  Reject bogon prefixes

   *  3.  Reject RPKI invalid NLRI



Fiebig                    Expires 29 July 2024                 [Page 36]

Internet-Draft                  BGP OPSEC                   January 2024


   *  4.  Accept all remaining prefixes

   If one now wants to swap the order of Rule 2 and 3, an implementation
   applying rule updates not atomically would proceed as follows:

   *  1.  Delete Rule 2, Reject bogon prefixes

   *  2.  Add Rule 2, Reject RPKI invalid NLRI

   *  3.  Delete Rule 3, Reject RPKI invalid NLRI

   *  4.  Add Rule 3, Reject bogon prefixes

   During the timeframe between the execution of Step 1 and 2, an NLRI
   for a bogon prefix would be passed by the filter.  While,
   technically, this timeframe should be negligibly small, a loaded
   control plane my create unexpected overhead allowing prefixes that
   should be filtered to pass.  Similarly, an error during the
   application of a ruleset, making the application stop after the
   execution of Step 1 may have a similar effect if rule-set changes are
   not atomic.

   Hence, it is RECOMMENDED that operators assess whether the
   application of changes to rule-sets on their BGP speakers is atomic.
   If it is not atomic, operators SHOULD take special care in drafting
   rule-set updates concerning inconsistent state that could be created
   by a delayed or incomplete update.  If no atomicity is provided by
   the BGP speaker, and the load-conditions are uncertain, operators
   SHOULD consider creating a new complete rule-set with the desired
   changes, and then changing the referenced rule-set for a given
   neighbor instead of updating an existing rule-set in-place.
   Naturally, after the new rule-set has been activated, the old rule-
   set should be deleted.

9.1.4.  Ensuring Idempotency for Prefixfilter Changes

   As prefix filters are changed regularly, idempotency is essential
   when issuing automated updates of prefix filters.  Specifically,
   prefix filters SHOULD NOT be generated on routers itself.

   Instead, filter lists SHOULD be generated on dedicated systems.
   These systems SHOULD ensure the idempotency of changes to filters
   applied to routers, i.e., they should only deploy a policy, if the
   policy changed.  This ensures no unnecessary regular load is placed
   on the control plane of BGP speakers.






Fiebig                    Expires 29 July 2024                 [Page 37]

Internet-Draft                  BGP OPSEC                   January 2024


9.1.5.  Ruleset Size Considerations

   Some BGP speaker implementations, and especially older BGP speakers,
   are restrained in terms of the number of prefixes and rules they can
   apply.  A common reaction of operators in such cases is reducing the
   number of filters applied on sessions.  Even though it is NOT
   RECOMMENDED to aggregate prefix lists for filtering, operators SHOULD
   consider aggressive aggregation of prefix filter lists to restrict
   the perfixes accepted by neighbors if the alternative is not using
   filters at all.

   Another approach that MAY be a suitable rule-set creation approach
   for downstreams and peers is offline validation.  In that case, a
   dedicated system regularly, e.g., every two hours, obtains the list
   of prefixes advertised by a given peer or downstream.  That list is
   then validated according to the applicable section below.
   Subsequently, instead of using a full representation of the neighbors
   cone, a condensed prefix list matching the aggregate of the exact
   prefixes announced is generated and deployed to the BGP speaker.
   While this increases the timeframe for newly added prefixes to be
   accepted, and may be unsuitable for, e.g., DDoS defense services, it
   can also reduce the size of prefix lists significantly.

9.1.6.  Ruleset Generation Failure

   As noted in Section 7.1.3, the creation and application of filter
   rules should be automated to reduce the margin for error and
   misconfigurations.  Nevertheless, the regeneration of filter rules
   may fail.

   Before applying a generated ruleset, an operator should check it for
   obvious errors and potentially require manual intervention to
   remediate the issue.  Examples include a ruleset for a neighbor
   suddenly significantly increasing or decreasing in size, or being
   empty.

   In case of such a failure, each administrator MAY decide which
   actions they will take.  Options include re-using the previously
   active rule set, or either accepting or rejecting all routes
   depending on routing policy.  Generally accepting all routes during
   that time frame could break BGP routing security.  However, rejecting
   them might re-route too much traffic towards upstreams, and could
   cause more harm than accepting invalid prefixes.  Similarly, reusing
   the previously active rule set may lead to prefixes being wrongfully
   accepted or rejected, despite on a smaller scale than for a general
   accept or reject decision.





Fiebig                    Expires 29 July 2024                 [Page 38]

Internet-Draft                  BGP OPSEC                   January 2024


   Hence, to still provide sufficient protection for an individual AS
   experiencing issues with rule generation, and therefore deciding to
   deviate to more permissive inbound filters, it is strongly
   RECOMMENDED that all BGP speakers in general employ inbound and
   outbound filtering as described in this document.

9.2.  Prefix Filtering Recommendations in Full Routing Networks

   For networks that have the full Internet BGP table, policies should
   be applied on each BGP neighbor for received and advertised routes.
   It is RECOMMENDED that each Autonomous System configures rules for
   advertised and received routes at all its borders, as this will
   protect the network and its neighbors even in case of
   misconfiguration.  The most commonly used filtering policy is
   proposed in this section and uses prefix filters defined in
   Section 6, Section 7, and Section 8.

9.2.1.  Filters with Internet Peers

9.2.1.1.  Inbound Filtering

   Inbound filtering on sessions with peers does not only ensure that an
   operator does not ingest maliciously or wrongfully advertised routes,
   but also serves as an additional safety net in case of unintentional
   misconfigurations.  For inbound filters with peers, the following
   rules SHOULD be applied in the given order to limit resource use on
   filter application (see Section 9.1).

   The RECOMMENDED filters ensure advertisements strictly conform to
   what is declared in routing registries (Section 7.1).  Warning is
   given as registries are not always accurate (prefixes missing, wrong
   information, etc.).  This varies across the registries and regions of
   the Internet.  Hence, before applying this policy, the reader SHOULD
   check the impact on the filter and make sure no prefixes are filtered
   that should actually be accepted.

   *  1.  All prefixes not in the neighbor's cone based on IRR data
      (Section 7.1)

   *  2.  Prefixes not allocated by IANA (IPv6 only) (Section 6.2.1)

   *  3.  RPKI invalid prefixes (Section 7.2.1)

   *  4.  Prefixes with an invalid AS path (ASPA) (Section 7.2.2)

   *  5.  Prefixes with an invalid AS path (longer than 64 entries)
      (Section 8.3.1)




Fiebig                    Expires 29 July 2024                 [Page 39]

Internet-Draft                  BGP OPSEC                   January 2024


   *  6.  Prefixes with an invalid AS path (containing private or
      reserved AS numbers) (Section 8.3.1)

   *  7.  Prefixes belonging to the local AS (Section 7.3)

   *  7.1.  Optionally: Reprioritizing prefixes belonging to the local
      AS' cone instead of filtering them (Section 7.4)

   *  8.  Prefixes that are not globally routable (Section 6.1)

   *  9.  IXP LAN prefixes of IXPs the local AS is connected to
      (Section 7.6)

   *  10.  The default route (Section 6.4)

   *  11.  Routes not matching the neighbor's next-hop (Section 8.4)

   *  12.  Routes that are too specific or too unspecific (Section 6.3)

   Note that Rule 12 MAY be formulated as an acceptance rule, i.e.,
   accepting all prefixes that are between a /8 and a /24 for IPv4 and
   between a /16 and a /48 for IPv6.

   Additionally, Rule 11 MUST NOT be set for sessions with IXP
   routeservers, while it SHOULD be set on direct sessions via IXP LANs
   (see Section 7.6).

   If BGP roles are used, the OTC attribute should be set according to
   [RFC9234].

9.2.1.2.  Outbound Filtering

   The configuration should ensure that only appropriate prefixes are
   sent, i.e., prefixes a neighbour would not need to filter based on
   Section 9.2.1.1.  These can be, for example, prefixes belonging to
   both the network in question and its downstreams.  This can be
   achieved by using BGP communities, AS paths, or both.

   Also, it may be desirable to add the following filters before any
   further policy to avoid unwanted route announcements due to bad
   configuration:

   *  1.  All prefixes not in the local AS' cone based on IRR/Internal
      data (Section 7.1)

   *  2.  All prefixes with the OTC attribute set evaluated according to
      [RFC9234] (Section 7.5.1)




Fiebig                    Expires 29 July 2024                 [Page 40]

Internet-Draft                  BGP OPSEC                   January 2024


   *  3.  Prefixes not allocated by IANA (IPv6 only) (Section 6.2.1)

   *  4.  RPKI invalid prefixes (Section 7.2.1)

   *  5.  Prefixes with an invalid AS path (ASPA) (Section 7.2.2)

   *  6.  Prefixes with an invalid AS path (longer than 64 entries)
      (Section 8.3.1)

   *  7.  Prefixes with an invalid AS path (containing private or
      reserved AS numbers) (Section 8.3.1)

   *  8.  Prefixes that are not globally routable (Section 6.1)

   *  9.  The default route (Section 6.4)

   *  11.  Routes not intended for re-export (Section 7.5)

   *  12.  Routes not listing the BGP speaker as the next-hop
      (Section 8.4)

   *  13.  Routes that are too specific or too unspecific (Section 6.3)

   If it is possible to list the prefixes to be advertised, then just
   configuring the list of allowed prefixes and denying the rest is
   technically sufficient.  Nevertheless, to ensure robustness in case
   of failure, especially for manually operated BGP speakers, it is
   RECOMMENDED that operators apply the full rule-set.

   Note that Rule 12 is technically not necessary for eBGP.  However, in
   some rare cases misconfigurations or implementation errors may occur,
   especially for sessions with a neighbor via an IXP LAN (directly or
   indirectly), where the implementation on the BGP speaker might export
   routes with a non-local next-hop.  While Rule 12 could prevent
   disturbance in such cases, the likelihood of such events is
   sufficiently low that operators MAY opt to not use Rule 12.

9.2.2.  Filters with Customers

9.2.2.1.  Inbound Filtering

   From customers, only customer prefixes SHOULD be accepted, all others
   SHOULD be discarded.  However, additionally, an operator should
   ensure that prefixes announced by customers also conform to best
   practices in terms of other BGP aspects (AS path, IRR compliance,
   RPKI etc.)  Not doing so might lead to intransparent failures when
   the customer is able to export routes to the upstream, but these are
   then not ingested by the upstream's neighbors.  Applying filtering



Fiebig                    Expires 29 July 2024                 [Page 41]

Internet-Draft                  BGP OPSEC                   January 2024


   close to the source ensures better debugability for such issues.

   *  1.  All prefixes not in the neighbor's cone based on IRR data
      (Section 7.1)

   *  2.  Prefixes not allocated by IANA (IPv6 only) (Section 6.2.1)

   *  3.  RPKI invalid prefixes (Section 7.2.1)

   *  4.  Prefixes with an invalid AS path (ASPA) (Section 7.2.2)

   *  5.  Prefixes with an invalid AS path (longer than 64 entries)
      (Section 8.3.1)

   *  6.  Prefixes with an invalid AS path (containing private or
      reserved AS numbers) (Section 8.3.1)

   *  7.  Prefixes belonging to the local AS (Section 7.3)

   *  8.  Prefixes that are not globally routable (Section 6.1)

   *  9.  IXP LAN prefixes of IXPs the local AS is connected to
      (Section 7.6)

   *  10.  The default route (Section 6.4)

   *  11.  Routes not matching the neighbor's next-hop (Section 8.4)

   *  12.  Routes that are too specific or too unspecific (Section 6.3)

   Technically, the inbound policy with end customers is pretty
   straightforward: only customer prefixes SHOULD be accepted, all
   others SHOULD be discarded.  For smaller downstreams, the list of
   accepted prefixes can be manually specified, after having verified
   that they are valid.  This validation can be done with the
   appropriate IP address management authorities.  For larger
   downstreams, an approach as documented in Section 9.1.5 MAY also be
   suitable.

   Additionally, Rule 11 MUST NOT be set in the rare case of an IXP
   routeserver providing upstream (see [CommunityIX]), while it SHOULD
   be set when providing upstream to a customer with a direct session
   via IXP LANs (see Section 8.4).








Fiebig                    Expires 29 July 2024                 [Page 42]

Internet-Draft                  BGP OPSEC                   January 2024


9.2.2.2.  Outbound Filtering

   The outbound policy with customers may vary according to the routes
   the customer wants to receive.  In the simplest possible scenario,
   the customer may want to receive only the default route; this can be
   done easily by applying a filter with the default route only.

   In case the customer wants to receive the full routing table (if it
   is multihomed or if it wants to have a view of the Internet table),
   the following filters SHOULD be applied on the BGP session:

   *  1.  Prefixes not allocated by IANA (IPv6 only) (Section 6.2.1)

   *  2.  RPKI invalid prefixes (Section 7.2.1)

   *  3.  Prefixes with an invalid AS path (ASPA) (Section 7.2.2)

   *  4.  Prefixes with an invalid AS path (longer than 64 entries)
      (Section 8.3.1)

   *  5.  Prefixes with an invalid AS path (containing private or
      reserved AS numbers) (Section 8.3.1)

   *  6.  Prefixes that are not globally routable (Section 6.1)

   *  7.  The default route (Section 6.4)

   *  8.  Routes not intended for re-export (Section 8.5)

   *  9.  Routes not listing the BGP speaker as the next-hop
      (Section 8.4)

   *  10.  Routes that are too specific or too unspecific (Section 6.3)

   In some cases, the customer may desire to receive the default route
   in addition to the full BGP table.  This can be done by the provider
   removing the filter for the default route in Rule 7.  As the default
   route may not be present in the routing table, operators SHOULD only
   originate it for neighbors that requested it.

   Note that Rule 9 is technically not necessary for eBGP.  However, in
   some rare cases misconfigurations or implementation errors may occur,
   especially on sessions with a neighbor via an IXP LAN (directly or
   indirectly), where the implementation on the BGP speaker might export
   routes with a non-local next-hop.  While Rule 9 could prevent
   disturbance in such cases, the likelihood of such events is
   sufficiently low that operators MAY opt to not use Rule 9.




Fiebig                    Expires 29 July 2024                 [Page 43]

Internet-Draft                  BGP OPSEC                   January 2024


9.2.3.  Filters with Upstream Providers

9.2.3.1.  Inbound Filtering

   If the upstream provider is supposed to announce only the default
   route, a simple filter will be applied to accept only the default
   prefix and nothing else.

   If the full routing table is desired from the upstream, the prefix
   filtering below should be applied:

   *  1.  Prefixes not allocated by IANA (IPv6 only) (Section 6.2.1)

   *  2.  RPKI invalid prefixes (Section 7.2.1)

   *  3.  Prefixes with an invalid AS path (ASPA) (Section 7.2.2)

   *  4.  Prefixes with an invalid AS path (longer than 64 entries)
      (Section 8.3.1)

   *  5.  Prefixes with an invalid AS path (containing private or
      reserved AS numbers) (Section 8.3.1)

   *  6.  Prefixes belonging to the local AS (Section 7.3)

   *  6.1.  Optionally: Reprioritizing prefixes belonging to the local
      AS' cone instead of filtering them (Section 7.4)

   *  7.  Prefixes that are not globally routable (Section 6.1)

   *  8.  IXP LAN prefixes of IXPs the local AS is connected to
      (Section 7.6)

   *  9.  The default route (Section 6.4)

   *  10.  Routes not matching the neighbor's next-hop (Section 8.4)

   *  11.  Routes that are too specific or too unspecific (Section 6.3)

   Sometimes, the default route (in addition to the full BGP table) can
   be desired from an upstream provider.  In that case, Rule 9 MAY be
   removed.

   Additionally, Rule 10 MUST NOT be set in the rare case of an IXP
   routeserver providing upstream (see [CommunityIX]), while it SHOULD
   be set when receiving upstream on a direct session via IXP LANs (see
   Section 8.4).




Fiebig                    Expires 29 July 2024                 [Page 44]

Internet-Draft                  BGP OPSEC                   January 2024


9.2.3.2.  Outbound Filtering

   In general, at least the same outbound filters as applied for
   Internet peers (Section 9.2.1.2) SHOULD be applied for upstreams.
   However, different policies could be applied if a particular upstream
   should not provide transit to all prefixes.

   When deciding to selectively announce prefixes to an upstream, it is
   important to be mindful of potential issues with uRPF in case of
   asymmetric traffic flows.  In certain strict uRPF cases traffic for a
   prefix may be blackholed if the outbound route to a destination
   traverses one upstream, while the prefix is only announced to another
   upstream.  It is RECOMMENDED that operators do not implement strict
   uRPF solely based on visible or selected routes received from a peer.
   Instead, either an approach similar to the cone determination (see
   Section 7.1), or loose uRPF should be used (see [RFC8704]).

9.3.  Prefix Filtering Recommendations for Leaf Networks

9.3.1.  Inbound Filtering

   The leaf network will deploy the filters corresponding to the routes
   it is requesting from its upstream.  If a default route is requested,
   a simple inbound filter can be applied to accept only the default
   route (Section 6.4).  If the leaf network is not capable of listing
   the prefixes because there are too many (for example, if it requires
   the full Internet routing table), then it SHOULD follow the filter
   recommendations in Section 9.2.3.1.

9.3.2.  Outbound Filtering

   A leaf network will most likely have a very straightforward policy:
   it SHOULD only announce its local routes.  For additional scrutiny,
   it is also RECOMMENDED that leaf ASes follow the recommendations in
   Section 9.2.3.2 to avoid announcing invalid routes to its upstream
   provider, and for additional resillience if the network later becomes
   multihomed.

9.4.  Prefix Filtering Recommendations for Mutual Transit

   If a mutual-transit relationship as defined in
   [I-D.ietf-sidrops-aspa-verification] exists between two neighbors,
   each neighbor SHOULD follow the recommendations in
   [I-D.ietf-sidrops-aspa-verification].  Furthermore, it is RECOMMENDED
   that both parties in a mutual-transit relationship take additional
   precautions to ensure that they do not export routes the other
   neighbor learned from their own upstreams to peers and upstreams of
   their own.  This can be accomplished, e.g., via annotations of



Fiebig                    Expires 29 July 2024                 [Page 45]

Internet-Draft                  BGP OPSEC                   January 2024


   imported routes (see Section 7.5.2) differing based on a filter
   representing the neighbor's cone (see Section 7.1).

9.5.  Prefix Filtering Recommendations for iBGP

   While iBGP sessions should generally be trusted, it is good practice
   to implement basic filters on iBGP sessions carrying external NLRI as
   well.  It is RECOMMENDED that other internal routing signalling is
   handled by a dedicated IGP or via a dedicated VRF/Routing Domain (see
   [NSRC-17]) to reduce the likelihood of internal routes leaking due to
   misconfigurations, with routes appropriately annotated to not be
   exported (see Section 7.5).  Doing so ensures that, e.g., localized
   misconfigurations, e.g., leaked (internal) routes, remain localized
   to a region or PoP, instead of spreading throughout the whole AS and
   to external neighbors, ideally limiting their impact.

   If the iBGP mesh/sessions via a route reflector (see [RFC4456]) of
   BGP speakers connected to external neighbors only carries external
   NLRI, the following filters are RECOMMENDED, the following rules
   should be applied when importing or exporting routes.

   *  1.  Prefixes not announced by the local AS not carrying an
      annotation (either via the OTC attribute evaluated according to
      [RFC9234], or a large community as outlined in Section 7.5)

   *  2.  Prefixes not allocated by IANA (IPv6 only) (Section 6.2.1)

   *  3.  RPKI invalid prefixes (Section 7.2.1)

   *  4.  Prefixes with an invalid AS path (ASPA) (Section 7.2.2)

   *  5.  Prefixes with an invalid AS path (longer than 64 entries)
      (Section 8.3.1)

   *  6.  Prefixes with an invalid AS path (containing private or
      reserved AS numbers) (Section 8.3.1)

   *  7.  Prefixes that are not globally routable (Section 6.1)

   *  9.  The default route (Section 6.4)

   *  11.  Routes that are too specific or too unspecific (Section 6.3)









Fiebig                    Expires 29 July 2024                 [Page 46]

Internet-Draft                  BGP OPSEC                   January 2024


   Depending on the local circumstances an operator MAY deviate from
   this suggestion and refrain from using individual rules.  For
   example, if the AS ingests a default route from at least one
   neighbor, Rule 9 should be omitted.  Similarly, when allowing
   downstreams to announce hyperspecifics (see Section 7.5.2), Rule 10
   SHOULD be omitted.

   While an operator MAY opt to not use any of the suggested rules, it
   is RECOMMENDED that at least Rule 1 is applied to iBGP sessions to
   ensure absent annotations do not propagate and cause route leaks.

10.  IANA Considerations

   This document does not require any IANA actions.

11.  Security Considerations

   This document is entirely about BGP operational security.  The
   document understands security not only as resilience against attacks,
   but also in the context of safety, i.e., ensuring that systems remain
   operational and behave as expected even if individual components fail
   or are mishandled.  It depicts best practices that one should adopt
   to secure BGP infrastructure: protecting BGP routers and BGP
   sessions, adopting consistent BGP prefix and AS path filters, and
   configuring other options to secure the BGP network.

   This document does not aim to describe specific BGP implementations,
   their potential vulnerabilities, or ways they handle errors.  It does
   not detail how protection could be enforced against attack techniques
   using crafted packets.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC2439]  Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
              Flap Damping", RFC 2439, DOI 10.17487/RFC2439, November
              1998, <https://www.rfc-editor.org/info/rfc2439>.




Fiebig                    Expires 29 July 2024                 [Page 47]

Internet-Draft                  BGP OPSEC                   January 2024


   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
              Reflection: An Alternative to Full Mesh Internal BGP
              (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
              <https://www.rfc-editor.org/info/rfc4456>.

   [RFC5065]  Traina, P., McPherson, D., and J. Scudder, "Autonomous
              System Confederations for BGP", RFC 5065,
              DOI 10.17487/RFC5065, August 2007,
              <https://www.rfc-editor.org/info/rfc5065>.

   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
              Pignataro, "The Generalized TTL Security Mechanism
              (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
              <https://www.rfc-editor.org/info/rfc5082>.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,
              <https://www.rfc-editor.org/info/rfc6811>.

   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
              Patel, "Revised Error Handling for BGP UPDATE Messages",
              RFC 7606, DOI 10.17487/RFC7606, August 2015,
              <https://www.rfc-editor.org/info/rfc7606>.

   [RFC7115]  Bush, R., "Origin Validation Operation Based on the
              Resource Public Key Infrastructure (RPKI)", BCP 185,
              RFC 7115, DOI 10.17487/RFC7115, January 2014,
              <https://www.rfc-editor.org/info/rfc7115>.

   [RFC7196]  Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O.
              Maennel, "Making Route Flap Damping Usable", RFC 7196,
              DOI 10.17487/RFC7196, May 2014,
              <https://www.rfc-editor.org/info/rfc7196>.

   [RFC7964]  Walton, D., Retana, A., Chen, E., and J. Scudder,
              "Solutions for BGP Persistent Route Oscillation",
              RFC 7964, DOI 10.17487/RFC7964, September 2016,
              <https://www.rfc-editor.org/info/rfc7964>.



Fiebig                    Expires 29 July 2024                 [Page 48]

Internet-Draft                  BGP OPSEC                   January 2024


   [RFC8092]  Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
              I., and N. Hilliard, "BGP Large Communities Attribute",
              RFC 8092, DOI 10.17487/RFC8092, February 2017,
              <https://www.rfc-editor.org/info/rfc8092>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8201]  McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
              "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
              DOI 10.17487/RFC8201, July 2017,
              <https://www.rfc-editor.org/info/rfc8201>.

   [RFC8212]  Mauch, J., Snijders, J., and G. Hankins, "Default External
              BGP (EBGP) Route Propagation Behavior without Policies",
              RFC 8212, DOI 10.17487/RFC8212, July 2017,
              <https://www.rfc-editor.org/info/rfc8212>.

   [RFC8326]  Francois, P., Ed., Decraene, B., Ed., Pelsser, C., Patel,
              K., and C. Filsfils, "Graceful BGP Session Shutdown",
              RFC 8326, DOI 10.17487/RFC8326, March 2018,
              <https://www.rfc-editor.org/info/rfc8326>.

   [RFC8704]  Sriram, K., Montgomery, D., and J. Haas, "Enhanced
              Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
              RFC 8704, DOI 10.17487/RFC8704, February 2020,
              <https://www.rfc-editor.org/info/rfc8704>.

   [RFC9234]  Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K.
              Sriram, "Route Leak Prevention and Detection Using Roles
              in UPDATE and OPEN Messages", RFC 9234,
              DOI 10.17487/RFC9234, May 2022,
              <https://www.rfc-editor.org/info/rfc9234>.

   [RFC9319]  Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B.
              Maddison, "The Use of maxLength in the Resource Public Key
              Infrastructure (RPKI)", BCP 185, RFC 9319,
              DOI 10.17487/RFC9319, October 2022,
              <https://www.rfc-editor.org/info/rfc9319>.










Fiebig                    Expires 29 July 2024                 [Page 49]

Internet-Draft                  BGP OPSEC                   January 2024


   [I-D.ietf-sidrops-aspa-verification]
              Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
              J., and K. Sriram, "BGP AS_PATH Verification Based on
              Autonomous System Provider Authorization (ASPA) Objects",
              Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
              verification-16, 29 August 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              aspa-verification-16>.

12.2.  Informative References

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              DOI 10.17487/RFC1191, November 1990,
              <https://www.rfc-editor.org/info/rfc1191>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996, <https://www.rfc-editor.org/info/rfc1918>.

   [RFC1997]  Chandra, R., Traina, P., and T. Li, "BGP Communities
              Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
              <https://www.rfc-editor.org/info/rfc1997>.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <https://www.rfc-editor.org/info/rfc2827>.

   [RFC3345]  McPherson, D., Gill, V., Walton, D., and A. Retana,
              "Border Gateway Protocol (BGP) Persistent Route
              Oscillation Condition", RFC 3345, DOI 10.17487/RFC3345,
              August 2002, <https://www.rfc-editor.org/info/rfc3345>.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <https://www.rfc-editor.org/info/rfc3704>.

   [RFC4012]  Blunk, L., Damas, J., Parent, F., and A. Robachevsky,
              "Routing Policy Specification Language next generation
              (RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005,
              <https://www.rfc-editor.org/info/rfc4012>.

   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
              RFC 4272, DOI 10.17487/RFC4272, January 2006,
              <https://www.rfc-editor.org/info/rfc4272>.





Fiebig                    Expires 29 July 2024                 [Page 50]

Internet-Draft                  BGP OPSEC                   January 2024


   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <https://www.rfc-editor.org/info/rfc4360>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

   [RFC6192]  Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
              Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
              March 2011, <https://www.rfc-editor.org/info/rfc6192>.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <https://www.rfc-editor.org/info/rfc6480>.

   [RFC6518]  Lebovitz, G. and M. Bhatia, "Keying and Authentication for
              Routing Protocols (KARP) Design Guidelines", RFC 6518,
              DOI 10.17487/RFC6518, February 2012,
              <https://www.rfc-editor.org/info/rfc6518>.

   [RFC6666]  Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6",
              RFC 6666, DOI 10.17487/RFC6666, August 2012,
              <https://www.rfc-editor.org/info/rfc6666>.

   [RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
              BGP, LDP, PCEP, and MSDP Issues According to the Keying
              and Authentication for Routing Protocols (KARP) Design
              Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
              <https://www.rfc-editor.org/info/rfc6952>.

   [RFC7132]  Kent, S. and A. Chi, "Threat Model for BGP Path Security",
              RFC 7132, DOI 10.17487/RFC7132, February 2014,
              <https://www.rfc-editor.org/info/rfc7132>.

   [RFC7454]  Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
              and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
              February 2015, <https://www.rfc-editor.org/info/rfc7454>.

   [RFC7947]  Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
              "Internet Exchange BGP Route Server", RFC 7947,
              DOI 10.17487/RFC7947, September 2016,
              <https://www.rfc-editor.org/info/rfc7947>.

   [RFC8195]  Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP
              Large Communities", RFC 8195, DOI 10.17487/RFC8195, June
              2017, <https://www.rfc-editor.org/info/rfc8195>.




Fiebig                    Expires 29 July 2024                 [Page 51]

Internet-Draft                  BGP OPSEC                   January 2024


   [RFC9229]  Chroboczek, J., "IPv4 Routes with an IPv6 Next Hop in the
              Babel Routing Protocol", RFC 9229, DOI 10.17487/RFC9229,
              May 2022, <https://www.rfc-editor.org/info/rfc9229>.

   [TBD]      Holder, P., "Reference still to be added", November 2023,
              <https://example.com>.

   [NSRC-17]  Smith, P., "BGP Best Current Practices", February 2017,
              <https://nsrc.org/workshops/2017/apricot2017/bgp/bgp/
              preso/05-BGP-BCP.pdf>.

   [KIRIN-22] Prehn, L., Foremski, P., and O. Gasser, "Kirin: Hitting
              the Internet with Millions of Distributed IPv6
              Announcements", October 2022,
              <https://arxiv.org/abs/2210.10676>.

   [APNICTRN-17]
              Roman, N. and A. Bhatia, "BGP Routing and IXP Workshop",
              March 2017, <https://wiki.apnictraining.net/_media/
              ixpworkshop-kolisoc-in/2.routing_ixp_workshop_upd.pdf>.

   [RIPE-804] RIPE, "IPv4 Address Allocation and Assignment Policies for
              the RIPE NCC Service Region", RIPE 804, September 2023,
              <https://www.ripe.net/publications/docs/ripe-804>.

   [CCR-22]   Sediqi, Z., Prehn, L., and O. Gasser, "Hyper-specific
              prefixes: gotta enjoy the little things in interdomain
              routing", June 2022,
              <https://dl.acm.org/doi/abs/10.1145/3544912.3544916>.

   [NLNOG-22] Li, Q., "Voorkom AS-set namespace collisions. AS-A2B vs
              AS51088:AS-A2B", NLNOG Mailinglist 2022, November 2022,
              <http://mailman.nlnog.net/pipermail/
              nlnog/2022-November/003046.html>.

   [FENG-22]  Feng, X., Li, Q., Sun, K., Xu, K., Liu, B., Zheng, X.,
              Yang, Q., Duan, H., and Z. Qian, "PMTUD is not Panacea:
              Revisiting IP Fragmentation Attacks against TCP",
              NDSS 2022, February 2022,
              <https://csis.gmu.edu/ksun/publications/
              TCP%20Fragmentation_NDSS22.pdf>.

   [RIPE-351] Daniel, D., "De-Bogonising New Address Blocks", RIPE 351,
              October 2005,
              <https://www.ripe.net/publications/docs/ripe-351>.






Fiebig                    Expires 29 July 2024                 [Page 52]

Internet-Draft                  BGP OPSEC                   January 2024


   [RIPE-378] Smith, P. and C. Panigl, "RIPE Routing Working Group
              Recommendations On Route-flap Damping", RIPE 378, May
              2006, <https://www.ripe.net/publications/docs/ripe-378>.

   [RIPE-399] Smith, P., Evans, R., and M. Hughes, "RIPE Routing Working
              Group Recommendations on Route Aggregation", RIPE 399,
              December 2006,
              <https://www.ripe.net/publications/docs/ripe-399>.

   [RIPE-532] Evans, R. and P. Smith, "RIPE Routing Working Group
              Recommendations on IPv6 Route Aggregation", RIPE 532,
              November 2011,
              <https://www.ripe.net/publications/docs/ripe-532>.

   [RIPE-580] Bush, R., Pelsser, C., Kuhne, M., Maennel, O., Mohapatra,
              P., Patel, K., and R. Evans, "RIPE Routing Working Group
              Recommendations on Route Flap Damping", RIPE 580, January
              2013, <https://www.ripe.net/publications/docs/ripe-580>.

   [IANAv4Spec]
              IANA, "IANA IPv4 Special-Purpose Address Registry",
              <https://www.iana.org/assignments/iana-ipv4-special-
              registry>.

   [IANAv6Spec]
              IANA, "IANA IPv6 Special-Purpose Address Registry",
              <https://www.iana.org/assignments/iana-ipv6-special-
              registry>.

   [IANAv4Reg]
              IANA, "IANA IPv4 Address Space Registry",
              <https://www.iana.org/assignments/ipv4-address-space>.

   [IANAv6Reg]
              IANA, "Internet Protocol Version 6 Address Space",
              <https://www.iana.org/assignments/ipv6-address-space>.

   [RADb]     Merit Network Inc., "RADb - The Internet Routing
              Registry", <https://www.radb.net>.

   [RFC7705]  George, W. and S. Amante, "Autonomous System Migration
              Mechanisms and Their Effects on the BGP AS_PATH
              Attribute", RFC 7705, DOI 10.17487/RFC7705, November 2015,
              <https://www.rfc-editor.org/info/rfc7705>.







Fiebig                    Expires 29 July 2024                 [Page 53]

Internet-Draft                  BGP OPSEC                   January 2024


   [RFC7353]  Bellovin, S., Bush, R., and D. Ward, "Security
              Requirements for BGP Path Validation", RFC 7353,
              DOI 10.17487/RFC7353, August 2014,
              <https://www.rfc-editor.org/info/rfc7353>.

   [PeeringDB]
              PeeringDB, "PeeringDB: The Interconnection Database",
              <https://www.peeringdb.com/>.

   [CommunityIX]
              IN-Berlin e.V., "Community-IX by IN-Berlin e.V., the
              connectivity-platform for non-commercial projects, ideas
              and organisations in Berlin and Frankfurt",
              <https://www.community-ix.net/>.

   [rpki-client]
              OpenBSD Project, "rpki-client 8.6 has been released",
              <https://marc.info/?l=openbsd-announce&m=169645206105360>.

   [OpenBGPd] OpenBSD Project, "OpenBGPD 8.2 released",
              <https://marc.info/?l=openbsd-announce&m=169624217322602>.

   [bgpq4]    Snijders, J., "bgpq4 Git Repository",
              <https://github.com/bgp/bgpq4>.

   [hotRPKI]  Cooper, D., Heilman, E., Brogle, K., Reyzin, L., and S.
              Goldberg, "", DOI 10.1145/2535771.2535787, November 2013,
              <https://dl.acm.org/doi/pdf/10.1145/2535771.2535787>.

   [I-D.ietf-grow-as-path-prepending]
              McBride, M., Madory, D., Tantsura, J., Raszuk, R., Li, H.,
              Heitz, J., and G. Mishra, "AS Path Prepending", Work in
              Progress, Internet-Draft, draft-ietf-grow-as-path-
              prepending-10, 16 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-
              path-prepending-10>.

Acknowledgements

   This document is based on [RFC7454] and we thank the original authors
   for their work.

   We thank the following people for reviewing this draft and suggesting
   changes:

   *  Gert Doerring

   *  Jeff Haas



Fiebig                    Expires 29 July 2024                 [Page 54]

Internet-Draft                  BGP OPSEC                   January 2024


   *  Geng Nan

   *  Martin Pels

   *  Job Snijders

   *  Berislav Todorovic

Author's Address

   Tobias Fiebig
   Max-Planck-Institut fuer Informatik
   Campus E14
   66123 Saarbruecken
   Germany
   Phone: +49 681 9325 3527
   Email: tfiebig@mpi-inf.mpg.de


































Fiebig                    Expires 29 July 2024                 [Page 55]