IETF Logo Mail Archive

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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Wed, 14 January 2015 22:40 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 E44381ACEA4 for <rtcweb@ietfa.amsl.com>; Wed, 14 Jan 2015 14:40:12 -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 MtlWARKi7htn for <rtcweb@ietfa.amsl.com>; Wed, 14 Jan 2015 14:40:07 -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 339921ACE6B for <rtcweb@ietf.org>; Wed, 14 Jan 2015 14:40:07 -0800 (PST)
Received: from [192.168.1.200] (p508F28EF.dip0.t-ipconnect.de [80.143.40.239]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9A96F1C104357; Wed, 14 Jan 2015 23:40:05 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <54B6E9BC.2060203@alvestrand.no>
Date: Wed, 14 Jan 2015 23:40:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@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>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1993)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/vxTvKIEx8qCAJK5Gi9GomufDSM0>
Cc: 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: Wed, 14 Jan 2015 22:40:13 -0000

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#section-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#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
> 
>> 
>> 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
>

v2.23.0 | Report a Bug | By Email