Internet Engineering Task Force (IETF)                         J. Durand
Internet-Draft                                       CISCO
Request for Comments: 7454                           Cisco Systems, Inc.
Intended status:
BCP: 194                                                    I. Pepelnjak
Category: Best Current Practice                      I. Pepelnjak
Expires: June 2, 2015                                      NIL
ISSN: 2070-1721                                               G. Doering
                                                                SpaceNet
                                                        December 2, 2014
                                                           February 2015

                      BGP operations Operations and security
                  draft-ietf-opsec-bgp-security-07.txt Security

Abstract

   BGP (Border

   The Border Gateway Protocol) 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 measures that can and should be deployed to prevent
   accidental or intentional routing disturbances.

   This document describes measures to protect the BGP sessions itself
   (like TTL, TCP-AO, control plane filtering)
   such as Time to Live (TTL), the TCP Authentication Option (TCP-AO),
   and control-plane filtering.  It also describes measures to better
   control the flow of routing information, using prefix filtering and
   automatization
   automation of prefix filters, max-prefix filtering, AS Autonomous System
   (AS) path filtering, route flap dampening dampening, and BGP community
   scrubbing.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

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 memo documents an Internet Best Current Practice.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   BCPs is available in Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 May 29, 2015.
   http://www.rfc-editor.org/info/rfc7454.

Copyright Notice

   Copyright (c) 2014 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Scope of the document Document . . . . . . . . . . . . . . . . . . . .   3
   3.  Definitions and Accronyms Acronyms  . . . . . . . . . . . . . . . . . .   4   3
   4.  Protection of the BGP speaker Speaker . . . . . . . . . . . . . . . .   4
   5.  Protection of BGP sessions Sessions  . . . . . . . . . . . . . . . . .   5
     5.1.  Protection of TCP sessions used Sessions Used by BGP  . . . . . . . . .   5
     5.2.  BGP TTL security Security (GTSM) . . . . . . . . . . . . . . . . .   6   5
   6.  Prefix filtering Filtering  . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Definition of prefix filters Prefix Filters  . . . . . . . . . . . . . .   6
       6.1.1.  Special purpose prefixes  Special-Purpose Prefixes  . . . . . . . . . . . . . .   6
       6.1.2.  Unallocated Prefixes not allocated  . . . . . . . . . . . . . . . .   7
       6.1.3.  Prefixes too specific . . . . . That Are Too Specific  . . . . . . . . . . .  11  10
       6.1.4.  Filtering prefixes belonging             Prefixes             Belonging
               to the local             Local AS and
               downstreams
               Downstreams . . . . . . . . . . . . . . . . . . . . .  11
       6.1.5.  IXP LAN prefixes Prefixes  . . . . . . . . . . . . . . . . . .  11
       6.1.6.  The default route Default Route . . . . . . . . . . . . . . . . . .  12
     6.2.  Prefix filtering recommendations Filtering Recommendations in full routing networks Full Routing Networks  13
       6.2.1.  Filters with Internet peers Peers . . . . . . . . . . . . .  13
       6.2.2.  Filters with customers Customers  . . . . . . . . . . . . . . .  15  14
       6.2.3.  Filters with upstream providers Upstream Providers . . . . . . . . . . .  15
     6.3.  Prefix filtering recommendations Filtering Recommendations for leaf networks Leaf Networks  . . .  16
       6.3.1.  Inbound filtering Filtering . . . . . . . . . . . . . . . . . .  16
       6.3.2.  Outbound filtering Filtering  . . . . . . . . . . . . . . . . .  16
   7.  BGP route flap dampening Route Flap Dampening  . . . . . . . . . . . . . . . . . .  17  16
   8.  Maximum prefixes Prefixes on a peering Peering . . . . . . . . . . . . . . . .  17
   9.  AS-path filtering  AS Path Filtering . . . . . . . . . . . . . . . . . . . . . .  17
   10. Next-Hop Filtering  . . . . . . . . . . . . . . . . . . . . .  19
   11. BGP community scrubbing Community Scrubbing . . . . . . . . . . . . . . . . . . .  20  19
   12. Change logs . . . . . . . . . . . . . . . . . . . . . . . . .  20
     12.1.  Diffs between draft-jdurand-bgp-security-01 and draft-
            jdurand-bgp-security-00  . . . . . . . . . . . . . . . .  20
     12.2.  Diffs between draft-jdurand-bgp-security-02 and draft-
            jdurand-bgp-security-01  . . . . . . . . . . . . . . . .  21
     12.3.  Diffs between draft-ietf-opsec-bgp-security-00 and
            draft-jdurand-bgp-security-02  . . . . . . . . . . . . .  22
     12.4.  Diffs between draft-ietf-opsec-bgp-security-01 and
            draft-ietf-opsec-bgp-security-00 . . . . . . . . . . . .  22
     12.5.  Diffs between draft-ietf-opsec-bgp-security-02 and
            draft-ietf-opsec-bgp-security-01 . . . . . . . . . . . .  23
     12.6.  Diffs between draft-ietf-opsec-bgp-security-03 and
            draft-ietf-opsec-bgp-security-02 . . . . . . . . . . . .  24
     12.7.  Diffs between draft-ietf-opsec-bgp-security-04 and
            draft-ietf-opsec-bgp-security-03 . . . . . . . . . . . .  25
     12.8.  Diffs between draft-ietf-opsec-bgp-security-05 and
            draft-ietf-opsec-bgp-security-04 . . . . . . . . . . . .  25
     12.9.  Diffs between draft-ietf-opsec-bgp-security-06 and
            draft-ietf-opsec-bgp-security-05 . . . . . . . . . . . .  25
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  26
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  26
   16.  20
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     16.1.  20
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  27
     16.2.  20
     13.2.  Informative References . . . . . . . . . . . . . . . . .  27  21
   Appendix A.  IXP LAN prefix filtering Prefix Filtering - example . Example . . . . . . . .  29
   Authors' Addresses  . .  24
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . . . . .  30  24

