[Masque] Endpoint requirements for unknown Capsules
Lucas Pardue <lucaspardue.24.7@gmail.com> Tue, 21 November 2023 20:02 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 326A3C14CF0D; Tue, 21 Nov 2023 12:02:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.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_NONE=-0.0001, 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 kLPekrbSYJ8k; Tue, 21 Nov 2023 12:02:44 -0800 (PST)
Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) (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 46586C15153E; Tue, 21 Nov 2023 12:02:30 -0800 (PST)
Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-1ea82246069so3361196fac.3; Tue, 21 Nov 2023 12:02:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700596949; x=1701201749; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=jrT+u3uPWV5/FRLWL5tO7IgNaRdahp1bPTHZpUi7WKU=; b=dzWss5pMK7DQg/qGIRSap7aDvUUvRDsxryV4/pcWF5690czj+JFTsL4Vp7t2rdlOaJ Rsr/A9WxdDt6wzmbYIbcHW2Bcm73NLCQ0meRMXLjpG5oA6Uf3R+0PW1FaVi6JAzSesrH w0XXRYuWxoZJIBnyKWBTo3MRf0zAFZxI7Jl/8CyXaUce/EQDc6j3xG4yLJMfOg6OsnWl 9HQYoHEMD+wkXbOyXVna0vuy3uPXye/D953CI2tG+IhYXkQm/oDLHePawihvpkwDKbka 9YFEFP4Ywn3uMiUM8C9jQ9ssi+jliSWe0DogUGmoZarMwOUGO+APJa9q/CA5Uuo+3osG a9tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700596949; x=1701201749; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jrT+u3uPWV5/FRLWL5tO7IgNaRdahp1bPTHZpUi7WKU=; b=RKooWDooWWGqHy4Vv/FUo6Qc3oQJIBplshozCd3GQU3Qh0bsKp0HPerjD1DunJWWb2 0V7EmogBrmO5tBhdgCRc3OYhxnTlfyAbHeJ4bvgjhrTXW4wa0W75K1xTC0sl+Q/iKaE1 jbMVIZx7pU3UCmm+sWxAY3LLeBSbVl/4vG0GnCYtW9GTzC+nVp5Z5liGZXZ1yJA3ocQK Fsl9tZmJ0jql0/iTKVb/z91qzGCN8YtJWVwDpa5inQQKxZnL+T4o3WssE6f43YWFTgY1 r8tF1QqVDAuqJz/Xj5o2NNQDTxPUvo3M/uj+gN8rDbz7vJsTPZ9tL+AopCaWIiC7+OB5 meKg==
X-Gm-Message-State: AOJu0YzH5bgR/sSdDuE5638gFUQIZ+rmOEi+fcjrLxXLiMhuwYM5eNLQ Wneyvltz1n0XHVFxmp2G/2aLZOtnRWe5exkFRECGkrSLqRw=
X-Google-Smtp-Source: AGHT+IFSLrUzGEf5M5e97U0apATBBgPcwCBWZ+ry4PXyR9sY/ycEl83TKhvc+JZZ+a6Q5lRUg+SBORE90OrXxpupEsk=
X-Received: by 2002:a05:6870:f818:b0:1e9:d4fd:6554 with SMTP id fr24-20020a056870f81800b001e9d4fd6554mr357931oab.39.1700596948709; Tue, 21 Nov 2023 12:02:28 -0800 (PST)
MIME-Version: 1.0
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Tue, 21 Nov 2023 20:02:17 +0000
Message-ID: <CALGR9oaGSX+p6K=yjjMye14oD+cpYqika05gkw6N8KbPOiRcTQ@mail.gmail.com>
To: MASQUE <masque@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, WebTransport <webtransport@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000008b69e060aaf150e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/GQIcetmDyZ5VwONi7tLlwext93g>
Subject: [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: Tue, 21 Nov 2023 20:02:48 -0000
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
- [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