Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32

Tom Herbert <tom@herbertland.com> Tue, 09 April 2024 15:17 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 DA01EC14F6BF for <tsvwg@ietfa.amsl.com>; Tue, 9 Apr 2024 08:17:17 -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_DNSWL_NONE=-0.0001, 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=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 d3_5jLkAaTpn for <tsvwg@ietfa.amsl.com>; Tue, 9 Apr 2024 08:17:13 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 99CDBC14F6E9 for <tsvwg@ietf.org>; Tue, 9 Apr 2024 08:17:13 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-516f2e0edb7so3116835e87.1 for <tsvwg@ietf.org>; Tue, 09 Apr 2024 08:17:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1712675831; x=1713280631; 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=1EHoNxlGHrO/AQfP7fAO09udtsu/LPZejtOu7AbUGvk=; b=Mjlo0NoytsP87YHdmr+ofQPOId0FfxiVKGMPAq1QKWfGl5T3xAxWP6vPFHnaETlJ3/ V4xeDayGd9rtp+ynGTNyh3m2ZV8+tnnZzP0ox70gumIjy6dausAD5V6UIqKYC1DVgUvt HfgIYVJSCYFPRsgIba3NW4bDnFALICAAhwtlydBaXNfhFxnaB6AslchcUKdnZzJ7IEdd yuoq/nIfSTT0zbBbqo4ZqPCw0rkaRnaT7qdt2ueDzF4Ab/gcDlUvUVk2oIzbdwJwr/xP DGPVb/fAc+f6WuvO1OeL7iQ0z4aeGt2Rt/Fquj7j7GQhjRlEq7DjObQ9IRjyl25OL0kY FeoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712675832; x=1713280632; 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=1EHoNxlGHrO/AQfP7fAO09udtsu/LPZejtOu7AbUGvk=; b=Yebpcszs+gJroITUPppshloQMZ8mJ1XZJxpNqmqDSNII0h01Il5Ifi14E9S1UhyWIt w9X1v+JxMDbxb9xQvy0OfqTjDYIlZt1orqVXIv0xbb5K3aUHki8vkFjCfwxyjZqfcrru j2WaCt/bWWbHLf7RrUuom7YRw7c+iSF6kHEN15EXtegXNgox34nPt14JP7fd3c8MzKdQ Jc5IGZ8otNMUkAiJxzZnw+uqiEjx0cMuzU4zcEJUNdhFafctHOWaQ+GVhGnneQMJvMR0 ZaBf67m7L6tkrC1ly3dlcxvXOToA9Lqd/5ZZuPZAjTjvCCdgk8Qf28IiZpoW1q9UZ4vn 5Ocw==
X-Forwarded-Encrypted: i=1; AJvYcCUJhWvObFPMIIgvcdra3hjclSSqT6KeA2CR70TksPLBCPxOznwao6prKGkTsNdqBfRW62CQPu5Jho3ROFcPtA==
X-Gm-Message-State: AOJu0YyVhy43bV1NcyyGf7P0iLWZF2FDoRjEZKCgWgKoJxAPsHT8bfc/ CAJDtKjjCY+U1S4MGari6kkr5JLlR7LB9PiKkGKgXzbSjOynVsjD21eGS2lqC9hUaEiGKhSQNLT 0XKikWYVaxx5zyp1eEtY5+OfFHbw+oID75+jT
X-Google-Smtp-Source: AGHT+IFVXzwhlZ/1hgsiUqUF20sRrJ0BNoT3+9RaJdWupilRIjeEZK3gyGubbaFuG7wCjCGl6mUtkmmmbkRZK7Tw5sM=
X-Received: by 2002:ac2:42c9:0:b0:516:d538:35a4 with SMTP id n9-20020ac242c9000000b00516d53835a4mr8236720lfl.7.1712675831421; Tue, 09 Apr 2024 08:17:11 -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>
In-Reply-To: <b7f7b836-c625-445d-bd38-f5ed8f4ba757@huitema.net>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 09 Apr 2024 08:17:00 -0700
Message-ID: <CALx6S34=5CCDY_Wj1+9Moj0NMnZr=gBjpT3NBfom6r6oouGJEw@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>, "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/H1h5swgC-mwYoDDTG9Gowl94cC4>
Subject: Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32
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: Tue, 09 Apr 2024 15:17:18 -0000

