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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 3 Mar 2014 10:09:51 +0000

Hi,

I removed things that don't additional follow up.

On 2014-02-28 21:24, Michael Tuexen wrote:

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

I think that is okay.

> 
>>
>> 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 think that is the wrong place. To my understanding the PMTUD is really
important to get SCTP to behave well. Thus, this DTLS encapsulation can
be used by other protocols than data channels, thus I think this is the
document that should mandate the PMTUD discovery.

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

Also here I think it is a SCTP/DTLS issue, not a DATA-Channel/SCTP/DTLS
issue.

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

Yes, I think that would be good.

Thanks

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: Michael Tuexen <[email-masked]>
Date: Mon, 3 Mar 2014 14:25:17 +0000

>> The support of future versions of DTLS is RECOMMENDED if defined</t>
OK.
> document that should mandate the PMTUD discovery.
I added text that you MUST do PMTUD either in SCTP or DTLS.
draft-ietf-rtcweb-data-channel then nails this down to SCTP
MUST do this in the RTCWeb context. That should cover what you want,
right?
> Also here I think it is a SCTP/DTLS issue, not a DATA-Channel/SCTP/DTLS
And that is why I added it to draft-ietf-tsvwg-sctp-dtls-encaps. So I think we agree here,
or am I wrong?
> Yes, I think that would be good.
OK. Added
<t>It should be noted that the inability to process ICMP or ICMPv6 messages
does not add any security issue. 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. Since DTLS provides a connection-oriented
lower layer, this kind of protection is not necessary.</t>

OK?

Best regards
Michael

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 3 Mar 2014 16:23:46 +0000

> MUST do this in the RTCWeb context. That should cover what you want,

Yes.

> And that is why I added it to draft-ietf-tsvwg-sctp-dtls-encaps. So I think we agree here,

Then we agree, I missunderstood that this addition was in the
data-channel draft, not this one.

> lower layer, this kind of protection is not necessary.</t>

Yes, assuming that you understand the motivation why this is true. I do,
and I hope many others do.

Cheers

Magnus Westerlund

---

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Mon, 3 Mar 2014 17:50:27 +0100

Hi,

I have also read the draft now.

Following up on the below I think that one need to explicitly state that
it is required for SCTP
PMTUD to be implemented in accordance with RFC4821 in the (extreme)
variant where one do not rely on ICMPs
at all.

I further would like to add, here but it need not go into the draft,
that I consider this to be somewhat of a limitation of SCTP over DTLS.
Indeed
quoting from RFC4821, section 2:

   Packetization Layer Path MTU Discovery (PLPMTUD) is a method for TCP
   or other Packetization Protocols to dynamically discover the MTU of a
   path by probing with progressively larger packets.  It is most

^^^^^^
   efficient when used in conjunction with the ICMP-based Path MTU
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Discovery mechanism as specified in RFC 1191 and RFC 1981, but
   resolves many of the robustness problems of the classical techniques
   since it does not depend on the delivery of ICMP messages.

Further one may note that the IPv6 node requirements, RFC6434, mentions
RFC4821,
but does not stipulate for nodes to implement it.

I know of some SCTP implementations that "supports" RFC4821, RFC4820
without
actually supporting the ICMP black hole part of RFC4821. I.e., they
support classical PMTUD
with all the clarifications and improvements that RFC4821 adds, but they
still rely on the return of an ICMP in order
to not handle a lost probe as a congestion event.

BR, Karen

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: 3. marts 2014 17:24
> To: Michael Tuexen
> Cc: tsvwg WG
> Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-dtls-encaps: To End
28th
> February 2014
> >>>> 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
> >>>> question of interoperability. Thus I think one probably should word
this
> as:
> >>>> Then one could add supporting future versions of DTLS is
> >>>> RECOMMENDED if defined.
> >>> OK. The reads
> >>>
> >>>>  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 think that is the wrong place. To my understanding the PMTUD is
> >> really important to get SCTP to behave well. Thus, this DTLS
> >> encapsulation can be used by other protocols than data channels, thus
> >> I think this is the document that should mandate the PMTUD discovery.
> > draft-ietf-rtcweb-data-channel then nails this down to SCTP MUST do
> > this in the RTCWeb context. That should cover what you want, right?
>
> Yes.
>
> >>
> >>
> >>>>
> >>>> I propose:
> >>>>
> >>> <t>The DTLS implementation SHOULD allow the DTLS user to control the
> >>> DSCP value used for IP packets being sent.</t>
> >>
> >> Also here I think it is a SCTP/DTLS issue, not a
> >> DATA-Channel/SCTP/DTLS issue.
> > And that is why I added it to draft-ietf-tsvwg-sctp-dtls-encaps. So I
> > think we agree here, or am I wrong?
>
data-channel
> draft, not this one.
>
> >>
> >>>>
> >>>> 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.
> >>
> >>> 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.
> >>
> > <t>It should be noted that the inability to process ICMP or ICMPv6
> > messages does not add any security issue. 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. Since
> > DTLS provides a connection-oriented lower layer, this kind of
> > protection is not necessary.</t>
> >
>
and I
> hope many others do.

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 3 Mar 2014 17:15:53 +0000

> variant where one do not rely on ICMPs
Based on the discussion on the list the next revision will contain a section
reading:

<section title='General Considerations'>
<t>An implementation of SCTP over DTLS MUST implement and use a path
MTU discovery method that functions without ICMP to provide SCTP/DTLS
with a MTU estimate.
An implementation of "Packetization Layer Path MTU Discovery"
<xref target='RFC4821'/> either in SCTP or DTLS is RECOMMENDED.</t>
</section>

Does this text address your issue?

>   efficient when used in conjunction with the ICMP-based Path MTU
Even an SCTP/IP implementation has to deal with the case that no ICMP
packets are received. So if you get them, you can optimize your discovery,
but you must need it. So it might make sense not to increase your T3 in
case of a probe packet (HEARTBEAT with PADDING) is lost.

However, I leave that out of the document.

Thanks a lot for your comments.

Best regards
Michael

---

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Mon, 3 Mar 2014 17:58:56 +0100

Hi,

I think that this work is very important and I support the progressing of
the work.

I personally see no reason why the work should not progress to RFC once
the editorial comments raised
recently on the list have been addressed.

BR, Karen

> From: tsvwg [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
> Sent: 26. februar 2014 15:47
> To: [email-masked]
28th
> February 2014
>
> 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
>
> On 07/02/2014 17: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)
> > [email-masked]
> >