Re: [Masque] Endpoint requirements for unknown Capsules

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