Subject: RE: Matching addresses in INIT and INIT ACK

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

> >>
> >	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
> >
> >  
> >
> 
> 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...

	But... When sending an INIT, how could you get an ABORT back (without error causes)? We have the next possible error causes as an answer to the INIT:

	- Missing Mandatory Parameter
	- Out of Resource
	- Unresolvable Address
	- Invalid Mandatory Parameter
	- Unrecognized Parameters

	I don't know now about any situation in which you would send an empty ABORT as a response to an INIT. So most probably receiving a plain ABORT simply means 'Restart of an association with new addresses'... :-/

	We could also use the 'User Initiated Abort'...

	And to get to this situation the attacker must have guessed already the address and port of the sender... which might not be really such a hard task either... :-0

	In any case if the attacker ends up NOT having a COOKIE ACK back, it also means that there is something going wrong. If it not an 'Out of Resource' problem, neither a 'Cookie Received While Shutting Down', because otherwise the ABORT would have carried that error case. Again, you can use the 'User Initiated Abort' to leave things a little bit more 'mysterious'...

	I think that in the best case, hiding the real error cause to confuse the attacker, could at most mean 5-6 reasons (and one of those is in reality an implicit 'Restart of an association with new addresses')... What's that, 3 extra bits of security? :-)

> This is definetly a question for Steve...

	Yes. I won't be at the IETF this time, so keep me informed!

	BR Iván Arias Rodríguez

> R
> 
> 
> -- 
> Randall R. Stewart
> ITD
> Cisco Systems Inc.
> [email-masked] 815-342-5222(cell) or 815-477-2127(office)
> 
> 
> 
> 
> >
> >
> >  
> >
> 
> 
> -- 
> 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 10:34:15 -0600

>	I don't know now about any situation in which you would send an empty ABORT as a response to an INIT. So most probably receiving a plain ABORT simply means 'Restart of an association with new addre…

What about when there is no one listening on that port? I suppose one
could send a "out of resource" in this case.. but I think I send just a
plain ole ABORT no error cause when this occurs :-0

>	I think that in the best case, hiding the real error cause to confuse the attacker, could at most mean 5-6 reasons (and one of those is in reality an implicit 'Restart of an association with new ad…

I have this on my list of discussions with Steve :>

R