Subject: RE: Addr in INIT or INIT ACK

From: <[email-masked]>
Date: Tue, 25 Feb 2003 13:57:35 +0200

Hi Vijay and Brian!

	Well, actually, the section doesn't specify exactly what's trying to solve... if you aren't aware in advance about what it is trying to fix, it is difficult to understand why one should do that...

	But the answer is very easy. The point is that the INIT ACK must be sent to the source address from which the INIT chunk came. However, it can be sent from any of the available source addresses at the INIT ACK sender. Thus, if the INIT ACK receiver doesn't recognize the source address doesn't take a look inside, it can wrongly discard the chunk, not establishing the association... :-(

	About the INIT... It is a little bit trickier, but there are also some special cases... Imagine the peer restarts and sends you an INIT, including (some of) the previous address as parameters, but using a new address as the source address (or instead of this, you simply have an attacker sending you such an INIT chunk). In this case you should in fact send back and ABORT with the 'Restart of an association with new addresses' cause error. You won't be able to recognize this situation if you don't go through the addresses inside... :-/

	I think that we could modify a little section 2.18.3. Currently it says:

2.18.3 Solution description

   This new text clearly specifies to an implementor the need to look
   within the INIT or INIT-ACK.  Any implementation that does not do
   this, may not be able to establish associations in certain
   circumstances.

	Could it be better something like...?:

   This new text clearly specifies to an implementor the need to look
   within the INIT or INIT ACK.  Any implementation that does not do
   this, may for example not be able to recognize an INIT chunk coming
   from an already established association that adds new addresses
   (see section 2.6), or an incoming INIT ACK chunk sent from a source
   address different to the destination address used to send the INIT
   chunk.

	How does it sound?

	BR Iván Arias Rodríguez

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, 25 February, 2003 11:41
> To: Vijay Kumar Choudhary
> Cc: [email-masked]
> Subject: Re: Addr in INIT or INIT ACK
> 
> 
> Vijay,
> 
> The section doesn't really way what problem
> it is trying to solve, does it?
> 
> --brian
> 
> On Tue, 25 Feb 2003, Vijay Kumar Choudhary wrote:
> 
> > Hi All,
> >    In the sctp-imp-guide version 7, the following paragraph 
> is there ..
> > 
> > 2.18.3 Solution description
> >    This new text clearly specifies to an implementor the 
> need to look
> >    within the INIT or INIT-ACK.  Any implementation that does not do
> >    this, may not be able to establish associations in certain
> >    circumstances.
> > 
> > I want to know the circumstances in the which the 
> association will not be
> > established.
> > 
> > Regards,
> > Vijay
> 
> -- 
> 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 06:38:04 -0700

Ivan.Arias-Rodriguez,

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

> 	Hi Vijay and Brian!
> 
> 	Well, actually, the section doesn't specify exactly what's trying to
> 	solve... if you aren't aware in advance about what it is trying to
> 	fix, it is difficult to understand why one should do that...
> 
> 	But the answer is very easy. The point is that the INIT ACK must be
> 	sent to the source address from which the INIT chunk came. However, it
> 	can be sent from any of the available source addresses at the INIT ACK
> 	sender. Thus, if the INIT ACK receiver doesn't recognize the source
> 	address doesn't take a look inside, it can wrongly discard the chunk,
> 	not establishing the association... :-(

One can use the verification tag and destination address of the INIT ACK and
need not examine the source address or source address list.

> 
> 	About the INIT... It is a little bit trickier, but there are also some
> 	special cases... Imagine the peer restarts and sends you an INIT,
> 	including (some of) the previous address as parameters, but using a
> 	new address as the source address (or instead of this, you simply have
> 	an attacker sending you such an INIT chunk). In this case you should
> 	in fact send back and ABORT with the 'Restart of an association with
> 	new addresses' cause error. You won't be able to recognize this
> 	situation if you don't go through the addresses inside... :-/

Restart of an assoc... is only sent when addresses are added, not when the
INIT is sent to a different address already belonging to the existing
association.

Also, IG section 2.6 is quite clear the the INIT addresses need to be
examined for new addresses.  There seems little reason to vaguely repeat
this in 2.18.

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 25 Feb 2003 07:50:28 -0600

>   address different to the destination address used to send the INIT
Sounds good to me Ivan.. I will edit in for the next version we are
about to send out :>

R

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