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

[Magnus Westerlund <[e-mail]>]

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.

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
- RTCWEB -> WebRTC
- non-media to non-RTP data

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.

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.

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.

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.

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.

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]
----------------------------------------------------------------------