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

[Michael Tuexen <[e-mail]>]

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

OK?

Best regards
Michael
> 
> Thanks
> 
> 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]
> ----------------------------------------------------------------------
> 
>