doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

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