Subject: [secdir] secdir review of draft-ietf-tsvwg-sctp-ndata-12

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 24 Aug 2017 10:39:17 -0700 (PDT)

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is ready with (maybe) issues. I'm not sure if there is an issue or not. Maybe this can be quickly resolved.

Paraphrasing from the abstract, the document adds a new chunk to SCTP for carrying payload data, allowing a sender to interleave different user messages that would otherwise result in head of line blocking at the sender. 

An example usage: a client (or server) is sending a large message over SCTP, so it fragments the message and sends the fragments one after the other; each fragment is assigned a Transmission Sequence Number (TSN). If that client has a higher priority message to send during the transmission of the fragments, that message must go to the end of the line. This document defines a "stream", and allows interleaving streams, so that the higher priority message can be transmitted immediately (on its own stream), and the receiver will understand that this is not part of the lower priority message's TSN chain (stream).
 
The security considerations section says

   This document does not add any additional security considerations in
   addition to the ones given in [RFC4960] and [RFC6458].

   It should be noted that the application has to consent that it is
   willing to do the more complex reassembly support required for user
   message interleaving.  When doing so, an application has to provide
   up to two reassembly buffers (one for ordered messages, one for
   unordered messages) for each incoming stream.  It has to protect
   itself against these buffers taking too many resources.  If user
   message interleaving is not used, only a single reassembly buffer
   needs to be provided for each association.  But the application has
   to protect itself for excessive resource usages there too.

The security considerations of 4960 are very thorough, but they never mention anything about fragment reassembly issues. I don't know much about SCTP, so maybe this is not a concern, but I wondered: could a hostile endpoint attack the reassembly scheme (which must be reimplemented for each application) by sending malicious fragments?

--Scott

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 25 Aug 2017 12:44:02 +0200

> On 24. Aug 2017, at 19:39, Scott G. Kelly <[email-masked]> wrote:
Hi Scott,

thank you very much for the review. See my comments in-line.

Best regards
Michael
> An example usage: a client (or server) is sending a large message over SCTP, so it fragments the message and sends the fragments one after the other; each fragment is assigned a Transmission Sequence Number (TSN). If that client has a higher priority message 
Actually, each fragment is assigned a fragment sequence number (FSN) to reassemble the fragments in the correct order.
A TSN is assigned to each chunk just to ensure all chunks sent are received by the receiver (in whatever order).
> to send during the transmission of the fragments, that message must go to the end of the line. This document defines a "stream", and allows interleaving streams, so that the higher priority message can be transmitted immediately (on its own stream), and the receiver will understand that this is not part of the lower priority message's TSN chain (stream).
The stream is not a TSN chain. A stream is a concept allowing user messages to be ordered. Ordered user messages
sent on the same stream are received in the order they are sent. This messages sequence preservation is only
guaranteed within each stream, but not across streams.
> The security considerations of 4960 are very thorough, but they never mention anything about fragment reassembly issues. I don't know much about SCTP, so maybe this is not a concern, but I wondered…
To send malicious fragments, the attacker must bypass the SCTP stack, which is possible.
That way a receiver has to deal with the case that it received arbitrary TSN/SID/FSN/MID/PPID
combinations. This is already true for RFC 4960 stacks, just with arbitrary TSN/SID/PPID combinations.
Using the I-DATA chunk makes it easier to detect illegal combinations, since some dependencies are
removed.

So therefore I don't see a big change for SCTP implementations here. There is a change for
applications using and SCTP stack and that difference is described above.

Best regards
Michael

---

From: "Scott G. Kelly" <[email-masked]>
Date: Sat, 26 Aug 2017 08:06:32 -0700 (PDT)

Hi Michael,

Thanks for the clarifications. I re-read the fragment handling text in 4960, and looked again through the draft, and I have a better understanding now. I also looked again at known attacks on fragmentation. I don't know of any specific attacks via malicious SCTP fragment construction, and I don't want to suggest chasing after ghosts. 

It wouldn't hurt to have someone with security expertise who also understands SCTP to think more about this, but I think it's the working group's call. I have no other concerns with the draft.

Thanks,

Scott

On Friday, August 25, 2017 3:44am, "Michael Tuexen" <[email-masked]> said:

>> I have reviewed this document as part of the security directorate's ongoing
>> effort to review all IETF documents being processed by the IESG.  These comments
>> were written primarily for the benefit of the security area directors.  Document
>> editors and WG chairs should treat these comments just like any other last call
>> comments.
>>
>> The summary of the review is ready with (maybe) issues. I'm not sure if there is
>> an issue or not. Maybe this can be quickly resolved.
>>
>> Paraphrasing from the abstract, the document adds a new chunk to SCTP for
>> carrying payload data, allowing a sender to interleave different user messages
>> that would otherwise result in head of line blocking at the sender.
>>
>> An example usage: a client (or server) is sending a large message over SCTP, so
>> it fragments the message and sends the fragments one after the other; each
>> fragment is assigned a Transmission Sequence Number (TSN). If that client has a
>> higher priority message
>> to send during the transmission of the fragments, that message must go to the end
>> of the line. This document defines a "stream", and allows interleaving streams,
>> so that the higher priority message can be transmitted immediately (on its own
>> stream), and the receiver will understand that this is not part of the lower
>> priority message's TSN chain (stream).
>> The security considerations of 4960 are very thorough, but they never mention
>> anything about fragment reassembly issues. I don't know much about SCTP, so maybe
>> this is not a concern, but I wondered: could a hostile endpoint attack the
>> reassembly scheme (which must be reimplemented for each application) by sending
>> malicious fragments?