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

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 07 Feb 2014 17:18:33 +0000

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)
[email-masked]

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 26 Feb 2014 14:47:16 +0000

A gentle reminder, I've seen no notes of support, or comments on this 
document during the WGLC so far.

Could people please send comments to the list if they think this is 
ready to publish?

Gorry

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Feb 2014 09:14:19 +0100

> The last call will run for TWO weeks, ending 28th February 2014.

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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Irene Rüngeler <[email-masked]>
Date: Thu, 27 Feb 2014 09:49:23 +0100

Hi all,

I read the draft and support it. It is very important for the encryption of the non-media streams in WebRTC.

Regards

Irene

Am 26.02.2014 um 15:47 schrieb Gorry Fairhurst <[email-masked]>:

> A gentle reminder, I've seen no notes of support, or comments on this document during the WGLC so far.
> 
> Could people please send comments to the list if they think this is ready to publish?
> 
> Gorry
> 

*****************************************

Dr. Irene Rüngeler 
Fachhochschule Münster, Abt. Steinfurt 
FB Elektrotechnik und Informatik 
Labor für Netzwerkprogrammierung, Datenbanklabor 
Bismarckstr. 11 
Tel.: 02551-962561 
Fax: 02551-962563 
EMail: [email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 28 Feb 2014 22:24:21 +0100

> 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
>   [I-D.ietf-rtcweb-data-channel].
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.

> references to where they are defined. The terms I consider needing
I removed TCP and TLS since they are not used in the document. For all
remaining acronyms (DTLS, MTU, PPID, SCTP) I added references.
> Then one could add supporting future versions of DTLS is RECOMMENDED if
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>

> 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.
> 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>
> do realize that it protects the SCTP stack from some attack vectors
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.