IETF Logo Mail Archive

Re: [rtcweb] SCTP issue: Datachannel MTU seems to be problematic.

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Tue, 02 March 2021 11:01 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA4F3A15AC for <rtcweb@ietfa.amsl.com>; Tue, 2 Mar 2021 03:01:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.001, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 hnBdOcaXdTSN for <rtcweb@ietfa.amsl.com>; Tue, 2 Mar 2021 03:01:04 -0800 (PST)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5DB3A15A7 for <rtcweb@ietf.org>; Tue, 2 Mar 2021 03:01:04 -0800 (PST)
Received: from [IPv6:2a02:8109:1140:c3d:8118:4e67:8ff9:4fe8] (unknown [IPv6:2a02:8109:1140:c3d:8118:4e67:8ff9:4fe8]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 2CD367002C835; Tue, 2 Mar 2021 12:00:53 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <90b567c1-40d3-6005-44c3-efd5d52c2064@alvestrand.no>
Date: Tue, 02 Mar 2021 12:00:52 +0100
Cc: Nils Ohlmeier <nohlmeier@mozilla.com>, rtcweb@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E8C387A-5A36-41CD-8DC0-906CD1B44290@lurchi.franken.de>
References: <94b3d388-37cd-c29b-9c71-59f8ae14aefa@alvestrand.no> <5300B7A1-6D3E-4BD4-8D41-6A03C2D6E5CC@mozilla.com> <388582AE-1FC6-4CD7-94DB-82FB68CCF679@lurchi.franken.de> <90b567c1-40d3-6005-44c3-efd5d52c2064@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/Sz5MKFYPAyyABcIX2hsJMqyPDW0>
Subject: Re: [rtcweb] SCTP issue: Datachannel MTU seems to be problematic.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 02 Mar 2021 11:01:07 -0000

> On 2. Mar 2021, at 08:53, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> 
> On 3/2/21 12:09 AM, Michael Tuexen wrote:
>>> On 1. Mar 2021, at 23:53, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
>>> 
>>> Hi Harald,
>>> 
>>>> On 1Mar, 2021, at 11:17, Harald Alvestrand <harald@alvestrand.no> wrote:
>>>> 
>>>> This for info:
>>>> 
>>>> We have recently discovered some problems with SCTP on small-MTU networks.
>>> Interesting problem you encountered there.
>>> 
>>>> Turns out we underestimated the max size of the encapsulating headers.
>>>> 
>>>> Current calculation:
>>>> 
>>>> // The biggest SCTP packet. Starting from a 'safe' wire MTU value of 1280,
>>>> // take off 85 bytes for DTLS/TURN/TCP/IP and ciphertext overhead.
>>>> //
>>>> // Additionally, it's possible that TURN adds an additional 4 bytes of overhead
>>>> // after a channel has been established, so we subtract an additional 4 bytes.
>>>> //
>>>> // 1280 IPV6 MTU
>>>> //  -40 IPV6 header
>>>> //   -8 UDP
>>>> //  -24 GCM Cipher
>>>> //  -13 DTLS record header
>>>> //   -4 TURN ChannelData
>>>> // = 1191 bytes.
>>>> 
>>>> Which is somewhat smaller than the number we assumed in the RFC of 1200 bytes.
>>> What I don’t understand here is that this calculation is only done for IPv6, which has a significantly higher minimum MTU compared to IPv4.
>> I was assuming that an IPv6 network is used with an MTU of 1280 to provide IPv4 connectivity via a TURN service.
>> So the IPv4 level MTU would be 1191, which is smaller than 1200 as mentioned in the RFC... Or am I wrong?
> 
> The actual problem we discovered in production was in a case without TURN, but with a client that did IPv6 only. (It may also be client OS specific - we're not sure about that.)
But in that case the specification says the IP level PMTU is at least 1280. The
overhead related to the protocol between IPv6 and SCTP is not specified in the RFC.

Best regards
Michael
> 
> So we could probably have gotten away with an MTU of 1195 bytes.
> 
> I'm also not sure if the 24 bytes of GCM cipher overhead is the right number for all ciphersuites that we permit; we may have to keep an eye on that.
> 
> But yes, we need Path MTU discovery to work, including a way to recover from too-large initial assumptions.
> 
> 
> 
> 
>

v2.23.0 | Report a Bug | By Email