Subject: [tsvwg] SCTP MH connectx(), INIT collisions and RFC4960 MUST

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 28 Jan 2015 14:07:48 +0100

Hi,

We have stumbled into an issue with a MUST in RFC4960 text on INIT
Collision handling.

We hope that the wg could help resolve the issue.

The issue is the following underlined text of RFC4960 (from RC4460).

Section 5.2.1 of RFC4960:

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

   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.

   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   Upon receipt of an INIT in the COOKIE-ECHOED 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),

   provided that no NEW address has been added to the forming

   association.  If the INIT message indicates that a new address has

   been added to the association, then the entire INIT MUST be

   discarded, and NO changes should be made to the existing association.

   An ABORT SHOULD be sent in response that MAY include the error

   'Restart of an association with new addresses'.  The error SHOULD

   list the addresses that were added to the restarting association.

The issue we have can be illustrated by the following example:

        A connect() towards peer address X and Y has been made at local EP.
INIT is sent to Peer address X.

       Peer EP in fact have local addresses Y and Z and an incoming
collision INIT is sent from Y including Y and Z as address parameters.

       According to the above MUST the INIT ACK should be returned to X
which will be completely in vain (of course).

Note:

It is understood that the in order to prevent association high jacking then
it is imperative that the INIT ACK be not returned to a peer address

not  specified on the local EP side as a remote address for the association
(in cookie_wait). Thus the INIT ACK cannot simply be reflected to sender
address.

Question:

Is this the intention of the RFC4960 MUST to prescribe for this exact
operation.

Possible answers:

·         Yes this is the intention, hopefully the association will be
established when local EP re-send INIT to alternative address Y

·         No,  the “MUST” is wrong and should have read – “SHOULD return to
a destination address provided in  the INIT which also is specified locally
as a peer address for the association (in cookie_wait)”

Thanks !

BR, Karen

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 28 Jan 2015 22:06:06 +0100

> On 28 Jan 2015, at 14:07, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> Hi,
>  
> We have stumbled into an issue with a MUST in RFC4960 text on INIT Collision handling.
>         A connect() towards peer address X and Y has been made at local EP. INIT is sent to Peer address X.
Do you mean sctp_connectx()? So the peer EP owns X and Y. The INIT is sent to X.
>  
>        Peer EP in fact have local addresses Y and Z and an incoming collision INIT is sent from Y including Y and Z as address parameters.
So the peer EP does not own X and Y, but Y and Z? So the INIT sent above would be dropped...
I'm not sure if I understand your example...

Best regards
Michael
>  
>        According to the above MUST the INIT ACK should be returned to X which will be completely in vain (of course).
>  
>  
> Note:
>  
> It is understood that the in order to prevent association high jacking then it is imperative that the INIT ACK be not returned to a peer address 
> not  specified on the local EP side as a remote address for the association (in cookie_wait). Thus the INIT ACK cannot simply be reflected to sender address.
>     
> Question:
>  
> Is this the intention of the RFC4960 MUST to prescribe for this exact operation.
>  
> Possible answers:
>  
> ·         Yes this is the intention, hopefully the association will be established when local EP re-send INIT to alternative address Y
> ·         No,  the “MUST” is wrong and should have read – “SHOULD return to a destination address provided in  the INIT which also is specified locally as a peer address for the association (in cookie_wait)”
>  
> Thanks !
>  
> BR, Karen

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 28 Jan 2015 22:38:22 +0100

HI Michael,

Yes the outgoing INIT would be dropped and so apparently would now also the
INIT_ACK as it following RFC4960 MUST would be
sent also to X.

However were the INIT_ACK instead send to Y, an association would come up
with peer addresses Y and Z.

The same will happen when the local side eventually decides to send the INIT
to Y instead (after timeout of original INIT).

The policy of RFC4960 to MUST send the INIT_ACK to X does not seem like a
very good thing to do.

This is the point of the example.

NB:
I understand that we need a MUST to return the INIT_ACK to an address that
is common to what has been specified locally as peer address candidates
(here X and Y) and
to what the peer indicates in the INIT (here Y and Z).

Indeed if a malicious peer owning W, sends in an INIT, from source W,
claiming to own also Z, then the INIT_ACK should not be returned to W as
this could result in association high-jacking by C.  And RFC4960 Path
Verification would do no good here to prevent this for the following two
reasons:
* Y is auto Path Verified as it has been provided from ULP (according to
RFC4960).
(Besides that peer owning address Y would not send  ABORT to HBs coming in
to Y if it continues to try to sends INITs (each INIT of course is answered
with ABORT))

But why we need a MUST to have the INIT_ACK be sent to same address as
original INIT (sent to X) is not clear to me. And this is a _MUST_ (added by
RFC4460).

