Re: [Masque] Endpoint requirements for unknown Capsules

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
>>
>>