[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-jdurand-bgp-security) 00 01 02 03 04 05 06 07

Internet Engineering Task Force                                J. Durand
Internet-Draft                                       CISCO Systems, Inc.
Intended status: BCP                                        I. Pepelnjak
Expires: July 22, 2013                                               NIL
                                                              G. Doering
                                                        January 18, 2013

                      BGP operations and security


   BGP (Border Gateway Protocol) is the protocol almost exclusively used
   in the Internet to exchange routing information between network
   domains.  Due to this central nature, it's 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, MD5, control plane filtering) and to better control the
   flow of routing information, using prefix filtering and
   automatization of prefix filters, max-prefix filtering, AS path
   filtering, route flap dampening and BGP community scrubbing.


   A placeholder to list general observations about this document.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 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 http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any

Durand, et al.            Expires July 22, 2013                 [Page 1]

Internet-Draft                  BGP OPSEC                   January 2013

   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 July 22, 2013.

Copyright Notice

   Copyright (c) 2013 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.

Durand, et al.            Expires July 22, 2013                 [Page 2]

Internet-Draft                  BGP OPSEC                   January 2013

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definitions and Accronyms  . . . . . . . . . . . . . . . . . .  4
   3.  Protection of the BGP router . . . . . . . . . . . . . . . . .  4
   4.  Protection of BGP sessions . . . . . . . . . . . . . . . . . .  4
     4.1.  Protection of TCP sessions used by BGP . . . . . . . . . .  4
     4.2.  BGP TTL security . . . . . . . . . . . . . . . . . . . . .  5
   5.  Prefix filtering . . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Definition of prefix filters . . . . . . . . . . . . . . .  5
       5.1.1.  Prefixes that MUST not be routed by definition . . . .  6
       5.1.2.  Prefixes not allocated . . . . . . . . . . . . . . . .  6
       5.1.3.  Prefixes too specific  . . . . . . . . . . . . . . . .  9
       5.1.4.  Filtering prefixes belonging to the local AS . . . . .  9
       5.1.5.  IXP LAN prefixes . . . . . . . . . . . . . . . . . . . 10
       5.1.6.  The default route  . . . . . . . . . . . . . . . . . . 11
     5.2.  Prefix filtering recommendations in full routing
           networks . . . . . . . . . . . . . . . . . . . . . . . . . 11
       5.2.1.  Filters with internet peers  . . . . . . . . . . . . . 12
       5.2.2.  Filters with customers . . . . . . . . . . . . . . . . 13
       5.2.3.  Filters with upstream providers  . . . . . . . . . . . 14
     5.3.  Prefix filtering recommendations for leaf networks . . . . 14
       5.3.1.  Inbound filtering  . . . . . . . . . . . . . . . . . . 14
       5.3.2.  Outbound filtering . . . . . . . . . . . . . . . . . . 15
   6.  BGP route flap dampening . . . . . . . . . . . . . . . . . . . 15
   7.  Maximum prefixes on a peering  . . . . . . . . . . . . . . . . 15
   8.  AS-path filtering  . . . . . . . . . . . . . . . . . . . . . . 16
   9.  Next-Hop Filtering . . . . . . . . . . . . . . . . . . . . . . 17
   10. BGP community scrubbing  . . . . . . . . . . . . . . . . . . . 18
   11. Change logs  . . . . . . . . . . . . . . . . . . . . . . . . . 18
     11.1. Diffs between draft-jdurand-bgp-security-01 and
           draft-jdurand-bgp-security-00  . . . . . . . . . . . . . . 18
     11.2. Diffs between draft-jdurand-bgp-security-02 and
           draft-jdurand-bgp-security-01  . . . . . . . . . . . . . . 19
     11.3. Diffs between draft-ietf-opsec-bgp-security-00 and
           draft-jdurand-bgp-security-02  . . . . . . . . . . . . . . 20
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     15.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23

Durand, et al.            Expires July 22, 2013                 [Page 3]

Internet-Draft                  BGP OPSEC                   January 2013

1.  Introduction

   BGP [7] is the protocol used in the internet to exchange routing
   information between network domains.  This protocol does not directly
   include mechanisms that control that routes exchanged conform to the
   various rules defined by the Internet community.  This document
   intends to both summarize common existing rules and help network
   administrators apply coherent BGP policies.

2.  Definitions and Accronyms

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

   o  IXP: Internet eXchange Point