Thanks !

BR, Karen

>-----Original Message-----
>From: Michael Tuexen [mailto:[email-masked]]
>Sent: Wednesday, January 28, 2015 10:06 PM
>To: Karen Elisabeth Egede Nielsen
>Cc: [email-masked]; Randall Stewart
>Subject: Re: [tsvwg] SCTP MH connectx(), INIT collisions and RFC4960 MUST
>
>
>> collision INIT
>is sent from Y including Y and Z as address parameters.
>> It is understood that the in order to prevent association high jacking
>> then it is imperative that the INIT ACK be not returned to a peer address
>> not
>specified on the local EP side as a remote address for the association (in
>cookie_wait). Thus the INIT ACK cannot simply be reflected to sender
>address.
>>
>> Question:
>>
>> established
>when local EP re-send INIT to alternative address Y
>> ·         No,  the “MUST” is wrong and should have read – “SHOULD return
>> to a
>destination address provided in  the INIT which also is specified locally
>as a
>peer address for the association (in cookie_wait)”
>>
>> Thanks !
>>
>> BR, Karen

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 29 Jan 2015 12:49:00 +0100

> On 28 Jan 2015, at 22:38, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI Michael,
> 
OK. Understood. I agree with your analysis. I see three conditions involved:
(a) The INIT-ACK MUST only be sent to an address configured by the upper layer
(b) The INIT-ACK MUST only be sent to an address reported in the incoming INIT
(c) The INIT-ACK SHOULD be sent to the source address of the received INIT.

I think the RFC actually needs to require (a) instead of limiting it to the
one address where the original INIT was sent to. (b) restricts the candidates
from (a). And I always prefer (c) in case of response packets.
> to what the peer indicates in the INIT (here Y and Z).
Correct.
> original INIT (sent to X) is not clear to me. And this is a _MUST_ (added by
The rule we are discussing was introduced in
https://tools.ietf.org/html/rfc4460#section-2.6

The path verification and the statement that the
upper layer can provide multiple peer addresses to the
sender of the INIT chunk is described in
https://tools.ietf.org/html/rfc4460#section-2.36
which is later introduced later.

The associate primitive in described in B) of
https://tools.ietf.org/html/rfc4960#section-10.1
also deals only with the possibility to provide a single
remote IP address (like the connect() call in the socket
API).

So I guess that the idea of providing multiple addresses
was introduce after
https://tools.ietf.org/html/rfc4460#section-2.6
was written. The rule is correct, if you only have a single
remote address. So at the writing, it was correct.

Later, when the idea of providing multiple peer addresses was
introduced (and sctp_connectx() was defined), neither the definition
of the Associate() primitive was updated nor the rule we are
discussing right now... At least this is what I suspect...

Best regards
Michael

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 29 Jan 2015 14:12:04 +0100

HI Michael,

Thanks a lot!

I am in perfect agreement with the proposed resolution:

(a) The INIT-ACK MUST only be sent to an address configured by the upper
layer
(b) The INIT-ACK MUST only be sent to an address reported in the incoming
INIT
(c) The INIT-ACK SHOULD be sent to the source address of the received INIT.

And this is how we would like to alter our MH SCTP to behave in this
situation.

Shall we propose for an Errata ?

BR, Karen

>Sent: Thursday, January 29, 2015 12:49 PM
>> Yes the outgoing INIT would be dropped and so apparently would now
>> also the INIT_ACK as it following RFC4960 MUST would be sent also to
>> X.
>>
>> However were the INIT_ACK instead send to Y, an association would come
>> up with peer addresses Y and Z.
>>
>> The same will happen when the local side eventually decides to send
>> the INIT to Y instead (after timeout of original INIT).
>>
>> The policy of RFC4960 to MUST send the INIT_ACK to X does not seem
>> like a very good thing to do.
>>
>one
>address where the original INIT was sent to. (b) restricts the candidates
>from
>(a). And I always prefer (c) in case of response packets.
>>
>> NB:
>> I understand that we need a MUST to return the INIT_ACK to an address
>> that is common to what has been specified locally as peer address
>> candidates (here X and Y) and to what the peer indicates in the INIT
>> (here Y and Z).
>Correct.
>>
>> claiming to own also Z, then the INIT_ACK should not be returned to W
>> as this could result in association high-jacking by C.  And RFC4960
>> Path Verification would do no good here to prevent this for the
>> following two
>> reasons:
>> * Y is auto Path Verified as it has been provided from ULP (according
>> to RFC4960).
>> (Besides that peer owning address Y would not send  ABORT to HBs
>> coming in to Y if it continues to try to sends INITs (each INIT of
>> course is answered with ABORT))
>>
>> original INIT (sent to X) is not clear to me. And this is a _MUST_
>> (added by RFC4460).
>The path verification and the statement that the upper layer can provide
>multiple peer addresses to the sender of the INIT chunk is described in
>also deals only with the possibility to provide a single remote IP address
>(like
>the connect() call in the socket API).
>
>So I guess that the idea of providing multiple addresses was introduce
>after
>was written. The rule is correct, if you only have a single remote address.
>So at
>the writing, it was correct.
>
>Later, when the idea of providing multiple peer addresses was introduced
>(and sctp_connectx() was defined), neither the definition of the
>Associate()
>primitive was updated nor the rule we are discussing right now... At least
>this
>is what I suspect...
>
>Best regards
>Michael
>>
>> Thanks !
>>
>> BR, Karen
>>
>>>> It is understood that the in order to prevent association high
>>>> jacking then it is imperative that the INIT ACK be not returned to a
>>>> peer address not
>>> specified on the local EP side as a remote address for the
>>> association (in cookie_wait). Thus the INIT ACK cannot simply be
>>> reflected to sender address.
>>>>
>>>> Question:
>>>>
>>> destination address provided in  the INIT which also is specified
>>> locally as a peer address for the association (in cookie_wait)”
>>>>
>>>> Thanks !
>>>>
>>>> BR, Karen
>>

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 29 Jan 2015 14:13:54 +0100

