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: Thu, 26 Aug 2021 18:15:09 +0800 (GMT+08:00)

Hi Michael，

Thank you. It covers all my concerns.

So when would you publish your updates to the rfc4960? Will it be a draft  somewhere so that Linux or others could fix the bug in coming releases?

Best Regards,

Chenzhong Guo

---Original---

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

Date: Tue, Aug 24, 2021 21:06 PM

To: "aimecava"<[email-masked]>;

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

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

> On 23. Aug 2021, at 09:45, [email-masked] wrote:
>
>
>
> ---Original---
> From: "[email-masked]"
> Date: Fri, Aug 20, 2021 12:41 PM
> To: "draft-ietf-tsvwg-2960bis";"tsvwg";"claudio.porfiri";
> 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.
That is a bug and not as intended by the specification.
>
> 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.)
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:

If the value of the Initiate Tag in a received INIT chunk is found to be 0,
the receiver MUST silently discard the packet.
>
> 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?
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.
>
> 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.)
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.

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 about in using the Verification Tag of the existing association? Please help me to understand that.
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
> Thank you!
> Best regards,
> Chenzhong Guo

---

From: [email-masked]<[email-masked]>
Date: Thu, 26 Aug 2021 21:29:43 +0800 (GMT+08:00)

Hi Michael，

Thank you.

There are another three small points I want to confirm with you.

1) For OOTB situation if a incoming Init Msg is sent with init tag set to zero, should we just drop the Init Msg?  I remember it is said that an Abort would sent with the verification tag set with the Init Tag of Init Msg in current RFC4960.

2) If an Init Msg is recieved with Init Chunk less than 8, the only way to respond is just ignore it since the reciever could not find a complete Init Tag. Am I right?

3) If so, will you consider ignoring the Init Msg with Init Chunk less than 20 other than responding with an Abort with the Verification Tag filled with Init Tag of the incoming Init Msg?  There is something wrong with even the manditory fields and as the receiver, it can not judge which byte(s) maybe missing.

Best Regards,

Chenzhong Guo

---Original---

Date: Thu, Aug 26, 2021 19:04 PM

> On 26. Aug 2021, at 12:15, [email-masked] wrote:
>
> Hi Michael，
>
My plan is to wait until the working group last call is over and then submit
a new revision of the 4960bis ID.

The .xml source is managed at https://github.com/sctplab/rfc4960bis

The current version of revision 14-to-be is available at
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?input=&url=https%3A%2F%2Fraw.githubusercontent.com%2Fsctplab%2Frfc4960bis%2Fmaster%2Fdraft-ietf-tsvwg-rfc4960-bis.xml&modeAsFormat=html%2Fascii&type=towindow&Submit=Submit

Best regards
Michael
> From: "Michael Tuexen"
> To: "aimecava";
> Cc: "draft-ietf-tsvwg-2960bis";"tsvwg";"claudio.porfiri";"tsvwg";
> > On 23. Aug 2021, at 09:45, [email-masked] wrote:
> >
> >
> >
> > ---Original---
> > From: "[email-masked]"
> > Date: Fri, Aug 20, 2021 12:41 PM
> > To: "draft-ietf-tsvwg-2960bis";"tsvwg";"claudio.porfiri";
> > 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: [email-masked]<[email-masked]>
Date: Sat, 28 Aug 2021 10:26:38 +0800 (GMT+08:00)

Hi Michael，

For situation 3,  will you add it into the bis as the FreeBSD does since the reaction to less than 20 Init Msg is not defined in rfc4960 by now.

Thank you.

Best Regards,

Chenzhong Guo

---Original---

Date: Fri, Aug 27, 2021 01:13 AM

> On 26. Aug 2021, at 15:29, [email-masked] wrote:
>
> Hi Michael，
>
> Thank you.
https://www.ietf.org/archive/id/draft-ietf-tsvwg-rfc4960-bis-13.html#name-initiation-init-1 contains already:

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.
> 2) If an Init Msg is recieved with Init Chunk less than 8, the only way to respond is just ignore it since the reciever could not find a complete Init Tag. Am I right?
Yepp. That is what the FreeBSD implementation also does.
> 3) If so, will you consider ignoring the Init Msg with Init Chunk less than 20 other than responding with an Abort with the Verification Tag filled with Init Tag of the incoming Init Msg?  There is…
The FreeBSD implementation will send an ABORT as long as the INIT chunk has at least 8 bytes (4 bytes chunk header and 4 bytes initiate tag) and
the initiate tag is not zero.

Best regards
Michael
> > On 26. Aug 2021, at 12:15, [email-masked] wrote:
> >
> > Hi Michael，
> >
> > Thank you. It covers all my concerns.
> > So when would you publish your updates to the rfc4960? Will it be a draft  somewhere so that Linux or others could fix the bug in coming releases?
> > Best Regards,
> > From: "Michael Tuexen"
> > Date: Tue, Aug 24, 2021 21:06 PM
> > To: "aimecava";
> > Cc: "draft-ietf-tsvwg-2960bis";"tsvwg";"claudio.porfiri";"tsvwg";
> > Subject: Re: [tsvwg] Questions on rfc4960 abort init tag equal 0 in init msg and manditory info less than 20 bytes
> >
> > > On 23. Aug 2021, at 09:45, [email-masked] wrote:
> > >
> > >
> > >
> > > ---Original---
> > > From: "[email-masked]"
> > > Date: Fri, Aug 20, 2021 12:41 PM
> > > To: "draft-ietf-tsvwg-2960bis";"tsvwg";"claudio.porfiri";
> > > 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.
> > That is a bug and not as intended by the specification.
> > >
> > > 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.)
> > 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:
> >
> > If the value of the Initiate Tag in a received INIT chunk is found to be 0,
> > the receiver MUST silently discard the packet.
> > >
> > > 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?
> > 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.
> > >
> > > 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.)
> > 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.
> >
> > 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 about in using the Verification Tag of the existing association? Please help me to understand that.
> > 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
> > > Thank you!
> > >
> > > Best regards,
> > > Chenzhong Guo
> > >
> >
>

---

From: [email-masked]<[email-masked]>
Date: Sat, 28 Aug 2021 10:26:38 +0800 (GMT+08:00)

Hi Michael，

Thank you.

Best Regards,

Chenzhong Guo

---Original---

Best regards
Michael