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

From: [email-masked]<[email-masked]>
Date: Mon, 23 Aug 2021 15:45:47 +0800 (GMT+08:00)

---Original---

From: "[email-masked]"<[email-masked]>

Date: Fri, Aug 20, 2021 12:41 PM

To: "draft-ietf-tsvwg-2960bis"<[email-masked]>;"tsvwg"<[email-masked]>;"claudio.porfiri"<[email-masked]>;

Cc: "245872825"<[email-masked]>;"37633825"<[email-masked]>;

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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 24 Aug 2021 15:06:51 +0200

> On 23. Aug 2021, at 09:45, [email-masked] wrote:
> 
> 
> 
> ---Original---
That is a bug and not as intended by the specification.
> (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 Veri…
It was expected to "close" the new association. It is also not a good idea to send a packet
with the verification tag of 0 and not containing an INIT CHUNK. Therefore, the text was changed to:

<t>If the value of the Initiate Tag in a received INIT chunk is found to be 0,
the receiver MUST silently discard the packet.</t>
> 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 rfc496…
The text has been updated to
* silently discard the INIT chunk if it contains the initiate tag of 0.
* send an ABORT using the initiate tag as the verification tag if IS = 0 or MIS is 0. In this case the verification is not 0.

I guess this addresses the issue you are describing.
> (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.)
It should use the initiate tag of the peer in the received INIT or INIT ACK chunk. I have changed the test to:

The Verification Tag field in the common header of the outbound SCTP packet
containing the ABORT chunk MUST be set to the Initiate Tag value of the
received INIT or INIT ACK chunk this ABORT chunk is responding to.</t>

to make this crystal clear.
> Still, this "less than 20 bytes" situation could be used as an attack method to bring down an existing association easily. 
Sure, but only if the receiver of the INIT chunk would send an ABORT belonging to the already established association, which
was never intended.
> 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…
I do not see any reason to send the ABORT chunk in a packet with the verification tag the peer expects. Especially
not if the association at the local is not destroyed. This definitely results in a loss of synchronisation
of the local and remote state.

So I guess the summary is:
* Linux correctly does not change the local state of the association
* Linux incorrectly uses the verification tag of the existing association instead
  of the initiate tag of the received INIT chunk with parameter problems as the
  verification tag of the packet containing the ABORT chunk.

Does this cover all you brought up?

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 24 Aug 2021 15:06:51 +0200

Best regards
Michael