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