BGP Vulnerabilities Draft

1. BGP Vulnerabilities Draft March 19, 2003 Sandra Murphy (sandy@tislabs.com)

2. Changes Since November • Many changes in text, but few changes in vulnerabilities • terminology now reflects FSM terminology • Tried to follow security considerations guidelines draft (draft-iab-sec-cons-03.txt) • Note: any change in protocol behavior necessitates a security analysis (usually trivial, but…)

3. Vulnerabilities vs Messages • Vulnerabilitites from malformed message headers • Vulnerabilities from OPEN, KEEPALIVE, and NOTIFICATION messages • if a legitimate peer sends you such a message, hard to say that it is “bogus” • so vulnerability comes from outsiders • Vulnerabilities from UPDATE • Vulnerabilities from support protocols • TCP, because BGP mandates use of BGP • other supporting protocols

4. Message Header Errors • E21: connection is broken

5. OPEN (outsiders only) • E19 • in states Connect, Active, and Established will break the connection (and may do peer oscillation dampening) • in state OpenSent may set up breaking of the connection when the valid OPEN arrives later, based on results of connection collision algorithm • E20 • in state OpenSent or Established when open delay timer is running breaks connection (and may do peer oscillation dampening) • but this must be an FSM error in the receiver, hard to exploit • E22 • (malformed Open) will break the connection (and may do peer oscillation dampening) • peer oscillation may limit how soon the connection can be re-established

6. KEEPALIVE (outsiders only) • E26: in states Connect, Active, and OpenSent will cause the connection to transition to Idle state, ceasing the attempt to establish the connection, even though peer may complete the connection on its end

7. NOTIFICATION (outsiders only) • E25 in any state breaks the connection (and may do peer oscillation dampening) or ceases the attempt to establish a connection. • E26 does the same except that it does not do peer oscillation dampening

8. UPDATE • E28 (malformed Update) will break the connection (and may do peer oscillation dampening)

9. UPDATE:Withdrawn Routes • Outsiders could damage the routing behavior if they were able to insert forged withdrawals • The legitimate peers have the authority to withdraw routes as they wish, so it it is hard to say that a withdrawal is “bogus” (i.e., not a vulnerability from legitimate peers)

10. UPDATE: Path Attributes: NEXT_HOP • Can use Next-Hop to induce a peer to forward traffic to another BGP speaker (the victim) who peers with them • the victim BGP speaker may not be able to forward traffic • the victim BGP speaker will carry traffic that it might not have intended to carry (resource stealing) traffic for N A B C UPDATE, Next-Hop=<B’s interface>, NLRI=N

11. TCP related vulnerabilities • SYN Flooding • E14, E16, E17: TCP SYN, TCP SYN ACK, TCP ACK: depending on the timing and the state, can create a bogus connection or can break an existing connection • E18: TCP RST/FIN/etc: may break an existing connection

12. Other Supporting Protocols • E2: Manual stop: will break an existing connection • E9-13: Keepalive, Hold, and Open Delay timers can have various affects on the behavior of BGP • BGP is dependent on the security of the protocols by which manual stop could be caused or timers could be changed

13. RFC2385 • The use of TCP MD5 would prevent outsiders from using forged message insertion or message modification to exploit these vulnerabilities. • Protection against replay is provided by the sequence numbers of TCP. Can be circumvented, but not likely for mature TCP implementations. • Reliant on use of good keys, protecting keys from exposure, etc.

14. Unconfigured Peers • Base draft says that implementations may accept “unconfigured peers” • This is hard to reconcile with TCP MD5 which requires a shared secret • suggestion: the listen socket may be configured with a secret that all the “unconfigured” peers would have to know • so “unconfigured” peers must have communicated with you to learn the key and they all know the same key • How to address this in vulnerabilities draft? • “Unconfigured peers are not in scope for the base BGP draft. However, it is know that some implementations do support this. The use of RFC2385 would mean that these unconfigured peers must at least have communicated with the BGP speaker to learn the key to use. The manner in which the key is distributed to these unconfigured peer can have an affect on the security that is provided. For example, if a group of routers all know the same key to use in TCP MD5, then TCP MD5 can only assure that connections are from some member of the group and cannot assure that the source is the particular member of the group mentioned.”

15. Acts of Omission • discussion from rpsec group: the following are attacks: • underclaiming: failure to advertise a NLRI that the AS owns • discard of control packets: failure to forward control packets • (perhaps - not announcing a withdrawal when you receive a withdrawal?) • should this be included in the draft?