Re: [Masque] Endpoint requirements for unknown Capsules
Lucas Pardue <lucaspardue.24.7@gmail.com> Thu, 23 November 2023 23:46 UTC
Return-Path: <lucaspardue.24.7@gmail.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19308C16F3E2; Thu, 23 Nov 2023 15:46:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.855
X-Spam-Level:
X-Spam-Status: No, score=-6.855 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=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 KVGrSjGJ_glU; Thu, 23 Nov 2023 15:46:35 -0800 (PST)
Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) (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 C2409C151081; Thu, 23 Nov 2023 15:46:30 -0800 (PST)
Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-1eb39505ba4so887594fac.0; Thu, 23 Nov 2023 15:46:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700783189; x=1701387989; 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=+pt/WgXAEvJQDSOC9+xWIV/JJRyMDTxhpFKEkn5LeTo=; b=Lvdvvj+mh9wqpqPyL9gkMBJxCWSkAC+XHw6ANi0z9+VHmh4HtW2UUTfdrlPNuoEIZz Fwj2m3qRcexkOi8m9EdI4siuO8yua+Ko5j+Dl377FCfJRMCsGVtPPutnNlYoxGtAm/Az 57yTpGHlgoISoyuMzRkjIdW85VYPpbuHiIKL3CZHWASsauaMQOhGG1ewCs1cc4Ckwp6y UDkiV7gLI9EbmZRzMe9Wq0PIWLdBHYsHh1icAUCxZSmkKPHK/1Ofb1COe5HPJb50aaA1 2l2gXBZb9irPaJSzt7wgg0NSNyy52RrQpTb8y45utbfo6Z6FvlduH/RF+e/Ct+6BJBCY 2xGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700783189; x=1701387989; 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=+pt/WgXAEvJQDSOC9+xWIV/JJRyMDTxhpFKEkn5LeTo=; b=kXbbto2znBIlt6HfHHaH1ZK0r+bHC5wieuWHB7CIdEnXJ2Ufa+e3VCp4FEOtt4bIkI ZJxoxFB45IbAbqT5EboGboK0LVeofEYjmsraPAM52fww1rVyvCNGcdWkNHNEWOVhZzBo C45kwtokd1PhwVg0H53Plai1EmVf0RchXUt8V4dcmmuwK6gjQXsVSDee5AG0rc31YH6o jhaqDv18t4iZ0ztiXMiyeofbufDCchfa4O9TL2o01J8QYV9BSY+BuqaB3pdHQJnqUm4m dyxGc1kKVzijFlS+8D2hT6HnvN0zXNsAocg8Uvs3dkFsi1T1SjcLCOk7hym1iPiw3QSb d2kg==
X-Gm-Message-State: AOJu0Yz/OQMd9lbTwZI5CZ0xWok6UTAjs2Uw99ey+IUlpLuwq8IJnqWA kSMlzq5+B7Lhbt4IRfGsMJWGFkHbcmPB8pccI+I=
X-Google-Smtp-Source: AGHT+IHqE6I7FA3fxeC1MQeTbQTJWNjxBABj6Qz4TOfn8CecZbXGZE4mnIFhb8TdgzRiTF6pRgzNL2tzDoZFJraO5pU=
X-Received: by 2002:a05:6870:c98b:b0:1f9:9ad0:cd3d with SMTP id hi11-20020a056870c98b00b001f99ad0cd3dmr1170464oab.4.1700783189410; Thu, 23 Nov 2023 15:46:29 -0800 (PST)
MIME-Version: 1.0
References: <CALGR9oaGSX+p6K=yjjMye14oD+cpYqika05gkw6N8KbPOiRcTQ@mail.gmail.com> <EFFA5FC9-0A09-4494-9F03-64D0C93CD79E@apple.com> <CALGR9obbAt5fSO1EAOb-csDCtiFS9bkiUNm4a_qLz0sbsjMX9w@mail.gmail.com>
In-Reply-To: <CALGR9obbAt5fSO1EAOb-csDCtiFS9bkiUNm4a_qLz0sbsjMX9w@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 23 Nov 2023 23:46:18 +0000
Message-ID: <CALGR9ob=U1W9z=FoWLLchUDtSa7yrUp5j62fGLhWZfOy_D=sPg@mail.gmail.com>
To: Tommy Pauly <tpauly@apple.com>
Cc: MASQUE <masque@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, WebTransport <webtransport@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d8476f060ada7124"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/03KxsOFli4FbFcmt1zOzhES60JM>
Subject: Re: [Masque] Endpoint requirements for unknown Capsules
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Nov 2023 23:46:40 -0000
I posted a draft, the repo is https://github.com/LPardue/draft-pardue-capsule-ext-guidance if anyone is interested A new version of Internet-Draft draft-pardue-capsule-ext-guidance-00.txt has been successfully submitted by Lucas Pardue and posted to the IETF repository. Name: draft-pardue-capsule-ext-guidance Revision: 00 Title: Guidance for HTTP Capsule Protocol Extensibility Date: 2023-11-23 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/archive/id/draft-pardue-capsule-ext-guidance-00.txt Status: https://datatracker.ietf.org/doc/draft-pardue-capsule-ext-guidance/ HTML: https://www.ietf.org/archive/id/draft-pardue-capsule-ext-guidance-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-pardue-capsule-ext-guidance Abstract: This document updates RFC 9297 with further guidance for extensibility of the HTTP Capsule Protocol. On Thu, Nov 23, 2023 at 1:49 PM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: > Hi Tommy, > > On Wed, Nov 22, 2023 at 5:48 AM Tommy Pauly <tpauly@apple.com> wrote: > >> Good question! >> >> While the connect-ip capsules don’t have defined behavior for >> connect-udp, that shouldn’t prevent them from being used in the future. An >> assign IP could make sense there. There’s a benefit from being able to use >> capsules across protocols like that. >> >> However, in order for it to work, I think we’d need to have a negotiation >> between client and server to say “I support the connect-udp extension that >> allows address assigning.” >> >> That doesn’t answer your question. I could see this going either way. The >> problem with option d is that it requires the connect-udp implementation to >> be aware of these capsules in order to send an error. So I’d probably go >> with interpretation b? >> > > Actually I think it goes part way to answering the question, so thanks! > > I agree we don't want to limit extensibility possibilities. For endpoints > to know that a new capsule type can be used, some form of negotiation is > required. I don't think we need to be prescriptive about how that is done, > a header might work (like "connect-udp-assign: ?1") or a setting, or > whatever. > > I could live with option b) augmented by new text that better describes > the general extension framework. I think we also overlooked adding text to > RFC 9297's security considerations related to DoS of endpoints, see > HTTP/3's [1] as an example of text I think we could port over. > > I'll see if I can find some time to collect these into a short I-D for > easier discussion. > > Cheers, > Lucas > > [1] - https://www.rfc-editor.org/rfc/rfc9114.html#section-10.5-4 > > >> Tommy >> >> On Nov 21, 2023, at 12:05 PM, Lucas Pardue <lucaspardue.24.7@gmail.com> >> wrote: >> >> >> Hi folks, >> >> I have a question about how endpoints (not intermediaries) should >> approach handling HTTP Capsules and I'm looking for some WG input. >> >> RFC 9297 defined HTTP Datagrams and the Capsule Protocol[1]. During >> standardization, the primary use case was for proxying UDP over HTTP (RFC >> 9298). >> >> 9297 defines Datagram capsules and 9298 defines how an Upgrade or >> extended request accompanied with a connect-udp token, when successful, >> enables *both* UDP proxying and the Capsule protocol. Once the request is >> set up it is the expectation that Datagram capsules are exchanged, modulo >> HTTP/3 which also has a native QUIC Datagram mapping (so endpoints can >> exchange either form). >> >> RFC 9297 section 3.2 states: >> >> > Endpoints that receive a Capsule with an unknown Capsule Type MUST silently >> drop that Capsule and skip over it to parse the next Capsule. >> >> This is inspired by HTTP/2&3 frame design with the goal of extensibility >> and maintenance*. We have GREASE capsule codepoints and unknown real >> extensions can be used with causing things to fall over. So far so good. >> >> Recently, RFC 9484 was published, defining IP over HTTP. This defined a >> connect-ip token and 3 new capsule types, ADDRESS_ASSIGN, ADDRESS_REQUEST, >> and ROUTE_ADVERTISEMENT. >> >> So here's the question: >> >> Assume there's an endpoint that supports both IP and UDP tunneling. It >> knows about the tokens and the capsules I mentioned above. If it receives a >> request for connect-udp and accepts it, then receives an ADDRESS_ASSIGN >> capsule what should it do? >> >> The text in RFC 9297 seems a little ambiguous and I tried to map out the >> options >> >> a) The ADDRESS_ASSIGN capsule is unknown in the context of RFC 9298, so >> it MUST be ignored >> b) The ADDRESS_ASSIGN capsule is unknown in the connect-udp context of >> the target resource of the request over which the capsule protocol is >> using, so it MUST be ignored >> c) The ADDRESS_ASSIGN capsule is known to the endpoint. However, it is >> undefined and so is silently dropped >> d) The ADDRESS_ASSIGN capsule is known to the endpoint. Since this >> capsule is unexpected for connect-udp, the server treats this as some form >> of protocol violation (stream or connection close). >> >> Option (d) seems drastic but is more in the theme of dealing with the >> "Harmful consequences of Tolerating the Unexpected" [4], so might actually >> be The Right Thing TM. >> >> We have other specs like WebTransport queuing up 13 new capsule >> registrations. If there's anything we could do to clarify the situation >> (such as a short update doc to RFC 9297) then now seems like the right time >> to be doing it. So please let me know your opinions. >> >> Cheers, >> Lucas >> >> * There are other considerations for intermediaries but I'm overlooking >> that complication right now. >> >> >> [1] - https://www.rfc-editor.org/rfc/rfc9297.html >> [2] - https://www.rfc-editor.org/rfc/rfc9298.html >> [3] - https://www.rfc-editor.org/rfc/rfc9484.html >> [4] - https://www.rfc-editor.org/rfc/rfc9413.html#section-4 >> -- >> Webtransport mailing list >> Webtransport@ietf.org >> https://www.ietf.org/mailman/listinfo/webtransport >> >>
- [Masque] Endpoint requirements for unknown Capsul… Lucas Pardue
- Re: [Masque] Endpoint requirements for unknown Ca… Tommy Pauly
- Re: [Masque] Endpoint requirements for unknown Ca… Lucas Pardue
- Re: [Masque] Endpoint requirements for unknown Ca… Lucas Pardue
- Re: [Masque] [Webtransport] Endpoint requirements… David Schinazi