> On 29 Jan 2015, at 14:12, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI Michael,
> 
> Thanks a lot!
> 
Makes sense to me...

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jan 2015 07:03:12 -0700

Karen,

Karen Elisabeth Egede Nielsen wrote:        (Wed, 28 Jan 2015 14:07:48)
>    According to the above MUST the INIT ACK should be returned to
>    X which will be completely in vain (of course).

  INIT --------------------> X

  <------------------------- Y INIT (Y,Z)

  INIT ACK ----------------> X

  Why is this in vain?

  X is an address of the peer.  The state cookie contains (Y,Z).
  Why would the peer not process this INIT ACK and form the
  association?

--brian

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

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 29 Jan 2015 15:08:29 +0100

Hi Brian,

In my example  X is not an address of the peer.

BR, Karen

>From: Brian F. G. Bidulock [mailto:[email-masked]]
>Sent: Thursday, January 29, 2015 3:03 PM
>Cc: [email-masked]; Randall Stewart; Michael Tuexen

---

From: Ka-Cheong Poon <[email-masked]>
Date: Thu, 29 Jan 2015 22:15:59 +0800

On 01/28/15 09:07 PM, Karen Elisabeth Egede Nielsen wrote:
>         A connect() towards peer address X and Y has been made at 
> local EP. INIT is sent to Peer address X.
>

So no INIT has been sent to Y yet?

> X which will be completely in vain (of course).

If no INIT has been sent to Y, I guess the local SCTP probably should 
drop this INIT.  It is not an INIT collision.  If an INIT has also been 
sent to Y, the INIT-ACK responding to this crossed INIT should be sent 
back to Y, as described in RFC 4960.

> not  specified on the local EP side as a remote address for the 
> ·Yes this is the intention, hopefully the association will be 

I think this is correct since there is no INIT sent to Y at all and no 
INIT-ACK should be triggered since the INIT from Y is dropped.

> ·No,  the “MUST” is wrong and should have read – “SHOULD return to a 

I think we should not confuse protocol behavior with API goodies. At the 
protocol level, there is no INIT sent to Y, so this is not INIT 
collision and section 5.2.1. is not applicable.  If there is an INIT 
sent to Y, 5.2.1. should be followed and the INIT-ACK should be sent to Y.

