Re: WGLC for draft-ietf-httpbis-connect-tcp

[David Schinazi <[e-mail]>]

First, to respond to Tommy's chair comment about WGLC: I absolutely agree
this needs more review. Additionally, I think we should wait for
implementation experience before sending it to the IESG.

Now, to respond to Tommy's technical points as individual:

When we originally developed the capsule protocol, I was worried about the
consequences of taking over the data stream. Luckily, there's a
straightforward solution: we define a DATA capsule - the semantics of all
DATA capsules is that they are concatenated to create the DATA stream. That
would allow us to have message content ("body") with methods that rely on
the capsule protocol.

I hadn't really thought about it in the context of connect-tcp, but I like
that idea. We could say that connect-tcp always uses the capsule protocol,
and then uses DATA capsules to encode the CONNECT/TCP bytestream. It's a
little bit more code on the receiver, and pretty much none on the sender
(just send a DATA capsule with length=2^61).

David

On Wed, Mar 6, 2024 at 3:03 PM Tommy Pauly <[e-mail]> wrote:

> (As an individual)
>
> I agree with David regarding the list of IP addresses — at the very least,
> it could be done in a similar way for connect-udp, etc.
>
> I did have one additional question about the design here. The related
> connect-udp and connect-ip protocols do have a nice feature inherent to
> using datagrams that they can use capsules to provide control messages
> between the client and the proxy at the start or during the middle of a
> transaction. Since connect-tcp consumes the stream, it doesn’t do that (and
> that makes sense for the sake of simplicity). However, I can imagine some
> cases where a client and proxy could want to have some generic capsules
> that describe proxy behavior that *could* be interesting for a
> connect-tcp proxy; for example, if a client and proxy wanted to communicate
> about different sending patterns to use for obfuscating traffic with
> padding and chaff, that could be negotiated using capsules.
>
> So my question is: do we think we’ll have any extension features that
> would want to use a capsule-like mechanism with connect-tcp, and if so how
> would that work? For example, if the client and proxy negotiate using the
> Capsule-Protocol header, do the stream data chunks end up going into
> capsules instead of directly into DATA frames?
>
> Thanks,
> Tommy
>
> On Feb 16, 2024, at 2:04 PM, David Schinazi <[e-mail]>
> wrote:
>
> Thanks for clarifying. At this point the list-of-IP-addresses
> feature seems unneeded to me, and it adds complexity to server
> implementations. I would personally recommend removing it from this
> document. It can always be added back if we need it later in an extension.
> David
>
> On Thu, Feb 15, 2024 at 1:01 PM Ben Schwartz <[e-mail]> wrote:
>
>>
>>
>> > On Feb 15, 2024, at 2:34 PM, David Schinazi <[e-mail]>
>> wrote:
>> >
>> > Hi Ben, thanks for the PR - it looks good to me.
>> >
>> > Regarding your point about client implementers, can you share more
>> about them? Who's implemented this so far? Who's depending on the address
>> list feature?
>>
>> I’m referring to prior conversations where some people seemed to prefer
>> leaving DNS resolution entirely in the client’s hands, e.g. [1].
>>
>> In most cases, I think target_host should simply be a hostname.  However,
>> I do think there are some cases where passing an IP address is appropriate,
>> and in those cases passing a list of N IPs is much more efficient than
>> sending N requests with one IP each:
>>
>> * When the client feels that it is necessary to enforce DNSSEC validation
>> of the A/AAAA responses.  (This is an unusual threat model, but it is
>> supported by platforms like iOS [2]).
>> * When the client attempts to reduce connection setup latency by using an
>> HTTPS record’s ipv4hint and ipv6hint SvcParams.
>> * When the IP addresses were not delivered through DNS at all (e.g., ICE
>> TCP in SDP [3])
>>
>> —Ben
>>
>> [1]
>> https://datatracker.ietf.org/doc/chatlog-115-masque-202211090930/#:~:text=In%20general%2C%20it%27s%20better%20for%20the%20proxy%20to%20do%20the%20final%20name%2D%3EIP%20resolution%2C%20whereas%20it%27s%20better%20for%20the%20client%20to%20do%20the%20HTTPS/SVCB%20lookup
>> .
>>
>> [2]
>> https://developer.apple.com/documentation/network/nwparameters/3952717-requiresdnssecvalidation
>>
>> [3] https://datatracker.ietf.org/doc/html/rfc6544#appendix-C
>>
>> >
>> > Thanks,
>> > David
>> >
>> > On Wed, Feb 14, 2024 at 1:59 PM Ben Schwartz <[e-mail]> wrote:
>> >
>> >> On Feb 13, 2024, at 10:48 PM, Tommy Pauly <[e-mail]> wrote:
>> >>
>> >>> On Jan 26, 2024, at 11:19 AM, Ben Schwartz <[e-mail]> wrote:
>> > ...
>> >>>     • "target_port" or "tcp_port":
>> https://github.com/httpwg/http-extensions/pull/2720
>> >
>> >
>> > …
>> >
>> >> As I’ve mentioned just now on the issue, the direction for
>> configuration might be to be more explicit on the supported protocol, so
>> that we don’t try to infer the protocol from the template. Based on that,
>> I’d lean right now towards just having a target_port, instead of tcp_port.
>> >
>> >
>> > OK it sounds like the consensus favors this change, so I’ve opened
>> https://github.com/httpwg/http-extensions/pull/2736.
>> >
>> >>>
>> >>>     • Support for "target_host=192.0.2.1&target_host=2001:db8::1":
>> https://github.com/httpwg/http-extensions/pull/2719
>> >>>
>> >>> To improve Happy Eyeballs and related behaviors, "connect-tcp" allows
>> the client to provide a list of IP addresses.  URI Templates have a
>> built-in notion of lists.  In URI Template Level 3 and below, list elements
>> are always joined by commas ("192.0.2.1,2001:db8::1").  However, in Level
>> 4, templates can use the "explode modifier" to generate repeated key=value
>> assignments (as above), which are more idiomatic in some web frameworks.
>> Should we require clients to support Level 4 templates, or restrict proxies
>> to publishing Level 3 templates?
>> >>
>> >>
>> >> In what I’ve seen, it’s usually best to have happy eyeballs be done by
>> the proxy based on the DNS resolution the proxy itself has performed, not
>> necessarily the addresses provided by the client. Before we make this too
>> complex, I'd like to hear about who would exercise this capability.
>> >
>> > I agree that this is best practice.  (It’s even documented at
>> https://datatracker.ietf.org/doc/html/rfc9460#section-3.2-2.)  However,
>> I’ve heard a number of arguments from client implementors who felt that the
>> client should be able to use its own DNS resolver, independent of the
>> proxy, in which case this functionality seems valuable for Happy Eyeballs
>> to work as intended.
>> >
>> > In the above pull request, I’ve simplified the syntax for this
>> (reducing the URI Template requirement to Level 3) to minimize the burden
>> on clients that don’t use the feature.
>> >
>> > —Ben
>>
>>
>>
>