Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-dtls-encaps: To End 28th February 2014

[Michael Tuexen <[e-mail]>]

On 27 Feb 2014, at 09:14, Magnus Westerlund <[e-mail]> wrote:

> On 2014-02-07 18:18, Gorry Fairhurst wrote:
>> This email announces the start of a working group last call
>> of draft-ietf-tsvwg-sctp-dtls-encaps-03,
>> "DTLS Encapsulation of SCTP Packets". This document was
>> discussed at the WG meeting in Vancouver and was thought at that
>> meeting to be ready for WG review, this email starts this process by
>> requesting review comments.
>> 
>> Please send any comments, notes of support, or concerns to the TSVWG list.
>> 
>> The draft is available at:
>> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps
>> 
>> The last call will run for TWO weeks, ending 28th February 2014.
>> 
>> James, David, and Gorry
>> (TSVWG Chairs)
>> [e-mail]
>> 
> 
> WG,
> 
> I have review the draft and think it is mostly ready but there are some
> issue I would like to bring to your attention for discussion.
Hi Magnus,

thank you very much for your review. Please see my comments in-line.

Best regards
Michael
> 
> 1) Section 1.1
> 
>   The Stream Control Transmission Protocol (SCTP) as defined in
>   [RFC4960] is a transport protocol running on top of the network
>   protocols IPv4 or IPv6.  This document specifies how SCTP is used on
>   top of the Datagram Transport Layer Security (DTLS) protocol defined
>   in [RFC6347].  This encapsulation is used for example within the
>   RTCWeb protocol suite (see [I-D.ietf-rtcweb-overview] for an
>   overview) for transporting non-media data between browsers.  The
>   architecture of this stack is described in
>   [I-D.ietf-rtcweb-data-channel].
> 
> I would like to rewrite this to:
> 
>   The Stream Control Transmission Protocol (SCTP) as defined in
>   [RFC4960] is a transport protocol running on top of the network
>   protocols IPv4 [RFC0791] or IPv6 [RFC2460].  This document specifies
>   how SCTP is used on top of the Datagram Transport Layer Security
>   (DTLS) protocol defined in [RFC6347].  This encapsulation is used
>   for example within the WebRTC protocol suite (see [I-D.ietf-rtcweb-
>   overview] for an overview) for transporting non-RTP [RFC3550] data
>   between browsers.  The architecture of this stack is described in
>   [I-D.ietf-rtcweb-data-channel].
> 
> Changes are:
> - References for IP
Added as Informative References
> - RTCWEB -> WebRTC
Done.
> - non-media to non-RTP data
Changed to non-(S)RTP data to be consistent with the data channel IDs.

> 
> 2) Section 1.3:
> 
> I think there are a need for some terms not yet mentioned to have
> references to where they are defined. The terms I consider needing
> references are:
> - PPID
> - TCP
> - TLS
> 
> MTU would be good also.
I removed TCP and TLS since they are not used in the document. For all
remaining acronyms (DTLS, MTU, PPID, SCTP) I added references.
> 
> 3) Section 4:
> 
>   The DTLS implementation MUST be based on [RFC6347].
> 
> What happens when RFC 6347 is obsoleted? And that obsoletion can be
> based on two cases, either the whole DTLS version is being replaced or
> the RFC just updated for the same DTLS version. The later case I
> definitely should be less locked in. For the DTLS version it is a
> question of interoperability. Thus I think one probably should word this as:
> 
>   The DTLS implementation MUST be based on DTLS 1.2 [RFC6347].
> 
> Then one could add supporting future versions of DTLS is RECOMMENDED if
> defined.
OK. The reads

<t>The DTLS implementation MUST be based on DTLS 1.2 <xref target='RFC6347'/>.
The support of future versions of DTLS is RECOMMENDED if defined</t>

> 
> 4) Section 4:
> 
>   If path MTU discovery is performed by the DTLS layer, the method
>   described in [RFC4821] MUST be used.  For probe packets, the
>   extension defined in [RFC6520] MUST be used.
> 
>   If path MTU discovery is performed by the SCTP layer and IPv4 is used
>   as the network layer protocol, the DTLS implementation MUST allow the
>   DTLS user to enforce that the corresponding IPv4 packet is sent with
>   the DF bit set.
> 
> Although this is stated, there are no requirement that I find in the
> specification that says that you MUST implement a PMTUD method. My

> understanding is that IP/UDP/DTLS/SCTP is going to have a misserable
> time working if one ends up with IP fragments in other cases than for
> PMTUD probing packets. Thus, I think there needs to be a requirement on
> implementing some type of PMTUD method that works in this setting.
It is stated in Section 5 of draft-ietf-rtcweb-data-channel that
PMTU discovery MUST be done by SCTP.
> 
> I propose:
> 
>   An implementation of SCTP over DTLS MUST implement and use a path
>   MTU discovery method that functions without ICMP to provide SCTP
>   with a MTU estimate. An implementation of "Packetization Layer Path
>   MTU Discovery" [RFC4821] either in SCTP or DTLS is RECOMMENDED.
> 
> I do note that this text is not suitable in any of the existing
> sections. Maybe a new section between 3 and 4 for general considerations.
Added exactly there...

I also added based on comments to one of the data channel documents:

<t>The DTLS implementation SHOULD allow the DTLS user to control the DSCP
value used for IP packets being sent.</t>
> 
> 5) Section 7.
> 
> It is not obvious that this do not create new security issues. To me an
> obvious candidate for causing potential issues is the requirement on
> SCTP to be able to function without ICMP. Are there behaviors introduced
> that are a result of not receiving ICMP because they are not provided to
> SCTP, which compared to SCTP over IP would not exist. At the same time I
> do realize that it protects the SCTP stack from some attack vectors
> through ICMP.
The processing of ICMP is important to protect non-SCTP capable hosts.
But when using SCTP/DTLS, you are running about a connection oriented
protocol and therefore you can't just send SCTP packets to a host.
So I think this is very different. If you think these should be mentioned
explicitly, I can add such text.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
>