3.  Protection of the BGP router

   The BGP router needs to be protected from stray packets.  This
   protection should be achieved by an access-list (ACL) which 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.  If supported, an ACL specific to the control-plane of the
   router should be used (receive-ACL, control-plane policing, etc.), to
   avoid filtering transit traffic if not needed.  If the hardware can
   not do that, interface ACLs can be used to block packets to the local

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

   The filtering of packets destined to the local router is a wider
   topic than "just for BGP" (if you bring down a router by overloading
   one of the other protocols from remote, BGP is harmed as well).  For
   a more detailed recommendation, see RFC6192 [21].

4.  Protection of BGP sessions

4.1.  Protection of TCP sessions used by BGP

   Attacks on TCP sessions used by BGP (ex: sending spoofed TCP
   RST packets) could bring down the TCP 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

Durand, et al.            Expires July 22, 2013                 [Page 4]

Internet-Draft                  BGP OPSEC                   January 2013

   the TCP stream (routing attacks).

   TCP sessions used by BGP can be secured with a variety of mechanisms.
   MD5 protection of TCP session header [2] is the most common one, but
   one could also use IPsec or TCP Authentication Option (TCP-AO, [11]).

   The drawback of TCP session protection is additional configuration
   and management overhead for authentication information (ex: MD5
   password) maintenance.  Protection of TCP sessions used by BGP is
   thus recommended when peerings are established over shared networks
   where spoofing can be done (like IXPs).

   You SHOULD block spoofed packets (packets with a source IP address
   belonging to your IP address space) at all edges of your network,
   making the protection of TCP sessions used by BGP unnecessary on iBGP
   or eBGP sessions run over point-to-point links.

4.2.  BGP TTL security

   BGP sessions can be made harder to spoof with the TTL security [10].
   Instead of sending TCP packets with TTL value = 1, the routers send
   the TCP packets with TTL value = 255 and the receiver checks that the
   TTL value equals 255.  Since it's impossible to send an IP packet
   with TTL = 255 to a non-directly-connected IP host, BGP TTL security
   effectively prevents all spoofing attacks coming from third parties
   not directly connected to the same subnet as the BGP-speaking
   routers.  Network administrators SHOULD implement TTL security on
   directly connected BGP peerings.

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

5.  Prefix filtering

   The main aspect of securing BGP resides in controlling the prefixes
   that are received/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 5), AS paths
   (as-path filters, Section 8) or any other attributes of a BGP prefix
   (for example, BGP communities, Section 10).

5.1.  Definition of prefix filters

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

Durand, et al.            Expires July 22, 2013                 [Page 5]

Internet-Draft                  BGP OPSEC                   January 2013

5.1.1.  Prefixes that MUST not be routed by definition  IPv4

   At the time of the writing of this document, there is no dynamic IPv4
   registry listing special prefixes and their status on the internet.
   On the other hand static document RFC5735 [19] clarifies "special"
   IPv4 prefixes and their status in the Internet.  One should note that
   RFC5735 [19] has been updated by RFC6598 [22] which adds a new prefix
   to the ones that MUST NOT be routed across network boundaries.  IPv6

   IPv6 registry [31] maintains the list of IPv6 special purpose
   prefixes and their routing scope.  Reader will refer to this registry
   in order to configure prefix filters.

   At the time of the writing of this document, the list of IPv6
   prefixes that MUST not cross network boundaries can be simplified as
   IANA allocates at the time being prefixes to RIR's only in 2000::/3
   prefix [30].  All other prefixes (ULA's, link-local, multicast... are
   outside of that prefix) and therefore the simplified list becomes:

   o  2001:DB8::/32 and more specifics - documentation [15]

   o  Prefixes more specifics than 2002::/16 - 6to4 [4]

   o  3FFE::/16 and more specifics - was initially used for the 6Bone
      (worldwide IPv6 test network) and returned to IANA

   o  All prefixes that are outside 2000::/3 prefix

5.1.2.  Prefixes not allocated

   IANA allocates prefixes to RIRs which in turn allocate prefixes to
   LIRs.  It is wise not to accept in the routing table prefixes that
   are not allocated.  This could mean allocation made by IANA and/or
   allocations done by RIRs.  This section details the options for
   building a list of allocated prefixes at every level.  It is
   important to understand that filtering prefixes not allocated
   requires constant updates as prefixes are continually allocated.
   Therefore automation of such prefix filters is key for the success of
   this approach.  One should probably not consider solutions described
   in this section if it is not capable of maintaining updated prefix
   filters: the damage would probably be worse than the intended
   security policy.

Durand, et al.            Expires July 22, 2013                 [Page 6]

