Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 4305
| Document | Type |
RFC
- Proposed Standard
(December 2005)
Errata
Obsoleted by RFC 4835
|
|
|---|---|---|---|
| Author | Donald E. Eastlake 3rd | ||
| Last updated | 2020-01-21 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Russ Housley | |
| Send notices to | (None) |
RFC 4305
Internet Engineering Task Force (IETF) J. Durand
Request for Comments: 7454 Cisco Systems, Inc.
BCP: 194 I. Pepelnjak
Category: Best Current Practice NIL
ISSN: 2070-1721 G. Doering
SpaceNet
February 2015
BGP Operations and Security
Abstract
The Border Gateway Protocol (BGP) is the protocol almost exclusively
used in the Internet to exchange routing information between network
domains. Due to this central nature, it is important to understand
the security measures that can and should be deployed to prevent
accidental or intentional routing disturbances.
This document describes measures to protect the BGP sessions itself
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
automation of prefix filters, max-prefix filtering, Autonomous System
(AS) path filtering, route flap dampening, and BGP community
scrubbing.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7454.
Durand, et al. Best Current Practice [Page 1]
RFC 7454 BGP OPSEC February 2015
Copyright Notice
Copyright (c) 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.
Durand, et al. Best Current Practice [Page 2]
RFC 7454 BGP OPSEC February 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Scope of the Document . . . . . . . . . . . . . . . . . . . . 4
3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4
4. Protection of the BGP Speaker . . . . . . . . . . . . . . . . 5
5. Protection of BGP Sessions . . . . . . . . . . . . . . . . . 6
5.1. Protection of TCP Sessions Used by BGP . . . . . . . . . 6
5.2. BGP TTL Security (GTSM) . . . . . . . . . . . . . . . . . 6
6. Prefix Filtering . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Definition of Prefix Filters . . . . . . . . . . . . . . 7
6.1.1. Special-Purpose Prefixes . . . . . . . . . . . . . . 7
6.1.2. Unallocated Prefixes . . . . . . . . . . . . . . . . 8
6.1.3. Prefixes That Are Too Specific . . . . . . . . . . . 12
6.1.4. Filtering Prefixes Belonging to the Local AS and
Downstreams . . . . . . . . . . . . . . . . . . . . . 12
6.1.5. IXP LAN Prefixes . . . . . . . . . . . . . . . . . . 12
6.1.6. The Default Route . . . . . . . . . . . . . . . . . . 13
6.2. Prefix Filtering Recommendations in Full Routing Networks 14
6.2.1. Filters with Internet Peers . . . . . . . . . . . . . 14
6.2.2. Filters with Customers . . . . . . . . . . . . . . . 16
6.2.3. Filters with Upstream Providers . . . . . . . . . . . 16
6.3. Prefix Filtering Recommendations for Leaf Networks . . . 17
6.3.1. Inbound Filtering . . . . . . . . . . . . . . . . . . 17
6.3.2. Outbound Filtering . . . . . . . . . . . . . . . . . 17
7. BGP Route Flap Dampening . . . . . . . . . . . . . . . . . . 17
8. Maximum Prefixes on a Peering . . . . . . . . . . . . . . . . 18
9. AS Path Filtering . . . . . . . . . . . . . . . . . . . . . . 18
10. Next-Hop Filtering . . . . . . . . . . . . . . . . . . . . . 20
11. BGP Community Scrubbing . . . . . . . . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. IXP LAN Prefix Filtering - Example . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
Durand, et al. Best Current Practice [Page 3]
RFC 7454 BGP OPSEC February 2015
1. Introduction
The Border Gateway Protocol (BGP), specified in RFC 4271 [2], is the
protocol used in the Internet to exchange routing information between
network domains. BGP does not directly include mechanisms that
control whether the routes exchanged conform to the various
guidelines defined by the Internet community. 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
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, and network administrators SHOULD carefully
appraise this impact before implementation.
3. Definitions and Acronyms
o ACL: Access Control List
o ASN: Autonomous System Number
o IRR: Internet Routing Registry
o IXP: Internet Exchange Point
o LIR: Local Internet Registry
o PMTUD: Path MTU Discovery
o RIR: Regional Internet Registry
o Tier 1 transit provider: an IP transit provider that can reach any
network on the Internet without purchasing transit services.
o uRPF: Unicast Reverse Path Forwarding
Durand, et al. Best Current Practice [Page 4]
RFC 7454 BGP OPSEC February 2015
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
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) 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, as it is
sometimes run in control-plane software. In the absence of ACLs, it
is possible to attack a BGP speaker by simply sending a high volume
of connection requests to it.
If supported, an ACL specific to the control plane of the router
SHOULD be used (receive-ACL, control-plane policing, etc.), to avoid
configuration of data-plane filters for packets transiting through
the router (and therefore not reaching the control plane). If the
hardware cannot do that, interface ACLs can be used to block packets
addressed to the local router.
Some routers automatically program such an ACL upon BGP
configuration. On other devices, this ACL should be configured and
maintained manually or using scripts.
In addition to strict filtering, rate-limiting MAY be configured for
accepted BGP traffic. Rate-limiting BGP traffic consists in
permitting only a certain quantity of bits per second (or packets per
second) of BGP traffic to the control plane. This protects the BGP
router control plane in case the amount of BGP traffic surpasses
platform capabilities.
Filtering and rate-limiting of control-plane traffic is a wider topic
than "just for BGP". (If a network administrator brings down a
router by overloading one of the other protocols remotely, BGP is
harmed as well.) For a more detailed recommendation on how to
protect the router's control plane, see RFC 6192 [11].
Durand, et al. Best Current Practice [Page 5]
RFC 7454 BGP OPSEC February 2015
5. Protection of BGP Sessions
Current security issues of TCP-based protocols (therefore including
BGP) have been documented in RFC 6952 [14]. The following
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 by BGP
Attacks on TCP sessions used by BGP (aka BGP sessions), for 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 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 has been obsoleted by the TCP
Authentication Option (TCP-AO; RFC 5925 [4]), which offers stronger
protection. While MD5 is still the most used mechanism due to its
availability in vendors' equipment, TCP-AO SHOULD be preferred when
implemented.
IPsec could also be used for session protection. At the time of
publication, there is not enough experience of the impact of using
IPsec for BGP 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 (for example, MD5 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.
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 Internal BGP (IBGP) from
attackers outside the Autonomous System.
5.2. BGP TTL Security (GTSM)
BGP sessions can be made harder to spoof with the Generalized TTL
Security Mechanisms (GTSM aka TTL security), defined in 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, and the receiver checks
Durand, et al. Best Current Practice [Page 6]
RFC 7454 BGP OPSEC February 2015
that the TTL value equals 255. Since it's impossible to send an IP
packet with TTL of 255 to an IP host that is not directly connected,
BGP TTL security effectively prevents all spoofing attacks coming
from third parties not directly connected to the same subnet as the
BGP-speaking routers. 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, TTL needs to be configured with a proper value
depending on the distance between BGP speakers (using the principle
described above). Nevertheless, it is not as effective because
anyone inside the TTL diameter could spoof the TTL.
Like MD5 protection, TTL security has to be configured on both ends
of a BGP session.
6. Prefix Filtering
The main aspect of securing BGP resides in controlling the prefixes
that are 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 (as described in this section),
AS paths (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
This section lists the most commonly used prefix filters. The
following sections will clarify where these filters should be
applied.
6.1.1. Special-Purpose Prefixes
6.1.1.1. IPv4 Special-Purpose Prefixes
The IANA IPv4 Special-Purpose Address Registry [23] maintains the
list of IPv4 special-purpose prefixes and their routing scope, and it
SHOULD be used for prefix-filter configuration. Prefixes with value
"False" in column "Global" SHOULD be discarded on Internet BGP
peerings.
6.1.1.2. IPv6 Special-Purpose Prefixes
The IANA IPv6 Special-Purpose Address Registry [24] maintains the
list of IPv6 special-purpose prefixes and their routing scope, and it
SHOULD be used for prefix-filter configuration. Only prefixes with
value "False" in column "Global" SHOULD be discarded on Internet BGP
peerings.
Durand, et al. Best Current Practice [Page 7]
RFC 7454 BGP OPSEC February 2015
6.1.2. Unallocated Prefixes
IANA allocates prefixes to RIRs 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 requires constant updates, as prefixes are
continually allocated. 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 has allocated all the IPv4 available space. Therefore, there is
no reason why network administrators would keep checking that
prefixes they receive from BGP peers are in the IANA-allocated IPv4
address space [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
to accept only prefixes derived from those allocated by IANA.
Administrators can dynamically build this list from the IANA-
allocated IPv6 space [26]. As IANA keeps allocating prefixes to
RIRs, the aforementioned list should be checked regularly against
changes, and if they occur, prefix filters should be computed and
pushed on network devices. The list could also be pulled directly by
routers 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 prefixes
allocated by IANA.
If the process in place (whether manual or automatic) cannot
guarantee that the list is updated regularly, then it's better not to
configure any filters based on allocated networks. The IPv4
experience has shown that many network operators implemented filters
for prefixes not allocated by IANA but did not update them on a
regular basis. This created problems for the latest allocations, and
required extra work for RIRs that had to "de-bogonize" the newly
allocated prefixes. (See [18] for information on de-bogonizing.)
Durand, et al. Best Current Practice [Page 8]
RFC 7454 BGP OPSEC February 2015
6.1.2.2. 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 (ASes) entitled to do so. It has been observed in
the past that an AS could easily advertise someone else&Eastlake Standards Track [Page 3]
RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
3.1.1. ESP Encryption and Authentication Algorithms
These tables list encryption and authentication algorithms for the
IPsec Encapsulating Security Payload protocol.
Requirement Encryption Algorithm (notes)
----------- --------------------
MUST NULL (1)
MUST- TripleDES-CBC [RFC2451]
SHOULD+ AES-CBC with 128-bit keys [RFC3602]
SHOULD AES-CTR [RFC3686]
SHOULD NOT DES-CBC [RFC2405] (3)
Requirement Authentication Algorithm (notes)
----------- ------------------------
MUST HMAC-SHA1-96 [RFC2404]
MUST NULL (1)
SHOULD+ AES-XCBC-MAC-96 [RFC3566]
MAY HMAC-MD5-96 [RFC2403] (2)
Notes:
(1) Since ESP encryption and authentication are optional, support for
the two "NULL" algorithms is required to maintain consistency
with the way these services are negotiated. Note that while
authentication and encryption can each be "NULL", they MUST NOT
both be "NULL".
(2) Weaknesses have become apparent in MD5; however, these should not
affect the use of MD5 with HMAC.
(3) DES, with its small key size and publicly demonstrated and open-
design special-purpose cracking hardware, is of questionable
security for general use.
3.1.2. ESP Combined Mode Algorithms
As specified in [ESP], combined mode algorithms are supported that
provide both confidentiality and authentication services. Support of
such algorithms will require proper structuring of ESP
implementations. Under many circumstances, combined mode algorithms
provide significant efficiency and throughput advantages. Although
there are no suggested or required combined algorithms at this time,
AES-CCM [CCM], which has been adopted as the preferred mode for
security in IEEE 802.11 [802.11i], is expected to be of interest in
the near future.
Eastlake Standards Track [Page 4]
RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
3.2. Authentication Header
The implementation conformance requirements for security algorithms
for AH are given below. See Section 2 for definitions of the values
in the "Requirement" column. As you would suspect, all of these
algorithms are authentication algorithms.
Requirement Algorithm (notes)
----------- ---------
MUST HMAC-SHA1-96 [RFC2404]
SHOULD+ AES-XCBC-MAC-96 [RFC3566]
MAY HMAC-MD5-96 [RFC2403] (1)
Note:
(1) Weaknesses have become apparent in MD5; however, these should not
affect the use of MD5 with HMAC.
4. Security Considerations
The security of cryptographic-based systems depends on both the
strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The security also depends on
the engineering and administration of the protocol used by the system
to ensure that there are no non-cryptographic ways to bypass the
security of the overall system.
This document concerns itself with the selection of cryptographic
algorithms for the use of ESP and AH, specifically with the selection
of mandatory-to-implement algorithms. The algorithms identified in
this document as "MUST implement" or "SHOULD implement" are not known
to be broken at the current time, and cryptographic research so far
leads us to believe that they will likely remain secure into the
foreseeable future. However, this is not necessarily forever. We
would therefore expect that new revisions of this document will be
issued from time to time that reflect the current best practice in
this area.
5. Acknowledgement
Much of the wording herein was adapted from RFC 4307, "Cryptographic
Algorithms for Use in the Internet Key Exchange Version 2", by
Jeffrey I. Schiller.
Eastlake Standards Track [Page 5]
RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
6. Changes from RFC 2402 and 2406
[RFC2402] and [RFC2406] defined the IPsec Authentication Header and
IPsec Encapsulating Security Payload. Each specified the
implementation requirements for cryptographic algorithms for their
respective protocols. They have now been replaced with [AH] and
[ESP], which do not specify cryptographic algorithm implementation
requirements, and this document, which specifies such requirements
for both [AH] and [ESP].
The implementation requirements are compared below:
Old Old New
Req. RFC(s) Requirement Algorithm (notes)
--- ------ ----------- ---------
MUST 2406 SHOULD NOT DES-CBC [RFC2405] (1)
MUST 2402 2406 MAY HMAC-MD5-96 [RFC2403]
MUST 2402 2406 MUST HMAC-SHA1-96 [RFC2404]
Note:
(1) The IETF deprecated the use of single DES years ago and has not
included it in any new standard for some time (see IESG note on
the first page of [RFC2407]). But this document represents the
first standards-track recognition of that deprecation by
specifying that implementations SHOULD NOT provide single DES.
The US Government National Institute of Standards and Technology
(NIST) has formally recognized the weakness of single DES by a
notice published in the 26 July 2004 US Government Federal
Register (Docket No. 040602169-4169-01) proposing to withdraw it
as a US Government Standard. Triple DES remains approved by both
the IETF and NIST.
7. Normative References
[AH] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[IPsec] Kent, S., "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Eastlake Standards Track [Page 6]
RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
Algorithm and Its Use With IPsec", RFC 3566, September
2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September
2003.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
8. Informative References
[802.11i] LAN/MAN Specific Requirements Part 11: Wireless Medium
Access Control (MAC) and physical layer (PHY)
specifications: Medium Access Control (MAC) Security
Enhancements, IEEE Std 802.11i, June 2004.
[JIS] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[CCM] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
Eastlake Standards Track [Page 7]
RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP'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, two options can be considered:
short- and long-term options. They are described in the following
subsections.
6.1.2.2.1. Prefix Filters Created from Internet Routing Registries
(IRRs)
An Internet Routing Registry (IRR) is a database containing Internet
routing information, described using Routing Policy Specification
Language objects as described in RFC 4012 [10]. Network
administrators are given privileges to describe routing policies of
their own networks in the IRR, and that information is published,
usually publicly. A majority of Regional Internet Registries do also
operate an IRR and can control whether registered routes conform to
the prefixes that are allocated or directly assigned. However, it
should be noted that the list of such prefixes is not necessarily a
complete list, and as such the list of routes in an IRR is not the
same as the set of RIR-allocated prefixes.
It is possible to use the IRR information to build, for a given
neighbor AS, a list of originated or transited prefixes that one may
accept. This can be done relatively easily using scripts and
existing tools capable of retrieving this information from the
registries. This approach is exactly the same for both IPv4 and
IPv6.
The macro-algorithm for the script is as follows. For the peer that
is considered, the distant network administrator has provided the AS
and may be able to provide an AS-SET object (aka AS-MACRO). An
AS-SET is an object 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 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 look in the corresponding IRR for all associated prefixes.
With these two mechanisms, a script can build, for a given peer, the
Durand, et al. Best Current Practice [Page 9]
RFC 7454 BGP OPSEC February 2015
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, and AS-SETs may not all be under the same
RIR authority, it is difficult to choose for each object the
appropriate IRR to poll. Some IRRs have been created and are not
restricted to a given region or authoritative RIR. They allow RIRs
to publish information contained in their IRR in a common place.
They also make it possible for any subscriber (probably under
contract) to publish information too. When doing requests inside
such an IRR, it is possible to specify the source of information in
order to have the most reliable data. One could check a popular IRR
containing many sources (such as RADb [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. Refreshing the filters on a daily basis SHOULD be
considered because routing changes must sometimes be done in an
emergency and registries may be updated at the very last moment.
Note that this approach significantly increases the complexity of the
router configurations, as it can quickly add tens of thousands of
configuration lines for some important peers. To manage this
complexity, network administrators could use, for example, IRRToolSet
[30], a set of tools making it possible to simplify the creation of
automated 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 Routing
An infrastructure called SIDR (Secure Inter-Domain Routing),
described in RFC 6480 [12], has been designed to secure Internet
advertisements. At the time of writing this 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 RIRs. There are basically two services that SIDR
offers:
o Origin validation, described in RFC 6811 [5], seeks to make sure
that attributes associated with routes are correct. (The major
point is the validation of the AS number originating a given
route.) Origin validation is now operational (Internet
Durand, et al. Best Current Practice [Page 10]
RFC 7454 BGP OPSEC February 2015
registries, protocols, implementations on some routers), and in
theory it can be implemented knowing that the number of signed
resources is still low at the time of writing this document.
o Path validation provided by BGPsec [29] seeks to make sure that no
one announces fake/wrong BGP paths that would attract traffic for
a given destination; see RFC 7132 [16]. BGPsec is still an
ongoing work item at the time of writing this document and
therefore cannot be implemented.
Implementing SIDR mechanisms is expected to solve many of the BGP
routing security problems in the long term, but it may take time for
deployments to be made and objects to become signed. Also, note that
the SIDR infrastructure is complementing (not replacing) the security
best practices listed in this document. Therefore, network
administrators SHOULD implement any SIDR proposed mechanism (for
example, route origin validation) on top of the other existing
mechanisms even if they could sometimes appear to be targeting the
same goal.
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 Resource Public
Key Infrastructure (RPKI) data set:
o If a corresponding ROA (Route Origin Authorization) is found and
is valid, then the prefix SHOULD be accepted.
o If the ROA is found and is INVALID, then the prefix SHOULD be
discarded.
o If a ROA is not found, then the prefix SHOULD be accepted, but the
corresponding route SHOULD be given a low preference.
In addition to this, 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, interesting
challenges. The paper "On the Risk of Misbehaving RPKI Authorities"
[31] explains how the RPKI model can impact the Internet if
authorities don't behave as they are supposed to. Further analysis
is certainly required on RPKI, which carries part of BGP security.
Durand, et al. Best Current Practice [Page 11]
RFC 7454 BGP OPSEC February 2015
6.1.3. Prefixes That Are Too Specific
Most ISPs will not accept advertisements beyond a certain level of
specificity (and in return, they do not announce prefixes they
consider to be too specific). That acceptable specificity is decided
for each peering between the 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 notes
that there are existing practices on the Internet and recommends that
the reader refer to them. As an example, the RIPE community has
documented that, at the time of writing of this document, IPv4
prefixes longer than /24 and IPv6 prefixes longer than /48 are
generally neither announced nor accepted in the Internet [20] [21].
These values may change in the future.
6.1.4. Filtering Prefixes Belonging to the Local AS and 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,
in case someone else is announcing the prefix over the Internet.
This also protects the infrastructure that may directly suffer if the
backbone's prefix is suddenly preferred over the Internet.
In some cases, for example, multihoming scenarios, such filters
SHOULD NOT be applied, as this would break the desired redundancy.
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
filters must be defined with caution as they can break existing
redundancy mechanisms. For 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 even if the BGP peering between the customer and the
operator is down.
6.1.5. IXP LAN Prefixes
6.1.5.1. Network 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-
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.
Durand, et al. Best Current Practice [Page 12]
RFC 7454 BGP OPSEC February 2015
If the IXP LAN prefix is accepted as an "exact match", care needs to
be taken to prevent other routers in the network from 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 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 -- this will
usually be automatically achieved by filtering announcements using
the IRR database.
6.1.5.2. 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 (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 for
the IXP itself to take care of the origination of its prefix and
advertise it to all IXP members through a BGP peering. Most likely,
the BGP route servers would be used for this, and the IXP would send
its entire prefix, which would be equal to or less specific than the
IXP LAN prefix.
Appendix A gives an example of guidelines regarding IXP LAN prefix.
6.1.6. The Default Route
6.1.6.1. IPv4
Typically, the 0.0.0.0/0 prefix is not intended to be accepted or
advertised except in specific customer/provider configurations;
general filtering outside of these is RECOMMENDED.
Durand, et al. Best Current Practice [Page 13]
RFC 7454 BGP OPSEC February 2015
6.1.6.2. IPv6
Typically, the ::/0 prefix is not intended to be accepted or
advertised except in specific customer/provider configurations;
general filtering outside of these is RECOMMENDED.
6.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
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 and uses prefix filters defined in
Section 6.1.
6.2.1. Filters with Internet Peers
6.2.1.1. Inbound Filtering
There are basically 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
In this case, the following prefixes received from a BGP peer will be
filtered:
o prefixes that are not globally routable (Section 6.1.1)
o prefixes not allocated by IANA (IPv6 only) (Section 6.1.2.1)
o routes that are too specific (Section 6.1.3)
o prefixes belonging to the local AS (Section 6.1.4)
o IXP LAN prefixes (Section 6.1.5)
o the default route (Section 6.1.6)
6.2.1.1.2. Inbound 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
Durand, et al. Best Current Practice [Page 14]
RFC 7454 BGP OPSEC February 2015
accurate (prefixes missing, wrong information, etc.). This varies
across the registries and regions of the Internet. Before applying a
strict policy, the reader SHOULD check the impact on the filter and
make sure the solution is not worse than the problem.
Also, 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, 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 that are not globally routable (Section 6.1.1)
o routes that are too specific (Section 6.1.3)
o prefixes belonging to the local AS (Section 6.1.4)
o IXP LAN prefixes (Section 6.1.5)
o the default route (Section 6.1.6)
6.2.1.2. Outbound Filtering
The configuration should 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 BGP communities, AS paths, or both. Also, it may be desirable
to add the following filters before any policy to avoid unwanted
route 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)
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.
Durand, et al. Best Current Practice [Page 15]
RFC 7454 BGP OPSEC February 2015
6.2.2. Filters with Customers
6.2.2.1. Inbound Filtering
The inbound policy with end customers is pretty straightforward: only
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 when the customer is a network connecting other
customers (for example, a Tier 1 transit provider connecting service
providers). An exception is when the customer network applies strict
inbound/outbound prefix filtering, and there are too many prefixes
announced by that network to list them in the router configuration.
In that case, filters as in Section 6.2.1.1 can be applied.
6.2.2.2. Outbound Filtering
The outbound policy with customers may vary according to the routes
the customer wants to receive. In the simplest possible scenario,
the customer may want to receive only the default route; this can be
done easily by applying a filter with the default route only.
In case the customer wants to receive the full routing (if it is
multihomed or if it wants to have a view of the Internet table), the
following filters can be applied on the BGP peering:
o prefixes that are not globally routable (Section 6.1.1)
o routes that are too specific (Section 6.1.3)
o the default route (Section 6.1.6)
In some cases, the customer may desire to receive the default route
in addition to the full BGP table. This can be done by the provider
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
6.2.3.1. Inbound 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. Sometimes, the default
Durand, et al. Best Current Practice [Page 16]
quot;, RFC 2407, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
Author's Address
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-786-7554 (w)
+1-508-634-2066 (h)
EMail: Donald.Eastlake@Motorola.com
Eastlake Standards Track [Page 8]
RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eastlake Standards Track [Page 9]