Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Tue, 25 Feb 2003 17:37:00 +0200

Brian,

> Ivan.Arias-Rodriguez,
> 
> On Tue, 25 Feb 2003, [email-masked] wrote:
> 
> > 	Hei!
> > 
> > > Iván,
> > > 
> > > But I don't have to look in either the INIT or INIT-ACK 
> to determine
> > > this.  All I have to do is look in the cookie of the COOKIE-ECHO.
> > 
> > 	Why looking in the COOKIE ECHO and not in the INIT 
> directly? Don't you
> > 	save time if you identify this situation earlier?
> 
> Saving time is implementation specific thing.  Time can be saved (and
> security improved) by not trusting anything until verified 
> with a cookie.

	I think you save time not creating, sending and reading the COOKIE ECHO... You will always take a look to the parameters in the INIT, why leaving it for later? I don't get it... :-/

	And you won't trust anything that has not been verified with a cookie... You simply anticipate the facts...

> > > (For the second INIT ACK below, the verification tag gives away
> > > the establishing association and a second COOKIE-ECHO can be
> > > avoided without looking at the address list.)
> > 
> > 	If you don't pay attention to the addresses inside the 
> first INIT ACK,
> > 	then you send the COOKIE ECHO and you save in your TCB 
> the information
> > 	about those addresses. When the second INIT ACK comes, 
> you do the
> > 	same... Depending how you have coded your 
> implementation, you will
> > 	either take that second INIT ACK as going to the first 
> association, or
> > 	to the second... If you take it as going to the first, you will
> > 	discard it... otherwise you will create another 
> association (still
> > 	pending the receipt of the COOKIE ACK)...
> > 
> > 	I don't see how taking a look to the parameters in the 
> INIT/INIT ACK
> > 	can hurt... :-/ You will have to do it sooner or later 
> in any case...
> > 
> > 	And most probably you can think about more harmful situations...
> 
> I was considering a resent INIT ACK, because the case you gave is not
> possible on our implementation.  (A user cannot establish two 
> associations
> in such a manner: the second attempt will be refused and no 
> INIT sent.)

	Why? If you haven't created the first association, the user can still ask for the second one. It (nor the SCTP implementation) doesn't have to know that both addresses belong to the same host until the INIT ACK is received and processed... This was just an example, I'm not saying that it is not a corner case...

> > > So that doesn't really explain the section to me...
> > > 
> > > Also the section in the IG implies that associations will 
> fail to be
> > > formed that would otherwise be formed (not that multiple 
> associations
> > > will be attempted to be formed and could fail in one way 
> instead of
> > > another).
> > 
> > 	Sometimes you cannot form the association, sometimes 
> you have some
> > 	other kind of problems... That's why I suggested the 
> change... But
> > 	that's in the other thread of mails...
> 
> The thread does not cite a case where an association will not 
> be formed that
> would otherwise be formed if the list was examined.

	I spoke about one such case: the INIT receiver sends the INIT ACK from a source different than the destination of the INIT...

	BR Iván Arias Rodríguez

> --brian
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Feb 2003 08:58:27 -0700

Ivan.Arias-Rodriguez,

On Tue, 25 Feb 2003, [email-masked] wrote:

> 	I think you save time not creating, sending and reading the COOKIE
> 	ECHO... You will always take a look to the parameters in the INIT, why
> 	leaving it for later? I don't get it... :-/

No need to look at them, copy them directly to the cookie.

> 	And you won't trust anything that has not been verified with a
> 	cookie... You simply anticipate the facts...

The facts may be different than you anticipate, particularly when under
attack.

> 	Why? If you haven't created the first association, the user can still
> 	ask for the second one. It (nor the SCTP implementation) doesn't have
> 	to know that both addresses belong to the same host until the INIT ACK
> 	is received and processed... This was just an example, I'm not saying
> 	that it is not a corner case...

We provide an address list to connect() which contains all the addresses of
the peer.  The second such attempt fails.

> 	I spoke about one such case: the INIT receiver sends the INIT ACK from
> 	a source different than the destination of the INIT...

In that example the association is supposed to fail (ABORT Restart with new
address...).  Do you have one where the association is supposed to form but
does not because the address list is not searched?

--brian