-- 
K. Poon.
[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jan 2015 07:19:09 -0700

Karen,

If X does not belong to the peer, Why would it think that the
INIT from Y belongs to the association it is trying to form?
I don't see how it figures it is in the COOKIE-WAIT state...

--brian

Karen Elisabeth Egede Nielsen wrote:                                      (Thu, 29 Jan 2015 15:08:29)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jan 2015 07:21:16 -0700

Ka-Cheong,

Ka-Cheong Poon wrote:                     (Thu, 29 Jan 2015 22:15:59)
> 
>    I think we should not confuse protocol behavior with API goodies.  At
>    the protocol level, there is no INIT sent to Y, so this is not INIT

+1

--brian

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

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 29 Jan 2015 15:29:57 +0100

Hi,

The local side is in cookie_wait state as it has sent an INIT.  There can
be no question about that.
Perhaps you question is more along the lines of whether this really is  an
INIT collision scenario - ?

The local side is via connectx() configured with peer addresses X and Y,
please note that the
connectx() information is only tentative - please refer to the following
text of RFC6458 copied in below.

There is no stipulation that all the addresses given in connectx()
necessarily will become part of the association.

It this policy is assumed then the situation is much different, I agree.

BR, Karen

9.9.  sctp_connectx()

   An implementation may provide a library function (or possibly system
   call) to assist the user with associating to an endpoint that is
   multi-homed.  Much like sctp_bindx(), this call allows a caller to
   specify multiple addresses at which a peer can be reached.  The way
   the SCTP stack uses the list of addresses to set up the association
   is implementation dependent.  This function only specifies that the
   stack will try to make use of all of the addresses in the list when
   needed.

   Note that the list of addresses passed in is only used for setting up
   the association.  It does not necessarily equal the set of addresses
   the peer uses for the resulting association.  If the caller wants to
   find out the set of peer addresses, it must use sctp_getpaddrs() to
   retrieve them after the association has been set up.

>Sent: Thursday, January 29, 2015 3:19 PM
>Cc: Michael Tuexen; [email-masked]
>If X does not belong to the peer, Why would it think that the INIT from Y
>belongs to the association it is trying to form?
>Karen Elisabeth Egede Nielsen wrote:
(Thu, 29 Jan 2015
>15:08:29)

---

From: Ka-Cheong Poon <[email-masked]>
Date: Thu, 29 Jan 2015 22:41:20 +0800

> necessarily will become part of the association.

Conceptually, when sctp_connectx() is used, it can be viewed as
multiple local endpoints operating independently.  This is the
reason behind the quoted paragraph below in RFC 6458.

Using your example in the previous email, conceptually there are 2
local endpoints, one tries to talk to X and the other tries to talk
to Y.  But if the endpoint trying to talk to Y has not even sent an
INIT, an incoming INIT from Y should not be considered as an INIT
collision.  But if an INIT has been sent, the INIT-ACK should be
sent back to Y as described in RFC 4960.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 29 Jan 2015 10:50:23 -0700

Karen,

Karen Elisabeth Egede Nielsen wrote:           (Thu, 29 Jan 2015 15:29:57)
> be no question about that.

OK, but for the wrong TCB.

> INIT collision scenario - ?

It is not.

> necessarily will become part of the association.

RFC6458 is INFORMATIONAL.

> It this policy is assumed then the situation is much different, I agree.

See Ka-Cheong's remarks as to why the situation is different.

Passing a list of addresses to connect is just a way of avoiding
waiting for the entire init retries and timeout between trying
another known address.  Passing it an invalid address does not
set up a collision.

--brian

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 29 Jan 2015 21:35:55 +0100

> On 29 Jan 2015, at 18:50, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Karen,
> 
It depends, I think.

RFC 4960 allows the upper layer to provide multiple IP addresses for the peer
to connect to. See the first bullet in
https://tools.ietf.org/html/rfc4960#section-5.4
When using the socket API, this might be done by using the sctp_connectx() call
as described in
https://tools.ietf.org/html/rfc6458#section-9.9

The question is what happens when the upper layer provides more than one address.
You are assuming that a TCB can have only one peer address during initialisation.
But this is not necessary true. A TCB could have multiple peer addresses. At
least in FreeBSD we allow this.
If only one address is provided, there is no doubt what has to happen. So let us assume
endpoint A having addresses A1 and A2 and endpoint B having B1 an B2. Assume that the
routing is setup such that packets flow A1 <-> B1 and A2 <-> B2. And assume that the
flow from A1 to B1 is broken.

A binds(A1, A2);
B binds(B1, B2);
A calls sctp_connectx(B1, B2);
Now the TCB contains local addresses A1 and A2 and remote addresses B1 and B2.
Now an INIT[A1, A2] is sent from A1 to B1, but it never reaches B
B calls sctp_connectx(A1, A2)
Now the TCB contains local addresses B1 and B2 and remote addresses A1 and A2.
Now an INIT[B1,B2] is sent from B2 to A2 and it reaches A.
This is an INIT collision. Following the RFC, endpoint A has to send the INIT-ACK[A1, A2]
to B1, which is dropped again. What Karen is suggesting is that sending the INIT-ACK[A1, A2]
from A2 to B2 should also be allowed.

If you restrict TCBs to a single peer address you avoid the above, but I don't see
any reason why it is not allowed (I also see no requirement in RFC 4960 that it must be supported).

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 29 Jan 2015 21:38:37 +0100

> On 29 Jan 2015, at 15:41, Ka-Cheong Poon <[email-masked]> wrote:
> 
You are right, it "can" be viewed like that. The wording is very vague
(intentionally, if I remember correctly). But you could also view
it as one end-point with multiple remote addresses... In that case
Karens argument is correct. In you case you always have only one
peer address and there is no difference between RFC 4960 and what
Karen is suggesting.

Best regards
Michael

---

From: Ka-Cheong Poon <[email-masked]>
Date: Fri, 30 Jan 2015 15:54:18 +0800

> https://tools.ietf.org/html/rfc4960#section-5.4

It does not seem to me that point (1) in 5.4 actually means that.
The address used to send an INIT is considered confirmed because
it is this INIT packet which triggers the peer to send an INIT-ACK.
So this address cannot be "invalid", otherwise no INIT-ACK will be
sent back.  Using Karen's original example, can SCTP mark X as
confirmed in the new association?  No, it cannot.  SCTP cannot even
include X in the peer address list of the new association.  SCTP
cannot know which address is available and is being used at the peer.
It only knows that the peer responds to its INIT, so the address INIT
uses to reach the peer is valid, hence confirmed.  One INIT cannot
and must not confirm multiple peer addresses.  This is against the
spirit of section 5.4, Path Verification.

> You are assuming that a TCB can have only one peer address during initialisation.

Note that I am not talking about API nor implementation.  I am
talking strictly at the protocol level.

> least in FreeBSD we allow this.

Sure.  I expect that all SCTP implementations' PCB can hold more
than one peer address since it is SCTP which supports the use of
multiple addresses :-)