1.  Introduction

   BGP (Border

   The Border Gateway Protocol - (BGP), specified in RFC 4271 [2]) [2], is the
   protocol used in the Internet to exchange routing information between
   network domains.  BGP does not directly include mechanisms that
   control that whether the routes exchanged conform to the various
   guidelines defined by the Internet community.  This document intends
   to both summarize common existing guidelines and help network
   administrators apply coherent BGP policies.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

2.  Scope of the document Document

   The guidelines defined in this document are intended for generic
   Internet BGP peerings.  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 environment, and network administrators SHOULD carefully
   appraise this impact before implementation.

3.  Definitions and Accronyms Acronyms

   o  ACL: Access Control List

   o  ASN: Autonomous System Number

   o  IRR: Internet Routing Registry

   o  IXP: Internet eXchange Exchange Point

   o  LIR: Local Internet Registry

   o  pMTUd:  PMTUD: Path MTU Discovery

   o  RIR: Regional Internet Registry

   o  Tier 1 transit provider: an IP transit provider which that can reach any
      network on the Internet without purchasing transit services services.

   o  uRPF: Unicast Reverse Path Forwarding
   In addition to the list above, the following terms are used with a
   specific meaning.

   o  Downstream: any network that is downstream; it can be a provider
      or a customer network.

   o  Upstream: any network that is upstream.

4.  Protection of the BGP speaker Speaker

   The BGP speaker needs to be protected from attempts to subvert the
   BGP session.  This protection SHOULD be achieved by an Access Control
   List (ACL) which that would discard all packets directed to TCP port 179 on
   the local device and sourced from an address not known or permitted
   to become a BGP neighbor.  Experience has shown that the natural
   protection TCP should offer is not always sufficient sufficient, as it is
   sometimes run in control-plane software: in software.  In the absence of ACLs ACLs, it
   is possible to attack a BGP speaker by simply sending a high volume
   of connection requests to it.

   If supported, an ACL specific to the control-plane 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 can not 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 devices, this ACL should be configured and
   maintained manually or using scripts.

   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 overcomes surpasses
   platform capabilities.

   Filtering and rate-limiting of control-plane traffic is a wider topic
   than "just for BGP" (if BGP".  (If a network administrator brings down a
   router by overloading one of the other protocols from remote, remotely, BGP is
   harmed as
   well). well.)  For a more detailed recommendation on how to
   protect the router's control plane, see RFC 6192 [11].

5.  Protection of BGP sessions Sessions

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

