Re: [Masque] Endpoint requirements for unknown Capsules

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?

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