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

[Magnus Westerlund <[e-mail]>]

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