Re: [tsvwg] UDP options and header-data split (zero copy)

Tom Herbert <tom@herbertland.com> Sun, 01 August 2021 21:20 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 7FC3E3A1188 for <tsvwg@ietfa.amsl.com>; Sun, 1 Aug 2021 14:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 X7P2x09GS8XJ for <tsvwg@ietfa.amsl.com>; Sun, 1 Aug 2021 14:20:02 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1D83A1187 for <tsvwg@ietf.org>; Sun, 1 Aug 2021 14:20:02 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id o13so14874035qkk.9 for <tsvwg@ietf.org>; Sun, 01 Aug 2021 14:20:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y5q7m6K0n6pmeL7YQkpNHOQxKDVeZVO4RJDFKpNvzNo=; b=2GdZ1q4ub94xB7AisZ37UM9epE5z76Gq9X2jCNEvY1K1aW1yn5ZqCoF1Ys+UoDrRYL hgSnoblp6odsJtwGIeS/OYSBPFScQFDPBvuS6wKjmEcx4WpEiR8WLa774d5WnynTmw9s HTrRmP7LqNCNz9rWzoJBrG4dsYLBm5prUyZ5fxp7zgzRUNVMUJQpkhhceU64VFvbBoMv fi9dU9u5AyZHRHCndnlHu0T+llNkR5oPmsVCD2czLrExa7f7lU1IxzXTt7B+0uGgqLQ+ MMCYnZ8SJ71oJV2wxwO/JY9sQniYMpTuOcrjQR54ktNkL2OIgSH+S5xnoebVKKwc84C2 /0Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y5q7m6K0n6pmeL7YQkpNHOQxKDVeZVO4RJDFKpNvzNo=; b=l3CEle5NLdPDMnTvNWiG/iYW9AuZ+1Oqad3MRCmCdrdGaI/uiNIjRSd1xAUOM0jQvP H79vIshp5accCdpqpWTfpll2RZ1EbI+Mi64VAr4N2u8Mdaoo24z8IzbU1z8E9ex7bjaA 93l1OShtR5vJhtXAWTJ+mRHAGmwgXNBtxwFMEM7N65+VaPKiNQp6fDSxG/mThQNj/Jvd X0hwbPfYDvANYzZW36cwnwlzTUb6YEHuZ7OoR9cRUc0XmjqRk4Blu+SHmmuKMZ993aB5 xicLkhHXOLTlMX1ZM+6Uj9ziS0FeRblN89rfbYD5S74zJEjl+GYymnH4uE+TKx+7nkvX 67Dg==
X-Gm-Message-State: AOAM5313RKgrTcf3RM3dngv0h/setJ/L2/7Wtp1syWQimUB78I1eTCTV slWlT7TgteMU8nM/mg/wHd1kAszb5e+Gs6D3a2JFUQ==
X-Google-Smtp-Source: ABdhPJxnN37zndcaBJvOPnTp38y3Z5JINy0bDFzwVT8dY/GekWQVHHeInz9tlwEkIiSm2f52X9cYwpb+2OAkPprF9tU=
X-Received: by 2002:a05:620a:2a14:: with SMTP id o20mr11693663qkp.298.1627852800732; Sun, 01 Aug 2021 14:20:00 -0700 (PDT)
MIME-Version: 1.0
References: <CALx6S37zVVXnCH+Dv7_QXgwOoqcL4h0SThh+LnmAWn-5enprZQ@mail.gmail.com> <FA155FD9-2319-405C-B082-C023DEC2BF28@strayalpha.com> <CALx6S3435ZjAz8ECgbFbH=Hxm-cXAGRQjTbxgtGb9U-CTXMw=A@mail.gmail.com> <C8CE3912-55B2-4DC0-AB39-2D6EA6953500@strayalpha.com> <1178DE92-175A-4293-8A97-9B6FEBAF7B02@strayalpha.com> <CALx6S35tB=j5y3-xr5S22y0p+WJxKX_hqk8rm30oCruFxZp5Dw@mail.gmail.com> <87662B22-F63B-4EA4-94B3-DF4B2439A4E1@strayalpha.com> <CALx6S35h3H-mvkHKFcpp3-k-Sq48NAMVRe-LEhfHxEA=hP49qQ@mail.gmail.com> <72098C16-868E-4A9A-80E7-5FFEE1382337@strayalpha.com>
In-Reply-To: <72098C16-868E-4A9A-80E7-5FFEE1382337@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 01 Aug 2021 14:19:48 -0700
Message-ID: <CALx6S364PPh8SKxZjC2D--EaxtUqwgV3QecdUujL+gjBt0bCcQ@mail.gmail.com>
To: Joseph Touch <touch@strayalpha.com>
Cc: tsvwg <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ef428605c886032d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/F5kZHVB8sFaQEs8j2hlMVpLD-RU>
Subject: Re: [tsvwg] UDP options and header-data split (zero copy)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 01 Aug 2021 21:20:08 -0000

