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

Christian Huitema <huitema@huitema.net> Tue, 09 April 2024 14:29 UTC

Return-Path: <huitema@huitema.net>
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 BC917C14F605; Tue, 9 Apr 2024 07:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 R5WW8BOMtbly; Tue, 9 Apr 2024 07:28:58 -0700 (PDT)
Received: from se04.mfg.siteprotect.com (se04.mfg.siteprotect.com [64.26.60.167]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 9942CC14F619; Tue, 9 Apr 2024 07:28:58 -0700 (PDT)
Received: from smtpauth02.mfg.siteprotect.com ([64.26.60.151]) by se04.mfg.siteprotect.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1ruCSz-00A49z-QZ; Tue, 09 Apr 2024 10:28:55 -0400
Received: from [192.168.1.102] (unknown [172.56.169.185]) (Authenticated sender: huitema@huitema.net) by smtpauth02.mfg.siteprotect.com (Postfix) with ESMTPSA id 4VDSxp3DPFz2YRNHP; Tue, 9 Apr 2024 10:28:46 -0400 (EDT)
Message-ID: <b7f7b836-c625-445d-bd38-f5ed8f4ba757@huitema.net>
Date: Tue, 09 Apr 2024 07:28:45 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>, "Gorry (erg)" <gorry@erg.abdn.ac.uk>
Cc: "C. M. Heard" <heard@pobox.com>, Martin Duke <martin.h.duke@gmail.com>, tsvwg <tsvwg@ietf.org>, draft-ietf-tsvwg-udp-options.all@ietf.org
References: <CAEh=tcd2FzQxgbSivuX2cEg2FpsnkoqdFw5gMhrx3pkT_JV88Q@mail.gmail.com> <2BEB5CC3-BB54-4119-A20F-8497ED4B5AE2@erg.abdn.ac.uk> <CAEh=tccKg7YHYkwKZ978uaXmTkBu3zyA+WBAW=eBMKAh2PSVDw@mail.gmail.com>
Content-Language: en-US
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; keydata= xjMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1RmvN J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsKWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAzjgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB8J+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
In-Reply-To: <CAEh=tccKg7YHYkwKZ978uaXmTkBu3zyA+WBAW=eBMKAh2PSVDw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=huitema@huitema.net
X-Originating-IP: 64.26.60.151
X-SpamExperts-Domain: mfg.outbound
X-SpamExperts-Username: 64.26.60.150/31
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=64.26.60.150/31@mfg.outbound
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.06)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9lTHS2jGyundoMqJZJm7JRPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5z5W83tr/6vNQtj+4/xevXo2Zybh0C7q2u3ACfXjTyoXiyb 5GIeP46iSHCD/hbqgmu1tKRQLPmP9InHnx1Brj2eX/LhG7FXTm6Tybw4nzs9RzpvjJMlRqtLYdVR m5o1UatFouhV/hTlnP3gizNJ4cCTbODl0npQ7QiJwO4ZFU5qPmw3eNeOhkLncll6ybXS3v37YzVM +DNLaG9EqC8HPWpqIecagTeih6ZIlZsKCgIlyj9V70oPWOV5e2jS1ELFlksEybI1sOftHmSKUCHC vcq0YTPNT555B5Mf73FCdrCIg3BXvrLBlKCVRjjdPbjQ4HnU/Pi2QiSAHmtoEaz2bwGM/SySBKPE LGmZ8koc19ew0uGF6ePhLVNfQ99xpFdqMeOtUvCxPaIM4Ou74wbpe1B+tPQt8ktwubmkyIGt5wqx bNYmyTxrQyWytnV+j2TEcDbyPOsQNm1yLTjGbseEpgCNV4nXdhmqZFgXvtwoyf4nBPqexC/FKmrB VQq3b2CTOB3jT+mbShou6hktCloTvTOZCr3KS+nSmfB/Le8WyggcZGNMyMGzGQ/sIq/J9wLEXmWK 2sg7fhU6xWMp7cHXwP7QnNBzJuL8Gr1cSOdPD+8kUhsGUBCdud6r3d8EwqZuwQA8bzhbGbYrpodL rvAd0KCRSdsy/sW8HAfzzH+4WszBuBOaHC5n55mAcO/V9SpUSv/jlorFXW3bhC79ikuI4jpG++Du IQUs/5JJj4C/n4CILpQjvpxZ7UPYmlSOVPdsu4mPA8mbzdTvSqWoD0J+HqTLBg2q5JoNYB0RxfVT 8C7NdH7HgAd3NkOV15aRTCT2yxkQ4sKVqNBqZI8EvH6iEaQNA0ktIwG6OzbKAMPdy8PF1PdjzQ6Y C7Heg3Xf7O1TOd5MkcPNRcApvSCyyqhSIIwVGOC+7ukCf411wDyLaL5NOLyFj7ORksGGTcv5Mk/R OpqvDd1+tpyI/Ju98coKLrIyoFerMg1nuEvMLfJEsg9sub8sFZYmujn9w1cwNWBS7bKnctmz90bX lncpPK4/0BcLB/aO4y6heshmOzypSUjkQYqPuKEgMyfBW022v5adAIlR7gKuJOz6hvTOYnc+46Ee YZuk+LRvHwhK/P1D2xoYX1AWGtsACu2JT7qExpH5i1stXXqfBUgOanr8kY4bkjzQpxo6McVVb7Dx QuoZigjAq/Q+PE9CfPRaI6O+XszhTgw=
X-Report-Abuse-To: spam@se02.mfg.siteprotect.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Z8vfZsgvJbDhSCdj6LBrFoGn-Eo>
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 14:29:02 -0000


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 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
>