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

Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com> Thu, 11 April 2024 11:16 UTC

Return-Path: <zahed.sarker.ietf@gmail.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 9E457C14F5EF; Thu, 11 Apr 2024 04:16:23 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 D_ejH32dM4V3; Thu, 11 Apr 2024 04:16:23 -0700 (PDT)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 1C8BBC14F5EE; Thu, 11 Apr 2024 04:16:23 -0700 (PDT)
Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-6ed9fc77bbfso1867084b3a.1; Thu, 11 Apr 2024 04:16:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712834182; x=1713438982; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j8eMVrf28Q2t4vVMk7uVW/fS5MaHrK25rFSeq/QkhfY=; b=T21AJzEGJTPJyTtabZyDESKQcfffHKNfKlgMgPrbucwk52b5ZRNXzxQ0lzfP6nQF/D TX3CFvHMCxMN8nx//bvtRRGAOdjVorS6H3mKHiCc8jSv+3mXNuLkhEI83iBqeYB9vCbA Wl7RkDjQ3U477CPEkPEWHeNhZbkUA/IA48lzrrTOtQVjnp0IOBC58k9nPjN1oj21dLqa RtlzlEpad5UeM2LgXhF3l+TLKkV/jinP99x5RFhci782vpfZNLezwXLKZGDrcAQo54An dMZ66bWPAt7kepW7dfmUu4c6WaRF8yrbmFQ3TWUg78lqXNLcA8ZG0R2mg3qtCcnvvGBg ppWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712834182; x=1713438982; h=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=j8eMVrf28Q2t4vVMk7uVW/fS5MaHrK25rFSeq/QkhfY=; b=gNFzBDSGzZxgDZtrda4Mn5nbVV4pnA3IqFVEq5j6fLG3VnvPrWdtrBQZuV5AnmiR63 0LFnZLL5jojYKnj0pJkvo9tYUTnrMyTmaXrYzaFpxD6TlWRjkIze5NLzv879H5qpovou MlcBRioFb0YUmO8nGemYppT+psW/fZDs+PTy/ek/IvbhyyoC46wR97yrSZVpM85nc5Fe o/ggOSFHOKfiqdGAgTqXD1WV05q3zUl5O7tmhcKjBPWeaFieCftG/ILZP4hopqRQ6Yut dsNku1Xc/5n8IeyKuNlYLqBn9d34qumEGNJe4m0VdiNVlKGw6NFyBI2dmt2VQXX1Vpd6 469w==
X-Forwarded-Encrypted: i=1; AJvYcCW+ECyEtWleEdqnn6oM/62rHZQmEX5neWUdiSfh/oTUL/Xwhc7EbovOAacoXU8gYC8qulYywKVTuMPSHqaIw1dviKNXJuP+nQ/b9hNloHnISnNPQNUYuYwdOw77naw6xcNhwc/0q0pAKfE=
X-Gm-Message-State: AOJu0YwZMqI9O80yodQug77jgoVIJwqEpRyhXsZaF/5uMcJxVGUM/Cd8 3k/Tc8pj45FQ41dsVUlBzkZdpb4JFvs6k0aI8IdIlFB6iaKx8PeV7jakAcGi3xD6j6zPflvtBs1 SgwxOcSBYx4uTpnmLmimTJUGQchw=
X-Google-Smtp-Source: AGHT+IERb2TY9PQ0MIXiXnM9PdvJrkDVzSpUgJgN7Z1bSGTxkO+bgeYrMO9KGoi4KiAHXAlm+j5bY5SGIv05JfnBDGo=
X-Received: by 2002:a05:6a20:2443:b0:1a9:7bd:845b with SMTP id t3-20020a056a20244300b001a907bd845bmr6430840pzc.0.1712834182228; Thu, 11 Apr 2024 04:16:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxSpwRF5E3Xc_hotgvCSdKVe4BY_zRUKAzHvW48JEtWqTA@mail.gmail.com> <CACL_3VGOLkJU1m7pqSXRRouCKwdQ6yrbmaPwoa22Jr-N3FZNzA@mail.gmail.com> <fccb92b0-dbc8-4cb2-b49c-1f603297d721@huitema.net> <CAEh=tcd2FzQxgbSivuX2cEg2FpsnkoqdFw5gMhrx3pkT_JV88Q@mail.gmail.com> <F36164D6-8685-4AB2-AED3-147E4D6D8FF8@strayalpha.com>
In-Reply-To: <F36164D6-8685-4AB2-AED3-147E4D6D8FF8@strayalpha.com>
From: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>
Date: Thu, 11 Apr 2024 13:16:10 +0200
Message-ID: <CAEh=tce1nU4P2NZVn7NVsWKgmKLhtUzDpfbf3wzJRjgbryy9+w@mail.gmail.com>
To: "touch@strayalpha.com" <touch@strayalpha.com>
Cc: Christian Huitema <huitema@huitema.net>, tsvwg <tsvwg@ietf.org>, draft-ietf-tsvwg-udp-options.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fdb4710615d0481b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/J4tTugf1os2qv5Ks-UfUYABwqrQ>
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: Thu, 11 Apr 2024 11:16:23 -0000

On Tue, Apr 9, 2024 at 5:01 PM touch@strayalpha.com <touch@strayalpha.com>
wrote:

> Hi, all,
>
> On Apr 9, 2024, at 3:31 AM, Zaheduzzaman Sarker <
> zahed.sarker.ietf@gmail.com> wrote:
>
> 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
>
>
> We can prevent that if/when we proceed with the UDP encryption option or
> using IPsec.
>

I wanted to make sure we have a consensus here that it is good enough to do
so.


>
> But all this talk about transport protocols and their vulnerability to
> on-path mods strikes me as hollow. We have had such protections for TCP for
> a generation (over 25 yrs) with TCP-MD5 and its successor TCP-AO. Neither
> one protects packets from on-path tampering with IP options, but we’ve had
> that for just as long too.
>
> What we don’t have is a widely enough deployed key infrastructure. Until
> that happens, it’s difficult to understand how raising these issues
> obligates protocol designers.
>

(I am not sure why that is not widely deployed yet :-).)

The obligation here is that we have thought about the possibilities,
understand the pros and cons, made the right choice, and well describe them
on what we published.  I am not AD reviewing the document now, but I would
not like wait till my AD review to express what I would be looking for. Now
you know and can just tell me yes we have done those thoughts and in
section XXX we have described it well.


>
> However, there’s a second point I have not seen raised. Saying these
> options MUST NOT be modified in transit isn’t just for implementers - it’s
> also for those seeking to standardize such behavior and for those in the
> IETF who might assess those standards. What we’re saying, besides “don’t do
> it”, is “don’t standardize it”.
>
> The doc can make that point more clear in the doc, but I don’t see any
> other action coming from this discussion for the core doc.
>

Please, do that!!.

>
> I also would suggest we move these discussions off to GITHUB as soon as
> possible so we can trace them more easily (chairs - what’s the procedure
> for that? Do you? Does the doc shepherd? Do I?).
>

I am late to respond and I am not sure I am supposed to respond, but have
we created the issue.. It would be great for the record to share the issue
link in this email thread.


>
> Joe
>
>