5.1.  Protection of TCP sessions used Sessions Used by BGP

   Attacks on TCP sessions used by BGP (aka BGP sessions), for example example,
   sending spoofed TCP RST packets, could bring down a BGP peering.
   Following a successful ARP spoofing attack (or other similar Man-in-
   the-Middle 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.  MD5
   protection of the TCP session header, described in RFC 2385 [7], was
   the first such mechanism.  It is now deprecated has been obsoleted by the TCP
   Authentication Option (TCP-AO, (TCP-AO; RFC 5925 [4]) [4]), which offers stronger
   protection.  While MD5 is still the most used mechanism due to its
   availability in
   vendor's vendors' equipment, TCP-AO SHOULD be preferred when
   implemented.

   IPsec could also be used for session protection.  At the time this
   document is published, of
   publication, there is not enough experience on impacts of the use impact of using
   IPsec for BGP peerings peerings, 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 (ex: (for example, MD5
   password) maintenance. passwords).  Protection of TCP sessions
   used by BGP is thus NOT REQUIRED even when peerings are established
   over shared networks where spoofing can be done (like IXPs), but
   operators are RECOMMENDED to consider the trade-offs and to apply TCP
   session protection where appropriate.

   Network

   Furthermore, network administrators SHOULD block spoofed packets
   (packets with a source IP address belonging to their IP address
   space) at all edges of their network (see RFC 2827 [8] and RFC 3704
   [9]).  This protects the TCP session used by iBGP Internal BGP (IBGP) from
   attackers outside the Autonomous System.

5.2.  BGP TTL security Security (GTSM)

   BGP sessions can be made harder to spoof with the Generalized TTL
   Security Mechanisms (GTSM, (GTSM aka TTL security), defined in RFC 5082 [3].
   Instead of sending TCP packets with TTL value of 1, the BGP speakers
   send the TCP packets with TTL value of 255 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 a non-directly-connected an IP host, 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
   BGP-speaking routers.  Network administrators SHOULD implement TTL
   security on directly connected BGP peerings.

   GTSM could also be applied to multi-hop BGP peering as well.  To
   achieve this this, TTL needs to be configured with a proper value
   depending on the distance between BGP speakers (using the principle
   described above).  Nevertheless  Nevertheless, it is not as effective as 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.  Prefix filtering Filtering

   The main aspect of securing BGP resides in controlling the prefixes
   that are received/advertised received and advertised on the BGP peerings.  Prefixes
   exchanged between BGP peers are controlled with inbound and outbound
   filters that can match on IP prefixes (prefix filters, Section 6), (as described in this section),
   AS paths
   (as-path filters, (as described in Section 9) or any other attributes of a BGP
   prefix (for example, BGP communities, as described in Section 11).

6.1.  Definition of prefix filters Prefix Filters

   This section list lists the most commonly used prefix filters.  Following  The
   following sections will clarify where these filters should be
   applied.

6.1.1.  Special purpose prefixes  Special-Purpose Prefixes

6.1.1.1.  IPv4 special purpose prefixes Special-Purpose Prefixes

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

6.1.1.2.  IPv6 special purpose prefixes Special-Purpose Prefixes

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

6.1.2.  Unallocated Prefixes not allocated

   IANA allocates prefixes to RIRs which that in turn allocate prefixes to
   LIRs (Local Internet Registries).  It is wise not to accept routing
   table prefixes that are not allocated by IANA and/or RIRs.  This
   section details the options for building a list of allocated prefixes
   at every level.  It is important to understand that filtering
   unallocated prefixes not allocated requires constant updates updates, as prefixes are
   continually allocated.  Therefore  Therefore, automation of such prefix filters
   is key for the success of this approach.  Network administrators
   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.

6.1.2.1.  IANA allocated prefix filters  IANA-Allocated Prefix Filters

   IANA has allocated all the IPv4 available space.  Therefore  Therefore, there is
   no reason why network administrators would keep checking that
   prefixes they receive from BGP peers are in the IANA allocated IANA-allocated IPv4
   address space [24]. [25].  No specific filters need to be put in place by
   administrators 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
   accepting
   to accept only prefixes derived from those allocated by IANA.
   Administrators can dynamically build this list from the IANA IANA-
   allocated IPv6 space [25]. [26].  As IANA keeps allocating prefixes to
   RIRs, the aforementioned list should be checked regularly against
   changes
   changes, and if they occur, prefix filters should be computed and
   pushed on network devices.  The list could also be pulled directly by
   routers when they implement such mechanisms.  As there is delay
   between the time a 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, network administrators
   SHOULD ensure that all IPv6 prefix filters are updated within a
   maximum of one month after any change in the list of IPv6 prefix prefixes
   allocated by IANA.

   If the process in place (manual (whether manual or automatic) cannot
   guarantee that the list is updated regularly 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 allocations, and
   required a extra work for RIRs that had to "de-bogonize" the newly
   allocated prefixes.  (See [18] for information on de-bogonizing.)

6.1.2.2.  RIR allocated prefix filters  RIR-Allocated Prefix Filters

   A more precise check can be performed when one would like to make
   sure that prefixes they receive are being originated or transited by
   autonomous systems
   Autonomous Systems (ASes) entitled to do so.  It has been observed in
   the past that an AS (Autonomous System) 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.  At this stage 2 stage, two options can be
   considered (short considered:
   short- and long term options). long-term options.  They are described in the following
   subsections.

6.1.2.2.1.  Prefix filters creation Filters Created from Internet Routing Registries
            (IRR)
            (IRRs)

   An Internet Routing Registry (IRR) is a database containing Internet
   routing information, described using Routing Policy Specification
   Language objects - RFC as described in RFC 4012 [10].  Network
   administrators are given privileges to describe routing policies of
   their own networks in the
   IRR IRR, and that information is published,
   usually publicly.  A majority of Regional Internet Registries do also
   operate an IRR and can control
   that whether registered routes conform to
   the prefixes that are allocated or directly
   assigned.However, 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 RIR-allocated prefixes.

   It is possible to use the IRR information to build, for a given
   neighbor autonomous system, AS, a list of prefixes originated or transited which prefixes that one may
   accept.  This can be done relatively easily using scripts and
   existing tools capable of retrieving this information in from the
   registries.  This approach is exactly the same for both IPv4 and
   IPv6.

   The macro-algorithm for the script is described as follows.  For the peer that
   is considered, the distant network administrator has provided the autonomous system AS
   and may be able to provide an AS-SET object (aka AS-MACRO).  An
   AS-SET is an object which that contains AS numbers or other AS-SETs.  An
   operator may create an AS-SET defining all the AS numbers of its
   customers.  A tier Tier 1 transit provider might create an AS-SET
   describing the AS-SET of connected operators, which in turn describe
   the AS numbers of their customers.  Using recursion, it is possible
   to retrieve from an AS-SET the complete list of AS numbers that the
   peer is likely to announce.  For each of these AS numbers, it is also
   easy to check look in the corresponding IRR for all associated prefixes.
   With these two mechanisms mechanisms, a script can build build, for a given peer peer, the
   list of allowed prefixes and the AS number from which they should be
   originated.  One could decide not use the origin information and only
   build monolithic prefix filters from fetched data.

   As prefixes, AS numbers numbers, and AS-SETs may not all be under the same
   RIR authority, a difficulty resides choosing 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 [26], RADb [27], 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.  A  Refreshing the filters on a daily basis could even SHOULD be
   considered as some because routing changes must sometimes be done sometimes in a certain an
   emergency and registries may be updated at the very last moment.  It has to be noted
   Note that this approach significantly increases the complexity of the
   router
   configurations configurations, as it can quickly add tens of thousands of
   configuration lines for some important peers.  To manage this
   complexity, network
   adminstrators administrators could use, for example use example, IRRToolSet [29],
   [30], a set of tools making it possible to simplify the creation of
   automated filters filter configuration from policies stored in an IRR.

   Last but not least, network administrators SHOULD publish and
   maintain their resources properly in the IRR database maintained by
   their RIR, when available.

6.1.2.2.2.  SIDR - Secure Inter Domain Inter-Domain Routing

   An infrastructure called SIDR (Secure Inter-Domain Routing),
   described in RFC 6480 [12] [12], has been designed to secure Internet
   advertisements.  At the time of writing this document is written, document, many documents
   have been published and a framework with a complete set of protocols
   is proposed so that advertisements can be checked against signed
   routing objects in RIR routing registries. RIRs.  There are basically two services that SIDR
   offers:

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

   o  Path validation provided by BGPsec [27] [29] seeks at making to make sure that no ones announce
      one announces fake/wrong BGP paths that would attract trafic traffic for
      a given destination, destination; see RFC 7132 [16].  BGPsec is still an
      on-going
      ongoing work item at the time of writing this document is written and
      therefore cannot be implemented.

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

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

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

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

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

   In addition to this, network administrators SHOULD sign their routing
   objects so their routes can be validated by other networks running
   origin validation.

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

6.1.3.  Prefixes too specific That Are Too Specific

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

6.1.4.  Filtering prefixes belonging Prefixes Belonging to the local Local AS and downstreams Downstreams

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

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

   To an extent, such filters can also be configured on a network for
   the prefixes of its downstreams in order to protect them them, too.  Such
   filters must be defined with caution as they can break existing
   redundancy mechanisms.  For example in case example, when an operator has a
   multihomed customer, it should keep accepting the customer prefix
   from its peers and upstreams.  This will make it possible for the
   customer to keep accessing its operator network (and other customers)
   via the Internet in case even if the BGP peering between the customer and the
   operator is down.

6.1.5.  IXP LAN prefixes Prefixes

6.1.5.1.  Network security Security

   When a network is present on an IXP and peers with other IXP members
   over a common subnet (IXP LAN prefix), it SHOULD NOT accept more more-
   specific prefixes for the IXP LAN prefix from any of its external BGP
   peers.  Accepting these routes may create a black hole for
   connectivity to the IXP LAN.

   If the IXP LAN prefix is accepted as an "exact match", care needs to
   be taken to avoid prevent other routers in the network from sending IXP
   traffic towards the externally-learned externally learned IXP LAN prefix (recursive
   route lookup pointing into the wrong direction).  This can be
   achieved by preferring IGP routes before eBGP, over External BGP (EBGP), or by
   using "BGP next-hop-self" on all routes learned on that IXP.

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

6.1.5.2.  pMTUd  PMTUD and the loose Loose uRPF problem Problem

   In order to have pMTUd PMTUD working in the presence of loose uRPF, it is
   necessary that all the networks that may source traffic that could
   flow through the IXP (ie. (i.e., IXP members and their downstreams) have a
   route for the IXP LAN prefix.  This is necessary as "packet too big"
   ICMP messages sent by IXP members' routers may be 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 IXP LAN prefix.

   In that case, any IXP member SHOULD make sure it has a route for the
   IXP LAN prefix or a less specific prefix on all its routers and that
   it announces the IXP LAN prefix or the less specific route (up to a
   default route) to its downstreams.  The announcements done for this
   purpose SHOULD pass IRR-generated filters described in
   Section 6.1.2.2.1 as well as "prefixes that are too specific" filters
   described in Section 6.1.3.  The easiest way to implement this is that for
   the IXP itself takes to take care of the origination of its prefix and advertises
   advertise it to all IXP members through a BGP peering.  Most likely likely,
   the BGP route servers would be used for this.  The this, and the IXP would most likely send
   its entire prefix prefix, which would be equal to or less specific than the
   IXP LAN prefix.

   Appendix Appendix A gives an example of guidelines regarding IXP LAN prefix.

6.1.6.  The default route Default Route

6.1.6.1.  IPv4

   The

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

6.1.6.2.  IPv6

   The

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

6.2.  Prefix filtering recommendations Filtering Recommendations in full routing networks Full Routing Networks

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

6.2.1.  Filters with Internet peers Peers

6.2.1.1.  Inbound filtering Filtering

   There are basically 2 options, two options -- the loose one where no check will
   be done against RIR allocations and the strict one where it will be
   verified that announcements strictly conform to what is declared in
   routing registries.

6.2.1.1.1.  Inbound filtering loose option Filtering Loose Option

   In this case, the following prefixes received from a BGP peer will be
   filtered:

   o  Prefixes  prefixes that are not globally routable (Section 6.1.1)

   o  Prefixes  prefixes not allocated by IANA (IPv6 only) (Section 6.1.2.1)

   o  Routes  routes that are too specific (Section 6.1.3)

   o  Prefixes  prefixes belonging to the local AS (Section 6.1.4)

   o  IXP LAN prefixes (Section 6.1.5)

   o  The  the default route (Section 6.1.6)

6.2.1.1.2.  Inbound filtering strict option Filtering Strict Option

   In this case, filters are applied to make sure advertisements
   strictly conform to what is declared in routing registries
   (Section 6.1.2.2).  Warning is given as registries are not always
   accurate (prefixes missing, wrong information...) information, etc.).  This varies
   across the registries and regions of the Internet.  Before applying a
   strict
   policy policy, the reader SHOULD check the impact on the filter and
   make sure the solution is not worse than the problem.

   Also

   Also, in case of script failure failure, each administrator may decide if all
   routes are accepted or rejected depending on routing policy.  While
   accepting the routes during that time frame could break the BGP
   routing security, rejecting them might re-route too much traffic on
   transit peers, and could cause more harm than what a loose policy
   would have done.

   In addition to this, network administrators could apply the following
   filters beforehand in case the routing registry that's used as the
   source of information by the script is not fully trusted:

   o  Prefixes  prefixes that are not globally routable (Section 6.1.1)

   o  Routes  routes that are too specific (Section 6.1.3)

   o  Prefixes  prefixes belonging to the local AS (Section 6.1.4)

   o  IXP LAN prefixes (Section 6.1.5)

   o  The  the default route (Section 6.1.6)

6.2.1.2.  Outbound filtering

   Configuration Filtering

   The configuration should be put in place to make sure ensure that only appropriate prefixes are
   sent.  These can be, for example, prefixes belonging to both the
   network in question and its downstreams.  This can be achieved by
   using a combination of BGP communities, AS-paths AS paths, or both.  It can also  Also, it may be desirable that
   to add the following filters are
   positioned before any policy to avoid unwanted
   route announcement announcements due to bad configuration:

   o  Prefixes that are not globally routable (Section 6.1.1)

   o  Routes that are too specific (Section 6.1.3)

   o  IXP LAN prefixes (Section 6.1.5)

   o  The default route (Section 6.1.6)

   In case

   If it is possible to list the prefixes to be advertised, then just
   configuring the list of allowed prefixes and denying the rest is
   sufficient.

6.2.2.  Filters with customers Customers

6.2.2.1.  Inbound filtering Filtering

   The inbound policy with end customers is pretty straightforward: only
   customers
   customer prefixes SHOULD be accepted, all others SHOULD be discarded.
   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.

   The same rules apply in case when the customer is also a network connecting other
   customers (for example example, a tier Tier 1 transit provider connecting service
   providers).  An exception can be envisaged in case
   it is known that when the customer network applies strict
   inbound/outbound prefix filtering, and the number of there are too many prefixes
   announced by that network is too large to list them in the router configuration.
   In that case case, filters as in Section 6.2.1.1 can be applied.

6.2.2.2.  Outbound filtering 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 only want to receive only the default route, which 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 (in case (if it is
   multihomed or if it wants to have a view of the Internet table), the
   following filters can be simply applied on the BGP peering:

   o  Prefixes  prefixes that are not globally routable (Section 6.1.1)

   o  Routes  routes that are too specific (Section 6.1.3)

   o  The  the default route (Section 6.1.6)

   There can be a difference for

   In some cases, the default route that can be announced customer may desire to receive the customer default route
   in addition to the full BGP table.  This can be done by the provider
   simply by removing the filter for the default route.  As the default
   route may not be present in the routing table, network administrators
   may decide to originate it only for peerings where it has to be
   advertised.

6.2.3.  Filters with upstream providers Upstream Providers

6.2.3.1.  Inbound filtering

   In case Filtering

   If the full routing table is desired from the upstream, the prefix
   filtering to apply is the same as the one for peers Section 6.2.1.1
   with the exception of the default route.  The  Sometimes, the default
   route (in addition to the full BGP table) can be desired from an
   upstream provider in addition to the
   full BGP table.  In case provider.  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.

6.2.3.2.  Outbound filtering Filtering

   The filters to be applied would most likely not differ much from the
   ones applied for Internet peers (Section 6.2.1.2).  But  However,
   different policies could be applied in case it is desired that if a particular upstream does should
   not provide transit to all the prefixes.

6.3.  Prefix filtering recommendations Filtering Recommendations for leaf networks Leaf Networks

6.3.1.  Inbound filtering Filtering

   The leaf network will deploy the filters corresponding to the routes
   it is requesting from its upstream.  In case  If a default route is requested,
   a simple inbound filter can be applied to accept only the default
   route (Section 6.1.6).  In case  If the leaf network is not capable of listing
   the prefixes because the amount is there are too large many (for
   example example, if it requires
   the full Internet routing table) table), then it should configure the
   following filters to avoid receiving bad announcements from its
   upstream:

   o  Prefixes  prefixes not routable (Section 6.1.1)

   o  Routes too  routes that are too specific (Section 6.1.3)

   o  Prefixes  prefixes belonging to local AS (Section 6.1.4)

   o  The  the default route (Section 6.1.6) depending if on whether or not the
      route is requested or not

6.3.2.  Outbound filtering Filtering

   A leaf network will most likely have a very straightforward policy:
   it will only announce its local routes.  It can also configure the
   following prefixes
   prefix filters described in Section 6.2.1.2 to avoid announcing
   invalid routes to its upstream provider.

7.  BGP route flap dampening 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.
   Initially
   Initially, this mechanism was created to protect the entire Internet
   from multiple events impacting that impact a single network.  Studies have
   shown that implementations of BGP route flap dampening could cause
   more harm than they solve problems and therefore benefit; therefore, in the past, the RIPE community
   has in the
   past recommended not against using BGP route flap dampening [18].  Studies
   have then been [19].  Later,
   studies were conducted to propose new route flap dampening thresholds
   in order to make the solution "usable", "usable"; see RFC 7196 [6] and [22] (in
   which RIPE has reviewed its recommendations in [21]. recommendations).  This document RECOMMENDS
   following IETF and RIPE recommendations and only use using BGP route flap
   dampening with the adjusted configured thresholds.

8.  Maximum prefixes Prefixes on a peering Peering

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

   o  From peers, it is RECOMMENDED to have a limit lower than the
      number of routes in the Internet.  This will shut down the BGP
      peering if the peer suddenly advertises the full table.  Network
      admistrators
      administrators can also configure different limits for each peer,
      according to the number of routes they are supposed to advertise advertise,
      plus some headroom to permit growth.

   o  From upstreams which 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
      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.

   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 shutdown shut down the peering, the first threshold will only trigger a
   log and can be used to passively adjust limits based on observations
   made on the network.

9.  AS-path filtering  AS Path Filtering

   This section lists the RECOMMENDED practices when processing BGP AS-
   paths: AS
   paths.

   o  Network administrators SHOULD accept from customers only AS(4)-
      Paths 2-byte or
      4-byte AS paths containing ASNs belonging to (or authorized to
      transit through) the customer.  If network administrators can not 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), own) and SHOULD try to discourage
      excessive prepending in such paths.  This loose policy could be
      combined with filters for specific AS(4)-Paths 2-byte or 4-byte AS paths that
      must not be accepted if advertised by the customer, such as
      upstream transit provider providers or peer ASNs.

   o  Network administrators SHOULD NOT accept prefixes with private AS
      numbers in the AS-path except AS path unless the prefixes are from customers.  Exception:  An
      exception could occur when an upstream is offering some particular
      service like black-hole origination based on a private AS number. number:
      in that case, prefixes SHOULD be accepted.  Customers should be
      informed by their upstream in order to put in place ad-hoc ad hoc policy
      to use such services.

   o  Network administrators SHOULD NOT accept prefixes when the first
      AS number in the AS-path AS path is not the one of the peer peer's unless the
      peering is done toward a BGP route-server route server [17] (for example example, on an
      IXP) with transparent AS path handling.  In that case case, this
      verification needs to be de-activated deactivated, as the first AS number will
      be the one of an IXP member member, whereas the peer AS number will be
      the one of the BGP route-server. route server.

   o  Network administrators SHOULD NOT advertise prefixes with non-
      empty AS-path a
      nonempty AS path unless they intend to be provide transit for these
      prefixes.

   o  Network administrators SHOULD NOT advertise prefixes with upstream
      AS numbers in the AS-path AS path to their peering AS unless they intend
      to be provide transit for these prefixes.

   o  Private AS numbers are conventionally used in contexts that are
      "private" and SHOULD NOT be used in advertisements to BGP peers
      that are not party to such private arrangements, and should they SHOULD
      be stripped when received from BGP peers that are not party to
      such private arrangements.

   o  Network administrators SHOULD NOT override BGP's default behavior
      accepting behavior,
      i.e., they should not accept their own AS number in the AS-path.  In case AS path.
      When considering an
      exception to this is required, impacts should exception, the impact (which may be studied carefully
      as this can create severe impact on routing.

   AS-path
      routing) should be studied carefully.

   AS path filtering should be further analyzed when ASN renumbering is
   done.  Such an operation is common common, and mechanisms exist to allow
   smooth ASN migration [28].  The usual migration technique, local to a
   router, consists in modifying the AS-path AS path so it is presented to a
   peer 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 EBGP peers at the same time (as this that operation would require
   synchronization with all peers attached to that router).  During this
   renumbering operation, the rules described above may be adjusted.

10.  Next-Hop Filtering

   If peering on a shared network, like an IXP, BGP can advertise
   prefixes with a 3rd-party next-hop, third-party next hop, thus directing packets not to
   the peer announcing the prefix but somewhere else.

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

   In direct peerings between ISPs, this is undesirable, as one of the
   peers could trick the other one to send into sending packets into a black
   hole (unreachable next-hop) next hop) or to an unsuspecting 3rd 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 at of the IXP.

   Therefore, an inbound route policy SHOULD be applied on IXP peerings
   in order to set the next-hop next hop for accepted prefixes to the BGP peer 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 route-server peerings, peerings or on
   peerings where network administrators intentionally permit the other
   side to send 3rd-party next-hops. third-party next hops.

   This policy also SHOULD be adjusted if the best practice of Remote
   Triggered Black Holing
   best practice (aka RTBH - as described in RFC 6666 [13]) is
   implemented.  In that
   case case, network administrators would apply a
   well-known BGP next-hop next hop for routes they want to filter (if an
   Internet threat is observed from/to this route route, for example).  This well known next-hop
   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 prefix.  Peers can exchange information about black-holes using
   black holes using, for example example, particular BGP communities.  Network
   administrators could propagate black-holes black-hole information to their peers
   using agreed an agreed-upon BGP community: when receiving a route with that community
   community, a configured policy could change the
   next-hop next hop in order to
   create the black hole.

11.  BGP community scrubbing

   Optionally Community Scrubbing

   Optionally, we can consider the following rules on BGP AS-paths: AS paths:

   o  Network administrators SHOULD scrub inbound communities with their
      number in the high-order bits, and allow only those communities
      that customers/peers can use as a signaling mechanism

   o  Networks administrators SHOULD NOT remove other communities
      applied on received routes (communities not removed after
      application of the previous statement).  In particular they SHOULD
      keep original communities when particular, they apply a community.  Customers
      might need them to communicate with upstream providers.  In
      particular network administrators
      SHOULD NOT (generally) remove
      the no-export community as it is usually announced by their peer
      for a certain purpose.

12.  Change logs

   !!! NOTE TO THE RFC EDITOR: THIS SECTION WAS ADDED TO TRACK CHANGES
   AND FACILITATE WORKING GROUP COLLABORATION.  IT MUST BE DELETED
   BEFORE PUBLICATION !!!

12.1.  Diffs between draft-jdurand-bgp-security-01 and draft-jdurand-
       bgp-security-00

   Following changes have been made since previous document draft-
   jdurand-bgp-security-00:

   o  "This documents" typo corrected in the former abstract

   o  Add normative reference for RFC5082 in former section 3.2

   o  "Non routable" changed in title of former section 4.1.1

   o  Correction of typo for IPv4 loopback prefix in former section
      4.1.1.1

   o  Added shared transition space 100.64.0.0/10 in former section
      4.1.1.1

   o  Clarification that 2002::/16 6to4 prefix can cross network
      boundaries in former section 4.1.1.2

   o  Rationale of 2000::/3 explained in former section 4.1.1.2
   o  Added 3FFE::/16 prefix forgotten initially in the simplified list
      of prefixes that must not be routed by definition in former
      section 4.1.1.2

   o  Warn that filters for prefixes not allocated by IANA MUST only be
      done if regular refresh is guaranteed, with some words about the
      IPv4 experience, in former section 4.1.2.1

   o  Replace RIR database with IRR.  A definition of IRR is added in
      former section 4.1.2.2

   o  Remove any reference to anti-spoofing in former section 4.1.4

   o  Clarification for IXP LAN prefix and pMTUd problem in former
      section 4.1.5

   o  "Autonomous filters" typo (instead of Autonomous systems)
      corrected in the former section 4.2

   o  Removal of an example for manual address validation in former
      section 4.2.2.1

   o  RFC5735 obsoletes RFC3300

   o  Ingress/Egress replaced by Inbound/Outbound in all the document

12.2.  Diffs between draft-jdurand-bgp-security-02 and draft-jdurand-
       bgp-security-01

   Following changes have been made since previous document draft-
   jdurand-bgp-security-01:

   o  2 documentation prefixes were forgotten due to errata in RFC5735.
      But all prefixes were removed from that document which now point
      to other references for sake of not creating a new "registry" that
      would become outdated sooner or later

   o  Change MD5 section with global TCP security session and
      introducing TCP-AO in former section 3.1.  Added reference to
      BCP38

   o  Added new section 3 about BGP router protection with forwarding
      plane ACL

   o  Change text about prefix acceptable specificity in former section
      4.1.3 to explain this doc does not try to make recommendations
   o  Refer as much as possible to existing registries to avoid creating
      a new one in former section 4.1.1.1 and 4.1.1.2

   o  Abstract reworded

   o  6to4 exception described (only more specifics MUST be filtered)

   o  More specific -> more specifics

   o  should -> MUST for the prefixes an ISP needs to filter from its
      customers in former section 4.2.2.1

   o  Added "plus some headroom to permit growth" in former section 7

   o  Added new section on Next-Hop filtering

12.3.  Diffs between draft-ietf-opsec-bgp-security-00 and draft-jdurand-
       bgp-security-02

   Following changes have been made since previous document draft-
   jdurand-bgp-security-02:

   o  Added a subsection for RTBH in next-hop section with reference to
      RFC6666

   o  Changed last sentence of introduction

   o  Many edits throughout the document

   o  Added definition of tier 1 transit provider

   o  Removed definition of a BGP peering

   o  Removed description of routing policies for IPv6 prefixes in IANA
      special registry as this now contains a routing scope field

   o  Added reference to RFC6598 and changed the IPv4 prefixes to be
      filtered by definition section

   o  IXP added in accronym/definition section and only term used
      throughout the doc now

12.4.  Diffs between draft-ietf-opsec-bgp-security-01 and draft-ietf-
       opsec-bgp-security-00

   Following changes have been made since previous document draft-ietf-
   opsec-bgp-security-00:

   o  Obsolete RFC2385 moved from normative to informative reference

   o  Clarification of preference of TCP-AO over MD5 in former section
      4.1

   o  Mentioning KARP efforts in TCP session protection section in
      former section 4 and adding 3 RFC as informative references: 6518,
      6862 and 6952

   o  Removing reference to SIDR working-group

   o  Better dissociating origin validation and path validation to
      clarify what's potentially available for deployment

   o  Adding that SIDR mechanisms should be implemented in addition to
      the other ones mentioned throughout this document

   o  Added a paragraph in former section 8 about ASN renumbering

   o  Change of security considerations section

   o  Added the newly created IANA IPv4 Special Purpose Address Registry
      instead of references to RFCs listing these addresses

12.5.  Diffs between draft-ietf-opsec-bgp-security-02 and draft-ietf-
       opsec-bgp-security-01

   Following changes have been made since previous document draft-ietf-
   opsec-bgp-security-01:

   o  Added a reference to draft-ietf-sidr-origin-ops

   o  Added a reference to RFC6811 and RFC6907

   o  Changes "Most of RIR's" to "A majority of RIR's" on IRR
      availability

   o  Various edits

   o  Added NIST BGP security recommendations document

   o  Added that it's possible to get info from ISPs from RADB

   o  Correction of the url for IPv4 special use prefixes repository

   o  Clarification of the fact only prefixes with Global Scope set to
      False MUST be discarded
   o  IANA list could be pulled directly by routers (not just pushed on
      routers).

   o  Warning added when prefixes are checked against IRR

   o  Recommend network operators to sign their routing objects

   o  Recommend network operators to publish their routing objects in
      IRR of their IRR when available

   o  Dissociate rules for local AS and downstreams in former section
      5.1.4

12.6.  Diffs between draft-ietf-opsec-bgp-security-03 and draft-ietf-
       opsec-bgp-security-02

   Following changes have been made since previous document draft-ietf-
   opsec-bgp-security-02:

   o  Added a note on TCP-AO to be preferred over MD5

   o  Mention that loose AS filtering with customers can be combined
      with precise filters for important ASNs (example those of
      transits) that are must not be received on theses peers in former
      section 8.

   o  MD5 removed from abstract

   o  recommended -> RECOMMENDED where appropriate

   o  Reference to BCP38 and BCP84 in former section 4.1

   o  Added a note to RFC Editor to remove change section before
      publication

   o  Removal of "future work" section

   o  Added rate-limiting in addition to filtering in former section 3

   o  Reference to IRRToolSet in former section 5.1.2.3

   o  Removed "foreword" section

12.7.  Diffs between draft-ietf-opsec-bgp-security-04 and draft-ietf-
       opsec-bgp-security-03

   Following changes have been made since previous document draft-ietf-
   opsec-bgp-security-03:

   o  RFC6890 updates RFC5735

   o  RFC6890 updates RFC5156

   o  Removed reference RFC2234 and RFC 4234

   o  Moved route-server draft into informative reference section

12.8.  Diffs between draft-ietf-opsec-bgp-security-05 and draft-ietf-
       opsec-bgp-security-04

   Following changes have been made since previous document draft-ietf-
   opsec-bgp-security-04:

   o  RFC7196 updates draft-ietf-idr-rfd-usable

   o  RFC7115 updates draft-ietf-sidr-origin-ops

   o  draft-ietf-idr-ix-bgp-route-server-05 updates ietf-idr-ix-bgp-
      route-server-00

12.9.  Diffs between draft-ietf-opsec-bgp-security-06 and draft-ietf-
       opsec-bgp-security-05

   Following changes have been made since previous document draft-ietf-
   opsec-bgp-security-05:

   o  Wording improvements

   o  Introduction improved

   o  References are expanded (not just reference numbers are displayed
      but also the title of the document

   o  First occurence of accronyms expanded

   o  GTSM for multi-hop peerings

   o  Remove eBGP as protected by BCP38

   o  Add a caveat for IPsec for session protection
   o  Changed MUST for SHOULD everywhere

   o  Small changes in communities section

   o  Removed simplified IPv6 prefix list

   o  Removed note in section 9 about 32 bits ASN

   o  IXP LAN prefix example in appendix

   o  Make sure all references are in the text.  Most of them were
      removed as they were initially here for previous version when IANA
      registries with routing scopes did not exist

13.  Acknowledgements

   The authors would like to thank the following people for their
   comments and support: Marc Blanchet, Ron Bonica, Randy Bush, David
   Freedman, Wesley George, Daniel Ginsburg, David Groves, Mike Hugues,
   Joel Jaeggli, Tim Kleefass, Warren Kumari, Jacques Latour, Lionel
   Morand, Jerome Nicolle, Hagen Paul Pfeifer, Thomas Pinaud, Carlos
   Pignataro, Jean Rebiffe, Donald Smith, Kotikalapudi Sriram, Matjaz
   Straus, Tony Tauber, Gunter Van de Velde, Sebastian Wiesinger,
   Matsuzaki Yoshinobu.

   Authors would like to thank once again Gunter Van de Velde for
   presenting the draft at several IETF meetings in various working
   groups, indeed helping dissemination of this document and gathering
   of precious feedback.

14.  IANA Considerations

   This memo includes no request keep original communities when they apply a community.
      Customers might need them to IANA.

15. communicate with upstream providers.
      In particular, network administrators SHOULD NOT (generally)
      remove the no-export community, as it is usually announced by
      their peer for a certain purpose.

12.  Security Considerations

   This document is entirely about BGP operational security.  It depicts
   best practices that one should adopt to secure its BGP infrastructure:
   protecting BGP router and BGP sessions, adopting consistent BGP
   prefix and AS-path filters AS path filters, and configure configuring other options to secure
   the BGP network.

   On the other hand this

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

16.

13.  References

16.1.

13.1.  Normative References

   [1]        Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <http://xml.resource.org/public/rfc/html/rfc2119.html>.
              <http://www.rfc-editor.org/info/rfc2119>.

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

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

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

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

   [6]        Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O.
              Maennel, "Making Route Flap Damping Usable", RFC 7196, May
              2014.

16.2.
              2014, <http://www.rfc-editor.org/info/rfc7196>.

13.2.  Informative References

   [7]        Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, August 1998. 1998,
              <http://www.rfc-editor.org/info/rfc2385>.

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

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

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

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

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

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

   [14]       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, May 2013. 2013,
              <http://www.rfc-editor.org/info/rfc6952>.

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

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

   [17]       Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
              "Internet Exchange Route Server",
              <http://tools.ietf.org/id/
              draft-ietf-idr-ix-bgp-route-server-05.txt>. Work in Progress draft-
              ietf-idr-ix-bgp-route-server-06, December 2014.

   [18]       Karrenberg, D., "RIPE-351 - De-Bogonising New Address
              Blocks", October 2005.

   [19]       Smith, P. and C. Panigl, "RIPE-378 - RIPE Routing Working
              Group Recommendations On Route-flap Damping", May 2006.

   [19]

   [20]       Smith, P., Evans, R., and M. Hughes, "RIPE-399 - RIPE
              Routing Working Group Recommendations on Route
              Aggregation", December 2006.

   [20]

   [21]       Smith, P. and R. Evans, "RIPE-532 - RIPE Routing Working
              Group Recommendations on IPv6 Route Aggregation", November
              2011.

   [21]

   [22]       Smith, P., Bush, R., Kuhne, M., Pelsser, C., Maennel, O.,
              Patel, K., Mohapatra, P., and R. Evans, "RIPE-580 - RIPE
              Routing Working Group Recommendations On Route-flap
              Damping", January 2013.

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

   [23]       IANA, "IANA IPv6 Special Purpose IPv4 Special-Purpose Address Registry",
              <http://www.iana.org/assignments/iana-ipv6-special-
              registry/iana-ipv6-special-registry.xml>.
              <http://www.iana.org/assignments/
              iana-ipv4-special-registry>.

   [24]       IANA, "IANA IPv4 IPv6 Special-Purpose Address Space Registry",
              <http://www.iana.org/assignments/ipv4-address-space/
              ipv4-address-space.xml>.
              <http://www.iana.org/assignments/
              iana-ipv6-special-registry>.

   [25]       IANA, "IANA IPv6 IPv4 Address Space Registry",
              <http://www.iana.org/assignments/ipv6-unicast-address-
              assignments/ipv6-unicast-address-assignments.xml>.
              <http://www.iana.org/assignments/ipv4-address-space>.

   [26]       "Routing Assets Database", <http://www.radb.net>.       IANA, "Internet Protocol Version 6 Address Space",
              <http://www.iana.org/assignments/ipv6-address-space>.

   [27]       "Security Requirements for BGP Path Validation",
              <http://datatracker.ietf.org/doc/
              draft-ietf-sidr-bgpsec-reqs/>.       Merit Network Inc., "Merit RADb", <http://www.radb.net>.

   [28]       George, W. and S. Amante, "Autonomous System (AS)
              Migration Features and Their Effects on the BGP AS_PATH
              Attribute",
              <http://datatracker.ietf.org/doc/
              draft-ga-idr-as-migration/>. Work in Progress, draft-ga-idr-as-migration-
              03, January 2014.

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

   [30]       "IRRToolSet project page", <http://irrtoolset.isc.org>.

   [30]

   [31]       Cooper, D., Heilman, E., Brogle, K., Reyzin, L., and S.
              Goldberg, "On the Risk of Misbehaving RPKI Authorities",
              <http://www.cs.bu.edu/~goldbe/papers/hotRPKI.pdf>.

Appendix A.  IXP LAN prefix filtering Prefix Filtering - example Example

   An IXP in the RIPE region is allocated an IPv4 /22 prefix by RIPE NCC
   (X.Y.0.0/22 in this example) and uses a /23 of this /22 for the IXP
   LAN (let say X.Y.0.0/23).  This IXP LAN prefix is the one used by IXP
   members to configure eBGP EBGP peerings.  The IXP could also be allocated
   an AS number (AS64496 in our example).

   Any IXP member SHOULD make sure it filters prefixes more specific
   than X.Y.0.0/23 from all its eBGP EBGP peers.  If it received X.Y.0.0/24
   or X.Y.1.0/24 this could seriously impact its routing.

   The IXP SHOULD originate X.Y.0.0/22 and advertise it to its members
   through an eBGP EBGP peering (most likely from its BGP route servers,
   configured with AS64496).

   The IXP members SHOULD accept the IXP prefix only if it passes the
   IRR generated filters (see Section 6.1.2.2.1)

   IXP members SHOULD then advertise X.Y.0.0/22 prefix to their
   downstreams.  This announce would pass IRR based filters as it is
   originated by the IXP.

Appendix B.  Acknowledgements

   The authors would like to thank the following people for their
   comments and support: Marc Blanchet, Ron Bonica, Randy Bush, David
   Freedman, Wesley George, Daniel Ginsburg, David Groves, Mike Hugues,
   Joel Jaeggli, Tim Kleefass, Warren Kumari, Jacques Latour, Lionel
   Morand, Jerome Nicolle, Hagen Paul Pfeifer, Thomas Pinaud, Carlos
   Pignataro, Jean Rebiffe, Donald Smith, Kotikalapudi Sriram, Matjaz
   Straus, Tony Tauber, Gunter Van de Velde, Sebastian Wiesinger, and
   Matsuzaki Yoshinobu.

   The authors would like to thank once again Gunter Van de Velde for
   presenting the document at several IETF meetings in various working
   groups, indeed helping dissemination of this document and gathering
   of precious feedback.

Authors' Addresses

   Jerome Durand
   CISCO
   Cisco Systems, Inc.
   11 rue Camille Desmoulins
   Issy-les-Moulineaux  92782 CEDEX
   FR

   Email:
   France

   EMail: jerduran@cisco.com
   Ivan Pepelnjak
   NIL Data Communications
   Tivolska 48
   Ljubljana  1000
   Slovenia

   Email:

   EMail: ip@ipspace.net

   Gert Doering
   SpaceNet AG
   Joseph-Dollinger-Bogen 14
   Muenchen  D-80807
   Germany

   Email:

   EMail: gert@space.net