Last Call Review of draft-ietf-tsvwg-sctp-prpolicies-05
review-ietf-tsvwg-sctp-prpolicies-05-secdir-lc-salowey-2014-12-04-00

Request Review of draft-ietf-tsvwg-sctp-prpolicies
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-12-01
Requested 2014-11-13
Authors Michael Tüxen, Robin Seggelmann, Randall Stewart, Salvatore Loreto
Draft last updated 2014-12-04
Completed reviews Genart Last Call review of -05 by Tom Taylor (diff)
Secdir Last Call review of -05 by Joseph Salowey (diff)
Opsdir Last Call review of -05 by Dan Romascanu (diff)
Assignment Reviewer Joseph Salowey
State Completed
Review review-ietf-tsvwg-sctp-prpolicies-05-secdir-lc-salowey-2014-12-04
Reviewed rev. 05 (document currently at 07)
Review result Has Issues
Review completed: 2014-12-04

Review
review-ietf-tsvwg-sctp-prpolicies-05-secdir-lc-salowey-2014-12-04

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.

I have reviewed this document and believe it is Ready with minor issues.  

This document describes new policies for the users of the SCTP Partial Reliability service (SCTP-PR).  These policies cover discarding data after too many retransmissions and discarding lower priority data.  

The security considerations are a bit thin.  They mostly refer to RFC 3758 which is also a bit thin and was published before SCTP-DTLS was available.  There is some useful text in RFC 

6083 (SCTP-DTLS) :

  "If PR-SCTP as defined in [

RFC3758

] is used, FORWARD-TSN chunks MUST
   also be sent in an authenticated way as described in [

RFC4895

].  This
   makes sure that it is not possible for an attacker to drop messages
   and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this
   dropping."

I think it would be good to include similar text in this document since it is relevant.  Are there any problems introduced if the INIT or the INIT-ACK messages are not protected?  

Cheers,

Joe