Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Wed, 12 Mar 2003 14:12:56 +0200

> [email-masked] wrote:
> 
> >	Randall, Brian,
> >
> >  
> >
> >>Brian F. G. Bidulock wrote:
> >>
> >>    
> >>
> >>> 
> >>>
> >>>      
> >>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>Please read the quote from Section 2.6 of the IG above again.  Host
> >>>A is in the COOKIE-ECHOED state.  C is trying to add the 
> new address
> >>>"C" to the TCB in the COOKIE-ECHOED state.  The quote from 
> the IG 2.6
> >>>above tells Host A to send the abort with the specified error code.
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>Interesting.. this is a mistake in the IG then.. if you read it 
> >>literally you
> >>would only send the abort/error in the COOKIE-ECHOED state.. which
> >>is wrong.. it should be under the existing association.. aka 
> >>ESTABLISHED.
> >>
> >>Not sure why its in the COOKIE-ECHOED state...
> >>
> >>We will fix this in the next IG pass...
> >>
> >>I will respond to the rest of your email seperately..
> >>
> >>R
> >>    
> >>
> >
> >	But then... Let's see...
> >
> >	If you are an attacker and you more or less know that 
> some other peer is going to connect to a server, you can send 
> INITs to the peer, including the addresses of the server...
> >
> >	You send some of them, and you will receive INIT ACKs 
> with random ITs... In the moment the peer tries to connect to 
> the server, if we are sending quite many INITs, we could hit 
> twice the peer while in the COOKIE WAIT and/or COOKIE ECHO. 
> This will mean that suddenly you will receive two consecutive 
> INIT ACKs with the same IT, meaning that the peer is trying 
> to connect to the server (I don't feel like making a drawing, 
> but I hope it is clear enough)... At this point, you know the 
> VT that the server will use to send packets to the peer. So 
> you can try something nasty...
> >
> >	Of course, you will either know quite precisely the 
> time when the peer is going to connect to the server, or be 
> prepared to send many INITs...
> >
> >	Summarizing, if you do send the INIT ACK back, I guess 
> you will have to do it to any of the "known addresses"...
> >
> >	BR Iván Arias Rodríguez
> >
> >  
> >
> Ahh, yes.. I knew last night that there was some reason we put 
> COOKIE-ECHOED state in this.. but even
> at that, one important point (at least from my quick re-read of the 
> section)... it does not say anything
> about the ESTABLISHED state.. Now of course if the correct 
> action is to 
> send an ABORT (with
> or without error-causes) then we should do that in COOKIE-ECHOED OR 
> ESTABLISHED... right
> now if I read correctly last night.. it does not tell you to do this 
> when you are in ESTABILISHED
> so then an attacker can gain the tags....

	Do you mean that the IG doesn't say that you have to send back an ABORT if you are in the ESTABLISHED state?

	It does... That's section 5.2.2 :-)

	The difference is that in the ESTABLISHED state you create a new IT, while in the COOKIE ECHO you use the previous one.

	BR Iván Arias Rodríguez

> So we at least need to put wording in the IG to include the 
> ESTABLISHED 
> state as well.
> 
> R
> 
> -- 
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> [email-masked] 815-342-5222(cell) or 815-477-2127(office)
> 
> 
>

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 12 Mar 2003 08:22:05 -0600

>	The difference is that in the ESTABLISHED state you create a new IT, while in the COOKIE ECHO you use the previous one.

Ahh..more coffee and I have found it :>

So then the only real issue is do we:

1) send ABORT()-> with error cause
2) send ABORT()-> with no error cause
3) send INIT-ACK to a known address

or ???

I can see that <3> does reveal (indirectly) information
to the attacker... since if you don't respond, and he/she
does it enough, it can be assured that you do have a
association up with some of the guessed addresses...Then
it must do a 1 in 4billion guess for the Vtag...

On the other hand sending an abort with an error cause
sends the same information.. in fact probably it points
out which addresses are valid :-0

So I wonder if <2> is not best, leave the optional error clause but
warn that using it may reveal information to potential attackers.. or
maybe just kill the cause... not sure...

This is definetly a question for Steve...

R