Re: [tsvwg] Questions on rfc4960 abort init tag equal 0 in init msg and manditory info less than 20 bytes

[Claudio Porfiri <[e-mail]>]

Hi Kylin,
from draft-ietf-tsvwg-rfc4960-bis-19 - Stream Control Transmission Protocol<https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/>

The Initiate Tag is allowed to have any value except 0.  See
      Section 5.3.1 for more on the selection of the tag value.

      If the value of the Initiate Tag in a received INIT chunk is found
      to be 0, the receiver MUST silently discard the packet.

BR,
Claudio Porfiri

From: Kylin <[e-mail]>
Sent: Tuesday, 31 May 2022 12:49
To: [e-mail]; draft-ietf-tsvwg-2960bis <[e-mail]>; tsvwg <[e-mail]>; Claudio Porfiri <[e-mail]>
Subject: Re: Questions on rfc4960 abort init tag equal 0 in init msg and manditory info less than 20 bytes

hi experts

about the change：

if the value of the initiate tag in a received Init chunk is found to be 0, the receiver must silently discard the packet

whether it is already write to the new rfc4960？



---Original---
From: "[e-mail]<mailto:[e-mail]>"<[e-mail]<mailto:[e-mail]>>
Date: Fri, Aug 20, 2021 12:41 PM
To: "draft-ietf-tsvwg-2960bis"<[e-mail]<mailto:[e-mail]>>;"tsvwg"<[e-mail]<mailto:[e-mail]>>;"claudio.porfiri"<[e-mail]<mailto:[e-mail]>>;
Cc: "245872825"<[e-mail]<mailto:[e-mail]>>;"37633825"<[e-mail]<mailto:[e-mail]>>;
Subject: Questions on rfc4960 abort init tag equal 0 in init msg and manditory info less than 20 bytes

Hi dear IETF experts,

Recently we found two confusing scenarios:

1) The endpoint received an Init Msg with Init Tag equal to 0 would send Abort with the Verification Tag with its own association but not the Initiate Tag in Init Msg.

I believe this behavior is as expected as rfc4960 since:
a) page 8 says: An association can be uniquely identified by transport address used by the endpoints in the association.
(The other endpoint is using the same IP pair so the association is determined.)

b) page 26 says: 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 close the association by transmitting an Abort.
(The receiver must close the association by transmitting an Abort and the Verification Tag in the Abort is using the Verification Tag of the existing association. The reason not to fill in the Verification Tag using the Initiate Tag of the received Init Msg is said on page 8 that two SCTP endpoints must not have more than one SCTP association between them at any time.)

But from the perspective of security, it is too easy to attack the existing SCTP association using an Init Msg with the Initiate Tag filled with 0. Would you consider adding some comments in rfc4960 that in this situation the Abort should be sent with the Verification Tag filled with Initiate Tag in recieved Init Msg?

2) If an endpoint of an association received an Init Msg with init chunk less than 20 bytes, for example the TSN only has three bytes, it could abort the existing association.
I believe this behavior is as expected as rfc4960 since page 57 says: If an endpoint receives an init but decides not to establish the new association due to missing mandatory parameters, it should respond with an Abort chunk and the verification tag field must be the initiate tag  value of the peer.
(This means the receiver would fill the Verification Tag of the Abort message with the Verification Tag of this own association but not the Initiate Tag in the receiving Init Msg.)

Still, this "less than 20 bytes" situation could be used as an attack method to bring down an existing association easily.

So would you consider adding comments that in this situation the Verification Tag of  the Abort should use the Initiate Tag in Init Msg received. Or do you have some good reasons I have not thought about in using the Verification Tag of the existing association? Please help me to understand that.
Thank you!

Best regards,
Chenzhong Guo