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

[Michael Tuexen <[e-mail]>]

On 03 Mar 2014, at 16:50, Karen E. Egede Nielsen <[e-mail]> wrote:

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

> 
> 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.
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
> 
> BR, Karen
> 
> 
>> -----Original Message-----
>> From: tsvwg [mailto:[e-mail]] 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
>> 
>> On 2014-03-03 14:25, Michael Tuexen wrote:
>>> On 03 Mar 2014, at 10:09, Magnus Westerlund
>> <[e-mail]> wrote:
>>> 
>>>> 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.
>>> OK.
>>>> 
>>>>> 
>>>>>> 
>>>>>> 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 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?
>> 
>> Yes.
>> 
>>>> 
>>>> 
>>>>>> 
>>>>>> 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.
>>> And that is why I added it to draft-ietf-tsvwg-sctp-dtls-encaps. So I
>>> think we agree here, or am I wrong?
>> 
>> Then we agree, I missunderstood that this addition was in the
> 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.
>>>> 
>>>>> 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.
>>> 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>
>>> 
>> 
>> Yes, assuming that you understand the motivation why this is true. I do,
> and I
>> hope many others do.
>> 
>> 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]
>> ----------------------------------------------------------------------
>