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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 22 May 2023 23:54 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92120C14CEFA; Mon, 22 May 2023 16:54:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 C6oXiyf1XzfR; Mon, 22 May 2023 16:54:56 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 59177C14F749; Mon, 22 May 2023 16:54:56 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-253570deb8dso4173331a91.1; Mon, 22 May 2023 16:54:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684799695; x=1687391695; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=GT70bKTbvYAfxai6J1HF7Vo1mbvTG0BZ5WednzveJPE=; b=rd8fpdUWKOZUxovvTDCWlFLYhMZO6cuokYGFYh6c/UTTUs6TB7MWYgezTZ2fMegaZ/ 0zlYxeN7dFFbSQDmf6p9Nz1/ZzaveqhUVH+eE614ZcEqcuCqo3xNkLmwX2dK79ePAp4N YsHe5sBtNfBRlAM/ZkLXoK9u5PmLSUQDwMnkO0S6RwO4GgZQ+BaS6N5aqyhE0ykyS6zK lGjGeDDCnOTug2zuu5N8cK+MKTAqbaqOjNfG5smS/eMAppCM4KB6fy9/WQKzaQSrjjwR /vo9itUmqMDE6mND74MOeI5PSiWt9M0sPPhR2+a3AHu+db35MI+Bl/vSDoztbpgt/M5G rvnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684799695; x=1687391695; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GT70bKTbvYAfxai6J1HF7Vo1mbvTG0BZ5WednzveJPE=; b=bfIVQ1K4MmIyUPs3nbOUBWPG/PtqQgPG94ifAy7wDC/UxgSK2zpOjYaqwt+5d0n8jr DblUOROBqomemxBZxUGUQ2Ho/2dtWq3n/AexgLo4Ks2sVYhve48OfV3qzhmXWzifSadQ HVN/XCWUe10E8JHO9a4HXhIudIunKIZlHncjTHbn/YmrD3iKT3es/IUgVqw/HWMzFtoJ V/8x0H/jP7qIRiQDmVuV4xhIc4VehOpSIaSrGYO08YgDfztxmAkhYU0q2eUP7fG07bWo yWVjpMYjGterrvPhlewHcevxT3RF/xdc/aETKSJ9/EGtJRGl3rrMfyhSyGe3hZNzdaHG Dqtg==
X-Gm-Message-State: AC+VfDyLHwuqjX19AG6XS40VlqDCW3i3U7Gm9r+GrHRN9QwG8h8NU8RV bbv3LWx0gU+rHuQOK/4w2SA=
X-Google-Smtp-Source: ACHHUZ7hvqqTPOZkO5g8tNj5Oa082miaoMXFV7hsMImExADBdGy3rNq6ESonL3W3Gp/NhdYLzRtP7g==
X-Received: by 2002:a17:90a:ba0a:b0:249:842d:312f with SMTP id s10-20020a17090aba0a00b00249842d312fmr11500879pjr.4.1684799695426; Mon, 22 May 2023 16:54:55 -0700 (PDT)
Received: from ?IPV6:2406:e003:1184:f001:abb6:ea4f:cf8e:1d0d? ([2406:e003:1184:f001:abb6:ea4f:cf8e:1d0d]) by smtp.gmail.com with ESMTPSA id gm1-20020a17090b100100b00250e48c27cdsm6352001pjb.45.2023.05.22.16.54.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 May 2023 16:54:55 -0700 (PDT)
Message-ID: <dcc0a6e3-9641-9d58-697b-a7c7e09e84e2@gmail.com>
Date: Tue, 23 May 2023 11:54:48 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>, Ole Troan <otroan=40employees.org@dmarc.ietf.org>
Cc: IPv6 Operations <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, Fernando Gont <fernando@gont.com.ar>
References: <338409937.875780.1684768913874@mail.yahoo.com> <C90EF571-2754-4C12-B7D6-FEDD1D17CA19@employees.org> <193402587.928006.1684773327427@mail.yahoo.com> <9078375A-F5F7-4D44-AAB8-03CED422B6F7@employees.org> <CALx6S35g39O6sc+ECwXFb9Zm6c2fNWvJRVY2TMw-ewznT4ZGQQ@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <CALx6S35g39O6sc+ECwXFb9Zm6c2fNWvJRVY2TMw-ewznT4ZGQQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/kN_QQlSFACbf9Cd71zK4j6oMR_I>
Subject: Re: [IPv6] [v6ops] [OPSEC] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 May 2023 23:54:58 -0000

On 23-May-23 05:24, Tom Herbert wrote:
> On Mon, May 22, 2023 at 10:09 AM Ole Troan
> <otroan=40employees.org@dmarc.ietf.org> wrote:
>>
>> Nalini,
>>
>>>
>>> Once bugs are fixed, then we need to consider carefully what BCP around EHs should be done, taking into account various common topologies as well as devices such as proxies and load balancers.  I mention those in particular as what we have found points to those devices in particular as posing problems rather than transit networks.
>>
>> I look at load balancers as an extension of the application (or network function).
> 
> Ole,
> 
> If you're talking about a transparent proxy or a transparent stateful
> device in the network, I  tend to view those devices as potentially
> invasive and harmful to an application as opposed to an extension of
> the application. Think of all the problems we've had with stateful
> middleboxes and all the hacks we need in networking stacks to work
> around them...
> 
>> Unless the application had a particular use for a extension header I would not implement it.
> 
> So you only run one application in your network? :-) Even if you
> polled every user in the network about every application they're
> running and found they don't currently use a certain protocol, what
> happens the next day when one of your customers wants to use the
> banned protocol?
> 
>> And that’s with an implementors hat on. Writing custom load-balancers for network services.
>> What would you even do with EHs through a load balancer? Provide ALGs for EHs containing addresses inside of them? It would have to be on a case by case basis.
> 
> Why would a load balancer care about EH? In the worst case, don't you
> just need to parse over the extension headers to find the transport
> layer headers for load balancing (note RFC8200 allow intermediate
> nodes to not process HBH options).

This was actually one of the main motivations for RFC7098, which discusses
this point in several places.

    Brian