Internet-Draft                  BGP OPSEC                   January 2013  IANA allocated prefix filters

   IANA has allocated all the IPv4 available space.  Therefore there is
   no reason why one would keep checking prefixes are in the IANA
   allocated address space [29].  No specific filters need to be put in
   place by administrators who want to make sure that IPv4 prefixes they
   receive have been allocated by IANA.

   For IPv6, given the size of the address space, it can be seen as wise
   accepting only prefixes derived from those allocated by IANA.
   Administrators can dynamically build this list from the IANA
   allocated IPv6 space [32].  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.  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 doing this step quickly and
   frequently.  Based on past experience, authors recommend that the
   process in place makes sure there is no more than one month between
   the time the IANA IPv6 allocated prefix list changes and the moment
   all IPv6 prefix filters are updated.

   If process in place (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 latest allocations and required a extra work for
   RIRs that had to "de-bogonize" the newly allocated prefixes.  RIR allocated prefix filters

   A more precise check can be performed as one would like to make sure
   that prefixes they receive are being originated or transited by
   autonomous systems entitled to do so.  It has been observed in the
   past that one could easily advertise someone else's prefix (or more
   specific prefixes) and create black holes or security threats.  To
   overcome that risk, administrators would need to make sure BGP
   advertisements correspond to information located in the existing
   registries.  At this stage 2 options can be considered (short and
   long term options).  They are described in the following subsections.  Prefix filters creation from Internet Routing Registries (IRR)

   An Internet Routing Registry (IRR) is a database containing internet
   routing information, described using Routing Policy Specification
   Language objects [16].  Network administrators are given privileges
   to describe routing policies of their own networks in the IRR and

Durand, et al.            Expires July 22, 2013                 [Page 7]

Internet-Draft                  BGP OPSEC                   January 2013

   information is published, usually publicly.  Most of Regional
   Internet Registries do also operate an IRR and can control that
   registered routes conform to prefixes allocated or directly assigned.

   It is possible to use the IRR information to build, for a given
   neighbor autonomous system, a list of prefixes originated or
   transited which one may accept.  This can be done relatively easily
   using scripts and existing tools capable of retrieving this
   information in 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 and may be able to provide an AS-SET
   object (aka AS-MACRO).  An AS-SET is an object which contains AS
   numbers or other AS-SETs.  An operator may create an AS-SET defining
   all the AS numbers of its customers.  A 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 in the corresponding IRR for all
   associated prefixes.  With these two mechanisms a script can build
   for a given 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

   As prefixes, AS numbers and AS-SETs may not all be under the same RIR
   authority, a difficulty resides choosing 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 [33], the Routing Assets
   Database) and only use information from sources representing the five
   current RIRs.

   As objects in IRRs may quickly vary over time, it is important that
   prefix filters computed using this mechanism are refreshed regularly.
   A daily basis could even been considered as some routing changes must
   be done sometimes in a certain emergency and registries may be
   updated at the very last moment.  It has to be noted that this
   approach significantly increases the complexity of the router
   configurations as it can quickly add tens of thousands configuration

Durand, et al.            Expires July 22, 2013                 [Page 8]

Internet-Draft                  BGP OPSEC                   January 2013

   lines for some important peers.  SIDR - Secure Inter Domain Routing

   IETF has created a working group called SIDR (Secure Inter-Domain
   Routing) in order to create an architecture to secure internet
   advertisements.  At the time this document is written, many documents
   have been published and a framework is proposed so that
   advertisements can be checked against signed routing objects in RIR
   routing registries.  Implementing mechanisms proposed by this working
   group is expected to solve many of these BGP routing security
   problems in the long term.  But as it may take time for deployments
   to be made and objects to become signed, such a solution will need to
   be combined with the other mechanisms detailed in this document.  The
   rest of this section assumes the reader is familiar with SIDR

   Each received route on a router SHOULD be checked against the RPKI
   data set: if a corresponding ROA is found and is valid then the
   prefix SHOULD be accepted.  It the ROA is found and is INVALID then
   the prefix SHOULD be discarded.  If an ROA is not found then the
   prefix SHOULD be accepted but corresponding route SHOULD be given a
   low preference.

5.1.3.  Prefixes too specific

   Most ISPs will not accept advertisements beyond a certain level of
   specificity (and in return do not announce prefixes they consider as
   too specific).  That acceptable specificity is decided for each
   peering between the 2 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 that there
   are existing practices on the internet and recommends the reader to
   refer to what those are.  As an example the RIPE community has
   documented that IPv4 prefixes longer than /24 and IPv6 prefixes
   longer than /48 are generally not announced/accepted in the internet
   [25] [26].

