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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Sat, 17 January 2015 08:47 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F202A1B2B58 for <rtcweb@ietfa.amsl.com>; Sat, 17 Jan 2015 00:47:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level:
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8szSCriNi3RC for <rtcweb@ietfa.amsl.com>; Sat, 17 Jan 2015 00:47:28 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10F71A8A82 for <rtcweb@ietf.org>; Sat, 17 Jan 2015 00:47:27 -0800 (PST)
Received: from [192.168.1.200] (p54819F98.dip0.t-ipconnect.de [84.129.159.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 774841C104343; Sat, 17 Jan 2015 09:47:24 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <323A2603-0D0F-41E9-BC54-F4B62DAF0D91@cisco.com>
Date: Sat, 17 Jan 2015 09:47:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B3BE973D-8C02-4374-82BF-8D15245D0246@lurchi.franken.de>
References: <CAOW+2dsaAOmOS=VZe8VTRoSSjN0TAQzY2kXaOqHUCAf9jaA5Mw@mail.gmail.com> <DD273892-F62C-423C-A4FF-0BA8288A5454@lurchi.franken.de> <CABkgnnU9D7kq9R_QtLcyw58jiyYLrvLjK==X=ur1=btesdpVCw@mail.gmail.com> <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <, <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <>> <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> <F37D57FF-09DC-4339-B862-0685BD26658D@lurchi.franken.de> <786615F3A85DF44AA2A76164A71FE1AC384689@FR711WXCHMBA03.zeu.alcatel-lucent.com> <A2963036-DD2E-4471-96F2-48CD036176A1@lurchi.franken.de> <323A2603-0D0F-41E9-BC54-F4B62DAF0D91@cisco.com>
To: Dan Wing <dwing@cisco.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/6xX8roeAR6FJpa_3YIYiKv9eSCk>
Cc: Iljitsch van Beijnum <iljitsch@muada.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Jan 2015 08:47:31 -0000

> On 17 Jan 2015, at 00:55, 🔓Dan Wing <dwing@cisco.com> wrote:
> 
> 
> On Jan 15, 2015, at 1:13 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> 
>> On 15 Jan 2015, at 09:45, Schwarz, Albrecht (Albrecht) <albrecht.schwarz@ALCATEL-LUCENT.COM> wrote:
>>> 
>>> 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.
>> 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
>> 
>>  Incoming ICMP or ICMPv6 messages can't be processed by the SCTP
>>  layer, since there is no way to identify the corresponding
>>  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).
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
> 
> -d
> 
> 
>> 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 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
>>> 
>>> Thanks,
>>> Albrecht
>>> 
>>> -----Original Message-----
>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Michael Tuexen
>>> Sent: Donnerstag, 15. Januar 2015 09:42
>>> To: Christer Holmberg
>>> Cc: rtcweb@ietf.org
>>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat
>>> 
>>>> On 15 Jan 2015, at 05:45, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I don't think the sctp-dtls-encaps draft shall contain data channel specific procedures.
>>> 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
>>>> 
>>>> Regards,
>>>> 
>>>> Christer
>>>> 
>>>> Sent from my Windows Phone
>>>> From: Michael Tuexen
>>>> Sent: ‎15/‎01/‎2015 00:40
>>>> To: Harald Alvestrand
>>>> Cc: rtcweb@ietf.org
>>>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS 
>>>> heartbeat
>>>> 
>>>> On 14 Jan 2015, at 23:12, Harald Alvestrand <harald@alvestrand.no> wrote:
>>>>> 
>>>>> Den 14. jan. 2015 21:06, skrev Michael Tuexen:
>>>>>> On 14 Jan 2015, at 18:17, Martin Thomson <martin.thomson@gmail.com> wrote:
>>>>>>> 
>>>>>>> On 14 January 2015 at 00:49, Michael Tuexen 
>>>>>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>>>>>> * 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#sect
>>>>>>>> ion-5
>>>>>>> 
>>>>>>> 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.
>>>>> 
>>>>> So which document should we put it in that we use the second option?
>>>>> -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#secti
>>>> on-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
>>>>> 
>>>>>> 
>>>>>> Best regards
>>>>>> Michael
>>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> rtcweb mailing list
>>>>>> rtcweb@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> rtcweb mailing list
>>>>> rtcweb@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
>