RE: [Idr] proposed additional text

["Naidu, Venkata" <Venkata.Naidu at Marconi.com>]

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
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr