- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Tue, 22 Oct 2024 00:26:05 +0100
- To: "HTTP Working Group" <ietf-http-wg@w3.org>
- Cc: "Tommy Pauly" <tpauly@apple.com>, "David Schinazi" <dschinazi.ietf@gmail.com>, MASQUE <masque@ietf.org>, WebTransport <webtransport@ietf.org>
- Message-Id: <41e6b4a3-e5d6-4f64-a96f-f7f4d0944900@app.fastmail.com>
Hi Folks, Reviving this thread because the last couple of weeks I spotted a new gotcha with capsule extensibility - use of error codes. It turns out in RFC 9297 we only formally registed H3_DATAGRAM_ERROR with the description "Datagram or Capsule Protocol parse error". If you have any kind problem with capsules you can use that, but it gets weird fast if you're a Capsule Protocol that doesn't use DATAGRAM capsules, and it doesn't help if you're HTTP/2. I added some text on this and cut draft-pardue-capsule-ext-guidance-01 [1]. The draft now treats 3 separate things and given we have several capsule related drafts in process (and maybe more to be adopted), this seems like the right time to iron things out. From prior discussion on list and in backchannels, the HTTP WG seems like the right venue. Chairs might I find some agenda time at Dublin to discuss? Cheers, Lucas [1] - https://datatracker.ietf.org/doc/draft-pardue-capsule-ext-guidance/ On Fri, Jan 5, 2024, at 16:39, David Schinazi wrote: > I think Lucas found a real oversight in RFC 9297, and we should fix it. Looking through Google's QUICHE implementation, we don't handle unexpected capsules consistently. For example, a connect-udp endpoint will silently ignore received ADDRESS_ASSIGN but will reset the stream on receipt of DRAIN_WEBTRANSPORT_SESSION [1]. Using the nomenclature from Lucas's original email, we do both (b) and (d). (The discrepancy in the same implementation comes from the fact that those were implemented by different folks.) > > Going forward, I think we should update 9297 to clarify this, and perhaps provide guidelines for future capsules. I think draft-pardue-capsule-ext-guidance is a good starting point, and I'd like to discuss it in Brisbane. The main question that needs resolving before then is: in what WG should we discuss this? My personal interpretation is that this is in-charter for MASQUE, but what do y'all think? > > Cheers, > David > > [1] https://github.com/google/quiche/blob/6c5a75906be4155ee7140415e9d2b2d18efc9fbc/quiche/quic/core/http/quic_spdy_stream.cc#L1382 > > On Fri, Nov 24, 2023 at 12:46 AM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: >> 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 >> -- >> Webtransport mailing list >> Webtransport@ietf.org >> https://www.ietf.org/mailman/listinfo/webtransport
Received on Monday, 21 October 2024 23:26:33 UTC