Subject: [Idr] change in draft-ietf-idr-bgp-vuln-00.txt

From: Yakov Rekhter <[email-masked]>
Date: Tue, 11 May 2004 06:26:34 -0700

Folks,

Sandy Murphy, the author of draft-ietf-idr-bgp-vuln-00.txt, proposed
the following change to her document, Replace 
  
  Spoofing a RST in this situation requires an attacker to guess a sequence 
  number that is in the proper half of the sending window,

with

  Spoofing a RST in this situation requires an attacker to guess a sequence 
  number that need only be within the receive window [9],

and add a [9] reference to the Paul Watson talk about the TCP RST
study he did.

The proposed change is intended to make the issue with TCP RST more
clear and accurate.

If there are any objections to the proposed change, please
send them to the list by May 18, 2004.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Sandy Murphy <[email-masked]>
Date: Tue, 11 May 2004 09:56:37 -0400 (EDT)

>  number that need only be within the receive window [9],

Note: this returns the discussion of TCP RST to the language that
was used in the draft for half a dozen prior versions of the draft.  So the
working group should be very familiar with this language - you've seen
this *many times* before.

>The proposed change is intended to make the issue with TCP RST more

And to help those who have seen the recent discussions of TCP RST and
are looking for coverage of the issue in the draft - the old language
matches the public reports better.

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Tue, 11 May 2004 09:56:37 -0400 (EDT)

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Tue, 11 May 2004 13:11:37 -0400 (EDT)

> If
>insertion of bogus data is the attacker's goal a packet boundary must
>be matched and the insertion must match a packet boundary or a cease
>will be caused and the bogus insertion lost.

Yes, I've been wondering about the "blind data injection" part
of the tcpm-tcpsecure draft.  First, not all TCP implementations buffer
out-of-order packets.  Second, unless the segment's bytes exactly
match a later arriving segment's upper boundary, then some of the
out-of-order segment's bytes could be overwritten.  But isn't this also
implementation specific?

And then comes the problem, as you say, of trying to match up the
BGP framing.  If the bogus data does get delivered to the application
(BGP) (depending on the timing of the reads and the arrival of the
real data), then not parsing as a proper BGP packet could cause a
CEASE.  Which would be yet another way to bring down a connection,
presuming that you needed another ;-}.

But the TCP issues, particularly implementation specific, are probably
off-topic for this list.

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Tue, 11 May 2004 16:24:01 -0400 (EDT)

>BGP security discussion is not off topic therefore if TCP issues
>impact BGP security its not off topic.

I didn't mean to suggest that the discussion of TCP issues was
off-topic, just that the discussion of TCP implementation issues
was probably too specific for this venue.  The -vuln draft does
spend some space talking about TCP issues.

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Tue, 11 May 2004 16:24:01 -0400 (EDT)

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Tue, 11 May 2004 16:21:57 -0400 (EDT)

>A cease is a very temporary DoS.  In order to be effective the attack
>must be somewhat continuous.  Injection of bad routing is a
>semipermanent DoS which if successful would be hard to detect.
>Therefore the latter is far more dangerous.  Knowing that we are much
>more safe against the dangerous form of attack is significant and
>should be mentioned, unless the goal is just to bash BGP.

Curtis, are you saying that you think the draft should be amended to
discuss this attack?  (Which would mean not just a request to the RFC
Editor, but a new version, last call, etc.)

Presently, section 2 (Attacks) of the draft says:

     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, more difficult against a mature TCP
     implementation but not entirely out of the question

     message modification: BGP does not provide protection against
     modification of messages.  A modification that did not change the
     length of the TCP payload would in general not be detectable.

In section 3.1.1 "Message Header", it says:

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 and run its decision process to
decide on new routes.

If you do not think these are sufficient, given the tcpm-tcpsecure
draft discussion of blind data injection, then would something like
the following be what you would want to see?

3.2.  Vulnerabilities through Other Protocols

3.2.1.  TCP messages
...
3.2.1.1.  TCP SYN
3.2.1.2.  TCP SYN ACK
3.2.1.3.  TCP ACK
3.2.1.4.  TCP RST/FIN/FIN-ACK

add a new section:

3.2.1.5.  TCP Data Injection

A TCP segment is accepted if some of its sequence numbers fall within
the receive window.  If the sequence numbers do not match the left
edge of the window, then the segment may, in some implementations, be
queued for later processing.  There is a chance that this would allow
insertion of bogus data that would be delivered to BGP.  However,
later arriving in-order segments may partially or completely overwrite
the out-of-order segment.  In order for this feature to be used to
attack BGP, the attacker would not only have to predict a sequence
number lying in the receive window, but also be fortunate in the bogus
segment not being overwritten by later arriving authentic segments.
Furthermore, the BGP message header contains framing information
(length, etc.) that would make it difficult for any bogus inserted
data that did get delivered to BGP to pass the syntactic checks.  The
likely result would be a Message Header Error, causing the connection
to be closed, rather than acceptance of bogus routing information.  The
use of [5] will counter this attack.

(That's off the top of my head, but you get the idea.)

--Sandy