Re: [Webtransport] [Masque] Endpoint requirements for unknown Capsules

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
>