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

From: Claudio Porfiri <[email-masked]>
Date: Wed, 18 Aug 2021 07:30:26 +0000

Hi,
I think that behavior in case of duplicated INIT is quite well described in section 5.2
If there are implementation handling INIT without considering the Association’s Status, the fault
is in those implementations not in the specification.

Regards,
Claudio

From: tsvwg <[email-masked]> On Behalf Of ??????
Sent: Tuesday, August 17, 2021 6:57 PM
To: draft-ietf-tsvwg-2960bis <[email-masked]>; tsvwg <[email-masked]>
Subject: [tsvwg] Some unclear points about rfc4960 (SCTP).

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: Gorry Fairhurst <[email-masked]>
Date: Wed, 18 Aug 2021 08:50:29 +0100

Thanks Claudio and Zhouming fro your comments, please do continue this 
discussion if needed within the WGLC period to see if any clarification 
will be helpful in the final spec.

Gorry

On 18/08/2021 08:30, Claudio Porfiri wrote:
> If there are implementation handling INIT without considering the 
> Association’s Status, the fault is in those implementations not in the 
> specification.
>
> Regards,
>
> Claudio
>
> *From:*tsvwg <[email-masked]> *On Behalf Of *??????
> *Sent:* Tuesday, August 17, 2021 6:57 PM
> *To:* draft-ietf-tsvwg-2960bis <[email-masked]>; 
> tsvwg <[email-masked]>
> *Subject:* [tsvwg] Some unclear points about rfc4960 (SCTP).
>
> 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.
>
> (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.
>
> 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.
>

---

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

> On 18. Aug 2021, at 09:30, Claudio Porfiri <claudio.porfiri=[email-masked]> wrote:
> 
> Hi,
I agree, but it doesn't deal with INIT chunks containing invalid mandatory parameters.
> If there are implementation handling INIT without considering the Association’s Status, the fault is in those implementations not in the specification.
But I think we can improve the wording used in the specification. Although, I agree the intention of the specification
is unchanged.

Best regards
Michael
> 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.
> (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. 
> 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.