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

[David Schinazi <[e-mail]>]

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