Re: [tsvwg] Discarding the UDP surplus area when protocol-agnostic checksum offload is used

Tom Herbert <tom@herbertland.com> Mon, 29 April 2024 21:43 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 BF171C1522B9 for <tsvwg@ietfa.amsl.com>; Mon, 29 Apr 2024 14:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MH52R5-7eWmK for <tsvwg@ietfa.amsl.com>; Mon, 29 Apr 2024 14:43:20 -0700 (PDT)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 42015C169409 for <tsvwg@ietf.org>; Mon, 29 Apr 2024 14:43:20 -0700 (PDT)
Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5727dc6d3edso2003188a12.0 for <tsvwg@ietf.org>; Mon, 29 Apr 2024 14:43:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1714426998; x=1715031798; darn=ietf.org; 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=lKyq29PGviEFBU5MQS0kvbHg2CR4D6Kn1SZsreT3qfc=; b=b2V7twEwPq6XQB4h2MVSfG6/YrgW5XzoZxQhERRbuWw0aLpVZlANl1sbToGcikrNmM YLRgVVHM0yla7x0ngCCGIvPnJpJ1o6fQyxwvctxl+6fuk0Oc9A/xrJn8PN0ov6HCuLs6 NRd8hte/byX3YLIYPVWBTFB1JEoI3ybgL4MV15H1Ebg6uFc6zSOPWiHhmyLLdpXi7l1k 7wNpXLTpeJnz7bdizPdRhBDIP1fPFjz8zIGEjv+Rz12VUUafqnrYWdd4lT6H0WRU1bS/ 97ETQ6xw2OD1DeoMz3u9ZxyKkXuOcHKUzi2iIappqGoaLWb1ZkMtzutvMYF+EZyAEXss 1NfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714426998; x=1715031798; 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=lKyq29PGviEFBU5MQS0kvbHg2CR4D6Kn1SZsreT3qfc=; b=iyX2+ywZQo1kMlvBVYGVF3tO85j49rPfK4ZPz6tKJr5kjMrqHn/iH3wwimu5Ad327c fRD8ehEoUKYJRkZHLj0v+jV55hT0Xf0gklAqsFIaXtCWpXiMGQqY6W1odCm6Xucm/YJi 7L7GWU1hRrTXO1MUQrws+IB/J4kpL6+n+daVh/GinCQE8Ny32ysgOJHMrM/4cyamn8Il DIzcgx0rFP1pX6MbDiZ1zFhj9raU0lzW+YnoVSzrbqqtvkoaFyn9z1Eld/MRfo3hbwhb 8AEcfItvwXXdBhXDgCfzCQ9+Thqka5vb4CqM0O/GzAFg/ZlvEG8AFro6B4IKdnzTWPfH CEJQ==
X-Forwarded-Encrypted: i=1; AJvYcCXdoh2uBvjkmUo164UPTYfP3djQpAU/nc93xwvHXdTrYFrswxUeccBYTyYXopVcWK0cTVfmsAuNvKVp+zVFYw==
X-Gm-Message-State: AOJu0Yy2s3pszHpwJheRoyRTH/rm+QQP7+LG1Hf9SsmhL9sQDceIgOrv lvszpVD2qf0HGktv3XqTZGy3ZSN8y0lJJasWILiju2M5wGeLhEgAydabJI1gvrZToCtCtj+mhWq g4nEA73hQj08OXd+dhrRwBDuEyKD37U39e9sH
X-Google-Smtp-Source: AGHT+IHcJx5X8BZKqS7YkPQHj6VlvmNMHQbLO9btME+Zr8MUPyfRVMfbbRNUoW+O8bnyiggXfxUo2XFwpRWNYZFijw4=
X-Received: by 2002:a50:a41c:0:b0:56e:215b:75c2 with SMTP id u28-20020a50a41c000000b0056e215b75c2mr585963edb.17.1714426998061; Mon, 29 Apr 2024 14:43:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAEh=tcd2FzQxgbSivuX2cEg2FpsnkoqdFw5gMhrx3pkT_JV88Q@mail.gmail.com> <2BEB5CC3-BB54-4119-A20F-8497ED4B5AE2@erg.abdn.ac.uk> <CAEh=tccKg7YHYkwKZ978uaXmTkBu3zyA+WBAW=eBMKAh2PSVDw@mail.gmail.com> <b7f7b836-c625-445d-bd38-f5ed8f4ba757@huitema.net> <CALx6S34=5CCDY_Wj1+9Moj0NMnZr=gBjpT3NBfom6r6oouGJEw@mail.gmail.com> <CACL_3VG4i+BYZuyDs5pf-t-e8DicU2s=6v6JZCuVSrYFew+wQQ@mail.gmail.com>
In-Reply-To: <CACL_3VG4i+BYZuyDs5pf-t-e8DicU2s=6v6JZCuVSrYFew+wQQ@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 29 Apr 2024 14:43:06 -0700
Message-ID: <CALx6S35JM1TRxZYgev=--FABPr88pvhu=GP4hQTYLde70Nm-UA@mail.gmail.com>
To: "C. M. Heard" <heard@pobox.com>
Cc: "Gorry (erg)" <gorry@erg.abdn.ac.uk>, tsvwg <tsvwg@ietf.org>, draft-ietf-tsvwg-udp-options.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ABq7yWA7vDIpNM4OFMZj_sRIyqA>
Subject: Re: [tsvwg] Discarding the UDP surplus area when protocol-agnostic checksum offload is used
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: Mon, 29 Apr 2024 21:43:25 -0000