> This is an INIT collision.

I think this is not an INIT collision.  No INIT from A has been sent
to B2.  So an INIT from B2 to A2 does not "collide" with the INIT
from A1 to B1.

> Following the RFC, endpoint A has to send the INIT-ACK[A1, A2]

IMHO, this is not the proper way to think of SCTP.  This is making
the protocol semantics much more complicated as it unnecessarily
ties the protocol to implementation details.

 From an implementation point of view, using 1-1 style socket, the
example can be considered as following.  Suppose listen() has been
called by A.  When A gets the INIT (B2 to A2) from B, it can be
considered as an initialization request from B.  So an INIT-ACK
(A2 to B2) will be sent to B.  Suppose listen() has not been called,
the INIT (B2 to A2) needs to be dropped.

> any reason why it is not allowed (I also see no requirement in RFC 4960 that it must be supported).

An implementation does not need to disallow that.  But it is
implementation details.

---

From: Ka-Cheong Poon <[email-masked]>
Date: Fri, 30 Jan 2015 16:03:24 +0800

> peer address and there is no difference between RFC 4960 and what

What I am trying to say is that we should not mix implementation
details with protocol semantics.  An SCTP endpoint can certainly
have multiple peer addresses (this is required by SCTP) from an
implementation's perspective.  But IMHO, INIT collision has a
clear semantics in SCTP.  Karen's example is not an INIT collision
scenario.

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 30 Jan 2015 09:22:11 +0100

> On 30 Jan 2015, at 09:03, Ka-Cheong Poon <[email-masked]> wrote:
> 
I agree.
> clear semantics in SCTP.  Karen's example is not an INIT collision
Well, I intentionally looked at another example, where I think we
have an INIT collision. The INIT collision is not between address
pairs, but between endpoints.

Best regards
Michael

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 30 Jan 2015 09:34:11 +0100

Hi Brian,

>Sent: Thursday, January 29, 2015 6:50 PM
>> The local side is in cookie_wait state as it has sent an INIT.  There
>> can be no question about that.
>

[Karen ] The local address and peer address Y matches the TCB.
There is definitively a collision ! :-)

>
>> Perhaps you question is more along the lines of whether this really is
>> an INIT collision scenario - ?
>
>It is not.

[Karen ] There is definitively a collision on Y address.

>
>> The local side is via connectx() configured with peer addresses X and
>> Y, please note that the
>> connectx() information is only tentative - please refer to the
>> following text of RFC6458 copied in below.
>>
>Passing a list of addresses to connect is just a way of avoiding waiting
for the
>entire init retries and timeout between trying another known address.
>Passing it an invalid address does not set up a collision.

[Karen ]
The X is the address in error in this situation, not the Y address.
A MUST policy in RFC4960 to give precedence to X over Y as a valid address
does not seem very constructive.

I am fully aligned with saying that the incoming INIT should not be
rejected due to the presence of X.

Further It would not be viable to disregard the existence of the TCB when
processing the incoming INIT (if for example, the local side also would
accept
such an incoming INIT, e.g., due to it having a listening EP) and the
reasons for that is that it would open up for association high-jacking as
described from peer C.

Could you be so kind as to point to where I can find Ka-Cheong's remark ?
Thanks.

BR, Karen

---

From: Ka-Cheong Poon <[email-masked]>
Date: Fri, 30 Jan 2015 16:54:05 +0800

> pairs, but between endpoints.

You are mixing implementation details with protocol semantics.
Before an association is established, there is no way an SCTP
endpoint can know the list of peer addresses will be used in
the to be established association, except the one used to send
the INIT will be there.  So in this sense, how can you say that
the above is an INIT collision?  SCTP cannot assume that B2 will
be used in the new association created because of the INIT (A1
to B1).  Then how can the INIT (B2 to A2) be considered a
collision?  As far as SCTP is concerned, INIT (B2 to A2) is an
out of the blue packet from B2.

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 30 Jan 2015 09:56:41 +0100

> On 30 Jan 2015, at 08:54, Ka-Cheong Poon <[email-masked]> wrote:
> 
Well, I think it makes clear that the upper layer can provide multiple
addresses during association setup. One way to handle this is to
create an end-point with multiple peer addresses (all of them confirmed).
> it is this INIT packet which triggers the peer to send an INIT-ACK.
One way to look at it. Another way: All addresses provided by the
upper layer are considered confirmed. This is what section 5.4 says.

Assume the client calls
sctp_bindx(A1, A2);
sctp_connectx(B1, B2);
Then you see on the wire:
A1->B1: INIT[A1, A2]
B1->A1: INIT-ACK[B1, b2]
A1->B1: COOKIE-ECHO
B1->A1: COOKIE-ACK
Now the client send user data and it is valid that you see
A2->B2: DATA

This would not be OK, if the client would have called connect(B1) or sctp_connectx(B1).
> cannot know which address is available and is being used at the peer.
Well, it would be when the end-point is in COOKIE-WAIT. After the
handshake has completed, the peer address would be removed from the association.
> spirit of section 5.4, Path Verification.
The spirit of section 5.4 in my understanding is that path verification
makes sure that the peer doesn't lie about its addresses. So they need
to be confirmed via the HB procedure. However, the stack trusts its upper
layer. That is what point 1) of
https://tools.ietf.org/html/rfc4960#section-5.4
is about.
> talking strictly at the protocol level.
I agree. If the API allows the upper layer to provide multiple addresses
or a single on is an API issue. If the upper layer allows this and you
allow an TCB to handle multiple addresses already in COOKIE-WAIT I think
my example show an INIT collision at the protocol level.
> than one peer address since it is SCTP which supports the use of
Sure... But I had the impression that when I call
fd = socket();
sctp_connectx(fd, {B1, B2}, 2);
you were considering it as two TCBs each having a single remote address.
I consider it a single TCB having two remote addresses.
I think we agree that we both end up with a single TCB having two remote addresses.
> to B2.  So an INIT from B2 to A2 does not "collide" with the INIT
I consider a collision on the end-point base, not on the address pair base.
The INIT received by A comes from B2 goes to A1 and contains A1 and A2. So A
can find the TCB which has the local addresses A1 and A2 and remote addresses B1 and B2.
So I consider it a collision.
http://tools.ietf.org/html/rfc4960#section-5.2.1
talks about receiving an INIT in COOKIE-WAIT. Endpoint A is in COOKIE-WAIT...
> ties the protocol to implementation details.
I think it is an INIT collision and the condition introduced when moving
from RFC 2960 to RFC 4960 is stricter than necessary.
> the INIT (B2 to A2) needs to be dropped.
Sure. But I'm looking at the collision case. Concentrating on A this would mean
fd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP);
sctp_bindx(3, {A1, A2}, 2);
sctp_connectx(3, {B1, B2}, 2, ...);
Now you would see an INIT[A1, A2] from A1 to B1.
If endpoint now receives an INIT[B1, B2] from B2 to A2, it looks up the TCB
and finds it (because the upper layer provided B2 as a peer address),
it is in COOKIE-WAIT and therefore it is an INIT collision.
It should be allowed to send the INIT-ACK[A1, A2] from A2 to B2.
> An implementation does not need to disallow that.  But it is
Agreed.

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 30 Jan 2015 01:58:32 -0700

Karen,

Karen Elisabeth Egede Nielsen wrote:           (Fri, 30 Jan 2015 09:34:11)
> There is definitively a collision ! :-)

Well, no.

INIT #1   (A,B) --- (X)

INIT #2   (Y,Z) --- (A)

This is a disjoint set of transport addresses.
By definition, there is no collision.

If you are adding (Y)--an unverified address--to 
the TCB of INIT #1 before forming the association,
that is your problem, not that of the protocol or
the peer.

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

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 30 Jan 2015 10:05:48 +0100

Hi Brian,

The X is just as verified as the Y. There really is no difference from a
protocol perspective. Both X and Y are configured by the ULP.

The RFC4960 MUST text seems to refer to a situation where only one peer
address is given to the SCTP layer.
This protocol restrictions is not in the RFC4960 and further it is a
restriction not followed by SCTP socket api implementations
supporting connextx(). (And I think that we can could write a book about
the deployment merits of connectx() in terms of providing a robust
interworkable operation...)

I would say that the RFC4960 MUST seems to refer to a particular situation
and that the general text should indeed by as specified by Michael:

 The INIT-ACK MUST only be sent to an address configured by the upper
layer
 The INIT-ACK MUST only be sent to an address reported in the incoming
INIT
 The INIT-ACK SHOULD be sent to the source address of the received INIT.

BR, Karen

>Sent: Friday, January 30, 2015 9:59 AM
>> >> The local side is in cookie_wait state as it has sent an INIT.
>> >> There can be no question about that.
>> >
>If you are adding (Y)--an unverified address--to the TCB of INIT #1
before
>forming the association, that is your problem, not that of the protocol
or the
>peer.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 30 Jan 2015 02:20:14 -0700

Karen,

Karen Elisabeth Egede Nielsen wrote:        (Fri, 30 Jan 2015 10:05:48)
> protocol perspective. Both X and Y are configured by the ULP.

No, when I launch the INIT to X, I cannot know that Y
will be part of the association.  So Y is not part of
the association until the peer tells me so in an INIT-ACK.
When the peer sends it in an INIT-ACK, I can treat Y
as "confirmed" and not send nonces to it; but until I
receive it in the INIT-ACK it is not part of the association.
I cannot predict (particularly based solely on erroneous
user input) what addresses the peer might want to add
to the association.  I only know that X is part of it.

Thus,

INIT #1 (A,B) -- (X)

INIT #2 (Y,Z) -- (A)

Remember, INITs are OOTB.  INIT #2 could have come
from anywhere.  We do not let A/B send INIT #1 to any
other address just because an OOTB packet told it to.

It is only harmless for us to send INIT#1 to the same
address that it was originally sent.

--brian

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

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 30 Jan 2015 10:30:03 +0100

Hi Brian,

>
>No, when I launch the INIT to X, I cannot know that Y will be part of the
>association.
[Karen ]

You must then be referring to your particular implementation of SCTP.

An SCTP implementation supporting connectx() are aware of this.

NO WHERE in the normative parts of RFC4960 is it said that you only know
one peer address when you send your (first) INIT.

Further in section 5.4 of RFC4960 it is said:

   1)  Any address passed to the sender of the INIT by its upper layer
      is automatically considered to be CONFIRMED.

>So Y is not part of the association until the peer tells me so in an
>INIT-ACK.
>When the peer sends it in an INIT-ACK, I can treat Y as "confirmed"
[Karen ]
You can definitively NOT consider Y as CONFIRMED just because peer gives
it to you.
This is why Path Verification is specified. This is explained in RFC5062.

and not
>send nonces to it; but until I receive it in the INIT-ACK it is not part
of the
>association.
>I cannot predict (particularly based solely on erroneous user input) what
>addresses the peer might want to add to the association.  I only know
that X is
>part of it.
[Karen ] You know no more about X than you know about Y at this time in
stage.
>
>Thus,
>
>INIT #1 (A,B) -- (X)
>
>INIT #2 (Y,Z) -- (A)
>
>Remember, INITs are OOTB.  INIT #2 could have come from anywhere.  We do
>not let A/B send INIT #1 to any other address just because an OOTB packet
>told it to.
>
[Karen ] This is NOT the situation described. The situation described is
the situation where ULP has specified Y as well as X.

BR, Karen
>It is only harmless for us to send INIT#1 to the same address that it was
>originally sent.
>
>--brian
>
>--
>Brian F. G. Bidulock
>[email-masked]
>http://www.openss7.org/

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 30 Jan 2015 11:08:21 +0100

> On 30 Jan 2015, at 09:58, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Karen,
> 
Brian,

Karens example mixes two issues:
1. X is contained in the addresses by the upper layer but is actually not
   an address of the peer.
2. You receive an INIT and can find the TCB if you take all addresses
   provided by the upper layer into account.
Let discuss them separately.

The issue with the text in the RFC is related to the second issue. That is
why I provided a different example.

Taking the multiple addresses into account, in the your scenario above you
show correctly the addresses on the the wire. However, the lokal endpoint sending
the first INIT has X and Y configured as remote addressees. Therefore it can
find the TCB for the second INIT.
> that is your problem, not that of the protocol or
Well, the protocol allows that (I wouldn't say it  requires it), but
if you all adding Y to the association, you can retransmit the INIT #1
after a timeout sending it to Y.

Dealing with the case that X actually doesn't belong to the peer adds
some complexity to the implementation is a consequence of supporting
multiple addresses during setup.

---

From: Ka-Cheong Poon <[email-masked]>
Date: Sat, 31 Jan 2015 00:08:42 +0800

> upper layer are considered confirmed. This is what section 5.4 says.

I guess you are saying that "Any address" used in 5.4 means "all
address".  My re-collection of RFC 4460 (discussed during SCTP
inter-ops) is that an address can only be confirmed if SCTP has
sent a packet to that address and this triggers a reply from peer.
It never occurred to me that the sentence may mean what you wrote
above since IMHO it is against the spirit of path verification.

> Now the client send user data and it is valid that you see

I'd say this is not valid since B2 is not confirmed as nothing
has ever been sent there.  And from a practical point of view, it
is also not desirable since SCTP does not even know if B2 is
reachable.  It makes more sense to start sending data to a known
reachable address.

> handshake has completed, the peer address would be removed from the association.

This is very strange.  And this kind of "automatic" address removal
is never mentioned anywhere in the protocol spec.  I think this is
introducing something new which is not covered in RFC 4960.  It is
also not talked about in RFC 5061.  Correct?  And you are saying
that RFC 4960 has an issue and this new introduction illustrates the
problem.  Right?

> https://tools.ietf.org/html/rfc4960#section-5.4

I guess we both understand what we are disagreeing with.  Is the
following summary correct?  Your interpretation introduces a
protocol detail (automatic peer address removal) not covered in
RFC 4960 and this causes an issue in sending INIT-ACK.  My
understanding of RFC 4960 is that things are OK and at the same
time, implementation can send the INIT-ACK without a problem.
Do you agree?

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 30 Jan 2015 22:48:28 +0100

> On 30 Jan 2015, at 17:08, Ka-Cheong Poon <[email-masked]> wrote:
> 
I'm not a native speaker so I might not got the meaning right.
If the upper layers passes B1 and B2 to the sender of the INIT
and the INIT-ACK contains B1, B2, B3 and B4.
My understanding is that B1 and B2 are confirmed by point (1) and
B3 and B4 are not confirmed by point (3). What is your understanding
of the text?
> sent a packet to that address and this triggers a reply from peer.
My understanding is that addresses passed to the sender of the INIT
are also confirmed. In case only a single address is provided, our
views are the same. The difference is only when passing multiple addresses.
> above since IMHO it is against the spirit of path verification.
I don't think so. As I wrote: The spirit of  path verification is
to deal with the problem that the peer can lie about the addresses
the peer owns. I think this is expressed clearly in
https://tools.ietf.org/html/rfc4460#section-2.36.1
> has ever been sent there.  And from a practical point of view, it
It is confirmed by point (1) of
https://tools.ietf.org/html/rfc4960#section-5.4
not by the heartbeat procedure.
> reachable.  It makes more sense to start sending data to a known
True. I only wanted to make clear what is allowed, what not.
> is never mentioned anywhere in the protocol spec.  I think this is
That is correct. When the upper layer provides multiple peer addresses
you need to deal with the case the list of addresses peer provided in the
INIT-ACK is different from that. That is why
https://tools.ietf.org/html/rfc6458#section-9.9
contains
   Note that the list of addresses passed in is only used for setting up
   the association.  It does not necessarily equal the set of addresses
   the peer uses for the resulting association.
The way how to deal with this is implementation dependent. In FreeBSD
we just remove the peer address.
> also not talked about in RFC 5061.  Correct?  And you are saying
Correct. Since no ASCONF is on the wire.
> that RFC 4960 has an issue and this new introduction illustrates the
No.

The whole argument is that it is allowed (not required)
that an endpoint can have multiple peer addresses in COOKIE-WAIT state
and when receiving an INIT it is OK to send the INIT-ACK to any address
which is (provided by the upper layer) AND (presented in the INIT),
preferably the source address of the received INIT. That was the issue
reported by Karen. Not more, not less.
> time, implementation can send the INIT-ACK without a problem.
The whole point of the discussion is that RFC 4960 says in
https://tools.ietf.org/html/rfc4960#section-5.2.1

   When
   responding, the endpoint MUST send the INIT ACK back to the same
   address that the original INIT (sent by this endpoint) was sent.

and it would be better to say
   When
   responding, the endpoint MUST send the INIT ACK back to an address
   which is provided by the upper layer and which is also present in
   the received INIT. If possible, it SHOULD be sent to the source
   address of the received packet containing the INIT chunk.

Please note that in the case that only a single address is provided
by the upper layer (for example connect() was used), both texts
are equivalent. If more addresses are provided, the suggested text
is a bit more flexible.

The other issue related to the removal of an address is another issue
not currently under discussion and I think we don't need a text change for this.
So what do you think regarding the above text change?

Best regards
Michael