Subject: Re: Addr in INIT or INIT ACK

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Feb 2003 07:05:18 -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.
> 
> 	I think this has been discussed many times... You are not supposed to
> 	use the VT to identify associations... This is not how the protocol
> 	works...

Where is it written that "You are not supposed to use the VT to identify
associations..." ???  As it is neither forbidden nor counter-recommended in
the RFC it is permitted.

And in situations like this it is particularly efficient.

--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: <[email-masked]>
Date: Tue, 25 Feb 2003 15:53:48 +0200

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

	I think this has been discussed many times... You are not supposed to use the VT to identify associations... This is not how the protocol works...

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

	I was meaning the source address of the INIT, not the destination...

	If you receive an INIT and you don't look inside the parameters, how do you know if the INIT comes from a new peer, of it is a peer with whom you already have an association but it is adding addresses (to start with the source address of the INIT)?

	Or, if a peer is restarting, how do you know it is simply restarting or it is also adding addresses? You have to look inside the INIT...

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

	One section is for "special" cases (duplicate packets), while the other is for normal ones... Maybe they could be merged... :-/

	BR Iván Arias Rodríguez

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

---

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

>And in situations like this it is particularly efficient.
Well, if you look at the key terms... RFC2960 states:
"
   o  SCTP association: A protocol relationship between SCTP endpoints,
      composed of the two SCTP endpoints and protocol state information
      including Verification Tags and the currently active set of
      Transmission Sequence Numbers (TSNs), etc.  An association can be
      uniquely identified by the transport addresses used by the
      endpoints in the association.  Two SCTP endpoints MUST NOT have
      more than one SCTP association between them at any given time.
"

Note that Verification Tags are considered state... and the transport 
addresses
can be used to uniquely identify an association... the V-Tags were never 
intended
to be used as a method to identify the association (thats why you
do not find it mentioned above).... you may be
able to use it has an optimization (depending on your implementation and
how you assign v-tags of course)...but this is your implementation
details...

R

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

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 26 Feb 2003 14:58:05 -0600

On 2/25/03, Brian F. G. Bidulock wrote:

>Where is it written that "You are not supposed to use the
>VT to identify associations..." ???  As it is neither
>forbidden nor counter-recommended in the RFC it is
>permitted.
>

I have also always assumed that the VT was where you began
your search for the association. That is, you looked up the
VT in order to find the list of valid Sources and the list
of valid Destinations for this association (and you assigned
the VTAGs so that there was at most one association for
each).

And while I can't find where it is forbidden to use the VT
for identification, I believe the intent is clearly that it
is supposed to provide *additional* protection against
spoofed packets. Using it *instead* of checking the source
of the packet is undermining your ability to detect spoofs.

I also fail to to see the benefit of not checking.

If the association is single-homed on both ends, then the
check is a simple comparison.

If there are multiple valid remote addresses, then they have
to be checked eventually anyway. Congestion control is
dependent on which remote address was used. How do you
do that without looking at the address?

Similarly, the destination address should affect how SACKs
are generated. How do you that without looking? Surely
allowing a reply to be hijacked by providing an incorrect
address is incorrect behavior.

Caitlin Bestler
http://asomi.com/CaitlinBestler/