Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-21.txt
Tom Herbert <tom@herbertland.com> Sat, 10 June 2023 01:23 UTC
Return-Path: <tom@herbertland.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879B7C15155A for <tsvwg@ietfa.amsl.com>; Fri, 9 Jun 2023 18:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.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_NONE=-0.0001, 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=ham 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 5HZflG3BVMeP for <tsvwg@ietfa.amsl.com>; Fri, 9 Jun 2023 18:23:49 -0700 (PDT)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 A8C9BC151557 for <tsvwg@ietf.org>; Fri, 9 Jun 2023 18:23:49 -0700 (PDT)
Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-25673e8c464so932208a91.3 for <tsvwg@ietf.org>; Fri, 09 Jun 2023 18:23:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1686360229; x=1688952229; 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=XClMqkd6zTceL7fXBgIAm4vj9XjBnhBXFVW5PG9/8XM=; b=ewg9gN6mEuffEBCJNvY5+A5eUzjydO84Y2/qYLzR4PgOQHIrQ8RGNBV+F8MCKVG0Iy kFP7/EDbiAtLZV5EUZLdA36z+eNBjBIng97bO4lJADg5uERQAuby7KtQKtjXQAmg/ir9 Zsu76gPA0JkK5lGII+xyKMmfPRG81cV9U4J9oKPcF3csc9dX1KcbL2tHSd3u+z3BYuOY 5SErmOAcocoqD+ip1PtMKc2C88iMShh5pgxtiNSzriVx3A0AXAeP5y1mz57ZhAHCAzXL SdWcG1m/Wd0KDYu8cJGJlzKB1Gs6BKOyOFqIrKHprAzB7tkM8BAFmpahdE0CFoMCrByn 1qQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686360229; x=1688952229; 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=XClMqkd6zTceL7fXBgIAm4vj9XjBnhBXFVW5PG9/8XM=; b=Nv/bV1fffpozmL4k27CEo+IXbxpC9j3OwFfK3mqJoOmXPJm+uDAMNRhnsVAVbxsFFj h8tzMHIQhAFdZp3NHupsg0EYngrT5Uy3+7kxkNBdvhLyumDpHgTN7JfxuLL4rPKqltzl nWWseVUxlYJ2iVdG/Znta6ulIHZUDfVas/8MMDWZRR/f9ifCgQM+Z+YmL6WpcoBzp8Y8 gWns6BvkBeCyQWbM4qxAaeSZ+V7uw5DrHaw2hInyXfdWajrDSt16zTBaE0mnhFf0ouqo dElTG0U6R6ezY/PjSeUcU85tHiWHJ6rRq1rqf0TC6B5hzbZKIio9n/3yL5cGsiq0yRMQ KUEg==
X-Gm-Message-State: AC+VfDxKCZlTucMeGCcdGhKLpVMRbUU7lfgEeF0zjWFpwL2Kt/sN32BJ 8bQ1zWnTDEyGdJfBRwEabdp0Qk5eMgNYJhFcPbnkviCh8oebeNQB8v4=
X-Google-Smtp-Source: ACHHUZ5pY4P9dqoKeB/YnJI7yTuXZW7WIUX1M+amMo6S2I7a4ZKEmqel40F/hCNQ3D2YB/Uc//XFqOE+rxrWZG8qltE=
X-Received: by 2002:a17:90a:1b2d:b0:25b:b1d0:6d6c with SMTP id q42-20020a17090a1b2d00b0025bb1d06d6cmr52459pjq.35.1686360228887; Fri, 09 Jun 2023 18:23:48 -0700 (PDT)
MIME-Version: 1.0
References: <168628341428.60924.1127559055874638238@ietfa.amsl.com> <CALx6S34DGvkdvbmNqD2-1YK=5mXDxvy8NROCUZZgSWxiFLurfQ@mail.gmail.com> <B64DA8BB-F2BE-4847-BE19-1182172F27F6@strayalpha.com> <CALx6S35AkGmRo1u4oxn55w-7dv==AUXT3EKsbMB6a2Zxerps6g@mail.gmail.com> <2D59EEAE-E56A-4C8C-A2D5-4EDF7C534A59@strayalpha.com> <CALx6S37Cyk_SwOHm6dT_jxbtqxuA-1Kk9aN6Fs=rR5SEJMhXYg@mail.gmail.com> <A5427E6C-C773-4B67-9F57-56BF8CC2AE0D@strayalpha.com> <CALx6S356FvPAav4AAkbpNafD=+hJDCfj0LBXDwD45Vk4VYioeQ@mail.gmail.com> <527D7B09-3011-4CBB-8DEB-D4621E59A397@strayalpha.com>
In-Reply-To: <527D7B09-3011-4CBB-8DEB-D4621E59A397@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 09 Jun 2023 18:23:37 -0700
Message-ID: <CALx6S35-iF7OH8tJnJG+=GwQYPciXXx=-Dff=N0PZoVp2upYug@mail.gmail.com>
To: "touch@strayalpha.com" <touch@strayalpha.com>
Cc: tsvwg@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/DhvWj0OUZJ6acgIi6dmFhO5WIpI>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-21.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Jun 2023 01:23:53 -0000
On Fri, Jun 9, 2023 at 5:28 PM touch@strayalpha.com <touch@strayalpha.com> wrote: > > ... > > On Jun 9, 2023, at 4:33 PM, Tom Herbert <tom@herbertland.com> wrote: > > On Fri, Jun 9, 2023 at 3:58 PM touch@strayalpha.com > <touch@strayalpha.com> wrote: > > > Cutting to the chase… > > On Jun 9, 2023, at 3:24 PM, Tom Herbert <tom@herbertland.com> wrote: > > ... > > > * > > There ARE good reasons a source might send more than N (for any N) SAFE options that a receiver might not support - and to do so repeatedly. > > > Really? From the draft: > > Each option SHOULD NOT occur more than once in a single UDP > > datagram, the only exceptions being NOP, EXP, and UEXP. If an option > other than these occurs more than once, a receiver MUST interpret > only the first instance of that option and MUST ignore all others. > > > The same option multiple times is NOT the same thing as many different options (the latter is what I refer to at the “*”) > > So if an option is received more than once is ignored, how is that > possibly useful? > > > It isn’t, but it isn’t necessarily an attack either. > > > Then what is it? An implementation bug on the sender? Either way, > these cause the receiver to consume power and burn resources without > beneficial effect. Receive one of these in a packet then it's in the > noise, receive a bunch of packets with 300 of these in each packet > then by any logic that's a Denial of Service Attack. > > > 300 in each packet, maybe. 10? 20? What’s the threshold? There isn’t one - nor should there be. > > And same for “a bunch of packets”. > > So yes, like any protocol, there are ways to abuse it. We can mention that in the security section, but should NOT proscribe specific ways or thresholds that aren’t inherently part of the protocol (e.g., 40 bytes for TCP options - which even that is being extended). > > ... > Every standard track protocol requires security considerations, and > DDOS is a security issue. > > > Yes, it can and should be discussed. > > Also note, that the protocol is CREATING the > DOS vector, > > > The default is already that UDP options are off unless a user turns them on. > > so it's incumbent on the creators to provide solutions for > mitigating that. > > > There are known solutions - but we should NOT be indicating specific thresholds because they WILL become baked into implementations. > > ... > This is a USER protocol. Let the USER decide. > > > Let the USER decide WHAT? > > > How many unknown options inside a single packet or how many such packets are an attack. > > Yes, we can talk about that, but NO, we should not say 22 is bad but 21 is OK unless we have a specific reason to pick those numbers. > > This is why RFC8504 style limits are useful; > > > They’ve basically killed IPv6 options - without actually having the hurdle of being an actual update to the standard. > That is simply not true. IPv6 options were dead long before RFC8504. The reason is that IETF failed to recognize the danger of unlimited options and failed to reasonably limit the protocol when it was created. When issues with the protocol were perceived, network providers were more than happy to fill the void and set a limit for the protocol. Unfortunately, the network providers chose the threshold to be zero because that was the easiest and cheapest limit. Because of this, IPv6 options are now considered non deployable on the Internet and we are trying to fix this mess by allowing both hosts and network nodes to limit what they process. And the default limits aren't being pulled out of a hat either, we have forty years of experience with network options and data that shows how often new ones are introduced. If you ignore the lessons to be learned from other protocols, it is very likely that UDP Options will have the same predicament. > It’s not OK to tell everyone they “MAY ignore a single header option: > > A host MAY disallow unknown options in destination options or hop-by-hop options. > > > Doing that gives permission for everyone to stop supporting it: > > It’s not OK to say: > > A host MAY impose a limit on the maximum number of non-padding > options allowed in the destination options and hop-by-hop extension > headers. If this feature is supported, the maximum number SHOULD be > configurable, and the default value SHOULD be set to 8. > > > The problem with that statement is it ought to have updated RFC8200 to say “IPv6 packets MUST NOT use more than 8 options”, because that’s the net effect. > > > In our case, we can add: > > - A host MAY impose a limit on the max number of options in a UDP packet. > > > - A host MAY also impose a separate limit on the max number of unknown options in a UDP packet > > BUT: > - A host MUST NOT impose these limits by default. Any such limits MUST be activated only after a threshold that combines the number of offending options AND significant repeated attempts to use those options in multiple packets. This document does not indicate a specific such limit. > > Joe
- [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-… internet-drafts
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… touch@strayalpha.com
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… touch@strayalpha.com
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… touch@strayalpha.com
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… touch@strayalpha.com
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-opti… touch@strayalpha.com