Subject: [tsvwg] Some unclear points about rfc4960 (SCTP).

From: "一念之后★だ" <[email-masked]>
Date: Wed, 18 Aug 2021 00:56:37 +0800

Dear IETF experts，

I read rfc4960 (SCTP) and felt that there were some unclear descriptions in the document. I hope to get your reply, so I wrote this email to you. And I think it's better to describe these more clearly in the subsequent version of the RFC.
The following description describes some scenarios requiring abort Association in rfc4960:

Page25

Page26

Page30

Page31

Page56

As can be seen from the above description, when an init message or init ACK message is received,
(1)If the init tag in the message is 0, the association must be released
(2)If the mandatory parameters in the message are not fully carried, the association must be released
(3)When the OS value or MIS value in the message is 0, it is strongly recommended to release this association

The following description also shows that there can only be one SCTP association between two SCTP endpoints at any time:

Because init messages can be forged arbitrarily, take the scenario where the initial tag in init message is 0 as an example. 
In this scenario, a malicious attacker can destroy other associations at a very low cost:

For the other two scenarios, i.e. init message with missing mandatory parameters or init message with OS value / MIS value of 0, the effect may be similar.
I think from the original intention of the protocol design, these error scenarios should be handled according to the following. However, the RFC does not specify how to deal with the established association endpoint when receiving this wrong init (or init ACK) message, and whether the corresponding association should still be removed.

Unfortunately, the SCTP implementation of Linux will be affected by the attacks described above, such as the open source lksctp.
I hope to receive your reply to clarify the above unclear areas.
Thank you very much.

Yours faithfully!
Zhouming.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 18 Aug 2021 18:46:49 +0200

> On 17. Aug 2021, at 18:56, 一念之后★だ <[email-masked]> wrote:
> 
> Dear IETF experts，
> 
You are correct, using an initiate tag of 0 or limit the number of streams to 0 is not allowed.

Please note the in the case of an initiate tag of 0 in an INIT chunk, you can't send an ABORT
since you have no tag different from 0 you could use as the verification tag.
This has already been clarified in draft-ietf-tsvwg-rfc4960-bis-13.

It states now:
<t>If the value of the Initiate Tag in a received INIT chunk is found to be 0,
the receiver MUST treat it as an error and silently discard the packet.</t>

For OS = 0 or MIS = 0, the INIT chunk MUST be dropped and an ABORT chunk
SHOULD be sent. So the next revision will contain:

<t>A receiver of an INIT chunk with the OS value set to 0 MUST discard the
packet and SHOULD send a packet in response containing an ABORT chunk and using
the Initiate Tag as the Verification Tag.
Any existing association MUST NOT be affected.</t>

<t>A receiver of an INIT chunk with the MIS value set to 0 MUST discard the
packet and SHOULD send a packet in response containing an ABORT chunk and using
the Initiate Tag as the Verification Tag.
Any existing association MUST NOT be affected.</t>

I guess this makes the description for the INIT chunk crystal clear.

The situation for the INIT-ACK is different. The INIT-ACK is only processed, if
the verification tag in the common header was correct. In this case it is OK
to destroy the association. A potential attacker has to guess the 32-bit
verification tag and if the attacker can do this, the attacker can send a
packet containing an ABORT chunk.
However, the consistency of the text can be improved.
> I think from the original intention of the protocol design, these error scenarios should be handled according to the following. However, the RFC does not specify how to deal with the established as…
I agree. I think the suggested changes above make this crystal clear.
> Unfortunately, the SCTP implementation of Linux will be affected by the attacks described above, such as the open source lksctp.
Have you reported that issue? If not, I can let them know.
> I hope to receive your reply to clarify the above unclear areas.
Thank you very mich for reporting the issue.
> Zhouming.
Please let me know how to write your name in ASCII to give you credit.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 18 Aug 2021 22:35:54 +0200

> Unfortunately, the SCTP implementation of Linux will be affected by the attacks described above, such as the open source lksctp.
Which version of the Linux kernel are you referring to? I tested it on the 5.11 kernel, which is used
by Ubuntu, and can't reproduce the issue. Maybe it was fixed recently?

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 21 Aug 2021 00:03:59 +0200

> On 18. Aug 2021, at 18:46, Michael Tuexen <[email-masked]> wrote:
> 
Here are the suggested changes to improve the consistency of the handling
of illegal parameters in the INIT ACK chunk:

For the Initiate Tag:
<t>If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk with the
Initiate Tag set to 0, it MUST destroy the TCB and SHOULD send an ABORT chunk
with the T bit set.
If such an INIT-ACK chunk is received in any state other than CLOSED or
COOKIE-WAIT, it SHOULD be discarded silently
(see <xref target='sec_unexpected_init_ack'/>).</t>

For OS:
<t>If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk with the
OS value set to 0, it MUST destroy the TCB and SHOULD send an ABORT chunk.
If such an INIT-ACK chunk is received in any state other than CLOSED or
COOKIE-WAIT, it SHOULD be discarded silently
(see <xref target='sec_unexpected_init_ack'/>).</t>

For MIS:
<t>If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk with the
MIS value set to 0, it MUST destroy the TCB and SHOULD send an ABORT chunk.
If such an INIT-ACK chunk is received in any state other than CLOSED or
COOKIE-WAIT, it SHOULD be discarded silently
(see <xref target='sec_unexpected_init_ack'/>).</t>

Best regards
Michael