Security Requirements for BGP Path Validation
Columbia University
1214 Amsterdam Avenue, MC 0401
New York
New York
10027
USA
+1 212 939 7149
bellovin@acm.org
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island
Washington
98110
USA
randy@psg.com
Cisco Systems
170 W. Tasman Drive
San Jose
CA
95134
USA
dward@cisco.com
example
This document describes requirements for a BGP security protocol
design to provide cryptographic assurance that the origin
Autonomous System (AS) has the right to announce the prefix and to
provide assurance of the AS Path of the announcement.
Origin validation based on Resource Public Key Infrastructure (RPKI)
provides a measure of
resilience to accidental mis-origination of prefixes; however, it
provides neither cryptographic assurance (announcements are not
signed) nor assurance of the AS Path of the announcement.
This document describes requirements to be placed on a BGP
security protocol, herein termed "BGPsec", intended to rectify these
gaps.
The threat model assumed here is documented in
and
.
As noted in the threat model , this work
is limited to threats to the BGP protocol. Issues of business
relationship conformance, while quite important to operators, are
not security issues per se and are outside the scope of this
document. It is hoped that these issues will be better understood
in the future.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
are to be interpreted as described in RFC
2119 only when they appear in all upper case. They may
also appear in lower or mixed case, without
normative meaning.
This document assumes knowledge of the RPKI
and the RPKI Repository Structure
.
This document assumes ongoing incremental deployment of Route
Origin Authorizations (ROAs)
, the RPKI to the Router Protocol
, and RPKI-based Prefix Validation
.
And, of course, a knowledge of BGP is
required.
The following are general requirements for a BGPsec protocol:
A BGPsec design MUST allow the receiver of a BGP announcement
to determine, to a strong level of certainty, that the
originating AS in the received PATH attribute possessed the
authority to announce the prefix.
A BGPsec design MUST allow the receiver of a BGP announcement
to determine, to a strong level of certainty, that the
received PATH attribute accurately represents the sequence of
External BGP (eBGP) exchanges that propagated the prefix from the origin AS
to the receiver, particularly if an AS has added or deleted
any AS number other than its own in the PATH attribute. This
includes modification to the number of AS prepends.
BGP attributes other than the AS_PATH are used only locally,
or have meaning only between immediate neighbors, may be
modified by intermediate systems and figure less prominently
in the decision process. Consequently, it is not appropriate
to try to protect such attributes in a BGPsec design.
A BGPsec design MUST be amenable to incremental deployment.
This implies that incompatible protocol capabilities MUST be
negotiated.
A BGPsec design MUST provide analysis of the operational
considerations for deployment and particularly of incremental
deployment, e.g., contiguous islands, non-contiguous islands,
universal deployment, etc.
As proofs of possession and authentication may require
cryptographic payloads and/or storage and computation, likely
increasing processing and memory requirements on routers, a
BGPsec design MAY require use of new hardware.
That is, compatibility with current hardware abilities is not a
requirement that this document imposes on a solution.
A BGPsec design need not prevent attacks on data-plane
traffic. It need not provide assurance that the data plane
even follows the control plane.
A BGPsec design MUST resist attacks by an enemy who has
access to the inter-router link layer, per Section 3.1.1.2 of
. In particular, such a design MUST
provide mechanisms for authentication of all data, including
protecting against message insertion, deletion, modification,
or replay. Mechanisms that suffice include TCP sessions
authenticated with the TCP Authentication Option (TCP-AO)
, IPsec
, or Transport Layer Security (TLS) .
It is assumed that a BGPsec design will require
information about holdings of address space and Autonomous System
Numbers (ASNs), and assertions about binding of address space to
ASNs. A BGPsec design MAY make use of a security
infrastructure (e.g., a PKI) to distribute such authenticated
data.
It is entirely OPTIONAL to secure AS SETs and prefix
aggregation. The long-range solution to this is the
deprecation of AS_SETs; see .
If a BGPsec design uses signed prefixes, given the difficulty
of splitting a signed message while preserving the signature,
it need not handle multiple prefixes in a single UPDATE
PDU.
A BGPsec design MUST enable each BGPsec speaker to configure
use of the security mechanism on a per-peer basis.
A BGPsec design MUST provide backward compatibility in the
message formatting, transmission, and processing of routing
information carried through a mixed security environment.
Message formatting in a fully secured environment MAY be
handled in a non-backward compatible manner.
While the formal validity of a routing announcement should be
determined by the BGPsec protocol, local routing policy MUST
be the final arbiter of the best path and other routing
decisions.
A BGPsec design MUST support 'transparent' route servers,
meaning that the AS of the route server is not counted in
downstream BGP AS-path-length tie-breaking decisions.
A BGPsec design MUST support AS aliasing. This technique is
not well defined or universally implemented but is being
documented in . A
BGPsec design SHOULD accommodate AS 'migration' techniques
such as common proprietary and non-standard methods that
allow a router to have two AS identities, without lengthening
the effective AS Path.
If a BGPsec design makes use of a security
infrastructure, that infrastructure SHOULD enable each network
operator to select the entities it will trust when
authenticating data in the security infrastructure. See, for
example, .
A BGPsec design MUST NOT require operators to reveal more
than is currently revealed in the operational inter-domain
routing environment, other than the inclusion of necessary
security credentials to allow others to ascertain for
themselves the necessary degree of assurance regarding the
validity of Network Layer Reachability Information (NLRI)
received via BGPsec. This includes peering,
customer/provider relationships, an ISP's internal
infrastructure, etc. It is understood that some data are
revealed to the savvy seeker by BGP, traceroute, etc.,
today.
A BGPsec design MUST signal (e.g., via logging or SNMP) security
exceptions that are significant to the operator. The
specific data to be signaled are an implementation matter.
Any routing information database MUST be re-authenticated
periodically or in an event-driven manner, especially in
response to events such as, for example, PKI updates.
Any inter-AS use of cryptographic hashes or signatures MUST
provide mechanisms for algorithm agility. For a discussion,
see .
A BGPsec design SHOULD NOT presume to know the intent of the
originator of a NLRI, nor that of any AS on the AS Path, other
than that they intend to pass it to the next AS in the
path.
A BGPsec listener SHOULD NOT trust non-BGPsec markings, such
as communities, across trust boundaries.
The following requirements MUST be met in the processing of BGP
UPDATE messages:
A BGPsec design MUST enable each recipient of an UPDATE to
formally validate that the origin AS in the message is
authorized to originate a route to the prefix(es) in the
message.
A BGPsec design MUST enable the recipient of an UPDATE to
formally determine that the NLRI has traversed the AS Path
indicated in the UPDATE. Note that this is more stringent
than showing that the path is merely not impossible.
Replay of BGP UPDATE messages need not be completely
prevented, but a BGPsec design SHOULD provide a mechanism to
control the window of exposure to replay attacks.
A BGPsec design SHOULD provide some level of assurance that
the origin of a prefix is still 'alive', i.e., that a monkey in
the middle has not withheld a WITHDRAW message or the effects
thereof.
The AS Path of an UPDATE message SHOULD be able to be
authenticated as the message is processed.
Normal sanity checks of received announcements MUST be done,
e.g., verification that the first element of the AS_PATH list
corresponds to the locally configured AS of the peer from
which the UPDATE was received.
The output of a router applying BGPsec validation to a
received UPDATE MUST be unequivocal and conform to a fully
specified state in the design.
If an external "security infrastructure" is used, as mentioned in
Section 3, paragraphs and
above, the
authenticity and integrity of the data of such an infrastructure
MUST be assured. In addition, the integrity of those data MUST be assured
when they are used by BGPsec, e.g., in transport.
The requirement of backward compatibility to BGP4 may open an
avenue to downgrade attacks.
The data plane might not follow the path signaled by the control
plane.
Security for subscriber traffic is outside the scope of this
document and of BGP security in general. IETF standards for
payload data security should be employed. While adoption of BGP
security measures may ameliorate some classes of attacks on
traffic, these measures are not a substitute for use of
subscriber-based security.
The authors wish to thank the authors of
from whom we liberally
stole, Roque Gagliano, Russ Housley, Geoff Huston, Steve Kent,
Sandy Murphy, Eric Osterweil, John Scudder, Kotikalapudi Sriram,
Sam Weiler, and a number of others.
Guidelines for Cryptographic Algorithm Agility
BGP Security Requirements
RPKI Local Trust Anchor Use Cases
Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute