Subject: [Tsvwg] Multihoming during SCTP 4-way handshake?

From: Tim Stevens <[email-masked]>
Date: Fri, 21 Nov 2008 10:55:38 +0100

Dear WG experts,

First of all I would like to apologize if I have sent this message to the wrong list.
For me, it is not clear how SCTP should react, given the 2 scenarios described below.
Consider a client with a single interface C1 and a multi-homed server with interfaces S1 and S2.

Scenario 1:
The following sequence of events occurs:
1) C1 sends INIT to S1
2) S1 receives the request, but prefers to use interface S2
3) S2 sends INIT ACK + ADDRESS PARAMETERS S2,S1 to C1
4) interface S1 becomes unreachable (due to some network event)
Now, according to RFC4960, does C1 handle this as follows?
5) C1 sends COOKIE ECHO to S1 (only CONFIRMED address) ---> FAILS!
6) C1 sends COOKIE ECHO + HEARTBEAT to S2 (because S2 is UNCONFIRMED?)
7) S2 sends COOKIE ACK + HEARTBEAT ACK to C1
8) connection ESTABLISHED
Is this correct?

Scenario 2:
Consider that both hosts support RFC5061. Is the following sequence of events correct?
1) C1 sends INIT to S1
2) S1 receives the request, but prefers to use interface S2
3) S2 sends INIT ACK + ADDRESS PARAMETERS S2,S1 + SET PRIMARY ADDRESS S2 to C1
4) interface S1 becomes unreachable (due to some network event)
5) C1 sends COOKIE ECHO + HEARTBEAT to S2 (because S2 is UNCONFIRMED?)
6) S2 sends COOKIE ACK + HEARTBEAT ACK to C1
7) connection ESTABLISHED

Any help/clarification/correction would be greatly appreciated.

Best regards,

Tim

---

From: Randy Stewart <[email-masked]>
Date: Fri, 21 Nov 2008 06:06:41 -0500

> 8) connection ESTABLISHED

Yes in fact I think you will find this very wording in
section 5.4 bullet item 4. Of course this is only true
if the client only provided S1 in the INIT. If the client
application used  sctp_connectx() with S1 and S2, then
the Heartbeat would not be necessary...

> 7) connection ESTABLISHED

When S2 sends the INIT it is not legal for it to bundle a
Set-Primary in it. The INIT and INIT-ACK chunks are specifically
prohibited from having any other chunks bundled with them.

S2 could send the INIT-ACK (remember it has no state either)... and
when the cookie arrives it could send

COOKIE-ACK, SET-PRIMARY.

Another interesting thought about your scenario is it also illustrates
another common problem that new SCTP stacks fail to think about..

when this occurs

IP:C1 ---INIT()-----IP:S1----->
<-----IP:C1--INIT-ACK(S1,S2)---IP:S2---

Since S is preferring (via routing or other wise) this is interesting
since:

1) For C1, S1 is still the confirmed address, since C1 sent the INIT
    to S1.. it does not matter what the "src (i.e. S2)" is.

2) C1 must look inside the INIT-ACK to find S1 in the list of addresses
    to be sure the packet is associated with the connection it was  
trying
    to set up.

Hope that helps...

R

> Any help/clarification/correction would be greatly appreciated.

-----
Randall Stewart
[email-masked]

---

From: Tim Stevens <[email-masked]>
Date: Fri, 21 Nov 2008 12:36:23 +0100

Dear Randy,

Thanks alot for your help!

Considering scenario 2, see my comments below.

> when the cookie arrives it could send

I think I must have misunderstood RFC5061 in this case... The last paragraph in Section 4.2.4 reads:
   "Valid Chunk Appearance

   The Set Primary IP Address parameter may appear in the ASCONF, the
   INIT, or the INIT-ACK Chunk Type.  The inclusion of this parameter in
   the INIT or INIT-ACK can be used to indicate an initial preference of
   primary address."

How should I interpret this paragraph?

Best regards,

Tim