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 revision | 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 R. Stewart , Salvatore Loreto | |
| I-D 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 A. Salowey (diff) Opsdir Last Call review of -05 by Dan Romascanu (diff) |
|
| Assignment | Reviewer | Joseph A. Salowey |
| State | Completed | |
| Request | Last Call review on draft-ietf-tsvwg-sctp-prpolicies by Security Area Directorate Assigned | |
| Reviewed revision | 05 (document currently at 07) | |
| Result | Has issues | |
| Completed | 2014-12-04 |
review-ietf-tsvwg-sctp-prpolicies-05-secdir-lc-salowey-2014-12-04-00
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