[tsvwg] github issue long term archiving[ was: Re: Review of draft-ietf-tsvwg-udp-options-32]

[Sebastian Moeller <[e-mail]>]

At list, chairs,

please see bewlow.

> On 9. Apr 2024, at 17:00, [e-mail] wrote:
>=20
> Hi, all,
>=20
>> On Apr 9, 2024, at 3:31=E2=80=AFAM, Zaheduzzaman Sarker =
<[e-mail]> wrote:
>>=20
>> The questions I would like to get answer is  -=20
>>=20
>>       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?=20
>>=20
>> //Zahed=20
>=20
> We can prevent that if/when we proceed with the UDP encryption option =
or using IPsec.
>=20
> 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=E2=80=99ve had that for just as long too.
>=20
> What we don=E2=80=99t have is a widely enough deployed key =
infrastructure. Until that happens, it=E2=80=99s difficult to understand =
how raising these issues obligates protocol designers.
>=20
> However, there=E2=80=99s a second point I have not seen raised. Saying =
these options MUST NOT be modified in transit isn=E2=80=99t just for =
implementers - it=E2=80=99s also for those seeking to standardize such =
behavior and for those in the IETF who might assess those standards. =
What we=E2=80=99re saying, besides =E2=80=9Cdon=E2=80=99t do it=E2=80=9D, =
is =E2=80=9Cdon=E2=80=99t standardize it=E2=80=9D.
>=20
> The doc can make that point more clear in the doc, but I don=E2=80=99t =
see any other action coming from this discussion for the core doc.
>=20
> I also would suggest we move these discussions off to GITHUB as soon =
as possible so we can trace them more easily (chairs - what=E2=80=99s =
the procedure for that? Do you? Does the doc shepherd? Do I?).
>=20
> Joe
>=20


Question: if we move relevant discussion to locations not under IETF =
control, how do we ensure that the discussion threads stay =
readable/available in the future? While I have no reason to believe =
github will change its access model, I also have no guarantee that they =
will not.