Subject: [Tsvwg] SCTP Init collision, MIS & OS values

From: "Vadim Borisov" <[email-masked]>
Date: Mon, 19 Jun 2006 14:07:34 +0400

Hello,

I've got a question about MIS/OS handling during INIT collision.
Here's the problem description:

We have 2 nodes with multihomed endpoints on both sides:
endpoint on Node1: {IP1, IP2, PORT}
endpoint on Node2: {IP3, IP4, PORT}
IP3 is disabled (pulled out).
Node1 is trying to establish association with remote IP3
At the same time Node2 is trying to establish association with remote IP1

IP1 -- INIT (MIS=256, OS=256) --> IP3 (unsuccessfully)
...(t1 expires, local rotation)...
IP2 -- INIT (MIS=256, OS=256) --> IP3 (unsuccessfully)
...(Node2 is sending INIT)...
IP4 -- INIT (MIS=17, OS=17) --> IP1
Here we have problem.
SCTP in its COOKIE_WAIT state has INIT collision.

>From the one point, RFC 2960bis states:

5.2.1. INIT received in COOKIE-WAIT or COOKIE-ECHOED State (Item B)
"Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST respond
with an INIT ACK using the same parameters it sent in its original INIT
chunk (including its Initiation Tag, unchanged)."

from the another point:

3.3.3. Initiation Acknowledgement (INIT ACK) (2):
"Number of Outbound Streams (OS): 16 bits (unsigned integer) Defines the
number of outbound streams the sender of this INIT ACK chunk wishes to
create in this association. The value of 0 MUST NOT be used, and the value
MUST NOT be greater than the MIS value sent in the INIT chunk."

Are rules in ch. 5.2.1 applied for MIS/OS values? In this case we'll break
ch. 3.3.3 rules and association will never establish.

In our implementation SCTP on Node1 responds with the same parameters it
sent in its original INIT chunk (according 5.2.1):
IP1 -- INIT_ACK(MIS=256, OS=256) --> IP4
...(Node2 checks parameters and aborts association)...
IP4 -- ABORT(error cause 0x07 "Invalid Mandatory parameter") --> IP1

In additional:
Also, ch. 5.2.1 states:
"When responding, the endpoint MUST send the INIT ACK back to the same
address that the original INIT (sent by this endpoint) was sent to."
In this case SCTP should send its INIT_ACK to dead IP address and
association won't be established either.

I couldn't find here discussion regarding this inconsistency.
Please clarify.

Thank you in advance,
Vadim Borisov

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Jun 2006 05:29:22 -0600

Vadim,

Vadim Borisov wrote:                                  (Mon, 19 Jun 2006 14:07:34)
>    "Upon  receipt  of  an INIT in the COOKIE-WAIT state, an endpoint MUST
>    respond  with  an  INIT  ACK  using the same parameters it sent in its
>    original INIT chunk (including its Initiation Tag, unchanged)."
>    from the another point:

No, this doesn't apply to MIS and OS: these have different meaning altogether
in the INIT and INIT-ACK (i.e. they are not the same paramters).  In the INIT
they are offered values, in the INIT-ACK they are negotiated values.

> 
>    In  our implementation SCTP on Node1 responds with the same parameters
>    it sent in its original INIT chunk (according 5.2.1):

Don't do that: these should he the negotiated values MIS=17, OS=17.

>    IP4 -- ABORT(error cause 0x07 "Invalid Mandatory parameter") --> IP1

Then this won't happen.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Vadim Borisov" <[email-masked]>
Date: Tue, 20 Jun 2006 18:14:28 +0400

Hi,

Brian, thanks a lot for your clarification about MIS/OS negotiation.

But it's still unclear what's expected behaviour when one node tries to
establish association with dead IP and INIT collision occurs.
I my case there're edpoints: Node1: {IP1, IP2, PORT}, Node2: {IP3, IP4,
PORT}
IP3 is disabled (pulled out).
IP1 -- INIT --> IP3 (unsuccessfully)
...(t1 expires, local rotation)...
IP2 -- INIT --> IP3 (unsuccessfully)
...(Node2 is sending INIT)...
IP4 -- INIT --> IP1
When Node1 receives INIT chunk from Node2 in COOKIE-WAIT state it must
respond with INIT_ACK to the same address that the original INIT (from
Node1) was sent to, RFC 2960bis states (ch. 5.2.1)
But this remote address (IP3) is disabled and the association seems never to
be established.

Should SCTP on Node1 respond with INIT_ACK to the address that incoming INIT
from Node2 was sent from (i.e. IP4) in this case? Should SCTP add new IPs
from incoming INIT to TCB on Node2 in COOKIE_WAIT state?

Thank you,
Vadim

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Jun 2006 09:16:07 -0600

Vadim,

Vadim Borisov wrote:                       (Tue, 20 Jun 2006 18:14:28)
> 
>    But  it's  still unclear what's expected behaviour when one node tries
>    to establish association with dead IP and INIT collision occurs.

The side sending the INIT to the dead address can always choose to send
an INIT to the other address, in which case the collision will resolve.
We had a long discussion on sctp-impl about this.  I poison the cookie
and send it to the source of the INIT.  If the poisoned cookie is
returned in COOKIE-ECHO and everything else is OK, I form the
association.  But others were convinced that what works for me in
practice is impossible in theory.  See the sctp-impl archives for
details.  The new rfc2960bis should get rid of most of these problems
because cookies will contain nonces instead of exposing verification tas
in tie tags.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/