On Tue, Apr 9, 2024 at 7:29 AM Christian Huitema <huitema@huitema.net> wrote:
>
>
>
> On 4/9/2024 6:09 AM, Zaheduzzaman Sarker wrote:
> >
> >
> > On Tue, Apr 9, 2024 at 12:48 PM Gorry (erg) <gorry@erg.abdn.ac.uk
> > <mailto:gorry@erg.abdn.ac.uk>> wrote:
> >
> >     See below for my 2c.
> >
> >      > On 9 Apr 2024, at 11:31, Zaheduzzaman Sarker
> >     <zahed.sarker.ietf@gmail.com <mailto:zahed.sarker.ietf@gmail.com>>
> >     wrote:
> >      >
> >      > Hi all,
> >      >
> >      > Putting my AD hat on, if we specify protocol features only for
> >     endpoints to
> >      > consume and not for endpoints to network, then we should make
> >     sure that is
> >      > case when we design and describe it. We cannot expect all the
> >      > intermediaries are well behaved or features are used as intended when
> >      > designed. From that point of view it is not good enough to send
> >     information
> >      > in clear and just say "UDP Options are for Transport, Not
> >     Transit". With
> >      > the current, well placed, scrutiny of privacy and security on all the
> >      > protocols that IETF is producing- It would require a huge
> >     exception to get
> >      > it published.
> >      >
> >      > The questions I would like to get answer is  -
> >      >
> >      >      Is it OK for the endpoints to send information in UDP
> >     options which
> >      > can be read (only) by the transit nodes and react to it? if NO,
> >     then how
> >      > to prevent that to happen?
> >      >
> >      > //Zahed
> >
> >     this is a transport/encapsulation that can be used without the
> >     benefits of encryption.To me, this was already clear when the
> >     working group asked to start this work (it certainly was made clear
> >     after the work was adopted), and this spec developed over many years.
> >
> >
> > Right, many years have past and we should then recheck the consensus on
> > this. From the mentioned email discussions and views expressed here I am
> > not sure it is clear to me what consensus we have now. Could you also
> > please provide me any reference to the consensus?
> >
> >
> >
> >     So.   I think given this, it is OK for the endpoints to send
> >     information in UDP options which can be read (only) by the transit
> >     nodes and they can indeed react to this. That has always been
> >     possible with tunnels, extension headers, and transports - at least
> >     those not using transport encryption. This comes with positive and
> >     negative impacts.
> >
> >     In today’s world, a designer can choose to protect all of the
> >     transport eg using QUIC - and many designs will follow that path.
> >     Although, there is a large body of work in the IETF that still
> >     directly uses UDP. That to me is OK if that best fits the use.
> >
> >
> > Yes, UDP should be considered as transport protocol. It would be good to
> > have a view on how many of those large body of work uses or envision to
> > use UDP options in clear. This would boost the motivation for this work
> > and back up the need of UDP options.
>
> Depending on the application stack, UDP is either a transport protocol
> or a transparent pass-through. Indeed, this is pretty much the intended
> design of UDP, as stated in RFC 768: "This protocol provides a procedure
> for application programs to send messages to other programs with a
> minimum of protocol mechanism."
>
> If the application stack is including its own transport protocol, then
> we are in the "pass-through" case. This is absolutely the case if the
> application stack includes QUIC, SCTP or DTLS, but there are other examples.
>
> In the pass-through examples, and especially when the application
> transport uses encryption, adding clear-text options does not add value.
> It destroys it, re-enabling surveillance despite encryption of the
> application.
>
> I think there should be a very clear mechanism for application to
> "opt-in" the usage of clear-text application, and that for applications
> that did not opt in the reception of clear-text options should be
> treated as a protocol error.
>

Christian,

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.

Tom

> -- Christian Huitema
>
> >
> >
> >     The backwards compatibility with UDP was considered important in the
> >     development of this Spec.
> >
> >
> > This point is absent, AFAIK in Section 16 of the draft now.
> >
> > //Zahed
> >
> >
> >     Gorry
> >
> >      >
> >      >> On Fri, Apr 5, 2024 at 2:29 AM Christian Huitema
> >     <huitema@huitema.net <mailto:huitema@huitema.net>>
> >      >> wrote:
> >      >>
> >      >>
> >      >>
> >      >>> On 4/4/2024 2:22 PM, C. M. Heard wrote:
> >      >>>> On Tue, Apr 2, 2024 at 2:23 PM Martin Duke wrote:
> >      >>>
> >      >>>    ...
> >      >>>
> >      >>>    - I appreciate the work to make this an end-to-end signal,
> >     and that
> >      >>>    UDP has pre-existing limitations in this regard. I also
> >     think the
> >      >>>    use cases are probably valuable.
> >      >>>
> >      >>>    But in 2024, if we want to make rules about what the network
> >     can and
> >      >>>    can't do, we enforce it with encryption and authentication. I
> >      >>>    recognize that these were originally in the draft, and were
> >     removed
> >      >>>    for very good reasons. But I'm also worried that, if successful:
> >      >>>    - This will attract "helpful" middlebox functions like MSS
> >     clamping
> >
>