Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Mon, 10 Mar 2003 14:55:53 +0200

Randall,

	... snip...

> >But the tie-tags are not to be populated in COOKIE-WAIT 
> states (according
> >to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or
> >SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New 
> text for Section
> >5.2.2)
> >
> >Now you are telling me they should be populated?  If they 
> are populated
> >and D is X (the attacker) then you will have surrendered the 
> VT of the
> >existing TCB to the attacker.
> >
> >So are you saying that I have done the wrong thing by 
> putting zero in the
> >tie-tags?  Then is RFC 2960 section 5.2.2 and IG 08 section 
> 2.6 new text
> >for 5.2.2 in error?
> >
> >I would seriously like to know what I've done wrong up to this point.
> >
> >Your statements of what I have done wrong are not consistent 
> with either
> >the RFC or the IG....  Please take a closer look at it and 
> tell me where
> >I have gone astray.
> >
> 
> After thinking on this a bit more and re-reading the IG and 
> the original 
> RFC...
> I think the following changes are in order:
> 
> 1) For the IG 2.6, as I said earlier, we need to change the 
> wording in the
>     IG to not send the "adding new address" error cause in the ABORT 
> sent. This
>     way, as Brian points out, we will not be revealing info to the 
> attacker.. <OR>
>     we may want to take Ivan's approach where we send the 
> INIT-ACK back
>     to one of the existing addresses... the down side of this is as 
> Brian pointed
>     out, by not getting information back, if it is an attacker, the 
> attacker can
>    deduce that an association exists.. (I will ask Steve on 
> this point 
> as well)...

	But the association cannot be established anyway... The difference between not answering the INIT and not answering the COOKIE ECHO, is that you may have more reasons to drop the COOKIE ECHO... However, I think that in most of them you will have to send an ABORT back to the sender... :-/

	If you are an attacker and you include somebody's addresses in your INIT, and then you try to establish the association, if you haven't done any other wrong thing, you will know that if you weren't able to establish the association and you didn't get any answer, most probably that's because some of the addresses were already used by another association.

	And, I haven't thought about this, but, what would happen if the address list in the INIT contains addresses of *more than one* other association? This would clearly identify the INIT as coming from an attacker... :-/

> 2) For the same section in the IG we need to populate the 
> tie-tags in the
>     COOKIE-WAIT state as well, not just the COOKIE-ECHOED state as
>     is currently in RFC2960. With the current changes in the 
> IG (as Brian
>     pointed out... you send back to the place you sent the 
> INIT to) there
>     is no danger of revealing your VT to a mallicious hacker 
> in this case...

	Changing this means that we need to send the INIT ACK back to a "known" address...

	BR Iván Arias Rodríguez

> 3) We may need a requirement that you MUST validate addresses and not
>     solely depend on the uniquness of the V-Tags... otherwise 
> you weaken
>     security... I will discuss this one with Steve Bellovin 
> in S.F. and see
>    what he has to say...
> 
> R

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 10 Mar 2003 07:40:44 -0600

>	If you are an attacker and you include somebody's addresses in your INIT, and then you try to establish the association, if you haven't done any other wrong thing, you will know that if you weren't…
Yeah, I do think an ABORT must go back to the sender of the C-E .. but 
maybe with no error causes...

>	And, I haven't thought about this, but, what would happen if the address list in the INIT contains addresses of *more than one* other association? This would clearly identify the INIT as coming fro…
Yes, this is a good point.. one could use this type of information to 
determine an attacker
and I would expect log this somewhere a counter or something.... but one 
must
be careful about logging since this to can be an attack :-0

>	Changing this means that we need to send the INIT ACK back to a "known" address...

The more I think on it, we really don't need the tie-tags in the 
COOKIE-WAIT state, as
you point out the key is to get the same tag so you can bring up the 
association and
of course follow 2.6 of the IG.. I think we should leave this alone... 
and if a
implementation wants to populate the tie-tags.. thats ok too... it 
servers really
no purpose (outside of making the code consistent)...

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)