Subject: [tsvwg] SCTP MH multiple destination address assignment and RFC4960

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 4 Feb 2015 14:48:35 +0100

HI,

My conclusion is that the discussion clearly demonstrate that there is no
wg consensus on what the text of RFC4960 specifies in terms

of how multiple peer addresses assigned to an EP prior to the handshake is
handled from a protocol perspective.

Our commercial and deployed SCTP MH implementation, which was developed at
the time of the making of RFC4460 and RFC2960bis/RFC4960, implements the
semantics of connectx()  as well as, we thought, a fully compliant
RFC4460/RFC4960 SCTP MH handshake behavior. Except for the much discussed
MUST  of section  5.2.1 (path selection for INIT ACK return for INIT
collision scenario).

In terms of the argumentation against the interpretation of RFC4460/RFC4960
text supported at least by FreeBSD SCTP implementation and our SCTP MH
implementation when multiple addresses are provided the following arguments
have been given. I will try to address each one below and give my point of
view.

#1:

“I did a quick check on RFC 4960, similar text is also used in section
5.1.  It is the normal case when sending back an INIT-ACK.  So what address
to use in sending INIT-ACK is consistent in RFC 4960.  It can be confusing
to make them different.”

But indeed:

In Section 5.1 it is said

   An endpoint MUST send the INIT ACK to the IP address from which it

   received the INIT.

In Section 5.2.1 it is said

   When responding, the endpoint MUST send the INIT ACK back to the same

   address that the original INIT (sent by this endpoint) was sent.

Thus the situations indeed are different and there are very good reasons
for this when there are multiple destination addresses associated

(In my  opinion and interpretation).

It has been claimed that the intended meaning of the second paragraph of
Section 5.2.1  should be something like:

   When responding, the endpoint MUST send the INIT ACK back to the IP
address which it

   received the INIT from just as in the normal situation. BTW this
corresponds to the  address that the original INIT (sent by this endpoint)
was sent to as there otherwise would not be an INIT collision.

Here I am not even sure you mean “original” – perhaps you mean “last sent
to” – or ?

I agree that the first MUST of section 5.1 needs to be changed to a SHOULD
to accommodate for that the text of section 5.2.1 means anything but “MUST
return to source of INIT” in this very particular situation. But on the
other hand if this “MUST return to source of INIT” was the intended
interpretation of the text of Section 5.2.1, then I think the text is so
far away from what it should say that it is unreasonable to expect  that
there was wg consensus on what it meant.

My interpretation is that this issues was not fully thought through at the
time when specifying the text of RFC4460/RFC4960 or intentionally was left
vague indeed to allow for a different interpretation than “MUST return to
source of INIT”  when there were multiple destination addresses assigned
(then unfortunate even if vague it ended up being wrong). My conclusion
would be that we need to agree on a clarification of the INIT collision
text for which wg consensus can be reached when multiple destination
addresses are provided from UL to SCTP layer (INIT sender).

#2: Destination addresses of the TCB in cookie_wait state and INIT
collision handling.

When determining what is an INIT collision situation when multiple
destination addresses are specified,  the text of section 5.1.2 D) is what
we have from RFC4960:

   D) An INIT or INIT ACK chunk MUST be treated as belonging to an

      already established association (or one in the process of being

      established) if the use of any of the valid address parameters

      contained within the chunk would identify an existing TCB.

It is correct that RFC4960 says nothing in the normative parts about that
multiple destination addresses provided to SCTP layer for a particular TCB
is put in the TCB – but it does not says the contrary either. The fact that
RFC4960 is mute about this issue cannot on the other hand be considered wg
consensus on that a TCB  in cookie_wait state, when multiple addresses have
been provided, contains only the destination address that the INIT last is
sent to for this TCB.

#3: What constitutes a CONFIRMED address in terms of RFC4960 Path
Verification:

Section 5.4 1) says

   1)  Any address passed to the sender of the INIT by its upper layer

      is automatically considered to be CONFIRMED.

It has been claimed, in this discussion, that the wg consensus expressed by
these lines is:

            (#)    “The INIT chunk may be send to any address provided by
its upper layer.  The only address CONFIRMED for an INIT sender is the

                address  for which an INIT has been send and a
corresponding INIT ACK has been received. “

First of all then I note that if multiple destination addresses are
associated with an EP and INITs have been transmitted to multiple of those,
 then SCTP may not unambiguously  determine which of the destination
addresses that hereby was CONFIRMED. Well possibly if different vtags are
used for the different INITs, but this is no-where prescribed in RFC4960.

Secondly then again I would conclude that the text (#) is so far from what
is written in 5.4 1) that I cannot agree to that 5.4 1) should represent a
wg consensus of not just simple exactly what is written in 5.4 1). Namely
that all addresses specified from ULP to INIT sender are CONFIRMED from the
perspective of RFC4960 Path Verification.

Conclusion:

I think we need to accept that RFC4960 does not clearly specify the
multiple address situation and that we need to clarify some of the text of
RC4960 in this respect, but also that we need not change any of the RFC4960
intended semantics for doing this clarification as we do not want to do
anything different from what was intended by RFC4960 SCTP protocol
prescription.

BR, Karen

*******************************************************************************************

*Karen Egede Nielsen*

Software Architect, Ph.D.

*Ericsson**, *

Ericsson DUNC,

Kistavägen 25, 164 80 Stockholm, SWEDEN

Direct Phone / Mobile +45 25134336

E-mail: [email-masked]

www.ericsson.com

*****************************************************************************************