Last Call Review of draft-ietf-tsvwg-sctp-dtls-encaps-07
review-ietf-tsvwg-sctp-dtls-encaps-07-opsdir-lc-taylor-2014-12-28-00

I have reviewed this document as part of the Operational directorate's 


ongoing effort to review all IETF documents being processed by the IESG. 


These comments were written primarily for the benefit of the operational 


area directors. Document editors and WG chairs should treat these 


comments just like any other last call comments.




Summary
-------



No discussion of operational or management aspects is provided. At the 


least, this document should provide a discussion of the applicability of 


the objects of the SCTP MIB module [RFC 3873] when SCTP is carried in 


DTLS. The dependency of parts of that module on IP addresses is a major 


consideration.






It would be desirable to provide a discussion of setup and management 


for the DTLS layer, since security is a key aspect of that protocol. 


DTLS documentation [RFCs 4347 and 6347] themselves fail to provide this 


information -- one has to go to the corresponding TLS documentation and 


infer the requirements.






SCTP authors tend to think in terms of APIs presented to applications 


rather than potential configuration data to link application 


requirements to SCTP options. It may be desirable to review the 


scalability of this architectural decision as the number of 


implementations of applications of SCTP grows.




Tom Taylor



Operational Considerations Checklist
------------------------------------

1. Deployment



No discussion of deployment or management is provided. The reviewer's 


view is that the dominating deployability concerns are those relating to 


DTLS, which are indirectly covered to some extent in RFC 5246 (TLS 1.2). 


See Operational Considerations Checklist Item 9 for a discussion of one 


aspect of scalability (at implementation time rather than deployment time).




2. Installation and initial setup



There is no discussion of installation and initial setup. See 


Operational Considerations Checklist item 9 regarding configuration.




3. Migration Path

Not applicable.

4. Requirements on other protocols



Dominated by the requirements on DTLS itself, which are spelled out 


explicitly, and those associated with the use of DTLS, which must be 


inferred. These latter include the protocol requirements for certificate 


validation.




5. Impact on network operation

Not discussed. None foreseen by the reviewer.

6. Testing and Verification



Not discussed. To some extent the SCTP MIB module [RFC 3873] could be 


used for this purpose.




7. Management interoperability



Aspects of the SCTP MIB module have a strong dependency on the 


availability of IP addresses. A discussion of the applicability of this 


module in the case of SCTP over DTLS should be provided.




8. Fault or threshold conditions that should be reported

Not discussed.



SCTP and DTLS individually have reportable conditions. The combination 


does not present any significant new conditions in the reviewer's mind.




9. Configuration

Not discussed.



SCTP can be carried over several transports, to which this document adds 


DTLS. Historically and within the present document, the designers of 


SCTP have tended to think in terms of APIs and implementation rather 


than configuration. The implication is that the application is written 


to invoke the particular SCTP options, including transport, that it 


requires. The obvious architectural question is then whether this 


approach is wasteful of implementation resources as the number of 


implementations of SCTP applications increases, compared with the use of 


configuration data to link application requirements to SCTP options.





Management Considerations Checklist
-----------------------------------

No discussion of management considerations is present.



As mentioned above, this document should at least provide a discussion 


of the applicability of the objects in the SCTP MIB module [RFC 3873] 


when SCTP runs over DTLS. It would also be desirable to summarize the 


management of certificate distribution and validation for the DTLS layer.






Editorial/nits
--------------



1) IDNits complains that normative DTLS reference RFC 4347 is obsolete. 


The current reference is RFC 6347. The Shepherd's write-up indicates 


that DTLS version was a point of WG discussion for several months, so 


this was deliberate. (Support of RFC 4347 is mandatory, support of the 


latest version of DTLS a SHOULD.) [No action required.]






draft-ietf-tsvwg-sctp-prpolicies has a later version than shown in the 


document.






2) IDNits complains about presence of URLs that don't use a 


documentation domain. I suspect the offending text is actually the sentence:



     "Therefore it is
      RECOMMENDED to set the SCTP parameter path.max.retrans to
      association.max.retrans."


in Sec. 6.1, which refers to SCTP protocol parameters. [Hence no action 


required.]




3) Abstract, final two sentences:

OLD

   Using the
   encapsulation method described in this document, SCTP is agnostic
   about the protocols being used below DTLS, explicit IP addresses can
   not be used in the SCTP control chunks.  As a consequence, the SCTP
   associations are single homed.

SUGGESTED

   Using the
   encapsulation method described in this document, SCTP is unaware
                                                            ^^^^^^^
   of the protocols being used below DTLS; hence explicit IP addresses
   ^^                                    ^^^^^^^
   cannot be used in the SCTP control chunks.  As a consequence, the
     ^^
   SCTP in DTLS associations can only be single homed.
        ^^^^^^^              ^^^^^^^^^^^

4) Final line of final bullet of Sec. 6.1: s/its/their/

5) Sec. 6.2:

OLD

   The padding extension defined in [RFC4820] MUST be supported and used
   for probe packets when performing path MTU discovery as specified in
   [RFC4821] by the SCTP layer.

PROPOSED

   When the SCTP layer performs path MTU discovery as specified in
   [RFC4821], the padding extension defined in [RFC4820] MUST be
   supported and used for probe packets.

6) Sec. 6.3:

OLD
... only wildcard addresses MUST be used in ASCONF chunks.

PROPOSED

... ASCONF chunks MUST use wildcard addresses only.

7) Sec. 8, last paragraph, middle sentence:

OLD

   The processing of these
   messages for SCTP carried over a connection-less lower layer like IP,
   IPv6 or UDP is required to protect nodes not supporting SCTP.

PROPOSED

   When SCTP is carried over a connection-less lower layer like IPv4,
   IPv6, or UDP, processing of these messages is required to protect
   other nodes not supporting SCTP.