On Sun, Aug 1, 2021, 12:42 PM Joseph Touch <touch@strayalpha.com> wrote:

>
>
> On Aug 1, 2021, at 12:03 PM, Tom Herbert <tom@herbertland.com> wrote:
>
> ...
> Again, that means that the FRAG option itself would float far inside the
> TLV list, which complicates DMA.
>
> I don't understand your concerns. The method I am describing is
> functionally equivalent to how fragmentation is done in IPv6. There is
> a fragment extension header that "floats" inside the IPv6 header
> chain, options that are before the fragment extension header are
> applied per packet and those after the extension header are applied to
> the reassembled packet. This is no issue with DMA since there are no
> trailers and we can use header-data split with fragments.
>
>
> We moved the FRAG header to the front due to previously expressed concerns
> - notably long TLV processing prior to DMA.
>
> Also, the trailing variant allows per-reassembled options to be
> arbitrarily long (limited by the reassembled length), rather than requiring
> them to fit inside a single fragment.
>
> That’s a key reason for using trailing options - no limit on length, even
> with fragmentation. That’s why we need a version that allows that,
> otherwise the options would be limited to what will fit in exactly one
> option.
>
> Deployment experience has shown arbitrarily long lists of TLVs in a
> datapath protocol is more a problem than a benefit. Implementations
> have a lot of trouble with these and to date the only use case for
> this is DoS attack.
>
>
> The issue isn’t just whether it’s arbitrarily long; it’s also that it’s
> restricted to a single fragment, which could be quite small.
>
> ...
> We need to keep a way to allow arbitrary option lengths;
>
>
> Why? Can you provide a *specific* example of an option or set of
> options that needs hundreds of bytes of options?
>
>
> Had we limited the option length as a few suggested when this work
> started, we would not have FRAG.
>
> We don’t know what others are, but we also don’t know that the first frag
> will have hundreds of bytes of available space either.
>

Actually, we do know that. The minimum MTU in IPv6 is 1280 and the minimum
MTU for IPv4 is 576. If someone we're so inclined they could fill up the
first fragment packet with nothing but options and start the payload in the
second. That means you'll have at least 520 bytes for options. But all this
is academic since there's no use case other than DoS attack that would need
anything close to that much space.



> ...
>
> We’ve been down the path of fixed headers before.
>
>
> And we've been down the path of protocols that allow arbitrarily long
> lists of TLVs. See IPv6 Hop-by-Hop options and Destination options.
> There is about no deployment of these and a major reason is that
> implementations efficiently implement necessary support.
>
>
> RFC8504 discusses these; they are all MAY limits via receiver
> configuration, notably that the default is that it accepts both sets of
> options of any length.
>
> Your suggestion would limit options by design, not receiver configuration.
>
> It wastes space for some uses to conserve it for others. E.g., in tunnel
> cases where UDP CS==0, it would waste space for OCS when not needed.
>
>
> Somehow the whole purpose of having a checksum in protocol is lost in
> this draft. The point of a checksum is that it's an integrity check of
> the protocol. Frankly, the requirements described in the draft seem
> more concerned with making sure the checksum is set properly to
> packets to get through some misbehaving routers on the Internet. The
> argument that UDP Options doesn't need a checksum is disingenuous
> given that UDP doesn't have options in the first place so making the
> checksum required in UDP to cover options; however the other major
> transport protocol of IETF, namely TCP, has a checksum that always
> covers TCP options. Similarly, the argument that the IPV6 UDP tunnels
> can have a zero checksum is disingenuous. If you read RFC6935 and
> RFC6936 you'll find that the conditions for which a zero checksum can
> be safely set are quite narrow. One of those conditions is if the
> encapsulated protocol has an integrity check of its own.
>
>
> Yes, but that’s actually the dominant case where Mike’s optimization
> fails, i.e., where UDP CS==0 but OCS is optional. In that case, if OCS
> fails, the TLV chain still needs to be checked to decide whether to drop
> the packet. It’s only when it succeeds that it need not be checked.
>
> IMO, a checksum should always be required over the surplus area.
>
>
> This, like the proposal for fixed headers, has already been discussed.
>
> New discussions would be useful; rehashing previous ones can probably be
> left to the interim.
>
> Joe
>
>
>