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

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------