Subject: RE: [Idr] proposed additional text

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 17 May 2004 13:59:50 -0400

Curtis,

-> A replay attack involves sending information later on when it is no
-> longer valid.  Since the TCP sequence number is covered by the TCP
-> checksum, and therefore MD5 digest that replaces it, a replay attack
-> is not possible.  

  IMHO, TCP sequence number is not designed to protect replay attacks,
  rather the intention is to detect network errors/congestion and to 
  provide a form of simple ordered byte stream reliability.

  For example, I computed that, the sequence number would wrap around:
  in (2^32 bytes * 8 bits/byte) / (10 * 10^6 bit/sec) = 3435.6 sec ~ 
  1 hour using 32 bit sequence number when streaming 10 Mbps, 
  in 343.56 sec using 32 bit sequence number when streaming 100Mbps, 
  in 0.00046 sec using 32 bit sequence numbers when streaming 75Tbps.
  
  I am not sure how TCP checksum and MD5 digest is going to protect
  if the attacker is not going to change a single bit the segment.

  So, all the replay attacker has to do is to wait for the next 
  window to sneak in the old segment after sequence number wrapping.
  This is the main reason why IPSec argued to increase the sequence
  number from 32 bit to 64 bits.

Venkata.

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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 May 2004 15:02:41 -0400

In message <[email-masked]>, 
>   number from 32 bit to 64 bits.

BGP does not stream continuously at 10 mb/s.  More like 10s of kb/s on
averge, usually less.  That would be an the order of 700,000 seconds
at about 50 kb/s.

So at best after about 8 days a denial of service would be possible.
Keep in mind that the old sequence of bytes has to fit exactly into a
packet in the new sequence of bytes - same start byte for the packet
and same length.  Otherwise the BGP session does a cease and there is
no damage except a temporary DoS.  Not also that the ACK sequence
number is part of the MD5.

Like I said this "attack" is a real stretch of the imagination.

For general IPSEC use it matters because inserting '\n rm -rf / \n'
(or equivalent depending on OS) into a telnet stream at almost any
time would be a bad thing.  For BGP a cease would occur and the damage
is limited to a DoS.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 May 2004 15:02:41 -0400

Curtis

---

From: Tony Li <[email-masked]>
Date: Mon, 17 May 2004 13:10:29 -0700

> Like I said this "attack" is a real stretch of the imagination.

True, but you have to acknowledge that it is possible.  On that basis
I recommend that we leave the text as is.

Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 May 2004 17:03:26 -0400

> I recommend that we leave the text as is.

OK.  If BGP cycles every 8 days and if UPDATE packet size are
distributed over a set of 500 values (for argument sake), then one out
of every 500 cycles on average you'd get the front of the packet to
align.  That's once every 4,000 days, or about 11 years.  Then the
packet size would have to be the same so you have to consider
statistically how often UPDATE packets are the same size (I think we
can agree that spoofing a keepalive is harmless).

So once every few hundred years someone could replay a valid UPDATE
packet and someone out there would be wondering how it is that they
can get to 140.222/16 and a bunch of other places that don't exist and
routes to some places that do exist might be going the wrong way.

That is if no one has changed the MD5 key in that amount of time.
And of course no one will notice that someone is sniffing packets all
this time.

Do we really need to document this as a "threat"?  If so, we should
look more carefully at BGP UPDATE packet size stats and get a more
accurate idea of what the threat is.

And since we know that BGP routing is so incredibly accurate it would
be disasterous if we discovered a BGP session had to be reset every 10
years or 100 years because routes weren't right...  :-)

Of course, since it takes a week or more to cycle through the sequence
numbers changing the MD5 key every couple of days would completely
eliminate the replay threat if anyone thought this threat was real.

Curtis

---

From: Tony Li <[email-masked]>
Date: Mon, 17 May 2004 13:10:29 -0700

Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 May 2004 17:03:26 -0400

Curtis