draft-ietf-idr-bgp-vuln-01.txt   rfc4272.txt 
none Sandra Murphy
INTERNET-DRAFT Sparta, Inc
Expires: April 13, 2005 October 2004
BGP Security Vulnerabilities Analysis
draft-ietf-idr-bgp-vuln-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions of
section 3 of RFC 3667. By submitting this Internet-Draft, each author
represents that any applicable patent or other IPR claims of which he or
she is aware have been or will be disclosed, and any of which he or she
become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Network Working Group S. Murphy
and may be updated, replaced, or obsoleted by other documents at any Request for Comments: 4272 Sparta, Inc.
time. It is inappropriate to use Internet-Drafts as reference material Category: Informational January 2006
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at BGP Security Vulnerabilities Analysis
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 13, 2005. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2006).
Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
Abstract Abstract
Border Gateway Protocol 4 (BGP-4), along with a host of other Border Gateway Protocol 4 (BGP-4), along with a host of other
infrastructure protocols designed before the Internet environment became infrastructure protocols designed before the Internet environment
perilous, was originally designed with little consideration for became perilous, was originally designed with little consideration
protection of the information it carries. There are no mechanisms for protection of the information it carries. There are no
internal to the BGP protocol to protect against attacks that modify, mechanisms internal to BGP that protect against attacks that modify,
delete, forge, or replay data, any of which has the potential to disrupt delete, forge, or replay data, any of which has the potential to
overall network routing behavior. disrupt overall network routing behavior.
This internet draft discusses some of the security issues with BGP This document discusses some of the security issues with BGP routing
routing data dissemination. This internet draft does not discuss data dissemination. This document does not discuss security issues
security issues with forwarding of packets. with forwarding of packets.
Table of Contents Table of Contents
Abstract ........................................................ 2 1. Introduction ....................................................3
1 Introduction .................................................... 4 1.1. Specification of Requirements ..............................5
2 Attacks ......................................................... 6 2. Attacks .........................................................6
3 Vulnerabilities and Risks ....................................... 8 3. Vulnerabilities and Risks .......................................7
3.1 Vulnerabilities in BGP messages ............................... 9 3.1. Vulnerabilities in BGP Messages ............................8
3.1.1 Message Header .............................................. 10 3.1.1. Message Header ......................................9
3.1.2 OPEN ........................................................ 10 3.1.2. OPEN ................................................9
3.1.3 KEEPALIVE ................................................... 12 3.1.3. KEEPALIVE ..........................................11
3.1.4 NOTIFICATION ................................................ 12 3.1.4. NOTIFICATION .......................................11
3.1.5 UPDATE ...................................................... 12 3.1.5. UPDATE .............................................11
3.1.5.1 Unfeasible Routes Length, Total Path Attribute Length ..... 13 3.1.5.1. Unfeasible Routes Length, Total
3.1.5.2 Withdrawn Routes .......................................... 14 Path Attribute Length .....................12
3.1.5.3 Path Attributes ........................................... 14 3.1.5.2. Withdrawn Routes ..........................13
Attribute Flags, Attribute Type Codes, Attribute Length .......... 14 3.1.5.3. Path Attributes ...........................13
ORIGIN ........................................................... 14 3.1.5.4. NLRI ......................................16
AS_PATH .......................................................... 15 3.2. Vulnerabilities through Other Protocols ...................16
Originating Routes ............................................... 15 3.2.1. TCP Messages .......................................16
NEXT_HOP ......................................................... 16 3.2.1.1. TCP SYN ...................................16
MULTI_EXIT_DISC .................................................. 16 3.2.1.2. TCP SYN ACK ...............................17
LOCAL_PREF ....................................................... 16 3.2.1.3. TCP ACK ...................................17
ATOMIC_AGGREGATE ................................................. 17 3.2.1.4. TCP RST/FIN/FIN-ACK .......................17
AGGREGATOR ....................................................... 17 3.2.1.5. DoS and DDos ..............................18
3.1.5.4 NLRI ...................................................... 17 3.2.2. Other Supporting Protocols .........................18
3.2 Vulnerabilities through Other Protocols ....................... 17 3.2.2.1. Manual Stop ...............................18
3.2.1 TCP messages ................................................ 17 3.2.2.2. Open Collision Dump .......................18
3.2.1.1 TCP SYN ................................................... 17 3.2.2.3. Timer Events ..............................18
3.2.1.2 TCP SYN ACK ............................................... 18 4. Security Considerations ........................................19
3.2.1.3 TCP ACK ................................................... 18 4.1. Residual Risk .............................................19
3.2.1.4 TCP RST/FIN/FIN-ACK ....................................... 18 4.2. Operational Protections ...................................19
3.2.1.5 DoS and DDos .............................................. 19 5. References .....................................................21
3.2.2 Other supporting protocols .................................. 19 5.1. Normative References ......................................21
3.2.2.1 Manual stop ............................................... 19 5.2. Informative References ....................................21
3.2.2.2 Open Collision Dump ....................................... 19
3.2.2.3 Timer events .............................................. 19
4 Security Considerations ......................................... 20
4.1 Residual Risk ................................................. 20
4.2 Operational Protections ....................................... 21
5 IANA Considerations ............................................. 22
6 References ...................................................... 22
6.1 Normative ..................................................... 22
6.2 Informative ................................................... 22
7 Author's Address ................................................ 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 design did not include protections against
deliberate or accidental errors causing disruptions of routing behavior. deliberate or accidental errors that could cause disruptions of
routing behavior.
We here discuss the vulnerabilities of BGP, based on the BGP This document discusses the vulnerabilities of BGP, based on the BGP
specification [BGP]. Readers are expected to be familiar with the BGP specification [RFC4271]. Readers are expected to be familiar with
RFC and the behavior of BGP. the BGP RFC and the behavior of BGP.
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 and BGP is no exception. Faulty, misconfigured or routing protocols and BGP is no exception. Faulty, misconfigured, or
deliberately malicious sources can disrupt overall Internet behavior by deliberately malicious sources can disrupt overall Internet behavior
injecting bogus routing information into the BGP distributed routing by injecting bogus routing information into the BGP-distributed
database (by modifying, forging, or replaying BGP packets). The same routing database (by modifying, forging, or replaying BGP packets).
methods can also be used to disrupt local and overall network behavior The same methods can also be used to disrupt local and overall
by breaking the distributed communication of information between BGP network behavior by breaking the distributed communication of
peers. The sources of bogus information can be either outsiders or true information between BGP peers. The sources of bogus information can
BGP peers. be either outsiders or true BGP peers.
Cryptographic authentication of the peer-peer communication is not an Cryptographic authentication of peer-peer communication is not an
integral part of the BGP protocol. As a TCP/IP protocol, BGP is subject integral part of BGP. As a TCP/IP protocol, BGP is subject to all
to all the TCP/IP attacks, like IP spoofing, session stealing, etc. Any TCP/IP attacks, e.g., IP spoofing, session stealing, etc. Any
outsider can inject believable BGP messages into the communication outsider can inject believable BGP messages into the communication
between BGP peers and thereby inject bogus routing information or break between BGP peers, and thereby inject bogus routing information or
the peer to peer connection. Any break in the peer to peer break the peer-peer connection. Any break in the peer-peer
communication has a ripple effect on routing that can be widespread. communication has a ripple effect on routing that can be widespread.
Furthermore, outsider sources can also disrupt communications between Furthermore, outsider sources can also disrupt communications between
BGP peers by breaking their TCP connection with spoofed packets. BGP peers by breaking their TCP connection with spoofed packets.
Outsider sources of bogus BGP information can reside anywhere in the Outsider sources of bogus BGP information can reside anywhere in the
world. world.
Consequently, the current BGP specification requires that a BGP Consequently, the current BGP specification requires that a BGP
implementation must support the authentication mechanism specified in implementation must support the authentication mechanism specified in
[TCPMD5]. However, the requirement for support of that authentication [TCPMD5]. However, the requirement for support of that
mechanism cannot ensure that the mechanism is configured for use. The authentication mechanism cannot ensure that the mechanism is
mechanism of [TCPMD5] is based on a pre-installed shared secret; it does configured for use. The mechanism of [TCPMD5] is based on a pre-
not have the capability of IPsec [IPsec] to agree on a shared secret installed, shared secret; it does not have the capability of IPsec
dynamically. Consequently, the use of [TCPMD5] must be a deliberate [IPsec] to agree on a shared secret dynamically. Consequently, the
decision, not an automatic feature or default. use of [TCPMD5] must be a deliberate decision, not an automatic
feature or a default.
The current BGP specification also allows for implementations that would
accept connections from "unconfigured peers" ([BGP] Section 8).
However, the specification is not clear as to what an unconfigured peer
might be or how the protections of [TCPMD5] would apply in such a case. The current BGP specification also allows for implementations that
It is therefore not possible to include an analysis of the security would accept connections from "unconfigured peers" ([RFC4271] Section
issues of this feature. When a specification is released that describes 8). However, the specification is not clear as to what an
this feature more fully, a security analysis should be part of that same unconfigured peer might be, or how the protections of [TCPMD5] would
specification. apply in such a case. Therefore, it is not possible to include an
analysis of the security issues of this feature. When a
specification that describes this feature more fully is released, a
security analysis should be part of that specification.
BGP speakers themselves can inject bogus routing information, either by BGP speakers themselves can inject bogus routing information, either
masquerading as any other legitimate BGP speaker, or by distributing by masquerading as any other legitimate BGP speaker, or by
unauthorized routing information as themselves. Historically, distributing unauthorized routing information as themselves.
misconfigured and faulty routers have been responsible for widespread Historically, misconfigured and faulty routers have been responsible
disruptions in the Internet. The legitimate BGP peers have the context for widespread disruptions in the Internet. The legitimate BGP peers
and information to produce believable bogus routing information and have the context and information to produce believable, yet bogus,
therefore have the opportunity to cause great damage. The cryptographic routing information, and therefore have the opportunity to cause
protections of [TCPMD5] and operational protections cannot exclude the great damage. The cryptographic protections of [TCPMD5] and
bogus information arising from a legitimate peer. The risk of operational protections cannot exclude the bogus information arising
disruptions caused by legitimate BGP speakers is real and cannot be from a legitimate peer. The risk of disruptions caused by legitimate
ignored. BGP speakers is real and cannot be ignored.
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
of the Internet that accepts the bogus information. If the bogus portion of the Internet that accepts the bogus information. If the
information changes the route to a network, then packets destined for bogus information changes the route to a network, then packets
that network may be forwarded by a sub-optimal path, or a path that does destined for that network may be forwarded by a sub-optimal path, or
not follow the expected policy, or a path that will not forward the by a path that does not follow the expected policy, or by a path that
traffic. As a consequence, traffic to that network could be delayed by will not forward the traffic. Consequently, traffic to that network
a longer than necessary path. The network could become unreachable from could be delayed by a path that is longer than necessary. The
areas where the bogus information is accepted. Traffic might also be network could become unreachable from areas where the bogus
forwarded along a path that permits some adversary a view of the data or information is accepted. Traffic might also be forwarded along a
a chance to modify the data. If the bogus information makes it appear path that permits some adversary to view or modify the data. If the
that an autonomous system originates a network when it does not, then bogus information makes it appear that an autonomous system
packets for that network may not be deliverable for the portion of the originates a network when it does not, then packets for that network
Internet that accepts the bogus information. A false announcement that may not be deliverable for the portion of the Internet that accepts
an autonomous systems originates a network may also fragment aggregated the bogus information. A false announcement that an autonomous
address blocks in other parts of the Internet and cause routing problems systems originates a network may also fragment aggregated address
for other networks. blocks in other parts of the Internet and cause routing problems for
other networks.
The damages that might result from these attacks include: The damages that might result from these attacks include:
starvation: Data traffic destined for a node is forwarded to a part starvation: Data traffic destined for a node is forwarded to a
of the network that cannot deliver it. part of the network that cannot deliver it.
network congestion: More data traffic is forwarded through some network congestion: More data traffic is forwarded through some
portion of the network than would otherwise need to carry the portion of the network than would otherwise need to carry the
traffic. traffic.
blackhole: Large amounts of traffic are directed to be forwarded blackhole: Large amounts of traffic are directed to be forwarded
through one router that cannot handle the increased level of through one router that cannot handle the increased level of
traffic and drops many/most/all packets. traffic and drops many/most/all packets.
delay: Data traffic destined for a node is forwarded along a path 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. 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 looping: Data traffic is forwarded along a path that loops, so
the data is never delivered. that the data is never delivered.
eavesdrop: Data traffic is forwarded through some router or network eavesdrop: Data traffic is forwarded through some router or
that would otherwise not see the traffic, affording an opportunity network that would otherwise not see the traffic, affording an
to see the data. opportunity to see the data.
partition: Some portion of the network believes that it is partition: Some portion of the network believes that it is
partitioned from the rest of the network when it is not. partitioned from the rest of the network, when, in fact, it is
not.
cut: Some portion of the network believes that it has no route to cut: Some portion of the network believes that it has no route to
some network that is in fact connected. some network to which it is, in fact, connected.
churn: The forwarding in the network changes at a rapid pace, churn: The forwarding in the network changes at a rapid pace,
resulting in large variations in the data delivery patterns (and resulting in large variations in the data delivery patterns (and
adversely affecting congestion control techniques). adversely affecting congestion control techniques).
instability: BGP become unstable so that convergence on a global instability: BGP becomes unstable in such a way that convergence
forwarding state is not achieved. on a global forwarding state is not achieved.
overload: The BGP messages themselves become a significant portion overload: The BGP messages themselves become a significant portion
of the traffic the network carries. of the traffic the network carries.
resource exhaustion: The BGP messages themselves cause exhaustion resource exhaustion: The BGP messages themselves cause exhaustion
of critical router resources, such as table space. of critical router resources, such as table space.
address-spoofing: Data traffic is forwarded through some router or address-spoofing: Data traffic is forwarded through some router or
network that is spoofing the legitimate address, enabling an active network that is spoofing the legitimate address, thus enabling an
attack by affording the opportunity to modify the data. active attack by affording the opportunity to modify the data.
These consequences can fall exclusively on one end system prefix or may These consequences can fall exclusively on one end-system prefix or
effect the operation of the network as a whole. may effect the operation of the network as a whole.
1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
2. Attacks 2. Attacks
The BGP protocol, in and of itself, is subject to the following attacks BGP, in and of itself, is subject to the following attacks. (The
(list taken from the IAB RFC providing guidelines for the security list is taken from the IAB RFC that provides guidelines for the
considerations section of Internet-Drafts and RFCs [SecCons]): "Security Considerations" section of RFCs [SecCons].)
confidentiality violations: The routing data carried in BGP is confidentiality violations: The routing data carried in BGP is
carried in cleartext, so eavesdropping is a possible attack against carried in cleartext, so eavesdropping is a possible attack
routing data confidentiality. (Routing data confidentiality is not against routing data confidentiality. (Routing data
a common requirement.) confidentiality is not a common requirement.)
replay: BGP does not provide for replay protection of its replay: BGP does not provide for replay protection of its
messages. messages.
message insertion: BGP does not provide protection against message insertion: BGP does not provide protection against
insertion of messages. However, because BGP uses TCP, when the insertion of messages. However, because BGP uses TCP, when the
connection is fully established, message insertion by an outsider connection is fully established, message insertion by an outsider
would require accurate sequence number prediction (not entirely out would require accurate sequence number prediction (not entirely
of the question, but more difficult with mature TCP out of the question, but more difficult with mature TCP
implementations) or session stealing attacks. implementations) or session-stealing attacks.
message deletion: BGP does not provide protection against deletion message deletion: BGP does not provide protection against
of messages. Again, this attack is more difficult against a mature deletion of messages. Again, this attack is more difficult
TCP implementation but is not entirely out of the question. against a mature TCP implementation, but is not entirely out of
the question.
message modification: BGP does not provide protection against message modification: BGP does not provide protection against
modification of messages. A modification that was syntactically modification of messages. A modification that was syntactically
correct and did not change the length of the TCP payload would in correct and did not change the length of the TCP payload would in
general not be detectable. general not be detectable.
man-in-the-middle: BGP does not provide protection against man-in-the-middle: BGP does not provide protection against man-
man-in-the-middle attacks. As BGP does no peer entity in-the-middle attacks. As BGP does not perform peer entity
authentication, a man-in-the-middle attack is childs-play. authentication, a man-in-the-middle attack is child's play.
denial of service: While bogus routing data can present a denial denial of service: While bogus routing data can present a denial
of service attack on the end systems that are trying to transmit of service attack on the end systems that are trying to transmit
data through the network and on the network infrastructure itself, data through the network and on the network infrastructure itself,
certain bogus information can represent a denial of service on the certain bogus information can represent a denial of service on the
BGP routing protocol. For example, advertising large numbers of BGP routing protocol. For example, advertising large numbers of
more specific routes (longer prefixes) can cause BGP traffic and more specific routes (i.e., longer prefixes) can cause BGP traffic
router table size to increase, even explode. and router table size to increase, even explode.
The mandatory-to-support mechanism of [TCPMD5] will counter the message
insertion, deletion, and modification, man-in-the-middle attacks and the
denial of service attacks from outsiders. The use of [TCPMD5] does not
protect against eavesdropping attacks, but routing data confidentiality
is not a goal of BGP. The mechanism of [TCPMD5] does not protect
against replay attacks, so the only protection against replay is
provided by the TCP sequence number processing. Therefore, a replay
attack could be mounted against a BGP connection protected with [TCPMD5]
but only in very carefully timed circumstances. The mechanism of
[TCPMD5] cannot protect against bogus routing information originating The mandatory-to-support mechanism of [TCPMD5] will counter message
with an insider. insertion, deletion, and modification, man-in-the-middle and denial
of service attacks from outsiders. The use of [TCPMD5] does not
protect against eavesdropping attacks, but routing data
confidentiality is not a goal of BGP. The mechanism of [TCPMD5] does
not protect against replay attacks, so the only protection against
replay is provided by the TCP sequence number processing. Therefore,
a replay attack could be mounted against a BGP connection protected
with [TCPMD5] but only in very carefully timed circumstances. The
mechanism of [TCPMD5] cannot protect against bogus routing
information that originates from an insider.
3. Vulnerabilities and Risks 3. Vulnerabilities and Risks
The risks in BGP arise from three fundamental vulnerabilities: The risks in BGP arise from three fundamental vulnerabilities:
BGP has no internal mechanism that provides strong protection of (1) BGP has no internal mechanism that provides strong protection of
the integrity, freshness and peer entity authenticity of the the integrity, freshness, and peer entity authenticity of the
messages in peer-peer BGP communications. messages in peer-peer BGP communications.
no mechanism has been specified within BGP to validate the (2) no mechanism has been specified within BGP to validate the
authority of an AS to announce NLRI information. authority of an AS to announce NLRI information.
no mechanism has been specified within BGP to ensure the (3) no mechanism has been specified within BGP to ensure the
authenticity of the path attributes announced by an AS. authenticity of the path attributes announced by an AS.
The first fundamental vulnerability motivated the mandated support of The first fundamental vulnerability motivated the mandated support of
[TCPMD5] in the BGP specification. When that is employed, message [TCPMD5] in the BGP specification. When the support of [TCPMD5] is
integrity and peer entity authentication is provided. The mechanism of employed, message integrity and peer entity authentication are
[TCPMD5] assumes that the MD5 algorithm is secure and that the shared provided. The mechanism of [TCPMD5] assumes that the MD5 algorithm
secret is protected and chosen to be difficult to guess. is secure and that the shared secret is protected and chosen to be
difficult to guess.
In the discussion that follows, the vulnerabilities are described in In the discussion that follows, the vulnerabilities are described in
terms of the BGP Finite State Machine events where the message terms of the BGP Finite State Machine events. The events are defined
processing occurs. The events are defined and discussed in section 8 of and discussed in section 8 of [RFC4271]. The events mentioned here
[BGP]. The events mentioned here are: are:
[Administrative Events] [Administrative Events]
Event 2: ManualStop Event 2: ManualStop
Event 8: AutomaticStop Event 8: AutomaticStop
[Timer Events] [Timer Events]
Event 9: ConnectRetryTimer_Expires Event 9: ConnectRetryTimer_Expires
skipping to change at page 9, line 38 skipping to change at page 8, line 38
Event 24: NotifMsgVerErr Event 24: NotifMsgVerErr
Event 25: NotifMsg Event 25: NotifMsg
Event 26: KeepAliveMsg Event 26: KeepAliveMsg
Event 27: UpdateMsg Event 27: UpdateMsg
Event 28: UpdateMsgErr Event 28: UpdateMsgErr
3.1. Vulnerabilities in BGP messages 3.1. Vulnerabilities in BGP Messages
There are four different BGP message types - OPEN, KEEPALIVE, There are four different BGP message types - OPEN, KEEPALIVE,
NOTIFICATION, and UPDATE. This section contains a discussion of the NOTIFICATION, and UPDATE. This section contains a discussion of the
vulnerabilities arising from each message and the ability of outsiders vulnerabilities arising from each message and the ability of
or BGP peers to exploit the vulnerabilities. To summarize, outsiders outsiders or BGP peers to exploit the vulnerabilities. To summarize,
can use bogus OPEN, KEEPALIVE, NOTIFICATION, or UPDATE messages to outsiders can use bogus OPEN, KEEPALIVE, NOTIFICATION, or UPDATE
disrupt the BGP peer-peer connections and can use bogus UPDATE messages messages to disrupt the BGP peer-peer connections. They can use
to disrupt routing without breaking the peer-peer connection. Outsiders bogus UPDATE messages to disrupt routing without breaking the peer-
can also disrupt BGP peer-peer connections by inserting bogus TCP peer connection. Outsiders can also disrupt BGP peer-peer
packets that disrupt the TCP connection processing. In general, the connections by inserting bogus TCP packets that disrupt the TCP
connection processing. In general, the ability of outsiders to use
ability of outsiders to use bogus BGP and TCP messages is limited, but bogus BGP and TCP messages is limited, but not eliminated, by the TCP
not eliminated, by the TCP sequence number processing. The use of sequence number processing. The use of [TCPMD5] can counter these
[TCPMD5] can counter these outsider attacks. BGP peers themselves are outsider attacks. BGP peers themselves are permitted to break peer-
permitted to break peer-peer connections at any time using NOTIFICATION peer connections, at any time, using NOTIFICATION messages. Thus,
messages, so there is no additional risk of broken connections through there is no additional risk of broken connections through their use
their use of OPEN, KEEPALIVE, or UPDATE messages. However, BGP peers of OPEN, KEEPALIVE, or UPDATE messages. However, BGP peers can
can disrupt routing (in impermissible ways) by issuing UPDATE messages disrupt routing (in impermissible ways) by issuing UPDATE messages
that contain bogus routing information. In particular, bogus that contain bogus routing information. In particular, bogus
ATOMIC_AGGREGATE, NEXT_HOP and AS_PATH attributes and bogus NLRI in ATOMIC_AGGREGATE, NEXT_HOP and AS_PATH attributes and bogus NLRI in
UPDATE messages can disrupt routing. The use of [TCPMD5] will not UPDATE messages can disrupt routing. The use of [TCPMD5] will not
counter these attacks from BGP peers. counter these attacks from BGP peers.
Each message introduces certain different vulnerabilities and risks and Each message introduces certain vulnerabilities and risks, which are
is discussed in the following sections. discussed in the following sections.
3.1.1. Message Header 3.1.1. Message Header
Event 21: Each BGP message starts with a standard header. In all Event 21: Each BGP message starts with a standard header. In all
cases, syntactic errors in the message header will cause the BGP speaker cases, syntactic errors in the message header will cause the BGP
to close the connection, release all associated BGP resources, delete speaker to close the connection, release all associated BGP
all routes learned through that connection, run its decision process to resources, delete all routes learned through that connection, run its
decide on new routes and cause the state to return to Idle. Also, decision process to decide on new routes, and cause the state to
optionally, an implementation specific peer oscillation damping may be return to Idle. Also, optionally, an implementation-specific peer
performed. The peer oscillation damping process can affect how soon the oscillation damping may be performed. The peer oscillation damping
connection can be restarted. An outsider who could spoof messages with process can affect how soon the connection can be restarted. An
message header errors could cause disruptions in routing over a wide outsider who could spoof messages with message header errors could
area. cause disruptions in routing over a wide area.
3.1.2. OPEN 3.1.2. OPEN
Event 19: Receipt of an OPEN message in state Connect or Active will Event 19: Receipt of an OPEN message in states Connect or Active
cause the BGP speaker to bring down the connection, release all will cause the BGP speaker to bring down the connection, release all
associated BGP resources, delete all associated routes, run its decision associated BGP resources, delete all associated routes, run its
process and cause the state to return to Idle. The deletion of routes decision process, and cause the state to return to Idle. The
can cause a cascading effect of routing changes propagating through deletion of routes can cause a cascading effect in which routing
other peers. Also, optionally, an implementation specific peer changes propagate through other peers. Also, optionally, an
oscillation damping may be performed. The peer oscillation damping implementation-specific peer oscillation damping may be performed.
process can affect how soon the connection can be restarted. The peer oscillation damping process can affect how soon the
connection can be restarted.
In state OpenConfirm or Established, the arrival of an OPEN may indicate In state OpenConfirm or Established, the arrival of an OPEN may
a connection collision has occurred. If this connection is to be indicate a connection collision has occurred. If this connection is
dropped, then Event 23 will be issued. (Event 23, discussed below, to be dropped, then Event 23 will be issued. (Event 23, discussed
results in the same set of disruptive actions as mentioned above for below, results in the same set of disruptive actions as mentioned
states Connect or Active.) above for states Connect or Active.)
In state OpenSent, the arrival of an OPEN message will cause the BGP In state OpenSent, the arrival of an OPEN message will cause the BGP
speaker to transition to the OpenConfirm state. If an outsider was able speaker to transition to the OpenConfirm state. If an outsider was
to spoof an OPEN message (requiring very careful timing), then the later able to spoof an OPEN message (requiring very careful timing), then
arrival of the legitimate peer's OPEN message might lead the BGP speaker the later arrival of the legitimate peer's OPEN message might lead
to declare a connection collision. The collision detection procedure the BGP speaker to declare a connection collision. The collision
may cause the legitimate connection to be dropped. detection procedure may cause the legitimate connection to be
dropped.
Consequently, the ability of an outsider to spoof this message can lead Consequently, the ability of an outsider to spoof this message can
to a severe disruption of routing over a wide area. lead to a severe disruption of routing over a wide area.
Event 20: If an OPEN message arrives when the DelayOpen timer is Event 20: If an OPEN message arrives when the DelayOpen timer is
running when the connection is in state OpenSent, OpenConfirm or running when the connection is in state OpenSent, OpenConfirm or
Established, the BGP speaker will bring down the connection, release all Established, the BGP speaker will bring down the connection, release
associated BGP resources, delete all associated routes, run its decision all associated BGP resources, delete all associated routes, run its
process and cause the state to return to Idle. The deletion of routes decision process, and cause the state to return to Idle. The
can cause a cascading effect of routing changes propagating through deletion of routes can cause a cascading effect in which routing
other peers. Also, optionally, an implementation specific peer changes propagate through other peers. Also, optionally, an
oscillation damping may be performed. The peer oscillation damping implementation-specific peer oscillation damping may be performed.
process can affect how soon the connection can be restarted. However, The peer oscillation damping process can affect how soon the
as the OpenDelay timer should never be running in these states, this connection can be restarted. However, because the OpenDelay timer
could only be caused by an error in the implementation (a NOTIFICATION should never be running in these states, this effect could only be
is sent with the error code "Finite State Machine Error"). It would be caused by an error in the implementation (a NOTIFICATION is sent with
difficult, if not impossible, for an outsider to induce this FSM error. the error code "Finite State Machine Error"). It would be difficult,
if not impossible, for an outsider to induce this Finite State
Machine error.
In states Connect and Active, this event will cause a transition to the In states Connect and Active, this event will cause a transition to
OpenConfirm state. As in Event 19, if an outsider were able to spoof an the OpenConfirm state. As in Event 19, if an outsider were able to
OPEN which arrived while the DelayOpen timer was running, then a later spoof an OPEN, which arrived while the DelayOpen timer was running,
arriving OPEN from the legitimate peer might be considered a connection then a later arriving OPEN (from the legitimate peer) might be
collision and the legitimate connection could be dropped. considered a connection collision and the legitimate connection could
be dropped.
Consequently, the ability for an outsider to spoof this message can lead Consequently, the ability of an outsider to spoof this message can
to a severe disruption of routing over a wide area. lead to a severe disruption of routing over a wide area.
Event 22: Errors in the OPEN message (e.g., unacceptable Hold state, Event 22: Errors in the OPEN message (e.g., unacceptable Hold state,
malformed Optional Parameter, unsupported version, etc.) will cause the malformed Optional Parameter, unsupported version, etc.) will cause
BGP speaker to bring down the connection, release all associated BGP the BGP speaker to bring down the connection, release all associated
resources, delete all associated routes, run its decision process and BGP resources, delete all associated routes, run its decision
cause the state to return to Idle. The deletion of routes can cause a process, and cause the state to return to Idle. The deletion of
cascading effect of routing changes propagating through other peers. routes can cause a cascading effect in which routing changes
Also, optionally, an implementation specific peer oscillation damping propagate through other peers. Also, optionally, an implementation-
may be performed. The peer oscillation damping process can affect how specific peer oscillation damping may be performed. The peer
soon the connection can be restarted. Consequently, the ability of an oscillation damping process can affect how soon the connection can be
outsider to spoof this message can lead to a severe disruption of restarted. Consequently, the ability of an outsider to spoof this
routing over a wide area. message can lead to a severe disruption of routing over a wide area.
3.1.3. KEEPALIVE 3.1.3. KEEPALIVE
Event 26: Receipt of a KEEPALIVE message when the peering connection is Event 26: Receipt of a KEEPALIVE message, when the peering
in the Connect, Active, and OpenSent states would cause the BGP speaker connection is in the Connect, Active, and OpenSent states, would
to transition to the Idle state and fail to establish a connection. cause the BGP speaker to transition to the Idle state and fail to
Also, optionally, an implementation specific peer oscillation damping establish a connection. Also, optionally, an implementation-specific
may be performed. The peer oscillation damping process can affect how peer oscillation damping may be performed. The peer oscillation
soon the connection can be restarted. The ability of an outsider to damping process can affect how soon the connection can be restarted.
spoof this message can lead to a disruption of routing. To exploit this The ability of an outsider to spoof this message can lead to a
vulnerability deliberately, the KEEPALIVE must be carefully timed in the disruption of routing. To exploit this vulnerability deliberately,
sequence of messages exchanged between the peers; otherwise, it causes the KEEPALIVE must be carefully timed in the sequence of messages
no damage. exchanged between the peers; otherwise, it causes no damage.
3.1.4. NOTIFICATION 3.1.4. NOTIFICATION
Event 25: Receipt of a NOTIFICATION message in any state will cause the Event 25: Receipt of a NOTIFICATION message in any state will cause
BGP speaker to bring down the connection, release all associated BGP the BGP speaker to bring down the connection, release all associated
resources, delete all associated routes, run its decision process and BGP resources, delete all associated routes, run its decision
cause the state to return to Idle. The deletion of routes can cause a process, and cause the state to return to Idle. The deletion of
cascading effect of routing changes propagating through other peers. routes can cause a cascading effect in which routing changes
Also, optionally, in any state but Established, an implementation propagate through other peers. Also, optionally, in any state but
specific peer oscillation damping may be performed. The peer Established, an implementation-specific peer oscillation damping may
oscillation damping process can affect how soon the connection can be be performed. The peer oscillation damping process can affect how
restarted. Consequently, the ability of an outsider to spoof this soon the connection can be restarted. Consequently, the ability of
message can lead to a severe disruption of routing over a wide area. an outsider to spoof this message can lead to a severe disruption of
routing over a wide area.
Event 24: A NOTIFICATION message carrying an error code of "Version Event 24: A NOTIFICATION message carrying an error code of "Version
Error" behaves the same as in Event 25, with the exception that the Error" behaves the same as in Event 25, with the exception that the
optional peer oscillation damping is not performed in states OpenSent or optional peer oscillation damping is not performed in states OpenSent
OpenConfirm, or in state Connect or Active if the DelayOpen timer is or OpenConfirm, or in states Connect or Active if the DelayOpen timer
running. The damage caused is therefore one small bit less, because is running. Therefore, the damage caused is one small bit less,
restarting the connection is not affected. because restarting the connection is not affected.
3.1.5. UPDATE 3.1.5. UPDATE
Event 8: A BGP speaker may optionally choose to automatically Event 8: A BGP speaker may optionally choose to automatically
disconnect a BGP connection if the total number of prefixes exceeds a disconnect a BGP connection if the total number of prefixes exceeds a
configured maximum. If such a case, an UPDATE may carry a number of configured maximum. In such a case, an UPDATE may carry a number of
prefixes that would result in that maximum being exceeded. The BGP prefixes that would result in that maximum being exceeded. The BGP
speaker would disconnect the connection, release all associated BGP speaker would disconnect the connection, release all associated BGP
resources, delete all associated routes, run its decision process and resources, delete all associated routes, run its decision process,
cause the state to return to Idle. The deletion of routes can cause a and cause the state to return to Idle. The deletion of routes can
cascading effect of routing changes propagating through other peers. cause a cascading effect in which routing changes propagate through
Also, optionally, an implementation specific peer oscillation damping other peers. Also, optionally, an implementation-specific peer
may be performed. The peer oscillation damping process can affect how oscillation damping may be performed. The peer oscillation damping
process can affect how soon the connection can be restarted.
Consequently, the ability of an outsider to spoof this message can
lead to a severe disruption of routing over a wide area.
soon the connection can be restarted. Consequently, the ability of an Event 28: If the UPDATE message is malformed, then the BGP speaker
will bring down the connection, release all associated BGP resources,
delete all associated routes, run its decision process, and cause the
state to return to Idle. (Here, "malformed" refers to improper
Withdrawn Routes Length, Total Attribute Length, or Attribute Length,
missing mandatory well-known attributes, Attribute Flags that
conflict with the Attribute Type Codes, syntactic errors in the
ORIGIN, NEXT_HOP or AS_PATH, etc.) The deletion of routes can cause
a cascading effect in which routing changes propagate through other
peers. Also, optionally, an implementation-specific peer oscillation
damping may be performed. The peer oscillation damping process can
affect how soon the connection can be restarted. Consequently, the
ability of an outsider to spoof this message could cause widespread
disruption of routing. As a BGP speaker has the authority to close a
connection whenever it wants, this message gives BGP speakers no
additional opportunity to cause damage.
Event 27: An Update message that arrives in any state except
Established will cause the BGP speaker to bring down the connection,
release all associated BGP resources, delete all associated routes,
run its decision process, and cause the state to return to Idle. The
deletion of routes can cause a cascading effect in which routing
changes propagate through other peers. Also, optionally, an
implementation-specific peer oscillation damping may be performed.
The peer oscillation damping process can affect how soon the
connection can be restarted. Consequently, the ability of an
outsider to spoof this message can lead to a severe disruption of outsider to spoof this message can lead to a severe disruption of
routing over a wide area. routing over a wide area.
Event 28: If the UPDATE message is malformed (Withdrawn Routes Length,
Total Attribute Length, or Attribute Length that are improper, missing
mandatory well-known attributes, Attribute Flags that conflict with the
Attribute Type Codes, syntactic errors in the ORIGIN, NEXT_HOP or
AS_PATH, etc.), then the BGP speaker will bring down the connection,
release all associated BGP resources, delete all associated routes, run
its decision process and cause the state to return to Idle. The
deletion of routes can cause a cascading effect of routing changes
propagating through other peers. Also, optionally, an implementation
specific peer oscillation damping may be performed. The peer
oscillation damping process can affect how soon the connection can be
restarted. Consequently, the ability of an outsider to spoof this
message could cause widespread disruption of routing. As a BGP speaker
has the authority to close a connection whenever it wants, this message
gives BGP speakers no more opportunity to cause damage than they already
had.
Event 27: An Update message that arrives in any state but Established
will cause the BGP speaker to bring down the connection, release all
associated BGP resources, delete all associated routes, run its decision
process and cause the state to return to Idle. The deletion of routes
can cause a cascading effect of routing changes propagating through
other peers. Also, optionally, an implementation specific peer
oscillation damping may be performed. The peer oscillation damping
process can affect how soon the connection can be restarted.
Consequently, the ability of an outsider to spoof this message can lead
to a severe disruption of routing over a wide area.
In the Established state, the Update message carries the routing In the Established state, the Update message carries the routing
information. The ability to spoof any part of this message can lead to information. The ability to spoof any part of this message can lead
a disruption of routing, whether the source of the message is an to a disruption of routing, whether the source of the message is an
outsider or a legitimate BGP speaker. outsider or a legitimate BGP speaker.
3.1.5.1. Unfeasible Routes Length, Total Path Attribute Length 3.1.5.1. Unfeasible Routes Length, Total Path Attribute Length
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 (see Event 28, above). As a message and the close of the connection (see Event 28, above). As a
true BGP speaker is always able to close a connection at any time, this true BGP speaker is able to close a connection at any time, this
vulnerability represents an additional risk only when the source is not vulnerability represents an additional risk only when the source is
not the configured BGP peer, i.e., it presents no additional risk
the configured BGP peer, i.e., it presents no additional risk from BGP from BGP speakers.
speakers.
3.1.5.2. Withdrawn Routes 3.1.5.2. Withdrawn Routes
An outsider could cause the elimination of existing legitimate routes by An outsider could cause the elimination of existing legitimate routes
forging or modifying this field. An outsider could also cause the by 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
However, as the BGP speaker is authoritative for the routes it will field. However, as the BGP speaker is authoritative for the routes
announce, it is allowed to withdraw any previously announced routes that it will announce, it is allowed to withdraw any previously announced
it wants. As the receiving BGP speaker will only withdraw routes routes that it wants. As the receiving BGP speaker will only
associated with the sending BGP speaker, there is no opportunity for a withdraw routes associated with the sending BGP speaker, there is no
BGP speaker to withdraw another BGP speaker's routes. Therefore, there opportunity for a BGP speaker to withdraw another BGP speaker's
is no additional risk from BGP peers via this field. routes. Therefore, there is no additional risk from BGP peers via
this field.
3.1.5.3. Path Attributes 3.1.5.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 o Attribute Flags, Attribute Type Codes, Attribute Length
A BGP peer or an outsider could modify the attribute length or attribute
type (flags and type codes) so they did not reflect the attribute values
that followed. If the flags were modified, the flags and type code
could become incompatible (i.e., a mandatory attribute marked as
partial), or a optional attribute could be interpreted as a mandatory
attribute or vice versa. If the type code were modified, the attribute
value could be interpreted as if it were the data type and value of a
different attribute.
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
would cause the transmission of a NOTIFICATION message and the close of
the connection (see Event 28, above). As a true BGP speaker is always
able to close a connection at any time, this vulnerability represents an
additional risk only when the source is an outsider, i.e., it presents
no additional risk from a BGP peer.
ORIGIN A BGP peer or an outsider could modify the attribute length or
attribute type (flags and type codes) not to reflect the attribute
values that followed. If the flags were modified, the flags and
type code could become incompatible (i.e., a mandatory attribute
marked as partial), or an optional attribute could be interpreted
as a mandatory attribute or vice versa. If the type code were
modified, the attribute value could be interpreted as if it were
the data type and value of a different attribute.
This field indicates whether the information was learned from IGP or EGP The most likely result from modifying the attribute length, flags,
information. This field is used in making routing decisions, so there or type code would be a parse error of the UPDATE message. A
parse error would cause the transmission of a NOTIFICATION message
and the close of the connection (see Event 28, above). As a true
BGP speaker is able to close a connection at any time, this
vulnerability represents an additional risk only when the source
is an outsider, i.e., it presents no additional risk from a BGP
peer.
is some small vulnerability in being able to affect the receiving BGP o ORIGIN
speaker's routing decision by modifying this field.
AS_PATH This field indicates whether the information was learned from IGP
or EGP information. This field is used in making routing
decisions, so there is some small vulnerability of being able to
affect the receiving BGP speaker's routing decision by modifying
this field.
A BGP peer or outsider could announce an AS_PATH that was not accurate o AS_PATH
for the associated NLRI.
As it is possible for a BGP peer not to verify that a received AS_PATH A BGP peer or outsider could announce an AS_PATH that was not
begins with the AS number of its peer, a malicious BGP peer could accurate for the associated NLRI.
announce a path that begins with the AS of any BGP speaker with little
impact on itself. This could affect the receiving BGP speaker's
decision procedure and choice of installed route. The malicious peer
could considerably shorten the AS_PATH, which will increase that route's
chances of being chosen, possibly giving the malicious peer access to
traffic it would otherwise not receive. The shortened AS_PATH also
could result in routing loops, as it does not contain the information
needed to prevent loops.
It is possible for a BGP speaker to be configured to accept routes with Because a BGP peer might not verify that a received AS_PATH begins
its own AS number in the AS path. Such operational considerations are with the AS number of its peer, a malicious BGP peer could
defined to be "outside the scope" of the BGP specification, but the fact announce a path that begins with the AS of any BGP speaker, with
that AS_PATHs can have loops means that implementations cannot little impact on itself. This could affect the receiving BGP
automatically reject routes with loops. Each BGP speaker verifies only speaker's decision procedure and choice of installed route. The
that its own AS number does not appear in the AS_PATH. malicious peer could considerably shorten the AS_PATH, which will
increase that route's chances of being chosen, possibly giving the
malicious peer access to traffic it would otherwise not receive.
The shortened AS_PATH also could result in routing loops, as it
does not contain the information needed to prevent loops.
Coupled with the ability to use any value for the NEXT_HOP, this gives a It is possible for a BGP speaker to be configured to accept routes
malicious BGP speaker considerable control over the path traffic will with its own AS number in the AS path. Such operational
take. considerations are defined to be "outside the scope" of the BGP
specification. But because AS_PATHs can legitimately have loops,
implementations cannot automatically reject routes with loops.
Each BGP speaker verifies only that its own AS number does not
appear in the AS_PATH.
Originating Routes Coupled with the ability to use any value for the NEXT_HOP, this
provides a malicious BGP speaker considerable control over the
path traffic will take.
A special case of announcing a false AS_PATH occurs when the AS_PATH o Originating Routes
advertises a direct connection to a specific network address. A BGP
peer or outsider could disrupt routing to the network(s) listed in the
NLRI field by falsely advertising a direct connection to the network.
The NLRI would become unreachable to the portion of the network that
accepted this false route, unless the ultimate AS on the AS_PATH
undertook to tunnel the packets it was forwarded for this NLRI on toward
their true destination AS by a valid path. But even when the packets
are tunneled to the correct destination AS, the route followed may not
be optimal or may not follow the intended policy. Additionally, routing
for other networks in the Internet could be affected if the false
advertisement fragmented an aggregated address block, forcing the
routers to handle (issue UPDATES, store, manage) the multiple fragments
rather than the single aggregate. False originations for multiple A special case of announcing a false AS_PATH occurs when the
addresses can result in routers and transit networks along the announced AS_PATH advertises a direct connection to a specific network
route to become flooded with mis-directed traffic. address. A BGP peer or outsider could disrupt routing to the
network(s) listed in the NLRI field by falsely advertising a
direct connection to the network. The NLRI would become
unreachable to the portion of the network that accepted this false
route, unless the ultimate AS on the AS_PATH undertook to tunnel
the packets it was forwarded for this NLRI toward their true
destination AS by a valid path. But even when the packets are
tunneled to the correct destination AS, the route followed may not
be optimal, or may not follow the intended policy. Additionally,
routing for other networks in the Internet could be affected if
the false advertisement fragmented an aggregated address block,
forcing the routers to handle (issue UPDATES, store, manage) the
multiple fragments rather than the single aggregate. False
originations for multiple addresses can result in routers and
transit networks along the announced route to become flooded with
misdirected traffic.
NEXT_HOP o 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
should be used as the next hop when forwarding the NLRI listed in the that should be used as the next hop when forwarding the NLRI
UPDATE message. If the recipient is an external peer, then the listed in the UPDATE message. If the recipient is an external
recipient and the NEXT_HOP address must share a subnet. It is clear peer, then the recipient and the NEXT_HOP address must share a
that an outsider modifying this field could disrupt the forwarding of subnet. It is clear that an outsider who modified this field
traffic between the two AS's. could disrupt the forwarding of traffic between the two ASes.
In the case that the recipient of the message is an external peer of an If the recipient of the message is an external peer of an AS and
AS and the route was learned from another peer AS (this is one of two the route was learned from another peer AS (this is one of two
forms of "third party" NEXT_HOP), then the BGP speaker advertising the forms of "third party" NEXT_HOP), then the BGP speaker advertising
route has the opportunity to direct the recipient to forward traffic to the route has the opportunity to direct the recipient to forward
a BGP speaker at the NEXT_HOP address. This affords the opportunity to traffic to a BGP speaker at the NEXT_HOP address. This affords
direct traffic at a router that may not be able to continue forwarding the opportunity to direct traffic at a router that may not be able
the traffic. A malicious BGP speaker can also use this technique to to continue forwarding the traffic. A malicious BGP speaker can
force another AS to carry traffic it would otherwise not have to carry. also use this technique to force another AS to carry traffic it
In some cases, this could be to the malicious BGP speaker's benefit, as would otherwise not have to carry. In some cases, this could be
it could cause traffic to be carried long-haul by the victim AS to some to the malicious BGP speaker's benefit, as it could cause traffic
other peering point it shared with the victim. to be carried long-haul by the victim AS to some other peering
point it shared with the victim.
MULTI_EXIT_DISC o MULTI_EXIT_DISC
The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted The MULTI_EXIT_DISC attribute is used in UPDATE messages
between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an transmitted between inter-AS BGP peers. While the MULTI_EXIT_DISC
inter-AS peer may be propagated within an AS, it may not be propagated received from an inter-AS peer may be propagated within an AS, it
to other AS's. Consequently, this field is only used in making routing may not be propagated to other ASes. Consequently, this field is
decisions internal to one AS. Modifying this field, whether by an only used in making routing decisions internal to one AS.
outsider or a BGP peer, could influence routing within an AS to be Modifying this field, whether by an outsider or a BGP peer, could
sub-optimal, but the effect should be limited in scope. influence routing within an AS to be sub-optimal, but the effect
should be limited in scope.
LOCAL_PREF o 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
peers and excluded from messages with external peers. Consequently, internal peers, and excluded from messages with external peers.
modification of the LOCAL_PREF could effect the routing process within Consequently, modification of the LOCAL_PREF could effect the
the AS only. Note that there is no requirement in the BGP RFC that the routing process within the AS only. Note that there is no
LOCAL_PREF be consistent among the internal BGP speakers of an AS. As requirement in the BGP RFC that the LOCAL_PREF be consistent among
BGP peers are free to choose the LOCAL_PREF as they wish, modification the internal BGP speakers of an AS. Because BGP peers are free to
of this field is a vulnerability with respect to outsiders only. choose the LOCAL_PREF, modification of this field is a
vulnerability with respect to outsiders only.
ATOMIC_AGGREGATE o ATOMIC_AGGREGATE
The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way The ATOMIC_AGGREGATE field indicates that an AS somewhere along
has aggregated several routes and advertised the aggregate NLRI without the way has aggregated several routes and advertised the aggregate
the AS_SET formed as usual from the AS's in the aggregated routes' NLRI without the AS_SET being formed as usual from the ASes in the
AS_PATHs. BGP speakers receiving a route with ATOMIC_AGGREGATE are aggregated routes' AS_PATHs. BGP speakers receiving a route with
restricted from making the NLRI any more specific. Removing the ATOMIC_AGGREGATE are restricted from making the NLRI any more
ATOMIC_AGGREGATE attribute would remove the restriction, possibly specific. Removing the ATOMIC_AGGREGATE attribute would remove
causing traffic intended for the more specific NLRI to be routed the restriction, possibly causing traffic intended for the more
incorrectly. Adding the ATOMIC_AGGREGATE attribute when no aggregation specific NLRI to be routed incorrectly. Adding the
was done would have little effect, beyond restricting the un-aggregated ATOMIC_AGGREGATE attribute, when no aggregation was done, would
NLRI from being made more specific. This vulnerability exists whether have little effect beyond restricting the un-aggregated NLRI from
the source is a BGP peer or an outsider. being made more specific. This vulnerability exists whether the
source is a BGP peer or an outsider.
AGGREGATOR o 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
represented in the UPDATE message from aggregation of other routes. The routes represented in the UPDATE message by aggregating other
field contains the AS number and IP address of the last aggregator of routes. The field contains the AS number and IP address of the
the route. It is not used in making any routing decisions, so it does last aggregator of the route. It is not used in making any
not represent a vulnerability. routing decisions, so it does not represent a vulnerability.
3.1.5.4. NLRI 3.1.5.4. NLRI
By modifying or forging this field, either an outsider 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
announced route will not forward traffic to the announced network, route the announced route will not forward traffic to the announced
traffic by a sub-optimal route, etc. network, route traffic by a sub-optimal route, etc.
3.2. Vulnerabilities through Other Protocols 3.2. Vulnerabilities through Other Protocols
3.2.1. TCP messages 3.2.1. TCP Messages
BGP runs over TCP, listening on port 179. Therefore, BGP is subject to BGP runs over TCP, listening on port 179. Therefore, BGP is subject
attack through attacks on TCP. to attack through attacks on TCP.
3.2.1.1. TCP SYN 3.2.1.1. TCP SYN
SYN flooding: BGP is as subject to the effects on the TCP SYN flooding: Like other protocols, BGP is subject to the effects on
implementation of SYN flooding attacks as other protocols, and must rely the TCP implementation of SYN flooding attacks, and must rely on the
on the implementation's protections against this attack. implementation's protections against these attacks.
Event 14: If an outsider were able to send a SYN to the BGP speaker at
the appropriate time during connection establishment, then the
Event 14: If an outsider were able to send a SYN to the BGP speaker
at the appropriate time during connection establishment, then the
legitimate peer's SYN would appear to be a second connection. If the legitimate peer's SYN would appear to be a second connection. If the
outsider were able to continue with a sequence of packets resulting in a outsider were able to continue with a sequence of packets resulting
BGP connection (guessing the BGP speaker's choice for sequence number on in a BGP connection (guessing the BGP speaker's choice for sequence
the SYN ACK, for example), then, the outsider's connection and the number on the SYN ACK, for example), then the outsider's connection
legitimate peer's connection would appear to be a connection collision. and the legitimate peer's connection would appear to be a connection
Depending on the outcome of the collision detection (i.e., the outsider collision. Depending on the outcome of the collision detection
chose a BGP identifier so as to win the race), the legitimate peer's (i.e., if the outsider chooses a BGP identifier so as to win the
true connection could be destroyed. The use of [TCPMD5] can counter race), the legitimate peer's true connection could be destroyed. The
this attack. use of [TCPMD5] can counter this attack.
3.2.1.2. TCP SYN ACK 3.2.1.2. TCP SYN ACK
Event 16: If an outsider were able to respond to a BGP speaker's SYN Event 16: If an outsider were able to respond to a BGP speaker's SYN
before the legitimate peer, then the legitimate peer's SYN-ACK would before the legitimate peer, then the legitimate peer's SYN-ACK would
receive a empty ACK reply, causing the legitimate peer to issue a RST receive an empty ACK reply, causing the legitimate peer to issue a
that would break the connection. The BGP speaker would bring down the RST that would break the connection. The BGP speaker would bring
connection, release all associated BGP resources, delete all associated down the connection, release all associated BGP resources, delete all
routes and run its decision process. This attack requires that the associated routes, and run its decision process. This attack
outsider be able to predict the sequence number used in the SYN. The requires that the outsider be able to predict the sequence number
use of [TCPMD5] can counter this attack. used in the SYN. The use of [TCPMD5] can counter this attack.
3.2.1.3. TCP ACK 3.2.1.3. TCP ACK
Event 17: If an outsider were able to spoof an ACK at the appropriate Event 17: If an outsider were able to spoof an ACK at the
time during connection establishment, then the BGP speaker would appropriate time during connection establishment, then the BGP
consider the connection complete, send an OPEN (Event 17) and transition speaker would consider the connection complete, send an OPEN (Event
to the OpenSent state. The arrival of the legitimate peer's ACK would 17), and transition to the OpenSent state. The arrival of the
not be delivered to the BGP process, as it would look like a duplicate legitimate peer's ACK would not be delivered to the BGP process, as
packet. This message, then, presents no particular vulnerability to BGP it would look like a duplicate packet. Thus, this message does not
during connection establishment. Spoofing an ACK after connection present a vulnerability to BGP during connection establishment.
establishment requires knowledge of the sequence numbers in use, and is Spoofing an ACK after connection establishment requires knowledge of
in general a very difficult task. The use of [TCPMD5] can counter this the sequence numbers in use, and is, in general, a very difficult
attack. task. The use of [TCPMD5] can counter this attack.
3.2.1.4. TCP RST/FIN/FIN-ACK 3.2.1.4. TCP RST/FIN/FIN-ACK
Event 18: If an outsider were able to spoof a RST, the BGP speaker Event 18: If an outsider were able to spoof a RST, the BGP speaker
would bring down the connection, release all associated BGP resources, would bring down the connection, release all associated BGP
delete all associated routes and run its decision process. If an resources, delete all associated routes, and run its decision
outsider were able to spoof a FIN, then data could still be transmitted, process. If an outsider were able to spoof a FIN, then data could
but any attempt to receive would receive a notification that the still be transmitted, but any attempt to receive it would trigger a
connection is closing. In most cases, this results in the connection notification that the connection is closing. In most cases, this
being placed in an Idle state, but if the connection is in the OpenSent results in the connection being placed in an Idle state. But if the
state at the time, the connection returns to an Active state. Spoofing connection is in the Connect state or the OpenSent state at the time,
a RST in this situation requires an outsider to guess a sequence number the connection will return to an Active state.
that need only be within the receive window [Watson04], generally an Spoofing a RST in this situation requires an outsider to guess a
easier task than guessing the exact sequence number so as to spoof a sequence number that need only be within the receive window
FIN. The use of [TCPMD5] can counter this attack. [Watson04]. This is generally an easier task than guessing the exact
sequence number required to spoof a FIN. The use of [TCPMD5] can
counter this attack.
3.2.1.5. DoS and DDos 3.2.1.5. DoS and DDos
Because the packet directed to TCP port 179 are passed to the BGP Because the packets directed to TCP port 179 are passed to the BGP
process, that potentially resides on a slower processor in the router, process, which potentially resides on a slower processor in the
flooding a router with TCP port 179 packets is an avenue for DoS attacks router, flooding a router with TCP port 179 packets is an avenue for
against the router. No BGP protocol mechanism can defeat such attacks; DoS attacks against the router. No BGP mechanism can defeat such
other mechanisms must be employed. attacks; other mechanisms must be employed.
3.2.2. Other supporting protocols 3.2.2. Other Supporting Protocols
3.2.2.1. Manual stop 3.2.2.1. Manual Stop
Event 2: A manual stop event causes the BGP speaker to bring down the Event 2: A manual stop event causes the BGP speaker to bring down
connection, release all associated BGP resources, delete all associated the connection, release all associated BGP resources, delete all
routes and run its decision process. If the mechanism by which a BGP associated routes, and run its decision process. If the mechanism by
speaker was informed of a manual stop were not carefully protected, the which a BGP speaker was informed of a manual stop is not carefully
BGP connection could be destroyed by an outsider. Consequently, BGP protected, the BGP connection could be destroyed by an outsider.
security is secondarily dependent on the security of the protocols by Consequently, BGP security is secondarily dependent on the security
which the platform is managed and configured that might signal this of the management and configuration protocols that are used to signal
event. this event.
3.2.2.2. Open Collision Dump 3.2.2.2. Open Collision Dump
Event 23: The OpenCollisionDump event may be generated administratively Event 23: The OpenCollisionDump event may be generated
when a connection collision event is detected and this connection has administratively when a connection collision event is detected and
been selected to be disconnected. When this event occurs in any state, the connection has been selected to be disconnected. When this event
the BGP connection is dropped, the BGP resources are released, the occurs in any state, the BGP connection is dropped, the BGP resources
associated routes are deleted, etc. Consequently, BGP security is are released, the associated routes are deleted, etc. Consequently,
secondarily dependent on the security of the protocols by which the BGP security is secondarily dependent on the security of the
platform is managed and configured that might signal this event. management and configuration protocols that are used to signal this
event.
3.2.2.3. Timer events 3.2.2.3. Timer Events
Events 9-13: BGP employs five timers (ConnectRetry, Hold, Keepalive, Events 9-13: BGP employs five timers (ConnectRetry, Hold, Keepalive,
MinASOrigination-Interval, and MinRouteAdvertisementInterval) and two MinASOrigination-Interval, and MinRouteAdvertisementInterval) and two
optional timers (DelayOpen and IdleHold). These timers are critical to optional timers (DelayOpen and IdleHold). These timers are critical
BGP operation. For example, if the Hold timer value were changed, the to BGP operation. For example, if the Hold timer value were changed,
remote peer might consider the connection unresponsive and bring the the remote peer might consider the connection unresponsive and bring
connection down, releasing resources, deleting associated routes, etc. the connection down, thus releasing resources, deleting associated
Consequently, BGP security is secondarily dependent on the security of routes, etc. Consequently, BGP security is secondarily dependent on
the protocols by which the platform is operated, managed and configured the security of the operation, management, and configuration
protocols that are used to modify the timers.
that might modify these timers.
4. Security Considerations 4. Security Considerations
This entire memo is about security, describing an analysis of the This entire memo is about security, describing an analysis of the
vulnerabilities that exist in the BGP protocol. vulnerabilities that exist in BGP.
Use of the mandatory-to-support mechanisms of [TCPMD5] counters the Use of the mandatory-to-support mechanisms of [TCPMD5] counters the
message insertion, deletion, and modification attacks and message insertion, deletion, and modification attacks, as well as
man-in-the-middle attacks from outsiders. If routing data man-in-the-middle attacks by outsiders. If routing data
confidentiality were desired (there being some controversy as to whether confidentiality is desired (there is some controversy as to whether
that is a desirable security service), the use of IPsec ESP could it is a desirable security service), the use of IPsec ESP could
provide that service. provide that service.
4.1. Residual Risk 4.1. Residual Risk
As cryptographic-based mechanisms, both [TCPMD5] and IPsec [IPsec] As cryptographic-based mechanisms, both [TCPMD5] and IPsec [IPsec]
assume that the cryptographic algorithms are secure, that secrets used assume that the cryptographic algorithms are secure, that secrets
are protected from exposure and are chosen well so as not to be used are protected from exposure and are chosen well so as not to be
guessable, that the platforms are securely managed and operated to guessable, that the platforms are securely managed and operated to
prevent break-ins, etc. prevent break-ins, etc.
These mechanisms do not prevent attacks that arise from a router's These mechanisms do not prevent attacks that arise from a router's
legitimate BGP peers. There are several possible solutions to prevent a legitimate BGP peers. There are several possible solutions to
BGP speaker from inserting bogus information in its advertisements to prevent a BGP speaker from inserting bogus information in its
its peers, i.e., from mounting an attack on a network's origination or advertisements to its peers (i.e., from mounting an attack on a
AS-PATH. network's origination or AS-PATH):
(1) Origination Protection: sign the originating AS. (1) Origination Protection: sign the originating AS.
(2) Origination and Adjacency Protection: sign the originating AS and (2) Origination and Adjacency Protection: sign the originating AS
predecessor information ([Smith96]) and predecessor information ([Smith96])
(3) Origination and Route Protection: sign the originating AS, and (3) Origination and Route Protection: sign the originating AS, and
nest signatures of AS_PATHs to the number of consecutive bad nest signatures of AS_PATHs to the number of consecutive bad
routers you want to prevent from causing damage. ([SBGP00]) routers you want to prevent from causing damage. ([SBGP00])
(4) Filtering: rely on a registry to verify the AS_PATH and NLRI (4) Filtering: rely on a registry to verify the AS_PATH and NLRI
originating AS ([RPSL]). originating AS ([RPSL]).
Filtering is in use near some customer attachment points, but is not Filtering is in use near some customer attachment points, but is not
effective near the Internet center. The other mechanisms are still effective near the Internet center. The other mechanisms are still
controversial and are not yet in common use. controversial and are not yet in common use.
4.2. Operational Protections 4.2. Operational Protections
The primary usage of BGP is as a means to provide reachability BGP is primarily used as a means to provide reachability information
information to Autonomous Systems (AS) and to distribute external to Autonomous Systems (AS) and to distribute external reachability
reachability internally within an AS. BGP is the routing protocol used internally within an AS. BGP is the routing protocol used to
to distribute global routing information in the Internet. BGP is distribute global routing information in the Internet. Therefore,
therefore used by all major Internet Service Providers (ISP) and many BGP is used by all major Internet Service Providers (ISP), as well as
smaller providers and other organizations. many smaller providers and other organizations.
The role which BGP plays in the Internet puts BGP implementations in BGP's role in the Internet puts BGP implementations in unique
unique conditions and places unique security requirements on BGP. BGP conditions, and places unique security requirements on BGP. BGP is
is operated over interprovider interfaces in which traffic levels push operated over interprovider interfaces in which traffic levels push
the state of the art in specialized packet forwarding hardware and the state of the art in specialized packet forwarding hardware and
exceed the performance capabilities of hardware implementation of exceed the performance capabilities of hardware implementation of
decryption by many orders of magnitude. The capability of an attacker decryption by many orders of magnitude. The capability of an
using a single workstation with high speed interface to generate false attacker using a single workstation with high speed interface to
traffic for denial of service (DoS) far exceeds the capability of generate false traffic for denial of service (DoS) far exceeds the
software based decryption or appropriately priced cryptographic hardware capability of software-based decryption or appropriately-priced
to detect the false traffic. One means to protect the network elements cryptographic hardware to detect the false traffic. Under such
from DoS attacks under such conditions is to use packet based filtering conditions, one means to protect the network elements from DoS
techniques based on relatively simple inspections of packets. As a attacks is to use packet-based filtering techniques based on
result, for an ISP carrying large volumes of traffic, the ability to relatively simple inspections of packets. As a result, for an ISP
packet filter on the basis of port numbers is an important protection carrying large volumes of traffic, the ability to packet filter on
against DoS attacks, and a necessary adjunct to cryptographic strength the basis of port numbers is an important protection against DoS
in encapsulation. attacks, and a necessary adjunct to cryptographic strength in
encapsulation.
Current practice in ISP operation is to use certain common filtering Current practice in ISP operation is to use certain common filtering
techniques to reduce the exposure to attacks from outside the ISP. To techniques to reduce the exposure to attacks from outside the ISP.
protect Internal BGP (IBGP) sessions, filters are applied at all borders To protect Internal BGP (IBGP) sessions, filters are applied at all
to an ISP network which remove all traffic destined for addresses of borders to an ISP network. This removes all traffic destined for
network elements internal addresses (typically contained within a single network elements' internal addresses (typically contained within a
prefix) and the BGP port number (179). Packets from within an ISP are single prefix) and the BGP port number (179). If the BGP port number
not forwarded from an internal interface to the BGP speaker's address on is found, packets from within an ISP are not forwarded from an
which External BGP (EBGP) sessions are supported, or to a peer's EBGP internal interface to the BGP speaker's address (on which External
address if the BGP port number is found. With appropriate consideration BGP (EBGP) sessions are supported), or to a peer's EBGP address.
in router design, in the event of failure of a BGP peer to provide the Appropriate router design can limit the risk of compromise when a BGP
equivalent filtering, the risk of compromise can be limited to the peer fails to provide adequate filtering. The risk can be limited to
peering session on which filtering is not performed by the peer or the the peering session on which filtering is not performed by the peer,
interface or line card on which the peering is supported. There is or to the interface or line card on which the peering is supported.
substantial motivation and little effort for ISPs to maintain such There is substantial motivation, and little effort is required, for
filters. ISPs to maintain such filters.
These operational practices can considerably raise the difficulty for an These operational practices can considerably raise the difficulty for
outsider to launch a DoS attack against an ISP. Prevented from an outsider to launch a DoS attack against an ISP. Prevented from
injecting sufficient traffic from outside a network to effect a DoS injecting sufficient traffic from outside a network to effect a DoS
attack, the attacker would have to undertake more difficult tasks,
attack, the attacker would have to undertake much more difficult tasks, such as compromising the ISP network elements or undetected tapping
such as compromise of the ISP network elements or undetected tapping
into physical media. into physical media.
5. IANA Considerations This document has no actions for IANA. 5. References
6. References
6.1. Normative 5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC2385, August 1998. Signature Option", RFC2385, August 1998.
[BGP] Rekhter, Y. and Li, T., "A Border Gateway Protocol 4 (BGP- [RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway
4)", work in progress, September 2004. available as Protocol 4 (BGP-4)", RFC 4271, January 2006.
<<draft-ietf-idr-bgp4-25.txt>> at Internet-Draft shadow
sites.
6.2. Informative 5.2. Informative References
[IPsec] Kent, S. and Atkinson, R., "Security Architecture for the [IPsec] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998. Internet Protocol", RFC2401, November 1998.
[SBGP00] Kent, S., Lynn, C. and Seo, K., "Secure Border Gateway [SBGP00] Kent, S., Lynn, C. and Seo, K., "Secure Border Gateway
Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Protocol (Secure-BGP)", IEEE Journal on Selected Areas in
Communications, Vol. 18, No. 4, April 2000, pp. 582-592. Communications, Vol. 18, No. 4, April 2000, pp. 582-592.
[SecCons] Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text [SecCons] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
on Security Considerations", RFC3552, BCP72, July 2003. Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[Smith96] Smith, B. and Garcia-Luna-Aceves, J.J., "Securing the Border [Smith96] Smith, B. and Garcia-Luna-Aceves, J.J., "Securing the
Gateway Routing Protocol", Proc. Global Internet'96, London, Border Gateway Routing Protocol", Proc. Global Internet
UK, 20-21 November 1996. '96, London, UK, 20-21 November 1996.
[RPSL] Villamizar, C., Alaettinoglu, C., Meyer, D., Murphy, S. and [RPSL] Villamizar, C., Alaettinoglu, C., Meyer, D., and S.
Orange, C., "Routing Policy System Security", RFC 2725, Murphy, "Routing Policy System Security", RFC 2725,
December 1999. December 1999.
[Watson04] Watson, P., "Slipping In The Window: TCP Reset Attacks", [Watson04] Watson, P., "Slipping In The Window: TCP Reset Attacks",
CanSecWest 2004, April 2004. CanSecWest 2004, April 2004.
7. Author's Address Author's Address
Sandra Murphy Sandra Murphy
Sparta, Inc. Sparta, Inc.
7075 Samuel Morse Drive 7075 Samuel Morse Drive
Columbia, MD 21046 Columbia, MD 21046
EMail: Sandy@tislabs.com
Intellectual Property Statement EMail: Sandy@tislabs.com
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Full Copyright Statement
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Copyright (C) The Internet Society (2006).
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Intellectual Property
Copyright (C) The Internet Society (2004). This document is subject to The IETF takes no position regarding the validity or scope of any
the rights, licenses and restrictions contained in BCP 78, and except as Intellectual Property Rights or other rights that might be claimed to
set forth therein, the authors retain all their rights. pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Acknowledgment Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Funding for the RFC Editor function is currently provided by the The IETF invites any interested party to bring to its attention any
Internet Society. copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 131 change blocks. 
643 lines changed or deleted 622 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/