[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: replay attacks

Sean O'Malley wrote:
> 	1. sequence space wrapping
> 
> 	2. brain dead initialization of the sequence number
> 
> Going to a 64 bit sequence number probably takes care of the first 
> for a while. But remember that the TCP large windows options actually 
> has a 32 bit sequence number combined in an with a 32 bit time 
> stamp which just happends to be accurate enough to weed out old 
> duplicates. This is complex enough that it took me a while to 
> figure out that it would work on accedently delayed packets. 
> I don't what an active atacker could do with it.

I guess that - if the sequence number is itself authenticated - he can do
nothing about it. If it's not authenticated, it's not secure against
malevolent attacks. Replay protection and authentication are closely
coupled.

> The real problem though is that every time a machine reboots you are 
> supposed to come up with a random number for the intial sequence 
> number. It is unclear how many TCP's actually do this. Thus you may 
> be able to predict a-prioir what the sequence space will look like 
> after a re-boot. As we all know a good random number is often hard 
> to find especially at boot time.  

Assume that each time the time-part of the sequence number is incremented,
the 'counting' part of it is reset to zero. Then interaction of different
hosts where one has been reset and the other kept counting will be possible
again.
AFAIK the TCP sequence numbers are initialized to random values and 
incremented by 2^16 all .5 seconds. This should hinder unwanted re-splicing 
of old connections if the same port is being reused for a new one. But I am
sure you know this better than I. What I want to say is that we do not have
the same problem. Re-splicing an UDP or IP data exchange is okay. And would
work if the time-part is not set to a random value but according to 'real'
time, and the counting part is reset each time the time part goes up.

> Just to be parinoid I would also like to see any sequence number 
> designed for protection against active attacks be encrypted or 
> otherwise obscured. Putting in the clear in the packet is asking 
> for trouble. 

Definitvely. I am sure authenticating is enough to 'gurantee' it's
integrity. I am not so sure about encryption alone.


My $0.02

  Germano
Follow-Ups: References: