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

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Mon, 2 Feb 2015 14:18:37 +0100

HI,

I fully support Michaels view in this discussion - and I may add that
it further is in complete agreement with our understanding and
implementation of
SCTP MH, including the RFC4960/RFC5062 Path Verification aspects of the
protocol.

I thus support Michael's proposal for update of the RFC4960 text in this
respect.

BR, Karen

>-----Original Message-----
>From: tsvwg [mailto:[email-masked]] On Behalf Of Michael Tuexen
>Sent: Friday, January 30, 2015 10:48 PM
>To: Kacheong Poon
>Cc: [email-masked]
>Subject: Re: [tsvwg] SCTP MH connectx(), INIT collisions and RFC4960 MUST
>
>
>> On 30 Jan 2015, at 17:08, Ka-Cheong Poon <[email-masked]>
>wrote:
>>
>> On 01/30/15 04:56 PM, Michael Tuexen wrote:
>>
>>>>> 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
>>>>
>>>>
>>>> It does not seem to me that point (1) in 5.4 actually means that.
>>> 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).
>>>> 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.
>>> 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.
>>
>>
>> I guess you are saying that "Any address" used in 5.4 means "all
>> address".  My re-collection of RFC 4460 (discussed during SCTP
>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?
>> 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.
>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.
>> It never occurred to me that the sentence may mean what you wrote
>> 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
>>
>>
>>> 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
>>
>>
>> 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
>It is confirmed by point (1) of
>https://tools.ietf.org/html/rfc4960#section-5.4
>not by the heartbeat procedure.
>> 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.
>True. I only wanted to make clear what is allowed, what not.
>>
>>
>>> This would not be OK, if the client would have called connect(B1) or
>sctp_connectx(B1).
>>>> 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.
>>> 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.
>>
>>
>> This is very strange.  And this kind of "automatic" address removal 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.
>> introducing something new which is not covered in RFC 4960.  It is
>> 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
>> problem.  Right?
>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.
>>
>>
>>>> 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.
>>> 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.
>>
>>
>> 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?
>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
>>
>>
>> --
>> K. Poon.
>> [email-masked]
>>
>>
>>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 2 Feb 2015 06:40:41 -0700

Karen,

It is not a collision because the first association (INIT) 
MUST include X, where as the second association (INIT) does
not include X.

There is nothing stopping your API from abandoning INIT #1
and accepting INIT #2; however, from a protocol perspective,
by definition, these are different associationas and there
is no collision.

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

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 2 Feb 2015 15:09:37 +0100

> On 02 Feb 2015, at 14:40, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Karen,
> 
Please have a look at the example I gave... Dealing with
remote addresses provided by the peer which are not reported
by the peer is a different issue.

Best regards
Michael

---

From: Ka-Cheong Poon <[email-masked]>
Date: Mon, 02 Feb 2015 22:12:56 +0800

On 01/31/15 05:48 AM, Michael Tuexen wrote:
>
>> On 30 Jan 2015, at 17:08, Ka-Cheong Poon <[email-masked]> wrote:
>>
>>>>> RFC 4960 allows the upper layer to provide multiple IP addresses for the peer
>>>>> to connect to. See the first bullet in
>>> 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).
>>>> 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.
> If the upper layers passes B1 and B2 to the sender of the INIT
> and the INIT-ACK contains B1, B2, B3 and B4.
> B3 and B4 are not confirmed by point (3). What is your understanding
> of the text?

My understanding is that it is only one address (any means any
types of address, such as any scope) used to send the INIT is
confirmed.  The reason is simply that the peer will respond to
the INIT.  This is consistent with how all other peer addresses
are confirmed.  To me, consistency is important.  There is no
special handling.  If it had occurred to me that point (1) may
mean what you meant, I would have objected to it when RFC 4460
was written.  It is also not consistent with other parts of RFC
4960.  There is never any mentioned that the list of peer
addresses exists prior to INIT/INIT-ACK handshake.  And this
list of peer addresses needs to be operated on when the INIT/
INIT-ACK handshake completes.

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

As I mentioned, I understand what you meant.  I just don't
agree with that.

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

So you agree that it is actually not desirable.  Correct?

>>> This would not be OK, if the client would have called connect(B1) or sctp_connectx(B1).
>>> 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
> you need to deal with the case the list of addresses peer provided in the
> INIT-ACK is different from that. That is why

We are talking about RFC 4960 here, not RFC 6458.  As I
repeatedly said, we should not confuse API with protocol
specification.  After all, RFC 6458 is just an informational
RFC.  You are introducing a new detail in the protocol
specification which is never mentioned in RFC 4960.  Do you
agree with that?

BTW, I have also mentioned what the above paragraph in
RFC 6458 meant.  I understand that you may not agree.  But
I am pretty sure that what I wrote before was the original
rationale of the above paragraph.

> The way how to deal with this is implementation dependent. In FreeBSD
> we just remove the peer address.

We don't need to discuss implementation details.  What we need
to discuss is that you are introducing a new protocol detail
which is not specified in RFC 4960.

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

I understand your argument.  And I am saying that your argument
depends on a new introduction to the SCTP specification.  Can
you point out where in RFC 4960 this address removal is mentioned?
And where in RFC 4960 specifies that there is a list of peer
addresses prior to the completion of INIT/INIT-ACK?

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

No, this is *not* the point of discussion!  The reason is simply
that without your new introduction, the paragraph below in RFC
4960 *does not* have any problem.  I have already pointed this
out in my previous email.

>     address of the received packet containing the INIT chunk.

The point of discussion is that you explicitly introduce a new state
to the protocol specification.  This state specifies that there is
a list of peer addresses associated with an embryonic association
before the INIT/INIT-ACK handshake.  And this list of peer addresses
needs to be operated on after the handshake.  This is the key thing
in the discussion.

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

As I mentioned, I don't think RFC 4960 has a problem.  The problem
is that you introduce a new protocol detail which breaks RFC 4960.
And IMHO, this new introduction is not needed and is not useful.  In
fact, it is also not desirable as shown in your previous example of
sending data to the address "confirmed by your new introduction".

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 2 Feb 2015 07:30:11 -0700

Michael,

Michael Tuexen wrote:                    (Mon, 02 Feb 2015 15:09:37)
> by the peer is a different issue.

The case I'm working with is Karen's original case:

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

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

The is the situation that was declared a "collision" and
it is not.  They are two different associations.

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

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 2 Feb 2015 15:53:09 +0100

> On 02 Feb 2015, at 15:12, Ka-Cheong Poon <[email-masked]> wrote:
> 
I see. So this is bad wording, no matter which of the two interpretations
we use.
> 4960.  There is never any mentioned that the list of peer
At least the point Karen brought up indicates the inconsistency.
Another one is the (informational) description of the API at
https://tools.ietf.org/html/rfc4960#section-10.1

I'm all in favour for getting it consistent. So we agree on
the case where the upper layer only provides a single address.
The case where multiple addresses are provided, is not completely
specified. I think this was done intentionally.

However, what is the problem in using the text I suggested.
If you consider all your associations initially with a single
remote address, it doesn't change anything. It just doesn't
restrict other implementations in a way which is not necessary.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 2 Feb 2015 16:01:39 +0100

> On 02 Feb 2015, at 15:30, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
Karen's original example shows two issues:
1. The upper layer at the endpoint sending the first INIT provides multiple IP addresses
   to the SCTP stack (X and Y).
2. The peer doesn't own both addresses and reports (Y Z).

The point I want to discuss (and to which the text change relates) is issue 1. That
is why I provided a different example, only illustrating issue 1.

Here it is again. I'm using a socket like API to show upper layer interactions:

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 at A 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 at B 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.

I guess the point we might no agree on is if a TCB can have multiple peer addresses at
this state of the association. However, the text change suggested by me in the discussion,
doesn't change anything if you don't allow multiple addresses at the early state, but it
allows implementations supporting multiple addresses to react more appropriately.

The proposed text change does not require anyone to change it implementations, it just allows
an implementation to be more flexible.

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 2 Feb 2015 09:07:14 -0700

Michael,

Please see comments inline...

Michael Tuexen wrote:                                    (Mon, 02 Feb 2015 16:01:39)
> 2. The peer doesn't own both addresses and reports (Y Z).

No, as Karen's example is not a collision.

> from A2 to B2 should also be allowed.

And because the INIT to B1 times out, so A is free to send the next INIT
to B2 as provided in the connect and the association is established.  No
problem.  That was the point of supplying multiple addresses in the
first place: to make the association setup more reliable.

> an implementation to be more flexible.

Not required, and, in fact, may introduce security problems,
particularly if B2 does not belong to B.

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

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 2 Feb 2015 18:49:18 +0100

> On 02 Feb 2015, at 17:07, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
But what happens if (as indicated above) B sends an INIT before the timer on A runs off?
> first place: to make the association setup more reliable.
So what is A doing when it receives the INIT from B as indicated above?
> particularly if B2 does not belong to B.
I disagree. You are exposing the vtags to B2. But you would do this also
when the timer runs off and you retransmit the INIT to B2...
So I agree, if the upper layer is mis-configured and provides invalid address
sets, things can go wrong...
But what happens in the case above, where nothing is configured wrong?
Why should A not send the INIT-ACK to B2?

Best regards
Michael

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Tue, 3 Feb 2015 10:12:59 +0100

Hi,

Michael explains this much better than I.
But again, just for the record:

Michael example below is indeed how we have understood SCTP MH of RFC4960
and how we have implemented
INIT Collision when we have multiple destination addresses associated with
an EP in cookie_wait.
The only issue indeed is that we have an issue with the MUST requirement
of RFC4960 for where to return the INIT_ACK to during INIT collision.
(Our policy is to return INIT ACK to source of INIT - but we realize that
we need to do this conditionally to the source of the INIT being
one of the destination addresses associated with the EP - which is what
the MUST policy of RFC4960 translates to when there are multiple
destination addresses associated with EP in cookie_wait. Our SCTP MH
implementation _is_ RFC5062 compliant, but for some reason this part of
RFC4960 (not referenced in RFC5062) has escaped us.)

My example was taking this to the extreme, in order to discuss an extreme
consequence
of the MUST requirement in RFC4960 for how to return INIT_ACK during INIT
Collision.
I had not imagined that one could contemplate this as NOT being an INIT
Collision scenario.
Michaels example is a better example than mine, illustrating this without
going to the extreme.

While I understand that one, if one associates only one destination
address (at a time ?) with an EP, would not come into this situation,
then it would be very sad, I think,  if we make RFC4960 SCTP MH
prescriptions be so that we are not able to exploit the benefits of
associating multiple destination addresses with an EP (in
cookie_wait/during the establishment). The existing MUST of RFC4960 for
INIT ACK return constitutes such a restriction. A restriction which I
would have hoped was not intended for.

I note that Path Verification, section 5.4 of RFC4960, does accommodate
for that one associates and exploits multiple destination addresses during
the handshake both by the auto-CONFIRMATION of any address specified by
ULP to INIT sender side. Thus allowing for both INIT and COOKIE_ECHOs (and
data) to be send to these addresses without prior (other) confirmation of
the addresses as being a "willing party" in the association negotiation.

If the intention of Path Verification, section 5.4, has been that the
INIT-INIT_ACK (or HB-HB ACK) exchange is needed on top on the trust
established by the addresses being specified by ULP, then section 5.4.
needs to be updated with this _ significant_ addition.

(In our SCTP MH implementation then whenever possible, we do not send DATA
to any destination address that has not been confirmed in terms of a
direct message exchange; INIT-INIT ACK, INIT_ACK-COOKIE_ECHO,
COOKIE_ECHO-COOKIE_ACK or HB-HB ACK. But this logically we consider as an
add on to RFC4960 Path Verification _in case_ the destination address
already have been AUTO_CONFIRMED for the association by virtue of it
having been specified by ULP (INIT sender side)).

BR, Karen

>From: Michael Tuexen [mailto:[email-masked]]
>Sent: Monday, February 02, 2015 6:49 PM
>To: [email-masked]
>Cc: Karen Elisabeth Egede Nielsen; [email-masked]
>>>>>> On 02 Feb 2015, at 14:40, Brian F. G. Bidulock
<[email-masked]>
>wrote:
>>>>>>
>>>>>> Karen,
>>>>>>
>>>>>> It is not a collision because the first association (INIT) MUST
>>>>>> include X, where as the second association (INIT) does not include
>>>>>> X.
>>>>>>
>>>>>> There is nothing stopping your API from abandoning INIT #1 and
>>>>>> accepting INIT #2; however, from a protocol perspective, by
>>>>>> definition, these are different associationas and there is no
>>>>>> collision.
>>>>> Please have a look at the example I gave... Dealing with remote
>>>>> addresses provided by the peer which are not reported by the peer
>>>>> is a different issue.
>>>>
>>>> The is the situation that was declared a "collision" and it is not.
>>>> They are two different associations.
>>> 1. The upper layer at the endpoint sending the first INIT provides
multiple
>IP addresses
>>> The point I want to discuss (and to which the text change relates) is
>>> issue 1. That is why I provided a different example, only illustrating
issue 1.
>>> Assume that the routing is setup such that packets flow A1 <-> B1 and
A2
><-> 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 at B contains local addresses
>>> B1 and B2 and remote addresses A1 and A2.
>>> 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.
>>
>> And because the INIT to B1 times out, so A is free to send the next
>> INIT to B2 as provided in the connect and the association is
>> established.  No
>But what happens if (as indicated above) B sends an INIT before the timer
on
>A runs off?
>>> I guess the point we might no agree on is if a TCB can have multiple
>>> peer addresses at this state of the association. However, the text
>>> change suggested by me in the discussion, doesn't change anything if
>>> you don't allow multiple addresses at the early state, but it allows
>implementations supporting multiple addresses to react more
appropriately.
>>>
>>> The proposed text change does not require anyone to change it
>>> implementations, it just allows an implementation to be more flexible.
>>
when
>the timer runs off and you retransmit the INIT to B2...

---

From: Ka-Cheong Poon <[email-masked]>
Date: Tue, 03 Feb 2015 18:47:39 +0800

> restrict other implementations in a way which is not necessary.

My understanding is that the original text has no problem.  So if
there is not a problem, is it necessary to change it?  IMHO,
changing it will create the confusion that there is a new protocol
state which is not specified in RFC 4960.

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.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Feb 2015 12:04:54 +0100

> On 03 Feb 2015, at 11:47, Ka-Cheong Poon <[email-masked]> wrote:
> 
The point is, it does provide a problem for implementations supporting
multiple addresses provided by the upper layer.
> 5.1.  It is the normal case when sending back an INIT-ACK.  So what
Section 5.1 contains:
"   B) "Z" shall respond immediately with an INIT ACK chunk.  The
      destination IP address of the INIT ACK MUST be set to the source
      IP address of the INIT to which this INIT ACK is responding."
and this is exactly what we want to allow. See the last sentence in
my proposed text below.

Here is my example (again):

* A binds(A1, A2);
* B binds(B1, B2);
* A calls sctp_connectx(B1, B2);
  - Now the TCB at A 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 at B contains local addresses B1 and B2 and remote addresses A1 and A2.
  - Now an INIT[B1,B2] is sent from B2 to A2.
* The INIT[B1,B2] sent from B2 to A2 arrives at A.

The current text in RFC 4960 requires A to send the INIT-ACK back to B1, whereas
the text suggested would allow A to send it back to B2.

OLD TEXT:
  When

NEW TEXT:
  When

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 3 Feb 2015 05:42:33 -0700

Michael,

> >> And assume that the flow from A1 to B1 is broken.

I'll show you what I do, which is fully consistent with the RFC and
does not exhibit the problem your implementations seem to be causing.

> >> A binds(A1, A2);

INITIALIZE(port,A1,A2) => A

> >> B binds(B1, B2);

INITIALIZE(port,B1,B2) => B

> >> Now the TCB at A contains local addresses A1 and A2 and remote addresses B1 and B2.

Incorrect.  The peer address list is populated based on the
INIT and INIT-ACK.  See for reference RFC4960/13.2 which says:

   Peer        : A list of SCTP transport addresses to which the peer
   Transport   : is bound.  This information is derived from the INIT or
   Address     : INIT ACK and is used to associate an inbound packet
   List        : with a given association.  Normally, this information
               : is hashed or keyed for quick lookup and access of the
               : TCB.

> >> Now an INIT[A1, A2] is sent from A1 to B1, but it never reaches B

ASSOCIATE(A, port, B1, streams)

Note that the ASSOCIATE primitive only allows for one destination
address to be supplied.  This populates the TCB with A1,A2 and B1.

> >> Now the TCB at B contains local addresses B1 and B2 and remote addresses A1 and A2.

Wrong again, for the same reason as A.

> >> Now an INIT[B1,B2] is sent from B2 to A2 and it reaches A.

ASSOCIATE(B, port, A2, streams)

Note that the ASSOCIATE primitive only allows for one destination
address to be supplied.  This populates the TCB with B1,B2 and A2.

> >> to B1, which is dropped again.

No, it is not a collision.  'A' cannot trust B1 because the INIT
came from B2.  So, looking for a TCB that has A2 in its local
transport address list and B2 in its peer transport address
list, I find none.  There is no collision.  So, I build an
INIT-ACK with a new initiate tag and send it to B2.

> >> What Karen is suggesting is that sending the INIT-ACK[A1, A2]

My point is that if you follow the RFC and only populate the
Peer Transport Address List in the TCB from the INIT and
INIT-ACK this is not a collision and you will send the INIT-ACK
to B2 per normal.  This is a new state cookie with a new
nascient TCB (i.e. different verification tag) and so cannot
leak the other.

> >> allows implementations supporting multiple addresses to react more appropriately.

No, the point is that if you don't add B2 to the TCB, as is
proper according to the RFC, you will not have this problem.

> >> an implementation to be more flexible.

Instead, fix the implementation to not add more than one address
to the TCB when launching an INIT.  Use the ASSOCIATE() primitive
as proscribed.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 3 Feb 2015 05:49:21 -0700

Michael,

Michael Tuexen wrote:                  (Tue, 03 Feb 2015 12:04:54)
>   address of the received packet containing the INIT chunk.

No, no, no.

We explicitly set the text that way in SCTP IG section 2.6 for a reason.
(The verification tag must not be sent to any address other than the one
to which the INIT was sent.)

Just don't add B2 to the TCB against the RFC when launching an INIT to B1
and you won't have a problem.

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

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Tue, 3 Feb 2015 15:11:21 +0100

Hi Brian,

>
>
>I'll show you what I do, which is fully consistent with the RFC and does
not
>exhibit the problem your implementations seem to be causing.
>
[Karen ] Our implementation is not causing a protocol. Our implementation
exploits the
association of multiple destation addresses resulting in a more qualified
and efficient operation ! :-)

It is the restrictive text of RFC4960 which gives an issue as this texts
seems to be
written in the context of an SCTP implementation not able to associate
more
than one destination address with an SCTP E in cookie_wait state.

>Incorrect.  The peer address list is populated based on the INIT and
INIT-ACK.
>See for reference RFC4960/13.2 which says:
>
[Karen ] Section 13 also ways:

   "This section is for
   illustrative purposes and should not be deemed as requirements on an
   implementation or as an exhaustive list of all parameters inside an
   SCTP TCB."

I do not think that section 13 is normative from an SCTP protocol
specification perspective.
I assume that we agree on this ! :-)

Had it been normative, which is truly is not, then I would not even find
it so strange that the text would suffer from the same limitation as the
MUST we are discussing as
it seems not to be have been updated from RFC2960 to RFC4960.  Looking for
example at the "state" of a transport address the text has not been
updated to reflect the existence of Path Verification.

The text of Section 13 cannot really serve in this context I believe.

>Note that the ASSOCIATE primitive only allows for one destination address
to
>be supplied.

[Karen ] The ASSOCIATE primitive is defined in Section 10 of RFC4960.
Section 10 is not a normative part
of the SCTP protocol specification.

 This populates the TCB with A1,A2 and B1.
>Wrong again, for the same reason as A.
[Karen ] This "wrong" may be correct for your SCTP implementation, but is
incorrect from an SCTP protocol specification perspective as
there is no normative text of RFC4960 to this effect,

>Note that the ASSOCIATE primitive only allows for one destination address
to
>be supplied.  This populates the TCB with B1,B2 and A2.

[Karen ] The ASSOCIATE primitive is defined in Section 10 of RFC4960.
Section 10 is not a normative part
of the SCTP protocol specification.

>
>> >> This is an INIT collision.  Following the RFC, endpoint A has to
>> >> send the INIT-ACK[A1, A2] to B1, which is dropped again.
>
>No, it is not a collision.  'A' cannot trust B1 because the INIT came
from B2.

[Karen ] A can trust both B1 and B2 as both have been specified by local
ULP as applicable for the association.

>looking for a TCB that has A2 in its local transport address list and B2
in its peer
>transport address list, I find none.  There is no collision.  So, I build
an INIT-ACK
>with a new initiate tag and send it to B2.
>
[Karen ] I assume that this is only done if you have a listening EP open
as well ?
Otherwise you will send an ABORT back - correct ?

>> >> What Karen is suggesting is that sending the INIT-ACK[A1, A2] from
>> >> A2 to B2 should also be allowed.
>
>My point is that if you follow the RFC

[Karen ] section 13 is not normative.

and only populate the Peer Transport
>Address List in the TCB from the INIT and INIT-ACK this is not a
collision
 and
>you will send the INIT-ACK to B2 per normal.

[Karen ] No only if you have a listening EP.

 This is a new state cookie with a
>new nascient TCB (i.e. different verification tag) and so cannot leak the
other.
>
>> >> I guess the point we might no agree on is if a TCB can have
>> >> multiple peer addresses at this state of the association. However,
>> >> the text change suggested by me in the discussion, doesn't change
>> >> anything if you don't allow multiple addresses at the early state,
but it
>No, the point is that if you don't add B2 to the TCB, as is proper
according to
>the RFC,
[Karen ] Section 13 is not normative.
you will not have this problem.

[Karen ] There is no problem then is a possibility to do things better :-)
!
>Instead, fix the implementation to not add more than one address to the
TCB
>when launching an INIT.  Use the ASSOCIATE() primitive as proscribed.
[Karen ] Not prescribed by normative text of RFC4960. :-)

BR, Karen

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Feb 2015 19:36:20 +0100

> On 03 Feb 2015, at 13:42, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
Yes, you can do that and I don't want to change that. I just want to
change the text such that allow others to do it differently. The support
of multiple remote addresses during association setup is not specified
consistently. The suggested text change addresses at least one of the issues.
>               : is hashed or keyed for quick lookup and access of the
Another point of inconsistency...
> address to be supplied.  This populates the TCB with A1,A2 and B1.
I mentioned that earlier.
> nascient TCB (i.e. different verification tag) and so cannot
I'm not arguing about the case where the upper can not provide
multiple addresses. I'm just saying
* some implementations might allow the upper layer to
  provide multiple address (by implementing sctp_connectx(), for example).
* The text under discussion hurts them.
> proper according to the RFC, you will not have this problem.
If I don't add B2, I don't have the problem. I agree. This is what
I'm saying that there is not problem if the stack doesn't allow
the upper layer to provide multiple addresses.
> to the TCB when launching an INIT.  Use the ASSOCIATE() primitive
I want to allow providing an efficient implementation of sctp_connectx(). I
don't want to force anyone to do that. Therefore the wording of the text change
is done in a way, that you can still do what you do right now.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Feb 2015 19:39:19 +0100

> On 03 Feb 2015, at 13:49, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
> and you won't have a problem
This would mean I can't support an efficient implementation of sctp_connectx().
The text in https://tools.ietf.org/html/rfc4960#section-5.4 was chosen such
that the upper layer can "confirm" multiple remote addresses. This allows
the sender to send an INIT to multiple destinations.
Again: If you don't like it, just don't support this in the API. I'm fine
with that, but why restrict other implementations?

Best regards
Michael
> .

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 3 Feb 2015 13:06:47 -0700

Karen,

Karen Elisabeth Egede Nielsen wrote:          (Tue, 03 Feb 2015 15:11:21)
> Hi Brian,
> 
> >
> >
> >I'll show you what I do, which is fully consistent with the RFC and does not
> [Karen ] Our implementation is not causing a protocol. Our
> implementation exploits the association of multiple destation
> addresses resulting in a more qualified and efficient operation ! :-)

I was actually responding to Michael.

> It is the restrictive text of RFC4960 which gives an issue as this
> texts seems to be written in the context of an SCTP implementation not
> able to associate more than one destination address with an SCTP E in
> cookie_wait state.

In fact, the RFC does not proscribe associating _any_ destination
addresses with an association in cookie-wait state.  And this is where
you are getting into trouble with IG 2.6.

> >INIT-ACK.  See for reference RFC4960/13.2 which says:
> >
>    "This section is for illustrative purposes and should not be deemed
>    as requirements on an implementation or as an exhaustive list of
>    all parameters inside an SCTP TCB."
> 
> specification perspective.  I assume that we agree on this ! :-)
>
> Had it been normative, which is truly is not, then I would not even
> find it so strange that the text would suffer from the same limitation
> as the MUST we are discussing as it seems not to be have been updated
> from RFC2960 to RFC4960.  Looking for example at the "state" of a
> transport address the text has not been updated to reflect the
> existence of Path Verification.
> 

Section 5.1.2 describes this process as outlined in 13.2, is normative,
and details how the information is derived from a received INIT or
INIT-ACK.  But you knew this, right?

5.1.2 also details how to "look up" a TCB based on a received INIT or
INIT-ACK based on this populated address list.

What the RFC does not describe is populating _any_ destination addresses
against an association when the first INIT is _sent_ and it enters
COOKIE-WAIT state.  It, however, describes in detail how to "populate"
the destination address list once the INIT-ACK is received.  So,
logically, for the purposes of looking up a TCB as described normatively
in RFC4069/5.1.2 (D), an association in the COOKIE-WAIT state has _no_
addresses in its destination address list and will never be found.

> >to be supplied.
> Section 10 is not a normative part of the SCTP protocol specification.
> 

The normative text of 5.1.2 proscribes that the destination address list
of the TCB is populated based on the received INIT or INIT-ACK.  It does
not proscribe populating any addresses when entering the COOKIE-WAIT
state.  If you do populate destination addresses for the purpose of the
5.1.2 (D) lookup, you must be ready to suffer the consequences of your
interpretation.

> ULP as applicable for the association.

You are missing the point.  Lookup of an existing TCB based on
parameters in the received INIT and existing TCB contents is described
explicitly in 5.1.2 (D).  What the RFC didn't tell you was to put either
B1 or B2 in that destination address list in the first place.

This is important.  You can remember whatever addresses provided by the
user that you want, however, the destination-address-list-for-the-purpose-
of-section-5.1-(D)-lookup can be considered empty--and this is completely
consistent with the RFC text, normative and otherwise.  Therefore,
following the normative conditions for lookup of TCB in section 5.1.2 (D),
an incoming INIT can be considered to *never* collide with an association
in the COOKIE-WAIT state--again, completely consistent with the RFC text,
normative and otherwise.

> >in its peer transport address list, I find none.  There is no collision.
> >So, I build an INIT-ACK with a new initiate tag and send it to B2.
> >
> as well ?  Otherwise you will send an ABORT back - correct ?

What constitutes a "listening" association is a matter for the
implementation.  That is, whether an implementation responds to
correct and valid INIT with an INIT-ACK is up to the implementation.

I follow the normal approach of looking for a Socket/Stream in the
listening state that is bound to the destination transport address of
the INIT or, if there is no Socket/Stream bound to that address, one
in the listening state bound to INADDR_ANY and the appropriate port
number, and, if there is no Socket/Stream bound that way, a Socket/Stream 
bound in the listening state to port 0 and the address, or one bound to
port 0 and INADDR_ANY.  If no listening Socket/Stream can be found, I
look for an association bound to the destination transport address in
a connecting or connected state that might be interested in receiving
a COOKIE-ECHO for an existing association.  If I did not find such a
Socket/Stream when first receiving the INIT, I discard it (as is
permitted by the RFC).

As you can see, section 5.1, only recommends sending ABORT in response
to INIT when there is some problem.  Refusing an association attempt is
not one of them.  Also, sending an abort is SHOULD.  In RFC 2960 it was
a MUST, but I got it downgraded to SHOULD in RFC 2960, particularly to
thwart port scanning.

> [Karen ] section 13 is not normative.

5.1 is normative and fully consistent with section 13.

> [Karen ] No only if you have a listening EP.

It is typical in Sockets to treat an initializing connection as
"listening" while it is initializing.  That is the case here.
RFC 4960 does not define a "listening" end-point: it just says what
the implementation does when it is "willing" or "unwilling" to respond
to a valid INIT with an INIT-ACK.

> [Karen ] Section 13 is not normative.

5.1 is normative and fully consistent with section 13.

> [Karen ] Not prescribed by normative text of RFC4960. :-)

If you add an address to the destination address list for the purpose of
RFC 4960/5.1.2(D) lookup before receiving an INIT or INIT-ACK, then your
are not following the RFC.  The RFC proscribes no such action.  You run
afoul of IG 2.6 because of this non-proscribed action.

Understand the history of the text to which that you object.  This text
was provided in the SCTP IG RFC 4460 Section 2.6.  It was hotly debated.
I disagreed with the text as worded.  The text was, nevertheless, agreed
upon by WG consensus.  It was not overlooked.  Its purpose was to close
the door on bleeding verification tags to attackers manipulating INITs
by trying to ADD their own IP addresses to the forming association of
another peer.

I oppose altering that WG consensus with an errata: especially because
it is possible to reliably and efficiently form secure associations
without need for the suggested changes.  Also, because the suggested
changes have not be given the intense level of review, particularly for
security, that was afforded RFC 4460 when that consensus was formed.

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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Feb 2015 21:53:05 +0100

> On 03 Feb 2015, at 21:06, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Karen,
> 
Brian,

I think the problem is that we discussed Section 2.6 and resolved the
issue in the way described in Section 2.6. This is WG consensus and
we don't want do change that.

Later, when working on
https://tools.ietf.org/html/rfc4460#section-2.36
the idea of the upper layer providing multiple addresses was taken into
consideration when working of the text changes. Unfortunately, this wasn't
done in a consistent way. However, it is also WG consensus, just the same
as https://tools.ietf.org/html/rfc4460#section-2.6

One way to resolve the issue is what you describe, simply don't consider
the case where the upper layer provides multiple addresses. And I agree,
RFC 4960 doesn't deal with it in a good way. However, some text does.
And I checked the kernel implementations of FreeBSD, Linux and Solaris.
They all send the same INIT to multiple destinations when the client
uses sctp_connectx() providing multiple addresses. So there are implementations
dealing in some way or the other with this case. So ignoring it might
also not be the best solution.

I'm wondering if you have any technical argument against the proposed text,
in the sense why you would disallow an implementation to do what the changed
text would allow. Several implementations already expose the initiate tag
to all destination provided by the upper layer. The security arguments used
in RFC 4460 where always dealing with no trusting the peer, the arguments
where not about not trusting the local upper layer.

So for some implementations the proposed text change helps. Where does it
hurt? For me it just allows more flexibility.

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 3 Feb 2015 14:01:13 -0700

Michael,

Michael Tuexen wrote:                           (Tue, 03 Feb 2015 19:36:20)
> consistently. The suggested text change addresses at least one of the issues.

As you know, I was an original proponent of supplying multiple addresses
on connect() and implemented it for the 2nd interop.  I still have it
implemented for reliable association establisment without the need for
a change to the RFC.  It is the persistence in adding addresses supplied
in the connect() to the destination address list for the purposes of
5.2.1 (D) association lookup, without any prescription in the RFC to do
so, that cause an implementation to run amuk of IG 2.6.  Just don't do that.

> Another point of inconsistency...

It is fully consistent with 5.1.  It is the implementation behavior of
adding an address to the destination address list for the purposes of
5.1.2 (D) lookup that is inconsistent with the RFC.

> * The text under discussion hurts them.

I implement multiple addresses to connect(), as just about everybody
has since 2001.  I use them to make the association establishment
process reliable (specifically for situations like your example case), 
I also use them to confirm addresses of a established association
without requiring path verification (nonce) procedures.  If you recall,
I was the one the lobbied for the text of 5.4 (1).  In fact, I lobbied
so hard you might say that I'm responsible for the text of 5.4 (1).

What I don't do is put addresses in the destination address list
of the association in COOKIE-WAIT state for the purposes of 5.1.2 (D)
lookup.  Nowhere does the RFC tell me to do that.  So, as far as I'm
concerned it is not a collision, and that interpretation is completely
consistent with the RFC.  I respond to the INIT with an INIT-ACK
as per normal association setup (with a new verification tag), because
I have a TCB bound to the desintation transport address of the INIT
in an initializing or established state.

> the upper layer to provide multiple addresses.

Still missing the point.  My stack allows the upper layer to provide
multiple addresses.  I just don't add them to the destination address
list for the purposes of 5.2.1 (D) lookup because the RFC does not
tell me to do so.  I have had running OSS code from before RFC 4460 was
issued.

> is done in a way, that you can still do what you do right now.

I have had an efficient implementation of connect() with multiple
addresses for almost 14 years.  I do not need a change to IG 2.6
because I do not persist in adding the addresses to the destination
address list for the purposes of 5.2.1 (D) lookup.

My advise to those implementations is: don't do that.

What you can do is launch an init INIT to any address in the list
whenever you want.  For example, launch an INIT to all of them;
launch an INIT to the first one and wait for a timeout and then
launch to the second one and so on; or simply wait for the first
INIT and retransmission to fail and be abandonned before launching
an INIT to the second one, etc.

Also, thanks to me, once the association is established, you do not
need to peform path verification (nonce) procedures to any address
that is in the destination address list of the association that was
provided in the connect().  Also, if you support ADD-IP (as I do),
you can also consider addresses from the list as confirmed if they
are later requested to be added by the peer.

I had objections to IG 2.6.   We argued them out and the WG consensus
was to err on the safe side and never send a verification tag on
receipt of an INIT in COOKIE-WAIT state to an address other than the
one to which the INIT was sent.  I don't think that we should attempt
to alter that consensus with an errata at this point, particularly
when these implementations are causing themselves their own grief.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 3 Feb 2015 15:11:58 -0700

Michael,

Michael Tuexen wrote:                            (Tue, 03 Feb 2015 21:53:05)
> as https://tools.ietf.org/html/rfc4460#section-2.6

I assume that you are talking about 5.4 (1).  This applies to user addresses
provided in the association for the purposes of path verification only, and
then only once the association is established.  It does not, and should not
IMHO alter the INIT process whatsoever.  Some implementations have obviously
read more into this than it states.  It does not say to add them anywhere.  It
just says that if you go to send a nonce to them, you can skip them and
consider them automatically confirmed.  Nothing more!

> also not be the best solution.

I send INITs to multiple destinations too.  We all have since about 2002.
That is not an issue.  Adding them to the destination address list of the
association for the purposes of 5.1.2 (D) lookup when entering COOKIE-WAIT
state, when the RFC does not tell you to do so, is an issue.  Actually, I
would call it a BUG.

> where not about not trusting the local upper layer.

Yes, I have three technical objections to altering the text:

1)  Just because some implementations may expose the initiate tag to all
    addresses in the list is not a reason to open an additional attack
    surface by exposing it again and in addition to the corresponding
    peer tag and sequence numbers in an INIT-ACK.  The first exposure
    is bad enough, the second is much worse.

2)  There is no problem with the current specification.  It is possible to
    use multiple addresses in the way intended without a change that weakens
    the security of the protocol.

3)  It expands 5.4 (1) in a way that was never intended.  5.4 (1) is only
    applied to established associations.  By treating the addresses as
    confirmed I am trusting the peer not to mess with them.  It is the
    peer that I trust, not the addresses.  In an established association,
    I can know that what peer I am trusting not to muck with addresses.
    During the initialization phases, particularly at receipt of an INIT
    and when sending an INIT-ACK, I have no idea whether it is the trusted
    peer.

Take what can happen if you allow the behavior of adding B1 and B2
to the address list.

Example 1:

  connect(B1,B2)

  TCB (A1,A2) (B1,B2) for the purposes of 5.1.2 (D) lookup.

  INIT (A1,A2) (A1) ----> (B1)

  (A2) <-- (X1) INIT(B1,B2,X1)

  5.2.1 (D) tells me that if any of the addresses B1,B2,X1 is in the
  destination address list of the TCB, that this TCB is considered to be
  an existing TCB for the association.  Therefore, I erronously treat
  this as a collision case and send an INIT-ACK.  According to
  5.2 I populate the TCB with destination addresses B1,B2,X1.  According
  to the fourth paragraph of 5.2.1, "the original parameters are
  combined with those ofrom the newly received INIT chunk.  The endpoint
  uses the parameters sent in its INIT to calculate the State cookie."

  With your change, I cannot send this INIT-ACK to X1, but I can now
  send it to B1 or B2.  X1 just got added to the address list.  Also,
  the INIT-ACK contains parameters that X1 placed in the INIT.  That is
  really bad.

  If you just don't place B1,B2 in the destination address list for the
  purposes of 5.2.1 (D) lookup, you will respond to the init with an
  newly formulated INIT-ACK with a new initiate tag and send it to X1.
  X1 cannot alter the TCB that launched the INIT.  X1 cannot have
  arbitrary parameters sent to B1 or B2 in an INIT-ACK.

Example 2:

Even though I may be confident that peer B will not mess around by
adding incorrect addresses B1 and B2, I do not know that B has
an association bound to B1 and B2 together.

A => bind(a, A1,A2)
B => bind(b1, B1)
B => bind(b2, B2)

A => connect(a,B1,B2) => TCB (A1,A2) (B1,B2)
B => connect(b2, A2)  => TCB (B2) (A2)

INIT(A1,A2) (A1) ---> (B1)  (lost)

(A2) <--- (B2) INIT(B2)

Find TCB for 'a' with B2.  Per 5.2.1 (D) it is a collision. Per
5.2 'A' populates the destination address list with B2 (but B1 and
B2 are already there).  I formulate an INIT-ACK with the initiate
tag sent to B1 and, with your change, send it to B2.  B2 just
hijacked the association intended for B1, without even needing
permission to bind to B1.

Don't change IG 2.6, change the implementation to simply not add
the supplied addresses to the destination address list used for
5.2.1 (D) lookiup.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 3 Feb 2015 15:19:41 -0700

Michael,

Michael Tuexen wrote:                       (Tue, 03 Feb 2015 19:39:19)
> with that, but why restrict other implementations?

Implemented. Running code since 2001. IG 2.6 compliant since 2004.
Don't need the change.

Simple: when you go to do a 5.2.1 (D) lookup for a TCB in the
COOKIE-WAIT state, consider the destination address list of the
TCB empty.  Done.  Running.  Efficient.  Reliable.  Multiple
addresses.  Since 2001.  IG 2.6 compliant since 2004.
Change not needed.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 3 Feb 2015 16:40:45 -0700

Ka-Cheong,

Ka-Cheong Poon wrote:                 (Fri, 30 Jan 2015 16:54:05)
>
> 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.

I agree.   In fact you cannot even tell that B1 will be part of the
association.  Sockets doesn't have the ability, but STREAMS XTI has
the ability to provide the responding address(es) in the t_accept(3)
call, so B could respond to the init with t_accept containing, say,
B2 and B3 as the responding address.  The INIT-ACK will then contain
(B2 and B3--sent from B2 or B3) and B1 is not part of the
association.  The RFC does not preclude this.  So, the end-point
cannot know what addresses will part of the established association
until it receives an INIT or INIT-ACK with the list.  I think this
is clear in 5.1.  Destination addresses are not populated until an
INIT or INIT-ACK is received.  This largely means that 'A' can only
really consider a collision one where it gets an INIT from B1, but
is likely free to even consider that case a non-collision.

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

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 4 Feb 2015 10:49:43 +0100

> On 03 Feb 2015, at 22:01, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
I actually don't remember...
> so, that cause an implementation to run amuk of IG 2.6.  Just don't do that.
OK. So you allow multiple remote addresses to be provided by the upper layer,
but don't use them during address lookup. OK.
> so hard you might say that I'm responsible for the text of 5.4 (1).
I don't remember. But this is the text which explicitly talks about
providing multiple addresses by the upper layer.
> lookup.  Nowhere does the RFC tell me to do that.  So, as far as I'm
I don't see why it is such a bad thing...
> tell me to do so.  I have had running OSS code from before RFC 4460 was
OK, I got that point now.
> whenever you want.  For example, launch an INIT to all of them;
Just to make sure I understand what you are doing:
You would send the INITs with (most likely) different initiate tags,
right?
> when these implementations are causing themselves their own grief.
I think I'm now understanding what your implementation does. The
way you implemented it you can send an INIT-ACK back to the source
of the received INIT. This is what we want to allow for the way we
implemented it, too. The difference is that we use the initiate
tag used for the other addresses, you use a (most likely) different
initiate tag per remote address. Is that correct?
Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 4 Feb 2015 12:43:27 +0100

> On 03 Feb 2015, at 23:11, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
I understand you point. But, as you say, some implementations have done it
differently. This means the text should be improved sometime in the future.
> state, when the RFC does not tell you to do so, is an issue.  Actually, I
Well, we might have a different view here...
>    is bad enough, the second is much worse.
This is what I want to understand:
Assume that I expose initiate tag / Initial TSN / whatever to all
addresses provided by the upper layer. What am I exposing more by replying
with an INIT-ACK (considering an INIT collision) only to addresses
provided by the upper layer? For me this looks like exposing the information
to the same IP-addresses. Am I missing something?
>    the security of the protocol.
I do undestand that you can do it like your implementation. I don't understand
why the other way being discussed weakens the security of the protocol.
>    and when sending an INIT-ACK, I have no idea whether it is the trusted
Well, the address is provided by the upper layer. In this sense it is trusted...
>  this as a collision case and send an INIT-ACK.  According to
Correct.
>  5.2 I populate the TCB with destination addresses B1,B2,X1.  According
Well,
https://tools.ietf.org/html/rfc4960#section-5.2.1
tells you:
   "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 Initiate 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."
X1 is new, so no INIT-ACK is sent. Therefore there is no security issue.
> Find TCB for 'a' with B2.  Per 5.2.1 (D) it is a collision. Per
Correct.
> tag sent to B1 and, with your change, send it to B2.  B2 just
Correct. This is a consequence of the upper layer providing wrong information.
> permission to bind to B1.
No, it wasn't intended with B1. It was intended with B1 and B2 (assuming that
they are bound to the same endpoint). This is not the case here.
Please note that the association being setup would only be between A1, A2
on one side and B2 on the other, at least in the implementation I have in mind.
In my understanding it is something within the constraints the upper layer
requested. Not a security issue.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 4 Feb 2015 12:51:43 +0100

> On 03 Feb 2015, at 23:19, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
That would mean I would respond to any incoming INIT with the
correct destination port number and a matching destination address
with an INIT-ACK? That is not what I would expect?

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Feb 2015 05:17:24 -0700

Michael,

Michael Tuexen wrote:                 (Wed, 04 Feb 2015 12:43:27)
> to the same IP-addresses. Am I missing something?

When I send INIT-ACK in accordance with a "collision" case, I tell the
receiver of the INIT-ACK what my final determination of local and peer
tags will be for the association.  Also you missed the address and
parameter polution below.

> why the other way being discussed weakens the security of the protocol.

See, below again, you missed a big thing (COOKIE-WAIT state vs.
COOKIE-ECHOED state).

> Well, the address is provided by the upper layer. In this sense it is trusted...

I don't trust every end-point on the Internet to not abuse the address.
I trust the endpoint I am connecting to not to abuse the address.  This
is why I say my trust is being placed in the endpoint and not in the
address per se.

> X1 is new, so no INIT-ACK is sent. Therefore there is no security issue.

I'm not in the COOKIE-ECHOED state, I'm in the COOKIE-WAIT state.  The
COOKIE-WAIT state says nothing about additional addresses.  All of the
addresses (B1,B2,X1) get entered into the TCB as proscribed in section
5.1.2.  And the rest follows...

> on one side and B2 on the other, at least in the implementation I have in mind.

Well, the b2 association is between (A1,A2) and (B2) as far as 'B' is
concerned.  However, because 'A' foolishly placed B1 into the destination
address list, 'A' thinks the association is between (A1,A2) and (B1,B2).
Maybe, b1 will attempt to connect later and 'restart' the association
and take it away from b2.  This is a mess.  You cannot put all those
addresses in the list of destination addresses in the TCB (for 5.1.2 (D)
lookup).

> requested. Not a security issue.

Oh, its a security issue alright.  b1 and b2 alternately disrupting
and restarting each other's association, bleeding data back and forth,
simply due to the incorrect behavior of a remote peer?  'A' thinking
that it is talking on one association when it is sending data
alternately to each?  Both when it is not necessary if you just don't
put the darn addresses in the list in the first place?

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Feb 2015 05:28:34 -0700

Michael,

Michael Tuexen wrote:                                      (Wed, 04 Feb 2015 12:51:43)
> with an INIT-ACK? That is not what I would expect?

No.  Why would you do that?  The determination as to whether to
respond to an INIT and whether a TCB "collision" exists per 5.1.2 (D)
are two different things.  Go adhead and use the user-provided addresses
to determine whether you would want to respond to the INIT at all.
I look for a listening or connecting TCB using the source, destination
and port of the received INIT.  But, understand, this is not a 5.1.2 (D)
lookup for determining collision in the COOKIE-WAIT state, but just a
search for a "listening" TCB.

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

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 4 Feb 2015 13:34:17 +0100

Correcting myself below...
> On 04 Feb 2015, at 12:43, Michael Tuexen <[email-masked]> wrote:
> 
My mistake, we are not in COOKIE-ECHOED, but in COOKIE-WAIT. Let me think about
this...

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 4 Feb 2015 13:40:22 +0100

> On 04 Feb 2015, at 13:28, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
OK.
> search for a "listening" TCB.
Hmm. Not sure I understand this. The client wouldn't normally call listen()...

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Feb 2015 05:48:03 -0700

Michael,

Michael Tuexen wrote:                                      (Wed, 04 Feb 2015 10:49:43)

> but don't use them during address lookup. OK.

Yes, because the RFC didn't tell me to put them in the destination address
list for the assocation.

> providing multiple addresses by the upper layer.

Well, no it doesn't.  It say 'any' addresses provided by the user.
One is any.  It says nothing about the user providing 'multiple'
addresses.  You are reading that into 'any'.

> OK, I got that point now.
Progress!

> You would send the INITs with (most likely) different initiate tags,

Yes, per the normal "non-collision" case.

> initiate tag per remote address. Is that correct?

Yes, per the normal "non-collision" case.

There are also other differences:

1) I do not add the addresses from the INIT to the existing TCB to
   be left around to possibly polute the list.  In the "collision"
   case this is required in the COOKIE-WAIT state, regardless which
   addresses are provided by the init.

2) I do not merge the parameters from the received INIT into the
   those of the "original" INIT when sending the INIT-ACK.  That is
   I do not allow parameters to be inserted by a potential attacker
   into an INIT-ACK that I will be sending to my honset peer.

3) I do not save any information from the INIT.  It is all placed
   in the state cookie and then the nascient TCB is destroyed.  Consider
   an attacker sending 2048 INITs back to back each with B1, B2 and
   256 more new addresses per INIT and a long list of new parameters.
   Better hope you set some hard bounds on your address and parameter
   lists.

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

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 4 Feb 2015 13:48:39 +0100

> On 04 Feb 2015, at 13:17, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
Sorry, I made a mistake and mixed up the states. Let me think about this...
> address list, 'A' thinks the association is between (A1,A2) and (B1,B2).
No. It has to remove B1, since it was not reported by the peer. So the association
is between (A1, A2) and B2 (from the perspective of A).
> and take it away from b2.  This is a mess.  You cannot put all those
It can't, since it doesn't belong to the association anymore. But you have
one point here: If you put the addresses on the list based on the upper layer,
you need to take those out, which are not reported by the peer. This is not
specified...
> simply due to the incorrect behavior of a remote peer?  'A' thinking
As said above, they can't (if you take the lists out of the peer list...).

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Feb 2015 05:51:23 -0700

Michael,

Michael Tuexen wrote:                                      (Wed, 04 Feb 2015 13:40:22)
> Hmm. Not sure I understand this. The client wouldn't normally call listen()...

No I mean in the sends that a connecting socket is deemed to be in a state
similar to the "listening" state with regard to accepting packet and
connection attempts.  If address-reuse is permitted, it can even mask
a listening socket bound to the same port.

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

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 4 Feb 2015 13:54:31 +0100

> On 04 Feb 2015, at 13:48, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
I'm not a native speaker, so you need to help me here.
I do understand that one is any. But I also think that multiple is also any.
In other words: are the following sentences equivalent:
   1)  Any address passed to the sender of the INIT by its upper layer
      is automatically considered to be CONFIRMED.

   1)  All addresses (possibly one, possibly multiple) passed to the
      sender of the INIT by its upper layer are automatically considered to be CONFIRMED.
I think they are, but I might be wrong...
> Yes, per the normal "non-collision" case.
OK. Actually progress.
> There are also other differences:
Will think about them... Just running out of time right now.

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Feb 2015 06:02:31 -0700

Michael,

Michael Tuexen wrote:                                      (Wed, 04 Feb 2015 13:54:31)
> I think they are, but I might be wrong...

It is probably logically closer to:

    1) If there exists an address that was passed to the sender of the
       INIT by its upper layer it is automatically considered to be CONFIRMED.

Yours is closer to 'Every' than 'Any'.

Yes, it is evasive, and purposely so.  The wording was crafted to not give
the impression of requiring the ULP to pass multiple addresses, while
accomodating the case if it did.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Feb 2015 06:31:33 -0700

Michael,

Michael Tuexen wrote:                           (Wed, 04 Feb 2015 13:48:39)
> is between (A1, A2) and B2 (from the perspective of A).

Remove it?  Where in the RFC does it say to remove an address from the
list?  It says to add (populate) to the list the addresses derived from
the received INIT or INIT-ACK per 5.1.2.

Now, of course, my point was that it should not have been added to the
list (for 5.1.2(D) lookup) in the first place.

ALso, if you are going to remove B1 as a result of the addresses in the
received INIT, how can you consider the INIT a collision?  The original
INIT was sent to B1: how can that be a collision when you are chucking
it out?

Also consider that because you are treating it as a collision, you are
not changing state.  The TCB is still in the COOKIE-WAIT state.  So you
have added whatever new addresses were in the INIT and now propose
removing addresses provided by the user without changing state?  Why
where they there in the first place?

> you need to take those out, which are not reported by the peer. This is not

It's not worth trying to save this approach.  Just don't consider any
INIT in COOKIE-WAIT state to be a collision and  you will be OK.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 4 Feb 2015 06:37:02 -0700

Michael,

Brian F. G. Bidulock wrote:                      (Wed, 04 Feb 2015 06:31:33)
> where they there in the first place?

Responding to myself, but Gosh: consider that I can now get you to remove
an address from your list just by sending you an INIT without it.

So, X sends INIT(B2,X1) (B2) --> (A1) (spoofing B2) and POW! you remove
B1 from your list even though you have an INIT outstanding to B1 and are
in the COOKIE-WAIT state.  Wonderful.  I think there is a good DOS attack
there.

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

---

From: Ka-Cheong Poon <[email-masked]>
Date: Wed, 04 Feb 2015 22:20:44 +0800

> multiple addresses provided by the upper layer.

I have explained in a previous mail that it does not.  What
is the problem in my explanation?

> and this is exactly what we want to allow. See the last sentence in

No.  It is not (SHOULD and MUST is different).  I may need to
repeat this point again.  There is never any mention of a list
of peer addresseses before the INIT/INIT-ACK handshake in RFC
4960..  Your proposed text *requires* such a list to be present
otherwise it does not make any sense.  Do you agree that if there
is not such a list, there is no problem?

Having such a list *requires* a change in the protocol state in
RFC 4960.  It does not really bring in any advantage as far as
I can see.  But it does bring in some problems, as shown in your
example of sending data to an "unchecked" address.

So why do we want to do extra work which brings us nothing?

> Here is my example (again):

I understand your example perfectly.  It *requires* exactly what
I wrote above.

> the text suggested would allow A to send it back to B2.

As I mentioned in a previous mail, this is not an INIT collision
unless you are adding a list of peer addresses to an association
before the INIT/INIT-ACK handshake, which is not specified in
RFC 4960.

---

From: Ka-Cheong Poon <[email-masked]>
Date: Wed, 04 Feb 2015 22:36:29 +0800

> and efficient operation ! :-)

Please do not confuse implementation details with protocol
specification.  As I mentioned before, I expect all
implementations to allow multiple peer addresses in an
association because it is SCTP.  You don't really need to
point out that your implementation can support that.  And I
hope we can agree that the point of discussion is not how
your implementation works.  We should focus on the protocol
specification.

> than one destination address with an SCTP E in cookie_wait state.

As I mentioned before.  I think you misunderstood what INIT
collision means, probably because of how your implementation
works.  You are *assuming* that there is a lit of peer
addresses prior to INIT/INIT-ACK handshake.  I don't think it
is specified in RFC 4960.  If you think I am wrong, please point
out the text which this is specified.  And please point out the
text how this list of peer addresses should be operated on.

I have also explained in a previous mail how an implementation
can work in your example which follows how RFC 4960 specifies
things.  It does not limit anything AFAICT.  If your implementation
does not work like that, I think you can change that.  It is
just code after all.

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 4 Feb 2015 21:24:38 +0100

HI Brian,

If you will consider my feedback to you some of the statements, then
please see below.

BR, Karen

>From: Brian F. G. Bidulock [mailto:[email-masked]]
>Sent: Wednesday, February 04, 2015 2:37 PM
>To: Michael Tuexen; Karen Elisabeth Egede Nielsen; [email-masked]
>> list?  It says to add (populate) to the list the addresses derived
>> from the received INIT or INIT-ACK per 5.1.2.
>>
[Karen ] What I find in section 5.1.2 is the following text:

If there are only IPv4/IPv6 addresses present in the received INIT
      or INIT ACK chunk, the receiver MUST derive and record all the
      transport addresses from the received chunk AND the source IP
      address that sent the INIT or INIT ACK.  The transport addresses
      are derived by the combination of SCTP source port (from the
      common header) and the IP Address parameter(s) carried in the INIT
      or INIT ACK chunk and the source IP address of the IP datagram.
      The receiver should use only these transport addresses as
      destination transport addresses when sending subsequent packets to
      its peer.

For me this is perfectly in line with both adding as well as removing
addresses. But the actions are of course only taken (in case on INIT)
when the COOKIE_ECHO arrives to establish the association.

When the COOKIE_ECHO arrives section 5.1.5 prescribes for the association
to be created from the TCB information in the COOKIE,
which then naturally would consist of the addresses received in the INIT.

>> ALso, if you are going to remove B1 as a result of the addresses in
>> the received INIT, how can you consider the INIT a collision?  The
>> original INIT was sent to B1: how can that be a collision when you are
>> chucking it out?
>>
>> not changing state.  The TCB is still in the COOKIE-WAIT state.  So
>> you have added whatever new addresses were in the INIT and now
>propose
in
>the COOKIE-WAIT state.  Wonderful.  I think there is a good DOS attack
there.
[Karen ] By the RFC you must make no changes as a result of the receipt of
the INIT.
Changes would only be made at receipt of COOKIE_ECHO.

In addition then:
* this INIT_ACK would be send back to B2 by the normal rules of  INIT_ACK
return, alternatively by the exact rules specified by Michael and I,
thus it  would arrive at the owner of B2,  but with a wrong vtag wherefore
it would be dropped.

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Wed, 4 Feb 2015 21:39:56 +0100

Hi Kaa-Cheong,

Please see below.

BR, Karen

>From: tsvwg [mailto:[email-masked]] On Behalf Of Ka-Cheong Poon
>Sent: Wednesday, February 04, 2015 3:36 PM
>To: [email-masked]
[Karen ] I should correct the above. I meant to say that the implementation
is not causing a protocol _problem_.
In terms of the word _implementation_, then this term came from your
previous posting, to which this was a response.
So to  be absolutely strict  with the wording so not to confuse anybody:

Our understanding of how the protocol should operate does not create any
protocol problems in the sense that it is not against
the RFC4960 protocol prescription. Furthermore it is how we think the
RFC4960 allow for specification and usage of multiple destination addresses
specified prior to the handshake operation starts. I.e., prior to that INIT
is first send.

>Please do not confuse implementation details with protocol specification.
[Karen ] I don't think that I am doing that at all.
As I
>mentioned before, I expect all implementations to allow multiple peer
>addresses in an association because it is SCTP.  You don't really need to
>point
>out that your implementation can support that.  And I hope we can agree
>that
>the point of discussion is not how your implementation works.  We should
>focus on the protocol specification.
>
[Karen ] I have intended to do nothing but that.
>As I mentioned before.  I think you misunderstood what INIT collision
>means,
>probably because of how your implementation works.
[Karen ]
:-)

You are *assuming*
>that there is a lit of peer addresses prior to INIT/INIT-ACK handshake.  I
>don't
>think it is specified in RFC 4960.
[Karen ] I don't think that the contrary is specified either. Why are you
assuming that there is no such list ?

 If you think I am wrong, please point out the
>text which this is specified.  And please point out the text how this list
>of peer
>addresses should be operated on.

[Karen ] Please point out the text where it is specified that there is no
such list.

>
>I have also explained in a previous mail how an implementation can work in
>your example which follows how RFC 4960 specifies things.  It does not
>limit
>anything AFAICT.  If your implementation does not work like that, I think
>you
>can change that.  It is just code after all.
>
[Karen ] Yes code can be changed. What we are discussing here is how the
protocol should be :-)

---

From: Randall Stewart <[email-masked]>
Date: Thu, 5 Feb 2015 06:59:34 -0500

All:

This is a *long* and windy thread. I still have to think about it and probably
re-read it ;-)

But I see a possible conflict within RFC4960 itself that I still have to think about.

It seems there is one example/question I want to ask on this. I think all
of these implementations, Brian/Kacheong’s or Michael/Karen’s probably
allow the user to specify a list of addresses (which are considered confirmed .. so
no HB/HB-Ack for confirmation) to the INIT?? i.e. connectx???

so both sides can probably do

—Bind(A1, A2)————|
                                       |—Bind(B1, B2)—
—Listen()————— —|
                                       |—Listen()
—Connectx(B1, B2)——|
                                       | — Connectx(A2, A1)

So no matter if in <or> out of the “address list” each side has A1/A2/B1/B2 in
some form hanging around for retransmission purposes?

Now one side does:

——INIT(A1,A2):B1——> XXLost

The other does:
         XXLost <——A2:(B1, B2)INIT

Now do both sides think that at time-out the implementations can do:

——INIT(A1,A2):B2——>XXLost
       or
        XXLost <——A1:(B1, B2)INIT

[I.e. retransmit to the alternate address?]

If so then at the points above in retransmission if you
don’t have a list of addresses populated by the user, then
you have to switch out B1 for B2 in the left side’s case <or>
in the right sides case the implementation has to switch out
A2 for A1.. <or> do they add these addresses in, after all
they have sent to both addresses on each side. Somehow
one has to keep track, what happens if the first XXLost packets
were *not* lost, but just slow … some speedy router put them
in the *extreme* slow path? and you get that INIT-ACK sometime
after you retransmitted to the alternate???

I.e. I think in any case you have to edit the addresses.. either
by adding or adding and deleting...

<or> 

As in Michael and Karen’s case they have the addresses contained
already so I guess no editing of an address list would happen there...

Is the above allowable? I.e. using the addresses in connectx()? And if
so (which I think it must be) then what goes on when you switch to
the alternate address? How does one deal with the late arriving
response after you have switched to the alternate address?

If Brian and KaCheong’s implementation just added the addresses, without subtracting
the old addresses, then they end up at the same place as Michael and Karen.. i.e.
an INIT collision. If they subtract the address back out .. then they are editing the address
list and they can’t deal with a very slow responding INIT-ACK from the original address
that they sent out….

So what about the above scenario, I am curious how this is handled.. I think I
know how Karen and Michaels implementation handle it… 

Unless of course Brian and KaCheong’s implementation does not use that
second address for retransmission???

R
--------
Randall Stewart
[email-masked]
803-317-4952

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 5 Feb 2015 13:24:52 +0100

> On 04 Feb 2015, at 14:02, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
OK. But you are not answering my question (at least not for me). If the upper layer
provides address B1 and B2. Assume the INIT-ACK contains B1, B2 and B3. Now, following
the rule above, I would expect B1 and B2 to be confirmed, B3 is not confirmed by rule 1.
In this sense I would expect "any" means "every". This includes the special case of 1.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 5 Feb 2015 13:38:14 +0100

>  uses the parameters sent in its INIT to calculate the State cookie."
Correct. It sends this COOKIE, but it also does not change its state.
>  send it to B1 or B2.  X1 just got added to the address list.  Also
Only in the cookie, not in the TCB.
>  the INIT-ACK contains parameters that X1 placed in the INIT.  That is
The INIT-ACK gets send to B1 or B2. Since the verification of this message
is the initiate tag chosen by X it won't match the one B is expecting.
Therefore the message is dropped by B. So no problem. The crucial point
here is that you don't expose information to X. This is done by
only allowing upper layer provided addresses (in our case) or sending new
information to X (in your case).

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 5 Feb 2015 13:43:29 +0100

> On 04 Feb 2015, at 14:31, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
I'm just trying to figure out how you deal with 5.2.1, which describes
an INIT collision and it covers COOKIE-WAIT...

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 5 Feb 2015 13:45:41 +0100

> On 04 Feb 2015, at 14:37, Brian F. G. Bidulock <[email-masked]> wrote:
> 
> Michael,
> 
It is not removed from the list when the INIT is received. It might when
the COOKIE-ECHO comes in. To get that attack working, X needs to guess
the initiate tag chosen by B. X is just a blind attacker...

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 5 Feb 2015 14:32:36 +0100

> On 04 Feb 2015, at 15:20, Ka-Cheong Poon <[email-masked]> wrote:
> 
Let me try to understand how you describe it. Assume one side
calls sctp_connectx(B1, B2).

Would you say that you have now a single association (in COOKIE-WAIT)
or two associations (sharing some state, since the initiate tag sent
to both addresses are the same)? How would you refer to B1 and B2?
> before the INIT/INIT-ACK handshake, which is not specified in
OK. I think I understand how you are arguing. What would you do in this case:
(1) A binds(A1, A2);
(2) B binds(B1, B2);
(3) A calls sctp_connectx(B1, B2);
    - Now the TCB at A contains local addresses A1 and A2.
    - Now an INIT[A1, A2] is sent from A1 to B1, but it never reaches B
    - On a timeout INIT[A1, A2] is sent from A2 to B2, but it never reaches B.
(4) B calls sctp_connectx(A1, A2)
    - Now the TCB at B contains local addresses B1 and B2.
    - Now an INIT[B1,B2] is sent from B2 to A2.

This is receiving an INIT for an association in COOKIE-WAIT, I would say.
Do you agree? If yes, what is the reaction? Send an INIT-ACK to
(a) B2 according to https://tools.ietf.org/html/rfc4960#section-5.1.2
(b) B1 according to https://tools.ietf.org/html/rfc4960#section-5.2.1

For (a) you would say that it is not received in COOKIE-WAIT, so it is normal
establishment, for (b) you would say that it is a collision and you sent the
initial INIT to B1. I'm assuming that you consider A after step (3)
having a single association in COOKIE_WAIT. If you consider it actually two
associations, things are different...

From a reachability point of view, it would make more sense to send it
to B2, I think, 

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 5 Feb 2015 14:43:15 +0100

> On 05 Feb 2015, at 12:59, Randall Stewart <[email-masked]> wrote:
> 
> All:
> 
At least I checked the FreeBSD, Linux and Solaris kernel. They all support sctp_connectx(),
They all retransmit the *same* INIT to the remote addresses provided.
> some form hanging around for retransmission purposes?
Yes. But it seems not all implementations use these remote addresses for finding
the TCB when an incoming packet is processed. (Brian, Kacheong: I think this is
one of your points, right?).
> [I.e. retransmit to the alternate address?]
Observed on FreeBSD, Linux and Solaris.
> second address for retransmission???
I haven't tested Brians, but he said that he used both addresses. Solaris does, I tested it.

Maybe the question to ask is how many associations are there (in COOKIE-WAIT), after
INIT have been transmitted to both IP addresses of the peer.

Maybe knowing what happens in the case I asked in a different mail about:

(1) A binds(A1, A2);
(2) B binds(B1, B2);

Helps to understand each other. If the INIT from B2 to A2 arrives, is this an INIT
collision? If yes, for which address? And where  is the INIT-ACK send to and why.

Best regards
Michael

---

From: Ka-Cheong Poon <[email-masked]>
Date: Thu, 05 Feb 2015 23:28:21 +0800

> no HB/HB-Ack for confirmation) to the INIT?? i.e. connectx???

I'd suggest that we don't talk about implementations here.  It is just
code after all.  It can be changed :-)  But my interpretation, based on
what I got out from the SCTP interop, is that no, only the peer address
used to send the INIT is confirmed.  It is the consistent thing to do
as I mentioned in a previous email.  A peer address is confirmed because
a packet sent to that address triggers a response.  The reason that the
address an ULP passes to SCTP to send the INIT is confirmed because it
is this INIT which triggers an INIT-ACK.  So logically it is confirmed
automatically.  And for practical purpose, this is the proper thing to
do since you don't want to send a data packet to a peer address with
unknown reachability.  IMHO, confirmed means known reachability.

> [I.e. retransmit to the alternate address?]

Yes, this is what sctp_connectx() intends to do (note, it is not
a retransmission, see below).  But as I mentioned, it is an API goody.
We should focus on the protocol specification.  As I wrote in a
previous email, conceptually, when sctp_connectx() is used, it can be
viewed as multiple local endpoints operating independently.  This is
the reason behind the explanation in RFC 6458.  Was I the person who
wrote that paragraph?

> by adding or adding and deleting...

The above is an implementation detail.  Conceptually, the above is not
necessary since there are multiple local endpoints (my view on the use
of sctp_connectx()).  This is why up to now, I have never talked about
any implementation details.  At least to me, this is very important.
Otherwise, one will just assume a lot of things, mixing API with
protocol specification.  While we can talk about how we implement the
protocol specification, we should not change the protocol specification
because of implementation details.  The specification should be changed
only when there is a real problem.

> response after you have switched to the alternate address?

Assume the multiple endpoints conceptual model.  Using this model, the
second INIT(A1,A2):B2 is not viewed as a retransmission because it is
from another conceptual endpoint.  Now suppose it is a late arrival,
not lost.  So the INIT-ACK from B1 arrives after the second INIT to B2
is sent.  Then we can view it as this endpoint wins the "race" in
setting up the association.  The second conceptual endpoint which sends
the INIT to B2 loses and is gone now.  The rest of processing will
follow the normal process.

> list and they can’t deal with a very slow responding INIT-ACK from the

My guess is that you have the above impression because you are thinking
in terms of implementation.  If you think in terms of the above model,
what is considered an INIT collision is very clear.  Do you agree?

As I wrote previously, the key problem of this discussion is that there
is not such a list of peer addresses specified in RFC 4960.  I believe
when folks (everyone on the mailing list engaged in SCTP specification)
check on the correctness, and/or other issues, such as security issue,
of RFC 4960, they never considered that such a list existed.  Otherwise,
it should be very clear to folks that handling of such a list has to be
explicitly spelled out.  And what the implications of such a list are
should be considered carefully as things may become very tricky.  All
the steps would have to be written down in RFC 4960.  Since no such
consideration has been written down in RFC 4960, I think we must assume
that such a list does not exist.  So when we talk about protocol
handling, we must not take this list into account.

> second address for retransmission???

Implementation does not matter.  We should focus on the protocol
specification.

---

From: Ka-Cheong Poon <[email-masked]>
Date: Thu, 05 Feb 2015 23:39:00 +0800

> to both addresses are the same)? How would you refer to B1 and B2?

Well, there is no association yet, right?  As I wrote previously,
conceptually we should consider the above case as there are two
local endpoints.  But note that no association has been formed
until handshake is complete.

> (b) B1 according to https://tools.ietf.org/html/rfc4960#section-5.2.1

Using the above conceptual model, it is an INIT collision to the
A2 -> B2 INIT.  So it is handled as an INIT collision.  I think this
is what I wrote in my first email in this thread explaining my view
on this.

>  From a reachability point of view, it would make more sense to send it

Right, it should.  And it is what the conceptual model using the API
will do.

---

From: Ka-Cheong Poon <[email-masked]>
Date: Fri, 06 Feb 2015 00:07:10 +0800

> specified prior to the handshake operation starts. I.e., prior to that INIT

I believe this is incorrect.  If RFC 4960 allows such a list of
peer addresses prior to association handshake, it has to be
explicitly spelled out.  Its handling must be written down.  As your
example shows, there can be complications.  Since nothing has been
written down, we must assume that folks involved in SCTP specification
did not have this list in mind.  So when they checked on the correctness
and other issues of RFC 4960, they did not take this list into account.
This means that we must not take this list into account when talking
about protocol handling now.

> [Karen ] I don't think that I am doing that at all.

Thanks.

> assuming that there is no such list ?

As explained above.

> [Karen ] Please point out the text where it is specified that there is no

As explained above.

> [Karen ] Yes code can be changed. What we are discussing here is how the

Agreed.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 5 Feb 2015 17:40:26 +0100

> On 05 Feb 2015, at 16:39, Ka-Cheong Poon <[email-masked]> wrote:
> 
I think there are either one or two associations from the perspective
of endpoint A. The one or both are in COOKIE-WAIT state. Since you consider
that you have two end-points (sharing the same local addresses and ports),
call them A' and A'', I would say that you have
* One association at A' towards B1
* One association at A'' towards B2
> until handshake is complete.
How do you call the entity being in COOKIE-WAIT state as specified in
https://tools.ietf.org/html/rfc4960#section-4
> is what I wrote in my first email in this thread explaining my view
This is consistent with your above view.

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Thu, 5 Feb 2015 11:45:00 -0500

KaCheong:

Yes, I am thinking of protocol spec not implementation.. but we also
need to see how folks interpret protocol spec to figure out if
we have the wording right now don’t we.

After all its very very possible for someone to interpret differently 
what was written down.. and often times spec’s leave “grey” area
on purpose...

> about protocol handling now

I believe that I might have been one of the ones around as both RFC2960 and RFC4960
were written.. and I had in mind that a list of addresses was formed.. we may not
have specified all the handling of it but there is evidence of that list I think in
all of my conversations and most likely the RFC.. but I need to dig back through
and have a look...

The point about the confirmed addresses if the user supplies them is also how I have *always*
interpreted the words that got into the RFC and here in fact is a case in point where you
interpret the words differently then both Michael and myself.

I still want to review this thread more carefully when I have time to review the RFC’s and the
thread.. I don’t right now since I have a paper due and some code for some internal things
I am working on… 

Hopefully this weekend I can put some thought to it..

Best wishes

R

--------
Randall Stewart
[email-masked]
803-317-4952

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 5 Feb 2015 21:06:46 +0100

HI,

 Some feedback from my side below.

BR, Karen

>Sent: Thursday, February 05, 2015 2:43 PM
>To: Randall Stewart
>Cc: Karen Elisabeth Egede Nielsen; Kacheong Poon; [email-masked]
>> This is a *long* and windy thread. I still have to think about it and
>> probably re-read it ;-)
>>
>> But I see a possible conflict within RFC4960 itself that I still have
to think
>about.
>>
>> It seems there is one example/question I want to ask on this. I think
>> all of these implementations, Brian/Kacheong's or Michael/Karen's
>> probably allow the user to specify a list of addresses (which are
>> considered confirmed .. so no HB/HB-Ack for confirmation) to the INIT??
i.e.
>connectx???
>At least I checked the FreeBSD, Linux and Solaris kernel. They all
support
>sctp_connectx(), They all retransmit the *same* INIT to the remote
>addresses provided.
[Karen ] I confirm that we retransmit the INIT to all destination
addresses in round robin order (if we need to = no INIT_ACK received, no
COOKIE_ECHO received . INIT collision case) and that the
Max.Init.Retransmits applies to the total of these retransmission (i.e.,
no max.init.retransmits per destination address).
>> -Bind(A1, A2)----|
>>                                        |-Bind(B1, B2)- -Listen()-----
>> -|
>>                                        |-Listen() -Connectx(B1, B2)--|
>>                                        | - Connectx(A2, A1)
>>
[Karen ] SCTP User can do listen(), but on one-to-one style sockets this
does not apply. I.e., SCTP User typically would do connectx() only.
Whether listen is called() on some other socket bounded to the same local
addresses may or may not happen. The discussion, as far as I understand,
should not be particular or isolated to the situation where listen() also
happens to be called.

>> So no matter if in <or> out of the "address list" each side has
>> A1/A2/B1/B2 in some form hanging around for retransmission purposes?

>Yes. But it seems not all implementations use these remote addresses for
>finding the TCB when an incoming packet is processed. (Brian, Kacheong: I
>think this is one of your points, right?).
>>
>> Now one side does:
>>
>> --INIT(A1,A2):B1--> XXLost
>>
>> The other does:
>>          XXLost <--A2:(B1, B2)INIT
>>
>> --INIT(A1,A2):B2-->XXLost
>>        or
>>         XXLost <--A1:(B1, B2)INIT
>>
[Karen ] Our implementation would do the same.
>>
>> If so then at the points above in retransmission if you don't have a
>> list of addresses populated by the user, then you have to switch out
>> B1 for B2 in the left side's case <or> in the right sides case the
>> implementation has to switch out
>> A2 for A1.. <or> do they add these addresses in, after all they have
>> sent to both addresses on each side. Somehow one has to keep track,
>> what happens if the first XXLost packets were *not* lost, but just
>> slow . some speedy router put them in the *extreme* slow path? and you
>> get that INIT-ACK sometime after you retransmitted to the alternate???
>>
>> I.e. I think in any case you have to edit the addresses.. either by
>> adding or adding and deleting...
>>
>> <or>
>>
>> As in Michael and Karen's case they have the addresses contained
[Karen ] Correct. Edit of addresses only happens at receipt of INIT_ACK or
COOKIE_ECHO (INIT collision case).
At this point in time the edit is done according to information in
INIT_ACK or information contained in the cookie of the COOKIE_ECHO.

I might add that COOKIE_ECHO is bundled with HB when retransmitted to
UNCONFIRMED peer (as per RFC4960, sec 5.4) and we don't sent DATA to peers
not CONFIRMED by 5.4 1). But we are actually changing this to add HB with
COOKIE_ECHO when sent to any destination address, but the one to which the
INIT was send. EXCEPT if the INIT was retransmitted, then we bundle a HB
with all COOKIE_ECHOs. This is an internal decision taken which will
appear in the products in deployment.  This is done as much to collect
solid path availability information, but it does address as well some
security concerns raised in these discussions. Whether this is part of sec
5.4 of the RFC is not entirely clear. We thought that it was not, but
could see a benefit in it being so.

BR, Karen

>> so (which I think it must be) then what goes on when you switch to the
>> alternate address? How does one deal with the late arriving response
>> after you have switched to the alternate address?
>>
>> If Brian and KaCheong's implementation just added the addresses,
>> without subtracting the old addresses, then they end up at the same
place
>as Michael and Karen.. i.e.
>> an INIT collision. If they subtract the address back out .. then they
>> are editing the address list and they can't deal with a very slow
>> responding INIT-ACK from the original address that they sent out..
>>
>> So what about the above scenario, I am curious how this is handled.. I
>> think I know how Karen and Michaels implementation handle it.
>>
>> Unless of course Brian and KaCheong's implementation does not use that
>I haven't tested Brians, but he said that he used both addresses. Solaris
does,
>I tested it.
>
>Maybe the question to ask is how many associations are there (in COOKIE-
>WAIT), after INIT have been transmitted to both IP addresses of the peer.
>
>Helps to understand each other. If the INIT from B2 to A2 arrives, is
this an
>INIT collision? If yes, for which address? And where  is the INIT-ACK
send to
>and why.