Subject: [rtcweb] Question about support for RFC 6520 DTLS heartbeat

From: Bernard Aboba <[email-masked]>
Date: Tue, 13 Jan 2015 16:57:43 -0800

Looking through IETF RTCWEB WG drafts (
https://tools.ietf.org/id/draft-ietf-rtcweb) and dependencies, "DTLS
Heartbeat" RFC 6520 appears to be referenced only in
draft-ietf-tsvwg-sctp-dtls-encaps Section 5, in the context of PMTU
discovery:

   If path MTU discovery is performed by the DTLS layer, the method
   described in [RFC4821 <https://tools.ietf.org/html/rfc4821>] MUST
be used.  For probe packets, the
   extension defined in [RFC6520
<https://tools.ietf.org/html/rfc6520>] MUST be used.

Is it correct to conclude that existing implementations do not use the DTLS
heartbeat other than for PMTU discovery?

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Jan 2015 17:28:17 -0800

> heartbeat other than for PMTU discovery?

I don't think we use it because I don't think that it is implemented
in NSS.  We don't need it now that we use ICE for the keep-alive
stuff.  I'll let others talk about PMTU discovery.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 14 Jan 2015 09:49:48 +0100

On 14 Jan 2015, at 01:57, Bernard Aboba <[email-masked]> wrote:
> 
> Looking through IETF RTCWEB WG drafts (https://tools.ietf.org/id/draft-ietf-rtcweb) and dependencies, "DTLS Heartbeat" RFC 6520 appears to be referenced only in draft-ietf-tsvwg-sctp-dtls-encaps Section 5, in the context of PMTU discovery: 
> 
>    described in [
> RFC4821
> ] MUST be used.  For probe packets, the
>    extension defined in [
> RFC6520] MUST be used.
> 
> Is it correct to conclude that existing implementations do not use the DTLS heartbeat other than for PMTU discovery? 
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07
describes two options for SCTP over DTLS:
* DTLS does the PMTUD using DTLS heartbeats
* SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks

My understanding is the RTCWeb uses the second option as described in
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5

Best regards
Michael 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Jan 2015 09:17:20 -0800

> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5

SGTM.  That means we don't need to reference the DTLS heartbleed extension.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 14 Jan 2015 21:06:53 +0100

> SGTM.  That means we don't need to reference the DTLS heartbleed extension.
It is not referenced in the RTCWeb documents, only in
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07
which allows both options.

Best regards
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Jan 2015 23:12:12 +0100

> which allows both options.

So which document should we put it in that we use the second option?
-transport, or a post-last-call update of -datachannel?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Jan 2015 14:17:22 -0800

> -transport, or a post-last-call update of -datachannel?

I think that -datachannel is most appropriate.  It's very late though;
if chairs think that it's too late, -transports or even -security-arch
(under its DTLS profiling remit) are probably OK places to squeeze it
in.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 14 Jan 2015 23:40:04 +0100

> -transport, or a post-last-call update of -datachannel?
Do we really need a change? We have in 
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5
   Incoming ICMP or ICMPv6 messages can't be processed by the SCTP
   layer, since there is no way to identify the corresponding
   association.  Therefore SCTP MUST support performing Path MTU
   discovery without relying on ICMP or ICMPv6 as specified in [RFC4821]
   using probing messages specified in [RFC4820].  The initial Path MTU
   at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for
   IPv6.

In the next revision of
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4
there will be the sentence:
   The path MTU discovery is performed by SCTP when SCTP over DTLS is
   used for data channels (see Section 4 of
   [I-D.ietf-rtcweb-data-channel]).

Best regards
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Jan 2015 00:19:06 +0100

>    at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for

Good! I misunderstood what "it is not referenced" referred to above.

>    [I-D.ietf-rtcweb-data-channel]).

I think the section number is wrong - section 4 of data-channel is
requirements. (unless revised).

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Jan 2015 04:45:47 +0000

Hi,

I don't think the sctp-dtls-encaps draft shall contain data channel specific procedures.

I agree with Martin that the best place is the data channel draft.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Michael Tuexen<mailto:[email-masked]>
Sent: ‎15/‎01/‎2015 00:40
To: Harald Alvestrand<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat

In the next revision of

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 15 Jan 2015 09:39:11 +0100

> requirements. (unless revised).
That is correct. I guess Gorry (who suggested the text) had Req. 9 in mind.
But we can change the reference to Section 5 if you prefer.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 15 Jan 2015 09:41:55 +0100

> On 15 Jan 2015, at 05:45, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
It doesn't. It only makes clear which of the two options are used in RTCWeb.
> I agree with Martin that the best place is the data channel draft.
So you think the text in the data channel draft is not enough? It is and
was clear to me that SCTP does the PMTUD, not DTLS, when SCTP over DTLS is
used in RTCWeb. 

Best regards
Michael
> From: Michael Tuexen
> To: Harald Alvestrand
> Cc: [email-masked]

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 15 Jan 2015 08:45:38 +0000

Michael,

neither obvious nor clear to me why SCTP is responsible for PMTUD in a stack such as {SCTP/DTLS/L4/IP} layering.
Perhaps I miss sth, but I would appreciate more text.

Thanks,
Albrecht

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Michael Tuexen
Sent: Donnerstag, 15. Januar 2015 09:42
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat

> I agree with Martin that the best place is the data channel draft.
So you think the text in the data channel draft is not enough? It is and was clear to me that SCTP does the PMTUD, not DTLS, when SCTP over DTLS is used in RTCWeb. 

Best regards
Michael

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Jan 2015 08:56:24 +0000

Hi,

> It doesn't. It only makes clear which of the two options are used in RTCWeb.

If it needs to be clear, it should be in an RTCWeb spec.

For sure, you can state it as an EXAMPLE in the encaps draft if you want to. But, an RTCWeb implementer should not have to read the encaps draft in order to figure out which option is used - that needs to be clear in an RTCWeb spec.

> So you think the text in the data channel draft is not enough? It is and was clear to me that SCTP does the PMTUD, not DTLS, when SCTP over DTLS is used in RTCWeb. 

I didn't check the text in the data channel draft :) Based on the discussion I assumed that some text is missing, and is needed somewhere.

Regards,

Christer

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 15 Jan 2015 10:13:07 +0100

> Perhaps I miss sth, but I would appreciate more text.
There are two options:
* It can be done by SCTP (using HEARTBEAT and PADDING chunks)
* It can be done by DTLS (using the heartbeat extension)
These two options are described in
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4
The next revision will add a clarifying sentence that in the case of RTCWeb
the first option is used as stated in
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13
The following text

in https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5
states that SCTP does PMTUD using the first option above.

Which text are you missing?

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 15 Jan 2015 10:19:54 +0100

> If it needs to be clear, it should be in an RTCWeb spec.
I agree and I think it is...
> For sure, you can state it as an EXAMPLE in the encaps draft if you want to. But, an RTCWeb implementer should not have to read the encaps draft in order to figure out which option is used - that n…
I agree. And I think the text suggested by Gorry is meant as that.
> I didn't check the text in the data channel draft :) Based on the discussion I assumed that some text is missing, and is needed somewhere.
Please have a look at my other responses in this thread where I cite the existing text. Let me know
if you think that the existing text doesn't state clearly enough that SCTP does PMTUD and not DTLS.

Best regards
Michael

---

From: 🔓Dan Wing <[email-masked]>
Date: Fri, 16 Jan 2015 15:55:55 -0800

On Jan 15, 2015, at 1:13 AM, Michael Tuexen <[email-masked]> wrote:

>   association.  

Why does the corresponding (SCTP) association need to be identified?  It's all over UDP, anyway.  On receipt of ICMP PTB, drop down to 1200 bytes (IPv4) or 1280 bytes (IPv6), or be smarter about the reduction (e.g., the table at https://tools.ietf.org/html/rfc1191#page-17 or Iljitsch's recent research to find common MTUs on today's Internet).

-d

> Therefore SCTP MUST support performing Path MTU

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 17 Jan 2015 09:47:23 +0100

> On 17 Jan 2015, at 00:55, 🔓Dan Wing <[email-masked]> wrote:
> 
> 
The current way SCTP processes ICMP messages is:
* Find the SCTP association based on IP addresses and port numbers
* Verify the verification tag contained in the SCTP common header contained in the ICMP message
* Process the ICMP message...
This clearly ICMP messages can't be processed by SCTP since especially the vtag check can't be done.

But you are right:
* UDP could notify its upper layer that it has received the ICMP PTB message (and possibly could provide a hint).
* DTLS could pass this through to its upper layer.
* SCTP could process it for all associations running over that DTLS connection bypassing
  the vtag check.

However, you loose the protection provided by the vtag check. An attacker knowing
the IP-addresses and UDP port numbers can inject such an ICMP packet.
SCTP normally requires that the sender of the packet does know the vtag.

Therefore the way currently specified is that PMTUD as specified in RFC4821
is used. This does not depend on incoming ICMP messages. They might be blocked
in the network or the DTLS layer might not pass them through.

If you think we should change the SCTP over DTLS ID, please bring this up at tsvwg@.

Best regards
Michael

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 19 Jan 2015 09:22:42 -0800

> SCTP normally requires that the sender of the packet does know the vtag.

To prevent similar off-path attacks, many TCP implementations validate the sequence number of ICMPs (https://tools.ietf.org/html/rfc5927#section-4.1).  The TCP sequence number is in the same place as SCTP's VTAG (both are immediately after the port numbers), so SCTP's VTAG should be returned in ICMP PTB as often as TCP sequence numbers are returned in ICMP PTBs.  https://tools.ietf.org/html/rfc1812#section-4.3.2.3 increased the recommended size of ICMPs, and I understand is pretty well deployed.

-d

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 19 Jan 2015 20:18:36 +0100

> On 19 Jan 2015, at 18:22, 🔓Dan Wing <[email-masked]> wrote:
> 
> 
You are right, this would work for SCTP/UDP/ICMP, but we are using SCTP/DTLS/UDP/ICMP.
So SCTP would get the encrypted SCTP packet, which is useless. I haven't seen DTLS decrypting
the partial packets. Therefore the TSVWG suggests using the method described in RFC4821.

Best regards
Michael

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 19 Jan 2015 11:44:12 -0800

> the partial packets. Therefore the TSVWG suggests using the method described in RFC4821.

Seems this highlights a more general problem with validating any ICMP error for a DTLS packet, which should have sanity checks performed (similar to sanity checks of SCTP VTAG and TCP sequence numbers).  DTLS has some fields in the clear which would be returned in ICMP (epoch and sequence number), but unfortunately they are not randomized like SCTP VTAG or TCP sequence numbers.  I'll bring that up on TSVWG.

-d

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 19 Jan 2015 21:30:42 +0100

> On 19 Jan 2015, at 20:44, 🔓Dan Wing <[email-masked]> wrote:
> 
> 
> Seems this highlights a more general problem with validating any ICMP error for a DTLS packet, which should have sanity checks performed (similar to sanity checks of SCTP VTAG and TCP sequence numbers).  DTLS has some fields in the clear which would be returned in ICMP (epoch and sequence number), but unfortunately they are not randomized like SCTP VTAG or TCP sequence 
Correct.
> numbers.  I'll bring that up on TSVWG.
Great. Thanks.

Best regards
Michael