Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Wed, 26 Feb 2003 14:08:01 +0200

Brian F. G. Bidulock,

	snip...

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

	Well... So the point is that if the attacker is using IP spoofing, forging its source address, you will never receive the COOKIE ECHO... This way you will save the time of checking all the addresses... that's right... If the attacker includes many addresses then that time could be long... However, producing the cookie also takes time, and if the number of addresses in the INIT was so big you might even have to fragment your IP packet and stuff... but surely this time is shorter...

	If the INIT sender is not an attacker then I think that checking the addresses already when receiving the INIT makes things faster... but I can accept that there will be more attackers than "special cases"... :-/

	However, I think that the point of recognizing if the peer is known or not because of the address parameters is vital for the initialization collision scenario... If you don't check it I guess that the whole procedure simply doesn't work... however I haven't deeply checked it... :-/

	Does it work, Brian?

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

	Ok, see above...

	snip...

> > > 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...
> 
> We provide an address list to connect() which contains all 
> the addresses of
> the peer.  The second such attempt fails.

	Supposing you already know which are the addresses of the peer... which you don't know...

> > > > > 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...
> 
> 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, please, this is the third time I have to repeat it... It seems that you are not reading what I write... :-0

	Read above again, and my previous mail if necessary... or Randall's... I mean when the INIT ACK sends the chunk from a different source address than the destination address of the INIT chunk (which is the only peer address you know so far, I don't know how you manage to know them all in advance... if it is that easy, why exchanging them at all?)...

	In any case, I think that the need of checking the addresses of the incoming INIT ACK is out of comment... you have to update your TCB... If you don't, when do you do it? After receiving the COOKIE ACK? Why if it doesn't add any information at all? Besides, the COOKIE ACK could easily come from a different address than the one used to send the INIT chunk... :-/

	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: Wed, 26 Feb 2003 05:53:29 -0700

Ivan.Arias-Rodriguez,

> 	Supposing you already know which are the addresses of the peer... which you don't know...

What makes you think an application can know one address and not know the
others?

> 	Brian, please, this is the third time I have to repeat it... It seems
> 	that you are not reading what I write... :-0
> 
> 	Read above again, and my previous mail if necessary... or Randall's...
> 	I mean when the INIT ACK sends the chunk from a different source
> 	address than the destination address of the INIT chunk (which is the
> 	only peer address you know so far, I don't know how you manage to know
> 	them all in advance... if it is that easy, why exchanging them at
> 	all?)...

As I replied to Randall, one doesn't need to examine to source addresses
to identify the association.  The verification tag, destination address and
port are sufficient.  I have no problems with a spec saying that one should
watch out for such situations, or making requirements that such situations
must result in an association, or that multiple associations must not be
formed between the same transport addresses; but, I do have a problem if the
spec tries to tell me what I have to do in an implementation to identify an
association.

And, yes, it is possible for the application to know the list in advance.

So we have this requirement on one association between two transport addresses.
And another requirement on no restarts with new (expanded) address lists.
The requirements are there: don't suppose to tell me how I should satistfy
them in implementation.  You can tell me how I MAY satisfy them, or better,
provide an example or note.  But don't tell me I SHOULD look in the address
list when I clearly don't have to.

> 
> 	In any case, I think that the need of checking the addresses of the
> 	incoming INIT ACK is out of comment... you have to update your TCB...
> 	If you don't, when do you do it? After receiving the COOKIE ACK? Why
> 	if it doesn't add any information at all? Besides, the COOKIE ACK
> 	could easily come from a different address than the one used to send
> 	the INIT chunk... :-/

No, it is possible in implementation not to check.  We've been over this
before, but, because of the way that static and dynamic port allocation is
normally performed it is possible for the implementation to know a priori that
no overlap can occur.  Where dynamic port allocation is performed for the
remote port, overlap can be avoided a priori by never assigning the same
remote port.  The same is true for local dynamic port assignment.  The
implementation can know a priori that no overlap will occur because it never
assigns the same local port to more than one association.  The same is true
where both ports are dynamically assigned.  The only case that might cause a
problem would be where both local and remote ports are statically assigned,
but there is no requirement on an implementation to support overlapping
address sets on a static port pair and even in this case the application can
know (and because it is a static port pair, should know) the addresses of
the remote host that it is connecting to.

So, an implemntation can easily know, a priori, that there is no possibilty
of overlap in the received transport addresses in the INIT ACK.  Certainly
it can know if dynamic port assignment was performed on either the local or
remote port number.  No examination is necessary and they can simply be copied
to the TCB without examination.  The association can be identified by
destination address and port from the packet and the verification tag
(properly generated to be unique when the INIT was sent).

--brian