Re: Call for Adoption: HTTP Proxy-Status Parameter for Next-Hop Aliases

2022年12月6日(火) 13:21 Mark Nottingham <mnot@mnot.net>:

> Tommy et al,
>
> This draft (or the protocol elements it defines) have been talked about in
> a few different places, so let's do a Call for Adoption to find out.
>
> This message opens a Call for Adoption for
> draft-pauly-httpbis-alias-proxy-status:
>
> https://www.ietf.org/archive/id/draft-pauly-httpbis-alias-proxy-status-00.html
>
> For the purposes of this CfA, assume that the proposed scope of work is as
> described -- just adding the `next-hop-alias` parameter, with any further
> work to be taken on separately.
>
> Please respond to indicate whether you support this work, that scope, and
> whether you intend to implement or use it.
>

This is a nice and clean draft that IIUC serves real use-cases. We plan to
implement and deploy this extension.

Aside from my +1 to adoption, I might state that the design looked good to
me as well. Initially, I was a bit surprised that the names have to be
concatenated as sf-string rather than using an array type of Structured
Headers. But I assume that's because we cannot have a list within an
sf-item. Therefore, we have to build an array outside of Structured Headers.


>
> The CfA will last for two weeks, ending on 20 December.
>
> Cheers,
>
>
> > On 1 Dec 2022, at 9:13 am, Tommy Pauly <tpauly@apple.com> wrote:
> >
> > Hello HTTP,
> >
> > Following up on this discussion, I presented this at Masque at IETF 115,
> and got the feedback that this would be fit more in HTTP, and also that it
> should just be a simpler proxy-status parameter to include only the alias
> name chain (generally, the CNAME chain).
> >
> > I’ve revised the document, and it’s super short — just defining a
> “next-hop-aliases” parameter, which is a list of names.
> >
> >
> https://www.ietf.org/archive/id/draft-pauly-httpbis-alias-proxy-status-00.html
> > https://datatracker.ietf.org/doc/draft-pauly-httpbis-alias-proxy-status/
> >
> > There was also discussion in the meeting about having more work on
> broader solutions to get rich and complex DNS information back from
> proxies, but I’d like to get this simple proxy-status parameter registered
> separately. I’d appreciate people’s reviews and thoughts.
> >
> > Thanks,
> > Tommy
> >
> >
> >> On Oct 12, 2022, at 4:02 PM, Mark Nottingham <mnot@mnot.net> wrote:
> >>
> >> Speaking personally -- I don't have any strong feelings either way, as
> long as appropriate communication happens. If the use cases are for
> non-MASQUE proxying too (and it seems like they are), that might tilt it
> slightly towards HTTP.
> >>
> >> Cheers,
> >>
> >>
> >>> On 11 Oct 2022, at 2:46 am, Tommy Pauly <tpauly@apple.com> wrote:
> >>>
> >>> Hi HTTP,
> >>>
> >>> I wanted to share this draft with this group, which I’ve initially
> started discussion on in MASQUE.
> >>>
> >>> It’s a simple parameter addition to proxy-status, to let the proxy
> send back the IP and CNAME/alias chain it used to reach the next hop. This
> is useful for clients of CONNECT/CONNECT-UDP proxies that want to apply
> policies to specific IPs and CNAMEs (for tracker detection, cookie rules,
> etc).
> >>>
> >>> In addition to any reviews and feedback on the technical content, we’d
> like to know if this is something that the HTTPbis WG would like to own, or
> if it is fine letting the work happen in MASQUE and get review from HTTP.
> >>>
> >>> Best,
> >>> Tommy
> >>>
> >>>> Begin forwarded message:
> >>>>
> >>>> From: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
> >>>> Subject: [Masque] HTTP Proxy-Status Parameter for DNS Information
> >>>> Date: October 4, 2022 at 12:29:33 PM PDT
> >>>> To: masque@ietf.org
> >>>>
> >>>> Hello MASQUErs,
> >>>>
> >>>> I wanted to share this document with this group, since it is mainly
> applicable to MASQUE-style (CONNECT/CONNECT-UDP) proxies.
> >>>>
> >>>> Right now, when a client connects to a TCP or UDP server via the
> proxy using a hostname in the request, it doesn’t perform its own DNS, and
> thus doesn’t learn about the IP address of the server it ultimately is
> connected to, or the CNAME / AliasMode chain that was used to get to the IP
> address of the server. That’s generally fine, but there are use cases where
> clients may want to know the IP address or CNAMEs to detect cases where
> trackers are performing CNAME cloaking, etc.
> >>>>
> >>>> So, this is a very simple proposal to define a new, optional
> proxy-status parameter that can let MASQUE-style proxies tell clients about
> the IP address and CNAME chain from DNS.
> >>>>
> >>>>
> https://www.ietf.org/archive/id/draft-pauly-masque-dns-proxy-status-00.html
> >>>>
> >>>> This certainly does not solve all of the use cases where clients may
> want to know more DNS details (SVCB/HTTPS records for ECH, alpn support,
> etc), and I expect more work to be needed for those use cases. However, I
> believe this extra bit of information is something that is incrementally
> useful, easy to implement, and simple to define.
> >>>>
> >>>> Thoughts and feedback welcome!
> >>>>
> >>>> Thanks,
> >>>> Tommy
> >>>>
> >>>>> Begin forwarded message:
> >>>>>
> >>>>> From: internet-drafts@ietf.org
> >>>>> Subject: New Version Notification for
> draft-pauly-masque-dns-proxy-status-00.txt
> >>>>> Date: October 4, 2022 at 11:01:29 AM PDT
> >>>>> To: Tommy Pauly <tpauly@apple.com>
> >>>>>
> >>>>>
> >>>>> A new version of I-D, draft-pauly-masque-dns-proxy-status-00.txt
> >>>>> has been successfully submitted by Tommy Pauly and posted to the
> >>>>> IETF repository.
> >>>>>
> >>>>> Name: draft-pauly-masque-dns-proxy-status
> >>>>> Revision: 00
> >>>>> Title: HTTP Proxy-Status Parameter for DNS Information
> >>>>> Document date: 2022-10-04
> >>>>> Group: Individual Submission
> >>>>> Pages: 5
> >>>>> URL:
> https://www.ietf.org/archive/id/draft-pauly-masque-dns-proxy-status-00.txt
> >>>>> Status:
> https://datatracker.ietf.org/doc/draft-pauly-masque-dns-proxy-status/
> >>>>> Html:
> https://www.ietf.org/archive/id/draft-pauly-masque-dns-proxy-status-00.html
> >>>>> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-pauly-masque-dns-proxy-status
> >>>>>
> >>>>>
> >>>>> Abstract:
> >>>>>  This document defines an HTTP Proxy-Status Parameter that contains
> >>>>>  the IP address and CNAME chain received over DNS that was used to
> >>>>>  establish the connection to the next hop.
> >>>>>
> >>>>> Discussion Venues
> >>>>>
> >>>>>  This note is to be removed before publishing as an RFC.
> >>>>>
> >>>>>  Source for this draft and an issue tracker can be found at
> >>>>>  https://github.com/tfpauly/privacy-proxy.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> The IETF Secretariat
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Masque mailing list
> >>>> Masque@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/masque
> >>>
> >>
> >> --
> >> Mark Nottingham   https://www.mnot.net/
> >>
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>

-- 
Kazuho Oku