19 March 2003Page 1 BGP Vulnerabilities Draft March 19, 2003 Sandra Murphy

19 March 2003Page 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…)

19 March 2003Page 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

19 March 2003Page 4 Message Header Errors E21: connection is broken

19 March 2003Page 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

19 March 2003Page 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

19 March 2003Page 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

19 March 2003Page 8 UPDATE E28 (malformed Update) will break the connection (and may do peer oscillation dampening)

19 March 2003Page 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)

19 March 2003Page 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) ABC UPDATE, Next-Hop=, NLRI=N traffic for N

19 March 2003Page 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

19 March 2003Page 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

19 March 2003Page 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.

19 March 2003Page 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.”

19 March 2003Page 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?