On Mon, Apr 29, 2024 at 2:12 PM C. M. Heard <heard@pobox.com> wrote:
>
> On Tue, Apr 9, 2024 at 8:17 AM Tom Herbert wrote:
> > In current host stack implementation, when a UDP packet is received
> > with surplus area we truncate the packet down to UDP Length and
> > otherwise ignore the surplus area bits. Are you suggesting that the
> > default behavior should be to drop packets with a UDP surplus area?
> >
> > IMO, this might be worth considering. I agree that this would tighten
> > security. Also, I would point out that even truncating the surplus
> > area like we do today is not without cost. If we are doing protocol
> > agnostic checksum offload, the preferred method, then we need to
> > compute the checksum over the surplus area when truncating and so we
> > do this in the CPU. For a large surplus area this can burn a lot of
> > cycles to process data that is useless to the receiver; conceivably,
> > this could be a basis for a DoS attack on CPU resources.
>
> Hi Tom,
>
> One question that I have is whether existing host stack implementations
> that use protocol-agnostic checksum offload typically do go to the
> trouble of computing the compensating checksum for the surplus area,
> which of course is identical to the OCS computation specified in the
> UDP Options spec. The main motivation for why OCS is specified in
> that way is because of the bugs found in middleboxes that erroneously
> use the IP Payload Length rather than the UDP Length to calculate the
> UDP checksum. The bug also seems to afflict some end systems. See:
>

Hi Mike,

Yes, a host that is using protocol agnostic checksum offload will
always perform a checksum over the surplus area in the CPU to "pullup"
the checksum when dropping the surplus area (the checksum value
received from the NIC is the ones' complement sum across all the bytes
in the packet).  This regardless of whether the OCS is present or not.
Of course, if OCS is present then we use the value of the computed
value and don't run the checksum computation twice over the surplus
area.

> https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones
>
> https://tma.ifip.org/2020/wp-content/uploads/sites/9/2020/06/tma2020-camera-paper70.pdf
>
> In end systems affected by this bug, one side effect would be that
> packets with a correct UDP checksum and UDP options with a properly
> calculated OCS would be accepted by tsuch systems, whereas arbitrary
> packets with a non-empty surplus area likely would not!

Well, even if it "works" these implementation bugs still need to be fixed ;-)

Tom

>
> Mike Heard