< draft-murphy-bgp-secr-03.txt   draft-murphy-bgp-secr-04.txt >
Network Working Group Sandra Murphy Network Working Group Sandra Murphy
INTERNET DRAFT NAI Labs INTERNET DRAFT NAI Labs
draft-murphy-bgp-secr-03.txt June 1999 draft-murphy-bgp-secr-04.txt November 2001
BGP Security Analysis BGP Security Analysis
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is subject to all provisions of
provisions of Section 10 of RFC2026. Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
Abstract Abstract
BGP, along with a host of other infrastructure protocols designed before BGP, along with a host of other infrastructure protocols designed before
the Internet environment became perilous, is designed with little the Internet environment became perilous, is designed with little
consideration for protection of the data it communicates or of its own consideration for protection of the information it carries. There are
behavior. There are no mechanisms in BGP to protect against attacks no mechanisms in BGP to protect against attacks that modify, delete,
that modify, delete, forge, or replay data, any of which has the forge, or replay data, any of which has the potential to disrupt overall
potential to be destructive of overall network routing behavior. network routing behavior.
This internet draft discusses some of the security issues with BGP This internet draft discusses some of the security issues with BGP
routing data dissemination, and possible security solutions and the routing data dissemination, and possible security solutions and the
costs of those solutions. This internet draft does not discuss security costs of those solutions. This internet draft does not discuss security
issues with forwarding of packets. issues with forwarding of packets.
Table of Contents Table of Contents
Status of this Memo .............................................. 1 Status of this Memo .............................................. 1
Abstract ......................................................... 1 Abstract ......................................................... 1
1 Introduction .................................................... 4 1 Introduction .................................................... 4
2 Vulnerabilities and Risks ....................................... 5 2 Vulnerabilities and Risks ....................................... 6
3 Possible Protections ............................................ 5 3 Possible Protections ............................................ 6
3.1 Threats from non-BGP peers .................................... 5 3.1 Threats from outsiders ........................................ 6
3.1.1 IP level protection ......................................... 6 3.1.1 IP level protection ......................................... 7
3.1.2 TCP level protection ........................................ 6 3.1.2 TCP level protection ........................................ 7
3.1.3 BGP level protection ........................................ 7 3.2 Threats from BGP peers ........................................ 8
3.2 Threats from BGP peers ........................................ 7 3.3 Origination Protection ........................................ 8
3.3 Sign Originating AS ........................................... 7 3.4 Origination and Adjacency Protection .......................... 9
3.4 Sign Originating AS and Predecessor Information ............... 8 3.5 Sign Originating AS and AS_PATH ............................... 10
3.5 Sign Originating AS and AS_PATH ............................... 9 3.5.1 Remaining Issues ............................................ 11
3.5.1 Special Considerations ...................................... 12 3.6 Filtering ..................................................... 13
3.6 Rely on Registries ............................................ 13 4 Security Costs .................................................. 14
4 Security Costs .................................................. 13
4.1 Protecting the Peer-Peer Link ................................. 14 4.1 Protecting the Peer-Peer Link ................................. 14
4.2 Sign Originating AS ........................................... 14 4.2 Origination Protection ........................................ 14
4.3 Sign Originating AS and Predecessor Information ............... 14 4.3 Origination and Adjacency Protection .......................... 15
4.4 Sign Originating AS and AS_PATH ............................... 15 4.4 Origination and AS_PATH Protection ............................ 15
4.5 Rely on Registries ............................................ 15 4.5 Rely on Registries ............................................ 16
5 Authentication vs Authorization ................................. 15 5 Security Considerations ......................................... 16
5.1 Authentication without Authorization .......................... 15 6 References ...................................................... 16
5.2 Authorization without Authentication .......................... 16 7 Author's Address ................................................ 17
5.2.1 Authentication and Authorization ............................ 16 A Appendix A - Vulnerabilities and Risks .......................... 18
6 Security Considerations ......................................... 17 A.1 OPEN .......................................................... 18
7 References ...................................................... 17 A.2 KEEPALIVE ..................................................... 18
8 Author's Address ................................................ 18 A.3 NOTIFICATION .................................................. 18
A Appendix A - Vulnerabilities and Risks .......................... 19 A.4 UPDATE ........................................................ 18
A.1 OPEN .......................................................... 19 A.4.1 Unfeasible Routes Length, Total Path Attribute Length ....... 18
A.2 KEEPALIVE ..................................................... 19 A.4.2 Withdrawn Routes ............................................ 19
A.3 NOTIFICATION .................................................. 19 A.4.3 Path Attributes ............................................. 19
A.4 UPDATE ........................................................ 19 Attribute Flags, Attribute Type Codes, Attribute Length .......... 19
A.4.1 Unfeasible Routes Length, Total Path Attribute Length ....... 19 ORIGIN ........................................................... 19
A.4.2 Withdrawn Routes ............................................ 20 AS_PATH .......................................................... 20
A.4.3 Path Attributes ............................................. 20 Originating Routes ............................................... 20
Attribute Flags, Attribute Type Codes, Attribute Length .......... 20 NEXT_HOP ......................................................... 21
ORIGIN ........................................................... 20 MULTI_EXIT_DISC .................................................. 21
AS_PATH .......................................................... 21 LOCAL_PREF ....................................................... 21
Originating Routes ............................................... 21 ATOMIC_AGGREGATE ................................................. 22
NEXT_HOP ......................................................... 22 AGGREGATOR ....................................................... 22
MULTI_EXIT_DISC .................................................. 22 A.4.4 NLRI ........................................................ 22
LOCAL_PREF ....................................................... 22
ATOMIC_AGGREGATE ................................................. 23
AGGREGATOR ....................................................... 23
A.4.4 NLRI ........................................................ 23
1. Introduction 1. Introduction
The inter-domain routing protocol BGP was created when the Internet The inter-domain routing protocol BGP was created when the Internet
environment had not yet reached the present contentious state. environment had not yet reached the present contentious state.
Consequently, the BGP protocol was not designed with protection against Consequently, the BGP protocol was not designed with protection against
deliberate or accidental errors causing disruptions of routing behavior. deliberate or accidental errors causing disruptions of routing behavior.
We here discuss the vulnerabilities of BGP, based on the BGP RFC [1]. We here discuss the vulnerabilities of BGP, based on the BGP RFC [1] and
Readers are expected to be familiar with the BGP RFC and the behavior of on [2]. Readers are expected to be familiar with the BGP RFC and the
BGP. We propose several different security solutions to protect these behavior of BGP. We propose several different security solutions to
vulnerabilities and discuss the benefits derived from each solution and protect these vulnerabilities and discuss the benefits derived from each
its cost. solution and its cost.
It is clear that the Internet is vulnerable to attack through its It is clear that the Internet is vulnerable to attack through its
routing protocols. BGP is no exception. Faulty, misconfigured or routing protocols. BGP is no exception. Faulty, misconfigured or
deliberately malicious sources can disrupt overall Internet behavior by deliberately malicious sources can disrupt overall Internet behavior by
injecting bogus routing information into the BGP distributed routing injecting bogus routing information into the BGP distributed routing
database (by modifying, forging, or replaying BGP packets). The same database (by modifying, forging, or replaying BGP packets). The same
methods can also be used to disrupt local and overall network behavior methods can also be used to disrupt local and overall network behavior
by breaking the distributed communication of information between BGP by breaking the distributed communication of information between BGP
peers. The sources of bogus information can be either non-BGP peers or peers. The sources of bogus information can be either outsiders or true
true BGP peers. BGP peers.
As a TCP/IP protocol, BGP is subject to all the TCP/IP attacks, like IP Under the present BGP design, cryptographic authentication of the peer-
spoofing, session stealing, SYN attacks, etc. Under the present BGP peer communication is not mandated. As a TCP/IP protocol, BGP is
design, any non-BGP peer source can inject believable BGP packets into subject to all the TCP/IP attacks, like IP spoofing, session stealing,
the communication between BGP peers and thereby inject bogus routing etc. Any outsider can inject believable BGP messages into the
information or break the peer to peer connection. With IP spoofing, the communication between BGP peers and thereby inject bogus routing
non-BGP peer sources of bogus BGP information can reside anywhere in the information or break the peer to peer connection. Any break in the peer
world. Furthermore, non-BGP peer sources can disrupt communications to peer communication has a ripple effect on routing that can be wide
spread. Furthermore, outsider sources can also disrupt communications
between BGP peers by breaking their TCP connection with spoofed RST between BGP peers by breaking their TCP connection with spoofed RST
packets. BGP speakers themselves can inject bogus routing information, packets. Outsider sources of bogus BGP information can reside anywhere
masquerading as information from any other legitimate BGP speaker, or in the world.
unauthentic routing information from themselves. Bogus information from
either non-BGP or BGP sources can affect routing behavior in the BGP speakers themselves can inject bogus routing information, either by
Internet over a wide, possibly unbounded, area. masquerading as information from any other legitimate BGP speaker, or by
distributing unauthentic routing information as themselves.
Historically, misconfigured and faulty routers have been responsible for
widespread disruptions in the Internet.
Bogus routing information can have many different effects on routing Bogus routing information can have many different effects on routing
behavior. If the bogus information removes routing information for a behavior. If the bogus information removes routing information for a
particular network, that network can become unreachable for the portion particular network, that network can become unreachable for the portion
of the Internet that accepts the bogus information. If the bogus of the Internet that accepts the bogus information. If the bogus
information changes the route to a network, then packets destined for information changes the route to a network, then packets destined for
that network may be forwarded by a sub-optimal path, or a path that does that network may be forwarded by a sub-optimal path, or a path that does
not follow the expected policy, or a path that will not forward the not follow the expected policy, or a path that will not forward the
traffic. Traffic to that network could be delayed or the network could traffic. As a consequence, traffic to that network could be delayed by
become unreachable from areas where the bogus information is accepted. a longer than necessary path. The network could become unreachable from
areas where the bogus information is accepted. Traffic might also be
forwarded along a path that permits some adversary a view of the data.
If the bogus information makes it appear that an autonomous system If the bogus information makes it appear that an autonomous system
originates a network when it does not, then packets for that network may originates a network when it does not, then packets for that network may
not be deliverable for the portion of the Internet that accepts the not be deliverable for the portion of the Internet that accepts the
bogus information. A false announcement that an autonomous systems bogus information. A false announcement that an autonomous systems
originates a network may also fragment aggregated address blocks in originates a network may also fragment aggregated address blocks in
other parts of the Internet and cause routing problems for other other parts of the Internet and cause routing problems for other
networks. networks.
The damage that might result from these attacks are:
starvation: data traffic destined for a node is forwarded to a part
of the network that cannot deliver it,
network congestion: more data traffic is forwarded through some
portion of the network than would otherwise need to carry the
traffic,
blackhole: large amounts of traffic are directed to be forwarded
through one router that cannot handle the increased level of
traffic and drops many/most/all packets,
delay: data traffic destined for a node is forwarded along a path
that is in some way inferior to the path it would otherwise take,
looping: data traffic is forwarded along a path that loops, so that
the data is never delivered,
eavesdrop: data traffic is forwarded through some router or network
that would otherwise not see the traffic, affording an opportunity
to see the data,
partition: some portion of the network believes that it is
partitioned from the rest of the network when it is not,
cut: some portion of the network believes that it has no route to
some network that is in fact connected,
churn: the forwarding in the network changes at a rapid pace,
resulting in large variations in the data delivery patterns (and
adversely affecting congestion control techniques),
instability: BGP become unstable so that convergence on a global
forwarding state is not achieved, and
overload: the BGP messages themselves become a significant portion
of the traffic the network carries.
2. Vulnerabilities and Risks 2. Vulnerabilities and Risks
The risks in BGP arise from three fundamental vulnerabilities: The risks in BGP arise from three fundamental vulnerabilities:
no mechanism has been specified that provides strong protection of no mechanism has been mandated that provides strong protection of
the integrity, freshness and source authenticity of the messages in the integrity, freshness and source authenticity of the messages in
peer-peer BGP communications. peer-peer BGP communications.
no mechanism has been specified to validate the authority of an AS no mechanism has been specified to validate the authority of an AS
to announce NLRI information. to announce NLRI information.
no mechanism has been specified to ensure the authenticity of the no mechanism has been specified to ensure the authenticity of the
AS_PATH announced by an AS. AS_PATH announced by an AS.
There are four different BGP message types - OPEN, KEEPALIVE, There are four different BGP message types - OPEN, KEEPALIVE,
NOTIFICATION, and UPDATE. A discussion of the vulnerabilities arising NOTIFICATION, and UPDATE. A discussion of the vulnerabilities arising
from each message and the ability of non-BGP peers or BGP peers to from each message and the ability of outsiders or BGP peers to exploit
exploit the vulnerabilities is contained in Appendix A. Suffice it to the vulnerabilities is contained in Appendix A. To summarize, outsiders
say here that non-BGP peers can use bogus OPEN, KEEPALIVE, or can use bogus OPEN, KEEPALIVE, or NOTIFICATION messages to disrupt the
NOTIFICATION messages to disrupt the BGP peer-peer connections and can BGP peer-peer connections and can use bogus UPDATE messages to disrupt
use bogus UPDATE messages to disrupt routing. Non-BGP peers can also routing. Outsiders can also disrupt BGP peer-peer connections by
disrupt BGP peer-peer connections by inserting bogus TCP RST packets. inserting bogus TCP RST packets. BGP peers themselves are permitted to
BGP peers themselves are permitted to break peer-peer connections at any break peer-peer connections at any time, and so they cannot be said to
time, and so they cannot be said to be issuing "bogus" OPEN, KEEPALIVE be issuing "bogus" OPEN, KEEPALIVE or NOTIFICATION messages. However,
or NOTIFICATION messages. However, BGP peers can disrupt routing by BGP peers can disrupt routing by issuing bogus UPDATE messages. In
issuing bogus UPDATE messages. In particular, bogus ATOMIC_AGGREGATE particular, bogus ATOMIC_AGGREGATE and AS_PATH attributes and bogus NLRI
and AS_PATH attributes and bogus NLRI in UPDATE messages can disrupt in UPDATE messages can disrupt routing.
routing.
3. Possible Protections 3. Possible Protections
3.1. Threats from non-BGP peers 3.1. Threats from outsiders
Non-BGP peers can be prevented from disrupting routing by providing Outsiders can be prevented from disrupting routing by providing
cryptographic protection of the BGP peer-peer connection. The cryptographic protection of the BGP peer-peer connection. The
cryptography chosen should protect the source authenticity and integrity cryptography chosen should protect the source authenticity and integrity
of the message and should also protect against replay. As the of the message and should also protect against replay. As the
protection is only of the peer-peer communications, asymmetric protection is only of the peer-peer communications, asymmetric
cryptography is not needed. Protection against spoofing in the peer- cryptography is not needed. Two different protection against spoofing
peer connection could be provided by: in the peer-peer connection have been suggested:
IP level protection as defined by IPSEC [7] IP level protection as defined by IPSEC [7]
TCP level protection as defined by [8] TCP level protection as defined by [8]
BGP level protection as defined by [9]
Prevention of IP spoofing completely removes any risk associated with Prevention of IP spoofing completely removes any risk associated with
bogus OPEN, KEEPALIVE, or NOTIFICATION messages, as the only bogus OPEN, KEEPALIVE, or NOTIFICATION messages, as the only
vulnerabilities from these messages come from non-BGP peers. It also vulnerabilities from these messages come from outsiders. It also
protects against all threats from bogus UPDATE messages and from bogus protects against all threats from bogus UPDATE messages and from bogus
TCP messages arising from non-BGP peers. TCP messages arising from outsiders.
3.1.1. IP level protection 3.1.1. IP level protection
Protection as specified for the IPSEC AH header [7] can be used to Protection as specified for the IPSEC [7] can be used to provide
provide connectionless integrity, data origin authentication, and an connectionless integrity, data origin authentication, and a anti-replay
optional anti-replay service. service.
3.1.2. TCP level protection 3.1.2. TCP level protection
It is possible to protect the peer-peer connection by applying It is possible to protect the peer-peer connection by applying
cryptographic protection at the TCP level to provide connectionless cryptographic protection at the TCP level to provide connectionless
integrity and data origin authentication. This has been in use with integrity and data origin authentication. This has been in use with
some vendors for some time as specified in [8]. Note, however, that the some vendors for some time as specified in [8]. Note, however, that the
protections specified in [8] were put in place some time ago. The IPSEC protections specified in [8] were put in place some time ago. The IPSEC
protections have advanced since that time. In particular, the protections have advanced since that time. In particular, the
protections of [8] use MD5 directly, where the IPSEC protections mandate protections of [8] use MD5 directly, where the IPSEC protections mandate
skipping to change at page 7, line 5 skipping to change at page 7, line 48
need only be within the receive window to be accepted, the TCP sequence need only be within the receive window to be accepted, the TCP sequence
number protection is not complete. Finally, [8] has no provisions for number protection is not complete. Finally, [8] has no provisions for
multiple keys to be used in rekeying. As these are pairwise keys used multiple keys to be used in rekeying. As these are pairwise keys used
for long-lived sessions, the inability to specify multiple keys may not for long-lived sessions, the inability to specify multiple keys may not
cause operational difficulties. cause operational difficulties.
Although the TCP level protection specified in [8] has deficiencies when Although the TCP level protection specified in [8] has deficiencies when
compared with the protection of IPSEC [7], it is vastly preferable to a compared with the protection of IPSEC [7], it is vastly preferable to a
unprotected connection. If IPSEC is not available, then the TCP level unprotected connection. If IPSEC is not available, then the TCP level
protection of [8] should definitely be used. When IPSEC is available, protection of [8] should definitely be used. When IPSEC is available,
IPSEC is preferable. IPSEC is preferable. One or the other must be used.
3.1.3. BGP level protection
Cryptographic protection of the peer-peer connection at the BGP level is
proposed in [9]. Note that applying the cryptographic protection within
BGP does not provide the same protection as applying it within TCP, as
TCP information other than the payload (BGP) data, particularly the RST
field, could still be spoofed in ways that would harm the connection.
3.2. Threats from BGP peers 3.2. Threats from BGP peers
Protection of the communication between BGP peers does nothing to Protection of the communication between BGP peers does nothing to
protect against errors introduced by the BGP speakers themselves. BGP protect against errors introduced by the BGP speakers themselves. BGP
speakers can introduce bogus routing information, e.g., invalid speakers can introduce bogus routing information, e.g., invalid
AS_PATHs, false origination announcements of NLRI, etc., at any time. AS_PATHs, false origination announcements of NLRI, etc., at any time.
Furthermore, detecting the BGP source of bogus information (if and when Furthermore, detecting the BGP source of bogus information (if and when
the bogus-ness is detected) can be difficult if not impossible. the bogus-ness is detected) can be difficult if not impossible.
There are several possible solutions to prevent a BGP speaker from There are several possible solutions to prevent a BGP speaker from
inserting bogus information in its advertisements to its peers. inserting bogus information in its advertisements to its peers.
(1) sign the originating AS. (1) Origination Protection: sign the originating AS.
(2) sign the originating AS and predecessor information. (2) Origination and Adjacency Protection: sign the originating AS and
predecessor information.
(3) sign the originating AS, and nest signatures of AS_PATHs to the (3) Origination and Route Protection: sign the originating AS, and
number of consecutive bad routers you want to prevent from nest signatures of AS_PATHs to the number of consecutive bad
causing damage. routers you want to prevent from causing damage.
(4) rely on a registry to verify the AS_PATH and NLRI originating AS. (4) Filtering: rely on a registry to verify the AS_PATH and NLRI
originating AS.
3.3. Sign Originating AS The first three solutions are implemented within the protocol exchanges.
The last solution is an operational protection and leaves the protocol
messages unchanged.
It would be beneficial to know which AS has first advertised a route to 3.3. Origination Protection
a NLRI. This could be done by including a new path attribute which
would contain the originating AS number and the originating AS's digital It would be beneficial to authenticate the AS that first advertises a
signature [3] of the AS number plus the NLRI advertised. A digital route to a NLRI. This could be done by including a new path attribute
signature (as opposed to a message integrity check using a shared which would contain the originating AS number and the originating AS's
secret) is required because the number and identities of all eventual digital signature [4] of the AS number plus the NLRI advertised. A
recipients could not be known and because non-repudiation would be digital signature (as opposed to a message integrity check using a
shared secret) is preferable because the number and identities of all
eventual recipients are not known and because non-repudiation would be
desired. If routing was disturbed by the presence of this desired. If routing was disturbed by the presence of this
advertisement, then the culprit could be determined. advertisement, then the culprit could be determined.
If an infra-structure exists representing ownership of network If an infra-structure exists representing ownership of network
addresses, then the owner as well as the originator could sign. This addresses, then the owner as well as the originator could sign. This
signature would indicate that the AS was authorized by the owner to signature would indicate that the AS was authorized by the owner to
originate the network. originate the network. A BGP speaker receiving a protected origination
could verify taht the origination was legitimate.
If routes are aggregated by a BGP speaker and the aggregated route If routes are aggregated by a BGP speaker and the aggregated route
advertised, then the idea of "originator" and "owner" become less advertised, then the idea of "originator" and "owner" become less
useful. There might be several "originators" and "owners" represented useful. There might be several "originators" and "owners" represented
among the aggregated routes. We suggest that the AGGREGATOR field among the aggregated routes. The AGGREGATOR field should be mandatory
become mandatory and that an aggregating BGP speaker append its and an aggregating BGP speaker should append its signature of the
signature of the AGGREGATOR field and the aggregated NLRI. AGGREGATOR field and the aggregated NLRI. Unfortunately, aggregation
Unfortunately, aggregation prevents identification of the specific prevents identification of the specific culprit should it be discovered
culprit should it be discovered that a network is being originated in that a network is being originated incorrectly.
error.
3.4. Sign Originating AS and Predecessor Information This protection does not ensure that the AS_PATH is authentic or
current.
Reference [2] suggests several different types of cryptographic 3.4. Origination and Adjacency Protection
Reference [3] suggests several different types of cryptographic
protection of BGP. The suggested protection against possibly faulty BGP protection of BGP. The suggested protection against possibly faulty BGP
speakers introduces some link state topology information (see [4]) that speakers introduces some link state topology information (as in OSPF
can be used to verify AS_PATHs. [5]) that can be used to verify AS_PATHs.
To obviate the need to trust BGP speakers regarding NLRI information not To obviate the need to trust BGP speakers regarding NLRI information not
specific to their own AS, [2] suggests adding the following information specific to their own AS, [3] suggests adding the following information
to the UPDATE message: to the UPDATE message in new path attributes:
- a sequence number for the UPDATE - a sequence number for the UPDATE
- the AS originating the information (either the aggregator or the - the AS originating the information (either the aggregator or the
originator of a direct route) and originator of a direct route) and
- the predecessor of the originating AS (i.e., the neighbor to which - the "predecessor" of the originating AS (i.e., the neighbor to
the NLRI is first advertised). which the NLRI is first advertised).
This information is digitally signed by the BGP originator along with This information is digitally signed by the BGP originator along with
the NLRI, the ATOMIC_AGGREGATE, the ORIGIN, and the AGGREGATOR fields of the NLRI, the ATOMIC_AGGREGATE, the ORIGIN, and the AGGREGATOR fields of
the UPDATE message. The signature and the predecessor information must the UPDATE message. The signature and the predecessor information must
be included as the route in the UPDATE message propagates across the be included as the route in the UPDATE message propagates across the
network, i.e., it is transitive. network, i.e., it is transitive.
This information distributes a bit of link state topology information, This information distributes a bit of link state topology information,
concerning just the last hop before the destination network's AS, into concerning just the last hop before the destination network's AS, into
the usual BGP distance vector (some say "path vector") protocol. Each the usual BGP distance vector (some say "path vector") protocol. Each
BGP speaker, even those who are transit only and originate no UPDATE BGP speaker will propogate this "predecessor" information. Any BGP
messages with NLRI contained in their own AS, will transmit this speaker could use the signed predecessor information received to verify
"predecessor" information. From all the signed predecessor information that each of the adjacencies represented in an AS_PATH is legitimate.
received, it would be possible to verify that each of the adjacencies That is, when a segment of an AS_PATH is a sequence, each adjacent pair
represented in an AS_PATH is legitimate. When a segment of an AS_PATH in the sequence could be verified to correspond to a received signed
is a sequence, each adjacent pair in the sequence must correspond to a predecessor tuple.
received signed predecessor tuple.
The protection provided by the signed predecessor information becomes The protection provided by the signed predecessor information becomes
more difficult to use past an aggregation point where a BGP speaker more difficult to use past an aggregation point where a BGP speaker
advertises a less specific route which includes the NLRI. In advertises a less specific route which includes the originated NLRI. In
particular, the rules for verifying an AS_PATH containing a segment that particular, the rules for verifying an AS_PATH containing a segment that
is a set would be either very lenient or very complex. is a set would be either very lenient or very complex.
While this predecessor information assures that each adjacency in a While this predecessor information assures that each adjacency in a
sequence of an AS_PATH is valid, it does not ensure that the AS_PATH as sequence of an AS_PATH is valid, it does not ensure that the AS_PATH as
a whole is valid. Each AS's decision regarding routes it will advertise a whole is valid. Each AS's decision regarding routes it will advertise
and traffic it will transit is individual and totally unconstrained. and traffic it will transit is individual and totally unconstrained.
The fact that a valid path of ASs exists to a destination does not The fact that a valid path of ASs exists to a destination does not
ensure that the corresponding AS_PATH is valid. This mechanism also ensure that the corresponding AS_PATH is valid. This mechanism also
does not assure that any information which comes from one router alone does not assure that any information which comes from one router alone
(LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. A router, then, (LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. A router, then,
can still falsely announce that its neighbor should be forwarded the can still falsely announce that its neighbor should be forwarded the
traffic for an NLRI. traffic for an NLRI.
3.5. Sign Originating AS and AS_PATH 3.5. Sign Originating AS and AS_PATH
A protection against possibly faulty BGP speakers that does provide some A protection against possibly faulty BGP speakers that does provide some
assurance that the AS_PATH is valid involves digital signatures of assurance that the AS_PATH is valid is described in [9]. The protection
nested prefixes of the AS_PATH, carried in a path attribute. requires digital signatures of nested prefixes of the AS_PATH, carried
in a transitive path attribute.
Each BGP speaker would receive signed route information (including the Each BGP speaker would receive signed route information (including the
AS_PATH, the ATOMIC_AGGREGATE attribute and NLRI) from its peer. The AS_PATH, the ATOMIC_AGGREGATE attribute and NLRI) from its peer. The
signature represents permission from the peer for the speaker to signature represents permission from the peer for the speaker to
advertise the route. After making its routing decision, the BGP speaker advertise the route. After making its routing decision, the BGP speaker
would augment the chosen AS_PATH with its own AS and sign the resulting would augment the chosen AS_PATH with its own AS and sign the resulting
route (NLRI + AS_PATH) and ATOMIC_AGGREGATE. The BGP speaker would pass route (NLRI + AS_PATH) and ATOMIC_AGGREGATE. The BGP speaker would pass
to its peers the augmented AS_PATH, its signature, and the signature it to its peers the augmented AS_PATH, its signature, and the signature it
received from its peer which covers the received AS_PATH. The neighbor received from its peer which covers the received AS_PATH. The neighbor
receiving this information can verify that the received AS_PATH was receiving this information can verify that the received AS_PATH was
indeed constructed from an authentic path, by verifying the signature of indeed constructed from an authorized path, by verifying the signature
the BGP speaker's peer over the tail of the received AS_PATH. The BGP of the BGP speaker's peer over the tail of the received AS_PATH. The
speaker's signature will be passed on by the neighbor to provide similar BGP speaker's signature will be passed on by the neighbor to provide
assurance that it constructed its advertised AS_PATH legitimately. similar assurance that it constructed its advertised AS_PATH
legitimately.
A BGP speaker could snip out a suffix of the data it received as well as
the associated signatures and pass those on as the proof that its
AS_PATH was based on reality. To prevent this, the signatures generated
must cover not only the route information but the intended receiver as
well.
This procedure as described protects against one consecutive faulty This procedure as described protects against one consecutive faulty
router in the path. If it is desired to protect against more than one router in the path. If it is desired to protect against more than one
possibly faulty routers in the path, then the procedure can be nested possibly faulty routers in the path, then the procedure can be nested
arbitrarily. To protect against K consecutive faulty routers, each arbitrarily. To protect against K consecutive faulty routers, each
router would receive signed AS_PATH information from its neighbor along router would receive signed AS_PATH information from its neighbor along
with K signatures of the preceding K BGP speakers in the path, each with K signatures of the preceding K BGP speakers in the path, each
successive signature covering a shorter suffix of the AS_PATH. It would successive signature covering a shorter suffix of the AS_PATH. It would
pass on a newly constructed AS_PATH along with its own signature, its pass on a newly constructed AS_PATH along with its own signature, its
neighbor's signature and K-1 of the included nested signatures. neighbor's signature and K-1 of the included nested signatures.
A BGP speaker could snip out a suffix of the data it received as well as For example, consider a case where it was decided to protect against two
the associated signatures and pass those on as the proof that its faulty BGP speakers. Suppose AS1 receives an AS_PATH from AS2 of 'AS2
AS_PATH was based on reality. To prevent this, the signatures generated AS3 AS4 ... ASk'. (In this discussion as well as the next,
should cover not only the route information but the intended receiver as
well.
For example, consider a case where it was decided to protect against
only one faulty BGP speaker. Suppose AS1 receives an AS_PATH from AS2
of 'AS2 AS3 ... ASk'. (In this discussion as well as the next,
ATOMIC_AGGREGATE would be included in the signature, but is omitted for ATOMIC_AGGREGATE would be included in the signature, but is omitted for
brevity.) Then AS1 should also receive AS2's signature of "AS1, 'AS2 brevity.) Then AS1 should also receive AS2's signature of "AS1, 'AS2
AS3 ... ASk', Ni" and AS3's signature of "AS2, 'AS3 ... ASk', Ni". AS1 AS3 ... ASk', NLRI" as well as AS3's signature of "AS2, 'AS3 ... ASk',
would verify the authenticity of AS2's route by verifying AS3's NLRI" and AS4's signature of "AS3, 'AS4 ... ASk', NLRI". AS1 would
signature. verify the authenticity of AS2's route by verifying the authorizing
signatures from AS3 and AS4.
AS1 would compute a path as 'AS1 AS2 AS3 ... ASk', and pass this path on
to AS0 this path along with its signature of "AS0, 'AS1 AS2 AS3 ...
ASk', Ni" and AS2's signature of "AS1, 'AS2 AS3 ... ASk', Ni".
The procedure in its full glory is as follows, where sign(A,B,C)[ASk]
means the signature of the data A,B,C generated with the key belonging
to ASk:
Given that it has been decided to protect against K faulty BGP
speakers:
When AS0 receives an UPDATE with AS_PATH 'ASi ... ASj' for NLRI N,
it
- verifies the signature from the UPDATE:
sign(AS0,'ASi ... ASj', N)[ASi],
this is a sanity check
- verifies the K signatures from the UPDATE:
sign(ASi,'ASi+1 ... ASj', N)[ASi+1],
sign(ASi+1,'ASi+2 ... ASj', N)[ASi+2], ... ,
sign(ASi+K-1, 'ASi+K ... ASj', N)[ASi+K]
If any signature fails to validate, then ASi did not have a
valid basis for the route sent to AS0. AS0 should drop the
route.
When AS0 chooses the AS_PATH 'ASi ... ASj' for NLRI N to send to
its neighbor ASn, it
- signs (ASn, 'AS0 ASi ... ASj', N)[AS0] and includes it in the
UPDATE
- sends the K signatures in the UPDATE:
sign(AS0,'ASi ... ASj', N)[ASi], AS1 uses AS2's signature in authorizing its own announcements. AS1
sign(ASi,'ASi+1 ... ASj', N)[ASi+1], ... , would compute a path as 'AS1 AS2 AS3 ... ASk', and pass to its neighbor
sign(ASi+K-2, 'ASi+K-1 ... ASj', N)[ASi+K-1] AS0 this path along with its signature of "AS0, 'AS1 AS2 AS3 ... ASk',
NLRI" and the authorizing signatures of AS2 and AS3.
Because the intended recipient is included in the signature, each BGP Because the intended recipient is included in the signature, each BGP
speaker with N peers generates N signatures for each route announced, speaker with N peers generates N signatures for each route announced,
one for each peer. one for each peer.
This discussion is predicated on the use of asymmetric cryptography. This discussion is predicated on the use of asymmetric cryptography.
Each autonomous system would be required to possess an asymmetric key Each autonomous system would be required to possess an asymmetric key
pair. The public key would have to be accessible to all recipients of pair. The public key would have to be accessible to all recipients of
the digital signature. The private key would have to be available to the digital signature. The private key would have to be available to
all BGP speakers in the autonomous system, but protected from exposure. all BGP speakers in the autonomous system, but protected from exposure.
Alternatively, each BGP speaker could possess its own asymmetric key
pair, at the cost of further complicating the protocol. The protocol
would have to be altered to include the identity of the BGP speaker
within the AS who produces the AS_PATH and signature so that the
signature verification procedure could choose the correct public key to
use.
Symmetric cryptography could be used to protect the information by using
a keyed cryptographic hash instead of a digital signature. However, in
order to provide the same level of protection against faulty routing,
each BGP speaker would have to share a different secret key with each of
its neighbors and each of its neighbors' neighbors. For N peers, each
with M peers, this means N*M+N keys and N*M+M keyed cryptographic hashes
of each update. (In the case that it is desired to protect against k>1
faulty BGP speakers, the number of keys would grow exponentially - a
different key with all neighbors, 2-hops-away neighbors, 3-hops-away
neighbors, and k+1-hop-away neighbors.) This is obviously not a
scalable solution. It may also require autonomous systems to reveal
their peering agreements where they would not wish to do so.
3.5.1. Special Considerations 3.5.1. Remaining Issues
Note that this scheme becomes more complicated when one of the BGP This scheme becomes more complicated when one of the BGP speakers
speakers performs aggregation of a set of routes. To assure recipients performs aggregation of a set of routes. To assure recipients of the
of the validity of the aggregated route, it would be necessary to pass validity of the aggregated route, it would be necessary to pass on the
on the text and signatures of each of the aggregated component routes. text and signatures of each of the aggregated component routes. This
This means an enormous increase in transmission bandwidth at each means an enormous increase in transmission bandwidth at each aggregation
aggregation point and a similar increase in verification time at each point and a similar increase in verification time at each verification
verification point's peers. This cost would not have to be passed on to point's peers. This cost would not have to be passed on to further
further neighbors further than K (the nesting level of signatures) hops neighbors further than K (the nesting level of signatures) hops away,
away, but it does violate the spirit of aggregation. Alternatively, an but it does violate the spirit of aggregation. Alternatively, an
aggregation point could be treated as another type of origination point, aggregation point could be treated as another type of origination point,
and signatures and verification would stop at that point. and signatures and verification would stop at that point.
Unfortunately, that provides a mechanism for malicious BGP peers to Unfortunately, that provides a mechanism for malicious BGP peers to
announce bogus routes, simply by claiming to have aggregated the announce bogus routes, simply by claiming to have aggregated the
information. Aggregation also prevents identification of the specific information. Aggregation also prevents identification of the specific
culprit should it be discovered that a network is being originated in culprit should it be discovered that a network is being originated in
error. error.
Note that this scheme does not assure that the received route is the Neither this scheme nor the Origination and Adjacency Protection assures
best route the peer could have computed. In particular, it does not that the received route is the best route the peer could have computed.
guard against a peer that does not announce the best result of its In particular, it does not guard against a peer that does not announce
decision process - for example, a peer that replays previous the best result of its decision process - for example, a peer that
announcements instead of forwarding a withdrawal, or does not change its replays previous updates instead of forwarding a withdrawal, or does not
announcements when it receives withdrawn routes, or replays withdrawal change its announcements when it receives withdrawn routes, or replays
information after a route is reestablished. These are a matter for the withdrawal information after a route is reestablished, or replays an
update after having forwarded a withdrawal. These are a matter for the
internal correct operation of the router and cannot be precluded by internal correct operation of the router and cannot be precluded by
security protection. This mechanism also does not assure that any authentication or authorization protection. This mechanism also does
information which comes from one router alone (LOCAL_PREF, NEXT_HOP, not assure that any information which comes from one router alone
AGGREGATOR, etc.) is accurate. With these fields, a router can still (LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. With these
falsely announce that its neighbor should be forwarded the traffic for fields, a router can still falsely announce that its neighbor should be
an NLRI. forwarded the traffic for an NLRI.
Note that the verification process chooses the key to use based on the The verification process chooses the key to use based on the AS's
AS's mentioned in the AS_PATH. If it is valid for a BGP speaker not to mentioned in the AS_PATH. If implementations do not verify that the
prepend its own AS to the AS_PATH before transmitting it to a peer, i.e. peer BGP speaker prepended its own AS to the AS_PATH, i.e. if a BGP
if a BGP speaker is allowed to pass on an AS_PATH in which it's own AS speaker might pass on an AS_PATH in which it's own AS is not the first
is not the first in the PATH, then the AS's mentioned in the AS_PATH are in the PATH, then the AS's mentioned in the AS_PATH are not necessarily
not necessarily the AS's that produced the signature. In that case, the AS's that produced the signature. In that case, this verification
this verification process could be using the wrong key. This signature process could be using the wrong key. This signature scheme would have
scheme would have to be complicated by requiring either to be complicated by requiring either
that the sender's AS be included in the UPDATE message and the
- that the sender's AS be included in the UPDATE message and the
signature (so that the verification process could find the signature (so that the verification process could find the
appropriate key for the signature) appropriate key for the signature)
or that each sender know the private key of the first AS in the - or that each sender know the private key of the first AS in the
AS_PATH (so that the signature and verification processes would be AS_PATH (so that the signature and verification processes would be
using the same key). using the same key).
Sharing keys between AS's makes those AS's indistinguishable to the Sharing keys between AS's makes those AS's indistinguishable to the
cryptography; the second alternative design should only be chosen with cryptography; the second alternative design should only be chosen with
that caution clearly understood. that caution clearly understood.
3.6. Rely on Registries 3.6. Filtering
The Internet registries can provide data that will help to assure that The Internet registries can provide data that will help to assure that
AS_PATHS and NLRI origination data are correct. If the data registered AS_PATHS and NLRI origination data are authorized. If the data
in the Internet registries can be assumed to be correct, then an NLRI registered in the Internet registries is available, then an NLRI
origination can be verified against the registry. Also, peering origination can be verified against the registry. Also, peering
information in the database can be used to verify each pair of AS's in information in the registry can be used to verify that the AS_PATH as a
an AS_PATH sequence segment are truly peers. Depending on the whole was valid.
sophistication of the information recorded in the registry, the
registries might also be used to verify that the AS_PATH as a whole was
valid.
The assurance provided by this protection would rely on the completeness The assurance provided by this protection would rely on the registry
of the registry, on the authenticity of the registry data and on the data being:
protection it received in storage and transit. The protection is useful
if data from the registry is either available locally or retrievable
with an acceptable lag time.
The assurance provided by this protection also relies on the openness of complete: AS's that do not register their peering relationships or
the data recorded in the registries. To be truly useful, each assigned networks would hamper the ability to protect the BGP data.
autonomous system's policy would have to be recorded in the registry, in
order that the AS_PATH as a whole can be verified to be valid. accurate: AS's must register peering relationships that exactly
Information about policy, however, can be sensitive to an autonomous match their policies. If the peering relationships are described
system and not openly available to every other autonomous system. Any too broadly, bogus routes will pass the filter. If the peering
restrictions on the availability of information stored in the registry relationships are described too narrowly, legitimate routes will
will restrict its applicability as a protection mechanism. fail.
timely: Additions and changes to the registry data must be
communicated to the AS's in a timely manner.
secure: The registries must be known to ensure the authenticity,
integrity and authorization of provided information while in
storage and in transmission to an AS.
The assurance provided by this protection relies on the openness of the
data recorded in the registries. To be truly useful, each autonomous
system's policy would have to be recorded in the registry, in order that
the AS_PATH as a whole can be verified to be valid. Information about
policy, however, can be sensitive to an autonomous system and not openly
available to every other autonomous system. Any restrictions on the
availability of information stored in the registry will restrict its
applicability as a protection mechanism.
Filtering based on the registries can also not ensure the authenticity
of the received routes. The registries currently contain permitted
routes, not necessarily the current forwarding routes. If, for example,
an AS will accept the same network from multiple peer, with one route to
serve as a backup, filtering based on the registry would not be able to
distinguish which is the route currently in use.
4. Security Costs 4. Security Costs
Choosing the protection to apply in any situation depends on the Choosing the protection to apply in any situation depends on the
perception of the risk of attack, of the damage that can result, of the perception of the risk of attack, of the damage that can result, of the
benefits derived from providing the protection, and of the cost of benefits derived from providing the protection, and of the cost of
providing the protection. This section discusses the cost of each of providing the protection. This section discusses the cost of each of
the protection options mentioned above. the protection options mentioned above.
4.1. Protecting the Peer-Peer Link 4.1. Protecting the Peer-Peer Link
The cost of this protection is the processing required for the The cost of this protection is the processing required for the
cryptography and the need to establish and manage the cryptographic cryptography and the need to establish and manage the cryptographic
keys. The cryptography need not be computationally expensive; HMAC or keys. The cryptography need not be computationally expensive; HMAC or
similar algorithms can be used. Shared secret keys are adequate for similar algorithms can be used. Shared secret keys are adequate for
this protection, as the protection applies only to the communication this protection, as the protection applies only to the communication
between peers, so the key management cost is low. Ideally, a separate between peers, so the key management cost is low. A separate key must
key should be used for each BGP peering. One key might be used for be used for each BGP peering. Using one key for multiple peerings even
multiple peerings with a reduction in the level of protection that is at a peering point reduces the level of protection that is provided.
provided. However, it is best to remember that apocryphally, the more
places know a secret, the more chances it will be exposed.
This level of protection is low cost and protects against the vast This level of protection is low cost and protects against the vast
number of possible adversaries (i.e., any non-BGP speaker in the number of outsiders who pose a threat.
internet).
4.2. Sign Originating AS 4.2. Origination Protection
The cost of signing the originating AS of each route is the cost of The cost of signing the originating AS of each route is the cost of the
providing a public key infrastructure to generate an asymmetric key pair processing required for the cryptography -- generating and verifying
for each autonomous system and to distribute and maintain the public digital signatures -- as well as the need to establish and manage the
keys associated with each autonomous system. cryptographic keys. For digital signatures, establishing and managing
the cryptographic keys means providing a public key infrastructure to
generate an asymmetric key pair for each autonomous system and to
distribute and maintain certifications of the public keys associated
with each autonomous system.
4.3. Sign Originating AS and Predecessor Information While the key distribution and signature generation and verification
provides for authentication and integrity of the messages, there is also
a need to ensure the authorization of the origination. This requires
another infrastructure that would provide certifications of the
authority of an AS to originate a route to a network.
This scheme requires the same public key infrastructure as is needed if The infrastructures required for authentication of AS messages and for
one simply signs the originating AS information. It also requires that authorization of origination information might be colocated. The
each adjacency for a BGP speaker be signed (the "predecessor" establishment and secure operation of the security infrastructure as
well as the cost of secure communication with the infrastructure are
additional costs of this technique.
4.3. Origination and Adjacency Protection
This scheme requires the same public key infrastructure and origination
infrastructure as is needed for Origination Protection It also requires
that each adjacency for a BGP speaker be signed (the "predecessor"
information) and transmitted along with an AS_PATH. Essentially, each information) and transmitted along with an AS_PATH. Essentially, each
BGP speaker must announce its peers, something that does not currently BGP speaker must announce its peers, something that does not currently
occur in the BGP protocol. Each BGP speaker must compute one signature occur in the BGP protocol.
for each NLRI in each UPDATE message transmitted and must verify one
signature for each NLRI in each UPDATE message received. (Each UPDATE Each BGP speaker must compute one signature for each NLRI in each UPDATE
message must be separately signed because the mechanism described in [2] message transmitted and must verify one signature for each NLRI in each
includes a sequence number, the Withdrawn Routes and the Unfeasible UPDATE message received. Each UPDATE message must be separately signed
Route Length fields, so the information to be signed changes with each because the mechanism described in [3] includes a sequence number, the
message. These fields are protected from non-BGP peers by the peer-peer Withdrawn Routes and the Unfeasible Route Length fields, so the
communication protection and so do not need to be digitally signed. If information to be signed changes with each message. (These fields are
only the NLRI, ATOMIC_AGGREGATE and predecessor information were signed protected from outsiders by the peer-peer communication protection and
each time, then the signature might not have to be computed with each so do not need to be digitally signed. If only the NLRI,
new UPDATE message, i.e., AS_PATH changes would not induce new signature ATOMIC_AGGREGATE and predecessor information were signed each time, then
computations.) The predecessor information in each route must be stored the signature might not have to be computed with each new UPDATE
by the recipient indefinitely. Each route received must be verified by message, i.e., AS_PATH changes would not induce new signature
computations.)
The signed predecessor information in each route must be stored by the
recipient indefinitely. Each route received must be verified by
comparison to the store of predecessor information previously received comparison to the store of predecessor information previously received
in UPDATE messages from all AS sources. in UPDATE messages from all AS sources.
4.4. Sign Originating AS and AS_PATH 4.4. Origination and AS_PATH Protection
This scheme requires the same public key infrastructure as is needed if The operational cost of this scheme is described in detail in [10].
one simply signs the originating AS information. For each UPDATE
message received, K signatures (the level of protection from consecutive This scheme requires the same public key infrastructure and origination
faulty routers) must be verified per NLRI included in the UPDATE. For infrastructure as is needed for Origination Protection.
each UPDATE message transmitted, one signature must be computed for each
NLRI per recipient. As discussed before, prevention of cut and paste For each UPDATE message received, K signatures (where K is the level of
attacks requires that the signature include the recipient, so computing protection desired from consecutive faulty routers) must be verified.
one signature per AS_PATH and NLRI announced is insufficient.
For each UPDATE message transmitted, one signature must be computed for
each NLRI per recipient. As discussed before, prevention of cut and
paste attacks requires that the signature include the recipient, so
computing one signature per AS_PATH and NLRI announced is insufficient.
The signatures contained in an UPDATE must be retained for all received
routes in case the route is ever chosen and announced to the peers.
This increases the size of the routing tables.
For efficiency in situations where route flapping is occuring, withdrawn
AS_PATHs and their signatures could be retained. This would mean that
new announcements of flapped routes still retained would not require new
signature verifications.
4.5. Rely on Registries 4.5. Rely on Registries
The cost of relying on registries would vary considerably depending on The cost of relying on registries would vary considerably depending on
the protection provided to the information in storage and in transit. the protection provided to the information in storage and in transit.
Any latency, above that caused by the use of cryptography, would depend Any latency, above that caused by the use of cryptography, would depend
on the mechanism used to protect the registry information (e.g., on the mechanism used to transmit the registry information (e.g.,
anything from frequent complete download to real-time query and anything from frequent complete download to real-time query and
response). response).
5. Authentication vs Authorization 5. Security Considerations
5.1. Authentication without Authorization
Each of the schemes described above provide authentication of the
information received. This is not sufficient for secure operation - the
BGP participants also need assurance that a BGP announcing a route is
authorized to announce that route. Signing the predecessor information,
nesting signatures of the AS_PATH, or consulting the registry for AS
peering arrangements help to show that a BGP speaker has a valid
authority for announcing a route by demonstrating either that the
connectivity exists or that the speaker based its route on a valid route
from its peer. However, none of the schemes provide any assurance that
a BGP speaker originating an NLRI is authorized to advertise that NLRI.
Authorization implies an authority to which one can refer. To prove the
authority to originate an NLRI, there must be an infrastructure for
assigning NLRI to autonomous systems. The Internet registries could
serve as this authority, providing the registry itself contained valid
information, the communication with the registry was secure, etc. Work
is ongoing to provide assurance about information contained in the
registries using RPS [5]. Other proposals suggest using the DNS inverse
lookup tree as a distributed mechanism for maintaining authorization
information [6].
5.2. Authorization without Authentication
Schemes have been proposed to provide authorization for AS announcements
of NLRI. As mentioned above, work is ongoing to provide for
authorization and authentication of network assignments to autonomous
systems, of peering agreements, transit policies, etc., for those
Internet registries employing the RPS [5]. Another scheme proposes to
use the DNS reverse lookup tree, CNAMES and a new AS resource record to
associate networks with autonomous systems [6]. These mechanisms
provide assurance that the AS announcing an NLRI is authorized to do so,
but they will not provide assurance of the authenticity of the source of
the announcement. Both schemes provide protection against misconfigured
or faulty BGP speakers accidentally announcing bogus direct connections
to NLRI, but not against malicious BGP speakers making deliberate bogus
announcements. Protected Internet registries can also be used to verify
authorization for AS_PATH information, as long as autonomous systems
maintain complete information of their peering agreements and transit
policies in the registries.
5.2.1. Authentication and Authorization
In their Secure Border Gateway Protocol [10], BBN has combined
authentication and authorization protection. Their work includes use of
IPSEC for peer-peer protection of authenticity, integrity and replay of
BGP messages. Their work incorporates signed authorization of NLRI
originations ("address attestations") into each UPDATE message.
Verification of this signature uses an infrastructure of a hierarchy of
signed authorizations for address blocks up to the IANA. Their work
also includes protection of the AS_PATH information using signatures of
nested prefixes of the path ("route attestations") -- much as in section
3.5.
Their technique differs from that presented in section 3.5 in that they
use one signature per update covering the entire NLRI block rather than
one signature per NLRI in the block. When a transmitted NLRI block is
not the same as the incoming NLRI block (perhaps the router would use
the AS_PATH for only some of the NLRI in the block), the incoming NLRI
block must be included in the transmitted UPDATE so that the nested
signatures can be verified.
Signing the NLRI block saves the time, bandwidth and storage associated
with the signing of each individual NLRI in the block but requires
additional bandwidth and storage space for forwarding the included NLRI.
It also requires an additional check in the verification process to see
if each NLRI is present in each included NLRI block. In most cases, the
one signature is much less costly than the multiple signatures.
6. Security Considerations
This entire memo is about security considerations. This entire memo is about security considerations.
7. References 6. References
[1] RFC1771, A Border Gateway Protocol 4 (BGP-4). Y. Rekhter & T. Li. [1] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
March 1995. RFC1771, March 1995.
[2] B. Smith and J.J. Garcia-Luna-Aceves, ``Securing the Border Gateway [2] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", work
Routing Protocol,'' Proc. Global Internet'96, London, UK, 20-21 in progress, November 2001. available as
<<draft-ietf-idr-bgp4-15.txt>> at Internet-Draft shadow sites.
[2] B. Smith and J.J. Garcia-Luna-Aceves, "Securing the Border Gateway
Routing Protocol", Proc. Global Internet'96, London, UK, 20-21
November 1996. November 1996.
[3] Bruce Schneier. Applied Cryptography Protocols, Algorithms, and [3] Bruce Schneier. Applied Cryptography Protocols, Algorithms, and
Source Code in C, John Wiley & Sons, Inc 1994. Source Code in C, John Wiley & Sons, Inc 1994.
[4] RFC 1583, OSPF Version 2. John Moy. March 1994. [4] John Moy, "OSPF Version 2", RFC 1583, March 1994.
[5] Curtis Villamizar, Cenzig Alaettinoglu, David Meyer, Sandy
Murphy and Carol Orange. "Routing Policy System Security", Apr
22, 1999. Work in progress, available as <<draft-ietf-rps-
auth-03.txt>> at Internet-Drafts Shadow Directories.
[6] Tony Bates, Randy Bush, Tony Li and Yakov Rekhter. "DNS-based NLRI [5] C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy and C. Orange,
origin AS verification in BGP", February 6, 1998. Work in "Routing Policy System Security", RFC 2725, December, 1999.
progress, available as <<draft-bates-bgp4-nlri-orig-verif-00.txt>>
at Internet-Drafts Shadow Directories.
[7] RFC1826, IP Authentication Header. R. Atkinson. August 1995. [7] S. Kent and R.Atkinson, "Security Architecture for the Internet
Protocol", RFC2401, November 1998.
[8] RFC2385, Protection of BGP Sessions via the TCP MD5 Signature [8] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature
Option. A. Heffernan. August 1998. Option", RFC2385, August 1998.
[9] T. Przygienda, "BGP-4 MD5 Authentication", 5 November 1997. Work [10] S.Kent, C.Lynn, and K. Seo, "Secure Border Gateway Protocol
in progress, available as <<draft-przygienda-bgp-md5-00.txt>> at (Secure-BGP)", IEEE Journal on Selected Areas in Communications,
Internet-Drafts Shadow Directories. Vol. 18, No. 4, April 2000, pp. 582-592.
[10] S. Kent, C. Lynn, L. Sanchez, M. Steenstrup, M. Casagni, K. Seo. [10] S. Kent, C. Lynn, J. Mikkelson, and K. Seo, "Secure Border Gateway
Secure Border Gateway Protocol. August 1998. Protocol (S-BGP) -- Real World Performance and Deployment Issues",
http://www.net-tech.bbn.com/sbgp/sbgp-index.html Proceedings of the IEEE Network and Distributed System Security
Symposium (NDSS 2000), February 2000.
8. Author's Address 7. Author's Address
Sandra Murphy Sandra Murphy
Network Associates, Inc. Network Associates, Inc.
NAI Labs NAI Labs
3060 Washington Road 3060 Washington Road
Glenwood, MD 21738 Glenwood, MD 21738
EMail: Sandy@tislabs.com EMail: Sandy@tislabs.com
A. Appendix A - Vulnerabilities and Risks A. Appendix A - Vulnerabilities and Risks
Each message introduces certain different vulnerabilities and risks: Each message introduces certain different vulnerabilities and risks:
skipping to change at page 19, line 22 skipping to change at page 18, line 22
release of all resources and deletion of all associated routes, the release of all resources and deletion of all associated routes, the
ability to spoof this message can lead to a severe disruption of ability to spoof this message can lead to a severe disruption of
routing. routing.
A.2. KEEPALIVE A.2. KEEPALIVE
Receipt of a KEEPALIVE message when the peering connection is in the Receipt of a KEEPALIVE message when the peering connection is in the
OpenSent state can lead to a failure to establish a connection. The OpenSent state can lead to a failure to establish a connection. The
ability to spoof this message is a vulnerability. To exploit this ability to spoof this message is a vulnerability. To exploit this
vulnerability deliberately, the KEEPALIVE must be carefully timed in the vulnerability deliberately, the KEEPALIVE must be carefully timed in the
sequence of messages exchanged between the peers or it causes no damage. sequence of messages exchanged between the peers; otherwise, it causes
no damage.
A.3. NOTIFICATION A.3. NOTIFICATION
Receipt of a NOTIFICATION message will cause the close of the BGP Receipt of a NOTIFICATION message will cause the close of the BGP
peering session and thereby induce the release of all resources and peering session and thereby induce the release of all resources and
deletion of all associated routes. Therefore, the ability to spoof this deletion of all associated routes. Therefore, the ability to spoof this
message can lead to a severe disruption of routing. message can lead to a severe disruption of routing.
A.4. UPDATE A.4. UPDATE
skipping to change at page 20, line 7 skipping to change at page 19, line 7
There is a vulnerability arising from the ability to modify these There is a vulnerability arising from the ability to modify these
fields. If a length is modified, the message is not likely to parse fields. If a length is modified, the message is not likely to parse
properly, resulting in an error, the transmission of a NOTIFICATION properly, resulting in an error, the transmission of a NOTIFICATION
message and the close of the connection. As a true BGP speaker is message and the close of the connection. As a true BGP speaker is
always able to close a connection at any time, this vulnerability always able to close a connection at any time, this vulnerability
represents an additional risk only when the source is a non-BGP speaker, represents an additional risk only when the source is a non-BGP speaker,
i.e., it presents no additional risk from BGP sources. i.e., it presents no additional risk from BGP sources.
A.4.2. Withdrawn Routes A.4.2. Withdrawn Routes
A non-BGP peer could cause the elimination of existing legitimate routes An outsider could cause the elimination of existing legitimate routes by
by forging or modifying this field. A non-BGP peer could also cause the forging or modifying this field. An outsider could also cause the
elimination of reestablished routes by replaying this withdrawal elimination of reestablished routes by replaying this withdrawal
information from earlier packets. information from earlier packets.
A BGP speaker could "falsely" withdraw feasible routes using this field. A BGP speaker could "falsely" withdraw feasible routes using this field.
However, as the BGP speaker is authoritative for the routes it will However, as the BGP speaker is authoritative for the routes it will
announce, it is allowed to withdraw any previously announced routes that announce, it is allowed to withdraw any previously announced routes that
it wants. As the receiving BGP speaker will only withdraw routes it wants. As the receiving BGP speaker will only withdraw routes
associated with the sending BGP speaker, there is no opportunity for a associated with the sending BGP speaker, there is no opportunity for a
BGP speaker to withdraw another BGP speaker's routes. Therefore, there BGP speaker to withdraw another BGP speaker's routes. Therefore, there
is no additional vulnerability from BGP peers via this field. is no additional risk from BGP peers via this field.
A.4.3. Path Attributes A.4.3. Path Attributes
The path attributes present many different vulnerabilities and risks. The path attributes present many different vulnerabilities and risks.
Attribute Flags, Attribute Type Codes, Attribute Length Attribute Flags, Attribute Type Codes, Attribute Length
A BGP peer or a non-BGP peer could modify the attribute length or A BGP peer or an outsider could modify the attribute length or attribute
attribute type (flags and type codes) so they did not reflect the type (flags and type codes) so they did not reflect the attribute values
attribute values that followed. If the length were modified, the likely that followed. If the flags were modified, the flags and type code
result would be that the UPDATE message would not parse correctly. If could become incompatible (i.e., a mandatory attribute marked as
the flags were modified, the flags and type code could become partial), or a optional attribute could be interpreted as a mandatory
incompatible (i.e., a mandatory attribute marked as partial), or a attribute or vice versa. If the type code were modified, the attribute
optional attribute could be interpreted as a mandatory attribute or vice value could be interpreted as if it were the data type and value of a
versa. Modifying the type code could cause the attribute value to be different attribute.
interpreted as if it were the data type and value of a different
attribute. The most likely result from modifying the attribute flags or The most likely result from modifying the attribute length, flags, or
type code would be a parse error of the UPDATE message. A parse error type code would be a parse error of the UPDATE message. A parse error
from any modification would cause the transmission of a NOTIFICATION would cause the transmission of a NOTIFICATION message and the close of
message and the close of the connection. As a true BGP speaker is the connection. As a true BGP speaker is always able to close a
always able to close a connection at any time, this vulnerability connection at any time, this vulnerability represents an additional risk
represents an additional risk only when the source is a non-BGP peer, only when the source is an outsider, i.e., it presents no additional
i.e., it presents no additional risk from BGP peer. risk from a BGP peer.
ORIGIN ORIGIN
This field indicates whether the information was learned from IGP or EGP This field indicates whether the information was learned from IGP or EGP
information. If the route is used in inter-AS multicast routing, a information. If the route is used in inter-AS multicast routing, a
values of INCOMPLETE may be used. This field is not used in making value of INCOMPLETE may be used. This field is not used in making
routing decisions, so there are no vulnerabilities arising from this routing decisions, so there are no vulnerabilities arising from this
field, either from BGP peers or non-BGP peers. field, either from BGP peers or outsiders.
AS_PATH AS_PATH
A BGP peer or non-BGP peer could announce an AS_PATH that was not A BGP peer or outsider could announce an AS_PATH that was not accurate
accurate for the associated NLRI. Forwarding for the NLRI associated for the associated NLRI. Forwarding for the NLRI associated with the
with the AS_PATH could potentially be induced to follow a sub-optimal AS_PATH could potentially be induced to follow a sub-optimal path, a
path, a path that did not follow some intended policy, or even a path path that did not follow some intended policy, or even a path that would
that would not forward the traffic. If the path would not forward the not forward the traffic. If the path would not forward the traffic, the
traffic, the NLRI would become unreachable for that portion of the NLRI would become unreachable for that portion of the Internet that
Internet that accepted the false path. If much traffic is mis-directed, accepted the false path. If much traffic is mis-directed, some routers
some routers and transit networks along the announced route could become and transit networks along the announced route could become flooded with
flooded with the mis-directed traffic. the mis-directed traffic.
It is not clear how far an inaccurate AS_PATH could deviate from the It is not clear how far an inaccurate AS_PATH could deviate from the
true AS_PATH. It may be that the first AS in the AS_PATH, at least, true AS_PATH. It may be that the first AS in the AS_PATH, at least,
must be a legal hop. The RFC states that a BGP speaker prepends its own must be a legal hop. The RFC states that a BGP speaker prepends its own
AS to an AS_PATH before announcing it to a neighbor. If the BGP speaker AS to an AS_PATH before announcing it to a neighbor. If the BGP speaker
must prepend its own AS, then a BGP speaker that produced a bogus must prepend its own AS, then a BGP speaker that produced a bogus
AS_PATH could end up receiving the traffic for the associated NLRI. AS_PATH could end up receiving the traffic for the associated NLRI.
This could be desirable if the error was deliberate and the intent was This could be desirable if the error was deliberate and the intent was
to receive traffic that would not otherwise be received. Receiving the to receive traffic that would not otherwise be received. Receiving the
mis-routed traffic could be undesirable for the faulty BGP speaker if it mis-routed traffic could be undesirable for the faulty BGP speaker if it
were not prepared to handle the extra (mis-routed) traffic. So, if a were not prepared to handle the extra (mis-routed) traffic. So,
BGP peer must prepend its own AS to the AS_PATH, it might be encouraged requiring a BGP peer to prepend its own AS to the AS_PATH, might
or discouraged from inventing an arbitrary AS_PATH, depending on its encourage or discourage it from inventing an arbitrary AS_PATH,
resources and intent. If BGP peers need not prepend its own AS, then a depending on its resources and intent.
malicious BGP peer could announce a path that begins with the AS of any
BGP speaker with little impact on itself. If BGP peers need not prepend its own AS (or implementations do not
ensure that this is done), then a malicious BGP peer could announce a
path that begins with the AS of any BGP speaker with little impact on
itself.
Whether such an arbitrary AS_PATH is a vulnerability would depend on Whether such an arbitrary AS_PATH is a vulnerability would depend on
whether BGP implementations check the AS_PATH (to see if the first AS is whether BGP implementations check the AS_PATH (to see if the first AS is
the neighbor) and would catch the error. If there are legitimate the neighbor) and would catch the error. If there are legitimate
situations in which a BGP speaker could pass an AS_PATH to a neighbor situations in which a BGP speaker could pass an AS_PATH to a neighbor
without putting its own AS at the head of the AS_PATH, then there is no without putting its own AS at the head of the AS_PATH, then there is no
way for implementations to detect totally bogus AS_PATHs. way for implementations to detect totally bogus AS_PATHs.
Originating Routes Originating Routes
A special case of announcing a false AS_PATH occurs when the AS_PATH A special case of announcing a false AS_PATH occurs when the AS_PATH
advertises a direct connection to a specific network address. An BGP advertises a direct connection to a specific network address. An BGP
peer or non-BGP peer could disrupt routing to the network(s) listed in peer or outsider could disrupt routing to the network(s) listed in the
the NLRI field by falsely advertising a direct connection to the NLRI field by falsely advertising a direct connection to the network.
network. The NLRI would become unreachable to the portion of the The NLRI would become unreachable to the portion of the network that
network that accepted this false route, unless the ultimate AS on the accepted this false route, unless the ultimate AS on the AS_PATH
AS_PATH undertook to tunnel the packets it was forwarded for this NLRI undertook to tunnel the packets it was forwarded for this NLRI on toward
on toward their true destination AS by a valid path. But even when the their true destination AS by a valid path. But even when the packets
packets are tunneled to the correct destination AS, the route followed are tunneled to the correct destination AS, the route followed may not
may not be optimal or may not follow the intended policy. Additionally, be optimal or may not follow the intended policy. Additionally, routing
routing for other networks in the Internet could be affected if the for other networks in the Internet could be affected if the false
false advertisement fragmented an aggregated address block, forcing the advertisement fragmented an aggregated address block, forcing the
routers to handle (issue UPDATES, store, manage) the multiple fragments routers to handle (issue UPDATES, store, manage) the multiple fragments
rather than the single aggregate. False originations for multiple rather than the single aggregate. False originations for multiple
addresses can result in routers and transit networks along the announced addresses can result in routers and transit networks along the announced
route to become flooded with mis-directed traffic. route to become flooded with mis-directed traffic.
NEXT_HOP NEXT_HOP
The NEXT_HOP attribute defines the IP address of the border router that The NEXT_HOP attribute defines the IP address of the border router that
should be used as the next hop when forwarding the NLRI listed in the should be used as the next hop when forwarding the NLRI listed in the
UPDATE message. If the recipient is an external peer, then the UPDATE message. If the recipient is an external peer, then the
recipient and the NEXT_HOP address must share a subnet. It is clear recipient and the NEXT_HOP address must share a subnet. It is clear
that a non-BGP peer modifying this field could disrupt the forwarding of that an outsider modifying this field could disrupt the forwarding of
traffic between the two AS's. traffic between the two AS's.
In the case that the NEXT_HOP address is an inter-AS peer and the In the case that the recipient of the message is an external peer of an
recipient of the message is an inter-AS peer of a different AS (this is AS and the route was learned from another peer AS (this is one of two
one of two forms of "third party" NEXT_HOP), then the BGP speaker forms of "third party" NEXT_HOP), then the BGP speaker advertising the
advertising the route has the opportunity to direct the recipient to route has the opportunity to direct the recipient to forward traffic to
forward traffic to a BGP speaker (the NEXT_HOP peer) that may not be a BGP speaker at the NEXT_HOP addresss. This affords the opportunity to
able to continue forwarding the traffic. It is unclear whether this direct traffic at a router that may not be able to continue forwarding
would also require the advertising BGP speaker to construct an AS_PATH the traffic. It is unclear whether this would also require the
mentioning the NEXT_HOP inter-AS peer's AS. advertising BGP speaker to construct an AS_PATH mentioning the NEXT_HOP
external peer's AS.
MULTI_EXIT_DISC MULTI_EXIT_DISC
The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted
between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an
inter-AS peer may be propagated within an AS, it may not be propagated inter-AS peer may be propagated within an AS, it may not be propagated
to other AS's. Consequently, this field is only used in making routing to other AS's. Consequently, this field is only used in making routing
decisions internal to one AS. Modifying this field, whether by an non- decisions internal to one AS. Modifying this field, whether by an
BGP peer or an BGP peer, could influence routing within an AS to be sub- outsider or an BGP peer, could influence routing within an AS to be sub-
optimal, but the effect should be limited in scope. optimal, but the effect should be limited in scope.
LOCAL_PREF LOCAL_PREF
The LOCAL_PREF attribute must be included in all messages with internal The LOCAL_PREF attribute must be included in all messages with internal
peers and excluded from messages with external peers. Consequently, peers and excluded from messages with external peers. Consequently,
modification of the LOCAL_PREF could effect the routing process within modification of the LOCAL_PREF could effect the routing process within
the AS only. Note that there is no requirement in the BGP RFC that the the AS only. Note that there is no requirement in the BGP RFC that the
LOCAL_PREF be consistent among the internal BGP speakers of an AS. As LOCAL_PREF be consistent among the internal BGP speakers of an AS. As
BGP peers are free to choose the LOCAL_PREF as they wish, modification BGP peers are free to choose the LOCAL_PREF as they wish, modification
of this field is a vulnerability with respect to non-BGP peers only. of this field is a vulnerability with respect to outsiders only.
ATOMIC_AGGREGATE ATOMIC_AGGREGATE
The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way
has received a more specific and a less specific route to the NLRI and has received a more specific and a less specific route to the NLRI and
installed the aggregated route. This route cannot be de-aggregated installed the aggregated route. This route cannot be de-aggregated
because it is not certain that the route to more specific prefixes will because it is not certain that the route to more specific prefixes will
follow the listed AS_PATH. Consequently, BGP speakers receiving a route follow the listed AS_PATH. Consequently, BGP speakers receiving a route
with ATOMIC_AGGREGATE are restricted from making the NLRI any more with ATOMIC_AGGREGATE are restricted from making the NLRI any more
specific. Removing the ATOMIC_AGGREGATE attribute would remove the specific. Removing the ATOMIC_AGGREGATE attribute would remove the
restriction, possibly causing traffic intended for the more specific restriction, possibly causing traffic intended for the more specific
NLRI to be routed incorrectly. Adding the ATOMIC_AGGREGATE attribute NLRI to be routed incorrectly. Adding the ATOMIC_AGGREGATE attribute
when no aggregation was done would have little effect, beyond when no aggregation was done would have little effect, beyond
restricting the un-aggregated NLRI from being made more specific. This restricting the un-aggregated NLRI from being made more specific. This
vulnerability exists whether the source is a BGP peer or a non-BGP peer. vulnerability exists whether the source is a BGP peer or an outsider.
AGGREGATOR AGGREGATOR
This field may be included by a BGP speaker who has computed the routes This field may be included by a BGP speaker who has computed the routes
represented in the UPDATE message from aggregation of other routes. The represented in the UPDATE message from aggregation of other routes. The
field contains the AS number and IP address of the last aggregator of field contains the AS number and IP address of the last aggregator of
the route. It is not used in making any routing decisions, so it does the route. It is not used in making any routing decisions, so it does
not represent a vulnerability. not represent a vulnerability.
A.4.4. NLRI A.4.4. NLRI
By modifying or forging this field, either a non-BGP peer or BGP peer By modifying or forging this field, either an outsider or BGP peer
source could cause disruption of routing to the announced network, source could cause disruption of routing to the announced network,
overwhelm a router along the announced route, cause data loss when the overwhelm a router along the announced route, cause data loss when the
announced route will not forward traffic to the announced network, route announced route will not forward traffic to the announced network, route
traffic by a sub-optimal route, etc. traffic by a sub-optimal route, etc.
 End of changes. 94 change blocks. 
471 lines changed or deleted 436 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/