5.1.4.  Filtering prefixes belonging to the local AS

   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
   in case someone else is announcing the prefix over the Internet.
   This also protects the infrastructure which may directly suffer in
   case backbone's prefix is suddenly preferred over the Internet.  To
   an extent, such filters can also be configured on a network for the
   prefixes of its downstreams in order to protect them too.  Such

Durand, et al.            Expires July 22, 2013                 [Page 9]

Internet-Draft                  BGP OPSEC                   January 2013

   filters must be defined with caution as they can break existing
   redundancy mechanisms.  For example in case 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 the BGP peering between the customer and the
   operator is down.

5.1.5.  IXP LAN prefixes  Network security

   When a network is present on an IXP and peers with other IXP members
   over a common subnet (IXP LAN prefix), it MUST NOT accept 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 other routers in the network sending IXP traffic
   towards the externally-learned IXP LAN prefix (recursive route lookup
   pointing into the wrong direction).  This can be achieved by
   preferring IGP routes before 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 MUST only be accepted
   from the ASes that the IXP authorizes to announce it - which will
   usually be automatically achieved by filtering announcements by IRR
   DB.  pMTUd and the loose uRPF problem

   In order to have 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.  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 less specific (up to a default
   route) to its downstreams.  The announcements done for this purpose
   SHOULD pass IRR-generated filters described in Section as
   well as "prefixes too specific" filters described in Section 5.1.3.
   The easiest way to implement this is that the IXP itself takes care

Durand, et al.            Expires July 22, 2013                [Page 10]

Internet-Draft                  BGP OPSEC                   January 2013

   of the origination of its prefix and advertises it to all IXP members
   through a BGP peering.  Most likely the BGP route servers would be
   used for this.  The IXP would most likely send its entire prefix
   which would be equal or less specific than the IXP LAN prefix.  Example

   Let's take as an example an IXP in the RIPE region for IPv4.  It
   would be allocated a /22 by RIPE NCC (X.Y.0.0/22 in our example) and
   use 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 peerings.
   The IXP could also be allocated an AS number (AS64496 in our

   Any IXP member MUST make sure it filters prefixes more specific than
   X.Y.0.0/23 from all its 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 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

   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.

5.1.6.  The default route  IPv4

   The prefix is likely not intended to be accepted nor
   advertised other than in specific customer / provider configurations,
   general filtering outside of these is RECOMMENDED.  IPv6

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

5.2.  Prefix filtering recommendations in 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 configures

Durand, et al.            Expires July 22, 2013                [Page 11]

Internet-Draft                  BGP OPSEC                   January 2013

   rules for advertised and received routes at all its 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.

5.2.1.  Filters with internet peers  Inbound filtering

   There are basically 2 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.  Inbound filtering loose option

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

   o  Prefixes not routable (Section 5.1.1)

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

   o  Routes too specific (Section 5.1.3)

   o  Prefixes belonging to the local AS (Section 5.1.4)

   o  IXP LAN prefixes (Section 5.1.5)

   o  The default route (Section 5.1.6)  Inbound filtering strict option

   In this case, filters are applied to make sure advertisements
   strictly conform to what is declared in routing registries
   (Section  In case of script 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, one could apply the following filters beforehand
   in case the routing registry used as source of information by the
   script is not fully trusted:

   o  Prefixes not routable (Section 5.1.1)

Durand, et al.            Expires July 22, 2013                [Page 12]

Internet-Draft                  BGP OPSEC                   January 2013

   o  Routes too specific (Section 5.1.3)

   o  Prefixes belonging to the local AS (Section 5.1.4)

   o  IXP LAN prefixes (Section 5.1.5)

   o  The default route (Section 5.1.6)  Outbound filtering

   Configuration should be put in place to make sure 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
   or both.  It can also be desirable that following filters are
   positioned before to avoid unwanted route announcement due to bad

   o  Prefixes not routable (Section 5.1.1)

   o  Routes too specific (Section 5.1.3)

   o  IXP LAN prefixes (Section 5.1.5)

   o  The default route (Section 5.1.6)

   In case it is possible to list the prefixes to be advertised, then
   just configuring the list of allowed prefixes and denying the rest is

5.2.2.  Filters with customers  Inbound filtering

   The inbound policy with end customers is pretty straightforward: only
   customers prefixes must be accepted, all others MUST 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 the customer is also a network
   connecting other customers (for example a tier 1 transit provider
   connecting service providers).  An exception can be envisaged in case
   it is known that the customer network applies strict inbound/outbound
   prefix filtering, and the number of prefixes announced by that
   network is too large to list them in the router configuration.  In
   that c