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

["Karen E. Egede Nielsen" <[e-mail]>]

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