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 General Internet Signaling Transport (GIST) protocol, as defined in draft-ietf-nsis-ntlp-20.txt, provides for flexibility in selection of transport and lower-layer security protocols, but initially specifies only TCP and TLS-over-TCP. The present document extends GIST by adding support for SCTP and DTLS-over-SCTP. The security considerations section is quite short, incorporating by reference the security considerations of GIST, SCTP, and DTLS. This seems entirely reasonable, with the exception of the specific points mentioned below, which I'd like to see addressed directly. It is noted in multiple places that replay protection is not available when using DTLS over SCTP, with no further explanation other than a reference to draft-ietf-tsvwg-dtls-for-sctp (which itself says that the feature MUST NOT be used, but gives no explanation). In particular, there is no discussion as to what implications this has for GIST or for higher-layer protocols in the NSIS stack. Section 8 says DTLS support MUST be implemented, presumably by anything complying with the present document and thus anything which supports GIST over SCTP. It then goes on to say that an implementation of GIST over SCTP without PR-SCTP (and thus, where there is no change that individual TLS records will be dropped from the middle of the stream due to differing timeouts) MAY use TLS instead of DTLS. That is, it permits GIST-over-TLS-over-SCTP instead of GIST-over-DTLS-over-SCTP when the latter is not available (provided PR-SCTP is not used). Why would this ever be necessary? If DTLS is mandatory-to-implement, in what scenario would TLS be available but not DTLS? _______________________________________________ secdir mailing list secdir at mit.edu https://mailman.mit.edu/mailman/listinfo/secdir