Subject: RE: Matching addresses in INIT and INIT ACK

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

Hi,

	... snip...

> >>>What have I done wrong to this point?
> >>>
> >>>      
> >>>
> >>He was illustrating what you are advocating, not looking in the INIT
> >>and INIT-ACK.. if you do look in the INIT, then at <AAA> you will
> >>have populated the tie-tags since you would have recognized the
> >>associations as being related (you would have found C in the the
> >>INIT's  list of addresses .. the one from D.. and then you would
> >>have found the TCB that sent the INIT to C...)
> >>    
> >>
> >
> >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)
> >  
> >
> Hmm.. maybe they should be populated especially if you sent the
> INIT-ACK back to the same place that you sent the INIT... I need
> to think about this case...

	It could be the right thing to do...

	I think we should unify the responses... I.e., always sending the INIT ACK back to a "known" destination, and probably always populating the Tie Tags...

	Section 5.2 is going to be changed anyway... But the problem is that as it is now, you know it works... We should be very careful.

	I haven't thought about it, but probably populating the Tie Tags would change table 2 of the RFC as well... :-/

> >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.
> >  
> >
> No, you send the INIT-ACK back to the original place you sent
> the INIT (as you just corrected me up above).. in such a case
> if D were X you would be sending the INIT-ACK back to
> C and you would not be giving anything away..

	Exactly.

> >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?
> >  
> >
> No, but I begin to wonder if maybe we should not do it this way... aka
> you send back the INIT-ACK to where you sent the orginal INIT
> AND you populate the tie-tags when you are in COOKIE-WAIT state.
> Since you would not be revealing anything to anyone else but who
> you sent the INIT to anyway...  let me think on this one for a while
> but I am pretty sure that is why we did not send tie-tags in 
> COOKIE-WAIT
> and if thats the case... with the new provisions of 2.6 IG it might be
> ok...

	Let's think about it...

> We might want to think about this for COOKIE_ECHOED as well...
> Need to mull on this one for a bit..
> 
> 
> 
> >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.
> >
> No, I was not paying attention and was thinking of the 
> INIT-ACK case...

	As I already said, Brian implementation is wrong mostly because it creates a new IT when it shouldn't. Apart from that there is the problem of sending it to D instead of C.

	What matters it that at the end, Brian seems not to be able to establish an association... :-/

	BR Iván Arias Rodríguez

> R
> 
> 
> >
> >--brian
> >
> >  
> >
> >>>(Note that I have not looked at the source address list in 
> the INIT.)
> >>> 
> >>>
> >>>      
> >>>
> >>Yep and that is why your association will not come up when 
> it should..
> >>    
> >>
> >
> >But I have following the RFC and Section 2.6 to the letter 
> (except for
> >the C/D thing which doesn't change the result here.)
> >
> >--brian
> >
> >  
> >
> 
> 
> -- 
> 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: Mon, 10 Mar 2003 07:35:01 -0600

Hi Ivan:

a few comments...

>	I haven't thought about it, but probably populating the Tie Tags would change table 2 of the RFC as well... :-/

I have thought about it even more.. and I think the bottom line is it works
either way.. The tie-tags are un-important and in fact by there not being
populated you end up at that third row in the 2960 table...

If they do get populated it does not change the outcome at all.. since the
Tag matches...

So leaving things alone is probably best.. but I don't think it really
matters if you populate the tie-tags or not... There no restriction NOT 
to and I think
there is no mandate to populate them.. this is ok...

>>and if thats the case... with the new provisions of 2.6 IG it might be
Probably it is not needed... you can do it but it does not matter
if you do or don't.. since there is no harm either way leaving
it unspecified is probably best...

>	What matters it that at the end, Brian seems not to be able to establish an association... :-/

exactly..