Re: [v6ops] [IPv6] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)

Tom Herbert <tom@herbertland.com> Wed, 17 May 2023 18:57 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F12C14F693 for <v6ops@ietfa.amsl.com>; Wed, 17 May 2023 11:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGr7hH3BxQfz for <v6ops@ietfa.amsl.com>; Wed, 17 May 2023 11:57:06 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32C6C14CF0D for <v6ops@ietf.org>; Wed, 17 May 2023 11:57:06 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-6436e075166so852495b3a.0 for <v6ops@ietf.org>; Wed, 17 May 2023 11:57:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1684349826; x=1686941826; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=x79NMAOxjwjBNnX67V2T/0TknTn4GHPlvBhChiopciQ=; b=EwFI2cBg3bioE1CREmmZC9SCEf2ofxqf/RcWCmIbsH8e96+6/7wCWtyRiDAE2Avnc3 vDPYtCaF1SGohycGrdAI7eHsV1MXt0aMzoZfpwkPik3+kV7iediwPabTuCvi7/Z+VAMK jXE2gRjVIqpJdok5M8N/qL3l0xIsdatE/RlvF8Oi0TTCUxsb2Kth9VAj50sOXiro+sw9 F558mxsgNxkty80u9l/d4oRgZPKJDgUQYW3OuPHO+rnlu7egc5ecJtiS6hmYULG/OVLi TKuGfwQUl2Q3VEkVBFG4fPavJX15YqQhnlADd408Z0wXJMkW52nubZMperSQgRjKw7Pz I5uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684349826; x=1686941826; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=x79NMAOxjwjBNnX67V2T/0TknTn4GHPlvBhChiopciQ=; b=Nrxy1C22sOJL6oqA2MY0iXrtQDFyQxWJCUDL+KhtqJM2U/qCA7hHV5L+jZi3GUCB8M ByYc6bU4eI1FDvowOz1LgfYyxFuhEf7P4yyIj4S+yMIvE8kifJkZzCvS0nwVTEhJ7jwa 3WQVTJr8utnrVmwFhqQ02yldBsU3tdk9qF0GLplc5vnWE+zCXGhuwHnLJnBmICwe6+jw 0w/nXk3U5wNEeic35JxdnNFnaHg0mdQ8LxZ50aXaTvQ5gjuZLHqoXMASoaCJ8ylqj1yr rLOAblWsJ2sxuOQZhOuYgjhjjyaS2T9t+VsGRHS2UMsZ92zBY3s1jWStsQNI0Mpwg2Ec Ud5g==
X-Gm-Message-State: AC+VfDxTZMPDtVwtwANyENqDpLwbXmDIERnj2oetIYffOtqDniZyYFp3 nBWw7/01iWhUH4zwh26+ybhV1n7S473vrZwWun8GNIXh7ittYqTLOCg=
X-Google-Smtp-Source: ACHHUZ5FS9hR+9fu6j09rQA8blcQrFs9zoUpGKAXRODRajwqF2s+TJSSnDZlW/PREc7TJI81WmznDdEP+hM75Yf3Xvg=
X-Received: by 2002:a05:6a21:788f:b0:101:37b2:62f3 with SMTP id bf15-20020a056a21788f00b0010137b262f3mr39808109pzc.61.1684349825729; Wed, 17 May 2023 11:57:05 -0700 (PDT)
MIME-Version: 1.0
References: <11087a11-476c-5fb8-2ede-e1b3b6e95e48@si6networks.com>
In-Reply-To: <11087a11-476c-5fb8-2ede-e1b3b6e95e48@si6networks.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 17 May 2023 11:56:54 -0700
Message-ID: <CALx6S343f_FPXVxuZuXB4j=nY-SuTEYrnxb3O5OQ3fv5uPwT8g@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: 6man@ietf.org, V6 Ops List <v6ops@ietf.org>, opsec WG <opsec@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/deaV7mPFOu2Kb7FIaXjk3X9hSFY>
Subject: Re: [v6ops] [IPv6] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 May 2023 18:57:10 -0000

On Wed, May 17, 2023 at 6:00 AM Fernando Gont <fgont@si6networks.com> wrote:
>
> Hi,
>
> I believe we've already covered the topic quite thoroughly in RFC 9098.
>
> But if you want yet another data point, FYI this is instance N++ of a
> DoS based on IPv6 EHs implementation flaws:
> https://www.interruptlabs.co.uk/articles/linux-ipv6-route-of-death
>
> It should be no surprise what security-minded folks tend to do with IPv6
> EHs, particularly when there's currently no much reliance on them these
> days.

Fernando,

There's an old saying phrased in the form of a question: "What is the
most secure network in the world?". The answer is "One that's turned
off". The analogy to this for a network is that if we want maximum
security, but still connect to the Internet, then only allow the
absolute bare minimum set of protocols to be used in the network and
always drive to maintain the status quo before any other
considerations.

So, if you want to build a network with maximum security then by all
means drop packets with extension headers; but, also be sure to drop
packets containing other protocols that are potentially susceptible to
implementation which includes any other transport protocol other than
TCP, IP fragmentation, and you probably should consider IPv6 as well
since we certainly haven't seen the last of the implementation bugs
for that. UDP as a secure protocol is right out! For the remaining
"authorized" protocols, which is just TCP over IPv4, immediately drop
all TCP packets that are not to or from port 443 because anything else
is insecure. Also a TCP implementation could have bugs, so require
that users only use a network provider approved TCP stack
implementation verified to be bug free and frozen in time that only
allows bug fixes (we need to avoid regressions!).

Do all this, and I think you might be able to claim to have a secure
network connected to the Internet :-)

Tom


Tom

>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------