Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt

[Mirja Kuehlewind <[e-mail]>]

Hi Lucas,

see inline.

From: Lucas Pardue <[e-mail]>
Date: Wednesday, 22. January 2020 at 17:56
To: Mirja Kuehlewind <[e-mail]>
Cc: Patrick McManus <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Zaheduzzaman Sarker <[e-mail]>, "Su, Chi-Jiun" <[e-mail]>
Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt

Hey Mirja,

So it turns out that me skim reading the draft results in misunderstanding its intent. I think I got it into my head that this document was a survey of general proxy discovery protocols, not a set of specific proposals for QUIC proxies. With my renewed understanding, I agree that the document shouldn't recommend the use of WPAD. Maybe there is an opportunity to discuss the more broad considerations, such as authentication, to make when deploying, advertising and selecting a QUIC proxy. But maybe that is covered in text elsewhere.

Yes, that definitely need more discussion/consideration and you might have notices that the security section is empty at the moment. So I think that’s the place to an initial discussion. PRs are welcome 😊

Taking a deeper look at the proposals, I wonder how some of the presented option play with the ALPN and SNI in the QUIC handshake. For instance, in the DHCP example, a client might discover that there is a QUIC proxy but not know its name or application layer protocol and hence could have a hard time setting up the QUIC connection.

My currently assumption right now was that a client could just open a QUIC connection on port 443 and there is only one proxy protocol, so it know it has to speak that. The proxy protocol could be H3 based (and then we would need a way to also discovery a name which DCHP could also provide) or something else. So I think this will depend on how the protocol will actually look like and we don’t know that yet. However in each of the discovery protocols there is also a block for reserved bits, so we could even make use of some of those bits.

And on this note I wonder if we need to delineate between what might be a general purpose "QUIC transport proxy" and an "Application-on-QUIC proxy". For example, with HTTPS proxies today it is possible for them to use Alt-Service to advertise the availability of HTTP/3.

Yes, that could be one option and I think is open for discussion. My thinking was that you have a control protocol that you speak with the proxy and also use to communication the application that you want to proxy. So if that would be H3, you can tell the proxy directly without making a detour by using Alt-Service. However, that an independent question to what the proxy control protocol itself is based on.

Mirja



Cheers
Lucas

On Wed, Jan 22, 2020 at 1:54 PM Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>> wrote:
Hi Partick, hi Lucus, hi all,

I’m currently updating the discovery draft and therefore looking at this email thread.

So looking at WPAD, it also uses DHCP and/or DNS to get a config file. In the draft we mentioned also the use of Provisioning Domains (PvDs) to get information about local configuration. This seems to be the more appropriate and soon to be standardized alternative, so I don’t think mentioning WPAD will add much. Lucas?

Mentioning WPAD could maybe lead to a discussion about who this information can be access by an application/browser (if needed because it could also be the OS that handles the proxying transparently for the app), however, this seems a bit out of scope for this document and probably is mostly covered by taps for PvDs.

Patrick, you said below that “series of CONNECT tunnels to the proxy are giving up the end to end security of transport features that QUIC“. In the setup we have in mind for use with MASQUE, we never touch the encrypted QUIC end-to-end connection and just forward those packets. Other than for HTTP/TCP proxies, the idea is to always have an outer QUIC connection between the client and the proxy and an inner QUIC connection between the client and the server. So I think if you only look for a forwarding service (+ address translation/anonymization), it’s actually okay to rely on potentially unauthenticated local discovery as you basically only have to trust the proxy as much as you trust any router on the path. However, given there is a QUIC connection between the client and the server which includes authentication, you may even be able to authenticate a known proxy even if the discovery was not authenticated.

Mirja



From: Masque <[e-mail]<mailto:[e-mail]>> on behalf of Patrick McManus <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 5. November 2019 at 22:37
To: "Su, Chi-Jiun" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>>, Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>, Lucas Pardue <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt

wpad is mostly an anti-pattern these days for important reasons - there is no authentication. When there was less https it was chronically responsible for people getting owned.

If the client is explicitly using a proxy it must have a reason to use and trust a particular one (or class of one). quic of course provides authentication to the peer and in the normal http way of things this auth is linked to the origin which is rooted in some kind of out of band information (i.e. the url obtained from a secure source such as an input box, a bookmark, the command line, or transitively by finding the url embedded in a resource found in those ways). unsecured broadcast mechanisms like dhcp on (mostly) unauthenticated local networks don't satisfy that which is why proxy config is generally viewed as an end host configuration requirement that can't be autodiscovered. (often done right via enterprise config).

even scenarios that only envision a series of CONNECT tunnels to the proxy are giving up the end to end security of transport features that QUIC has added and so I would think use of a untrusted proxy (i.e. one not rooted in a trust anchor in some meaningful way) should be discouraged.

On Mon, Nov 4, 2019 at 3:35 PM Su, Chi-Jiun <[e-mail]<mailto:[e-mail]>> wrote:
Here are some more related to wpd for http:

https://tools.ietf.org/html/draft-chow-httpbis-proxy-discovery-00

https://tools.ietf.org/html/draft-nottingham-web-proxy-desc-01



From: Masque <[e-mail]<mailto:[e-mail]>> On Behalf Of Lucas Pardue
Sent: Monday, November 4, 2019 12:16 PM
To: Mirja Kuehlewind <[e-mail]<mailto:mirja.kuehlewind@ericsson..com>>
Cc: [e-mail]<mailto:[e-mail]>; Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I'm not an expert in either WPAD [1] or PAC [2], but I am an expert in feeling their pain as a user on Windows. Part of their pain comes from lack of formal standardization, resulting in some word-of-mouth approaches to problem solving, especially how they work (or don't) with the standardised approaches such as DHCP.

In looking this up, I did discover draft-ietf-wrec-wpad-01, a > 20 I-D for WPAD [3], wow!

[1] - https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Protocol<https://protect2.fireeye.com/v1/url?k=8143fc09-ddca5362-8143bc92-0cc47ad93ea2-9c4c1e59f3a4763a&q=1&e=2f71b81e-3b7f-407d-94ee-477723065acb&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fen.wikipedia.org%2Fwiki%2FWeb_Proxy_Auto-Discovery_Protocol__%3B%210rLxnc5oh4s%21jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PN7gcAGxA%24>
[2] - https://en.wikipedia.org/wiki/Proxy_auto-config<https://protect2.fireeye.com/v1/url?k=ec283b44-b0a1942f-ec287bdf-0cc47ad93ea2-c0fa6c32446bda1a&q=1&e=2f71b81e-3b7f-407d-94ee-477723065acb&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fen.wikipedia.org%2Fwiki%2FProxy_auto-config__%3B%210rLxnc5oh4s%21jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9POhddlmBA%24>
[3] - https://tools.ietf.org/html/draft-ietf-wrec-wpad-01<https://protect2.fireeye.com/v1/url?k=4c72b7f1-10fb189a-4c72f76a-0cc47ad93ea2-304f9fbace2f867e&q=1&e=2f71b81e-3b7f-407d-94ee-477723065acb&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-wrec-wpad-01__%3B%210rLxnc5oh4s%21jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9POJiXk9oA%24>

On Mon, Nov 4, 2019 at 5:09 PM Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>> wrote:
Hi Lucas,

no, we didn’t consider this yet but only because we were not really aware of that. Do you have a pointer? Or send a PR 😊

https://github.com/mirjak/draft-kuehlewind-quic-proxy-discovery<https://protect2.fireeye.com/v1/url?k=17915901-4b18f66a-1791199a-0cc47ad93ea2-7a6093b538b2b046&q=1&e=2f71b81e-3b7f-407d-94ee-477723065acb&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgithub..com%2Fmirjak%2Fdraft-kuehlewind-quic-proxy-discovery__%3B%210rLxnc5oh4s%21jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PMVg31Abw%24>

Mirja


From: Lucas Pardue <[e-mail]<mailto:[e-mail]>>
Date: Monday, 4. November 2019 at 18:06
To: Mirja Kuehlewind <[e-mail]<mailto:mirja.kuehlewind@ericsson...com>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Zaheduzzaman Sarker <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt

Thanks for sharing this.

I wonder if you considered WPAD (Web Proxy Autodiscovery) or PAC (Proxy auto-config)? Although targetted at the application layer, it might help to comment on how those forms of discovery would relate to the methods outlined in your draft.

Cheers,
Lucas

On Mon, Nov 4, 2019 at 4:58 PM Mirja Kuehlewind <mirja..kuehlewind=[e-mail]<mailto:[e-mail]>> wrote:
Hi all,

we submitted a new draft that lists discovery mechanisms for QUIC-based proxies (see below). This is one piece of work that is needed for most of the use cases in draft-kuehlewind-quic-substrate.

Let me know if you have any questions or comments!

Mirja


On 04.11.19, 17:53, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> wrote:


    A new version of I-D, draft-kuehlewind-quic-proxy-discovery-00.txt
    has been successfully submitted by Mirja Kuehlewind and posted to the
    IETF repository.

    Name:               draft-kuehlewind-quic-proxy-discovery
    Revision:   00
    Title:              Discovery Mechanism for QUIC-based, Non-transparent Proxy Services
    Document date:      2019-11-04
    Group:              Individual Submission
    Pages:              11
    URL:            https://www.ietf.org/internet-drafts/draft-kuehlewind-quic-proxy-discovery-00.txt<https://protect2.fireeye.com/v1/url?k=85e7114c-d96ebe27-85e751d7-0cc47ad93ea2-9cf6dc87f9d610e4&q=1&e=2f71b81e-3b7f-407d-94ee-477723065acb&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-kuehlewind-quic-proxy-discovery-00.txt__%3B%210rLxnc5oh4s%21jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PP6fOtFfw%24>
    Status:         https://datatracker.ietf.org/doc/draft-kuehlewind-quic-proxy-discovery/<https://protect2.fireeye.com/v1/url?k=930ea7e1-cf87088a-930ee77a-0cc47ad93ea2-e9456f4f4f38641c&q=1&e=2f71b81e-3b7f-407d-94ee-477723065acb&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-kuehlewind-quic-proxy-discovery%2F__%3B%210rLxnc5oh4s%21jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PNirJBnKQ%24>
    Htmlized:       https://tools.ietf.org/html/draft-kuehlewind-quic-proxy-discovery-00<https://protect2.fireeye.com/v1/url?k=b7749253-ebfd3d38-b774d2c8-0cc47ad93ea2-e8760832de2d32a0&q=1&e=2f71b81e-3b7f-407d-94ee-477723065acb&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-kuehlewind-quic-proxy-discovery-00__%3B%210rLxnc5oh4s%21jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PNt2ljWVQ%24>
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-kuehlewind-quic-proxy-discovery<https://protect2.fireeye.com/v1/url?k=f5936d55-a91ac23e-f5932dce-0cc47ad93ea2-194b954195f07874&q=1&e=2f71b81e-3b7f-407d-94ee-477723065acb&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-kuehlewind-quic-proxy-discovery__%3B%210rLxnc5oh4s%21jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PNLkowwPw%24>


    Abstract:
       Often an intermediate instance (such as a proxy server) is used to
       connect to a web server or a communicating peer if a direct end-to-
       end IP connectivity is not possible or the proxy can provide a
       support service like, e.g., address anonymisation.  To use a non-
       transparent proxy a client explicitly connects to it and requests
       forwarding to the final target server.  The client either knows the
       proxy address as preconfigured in the application or can dynamically
       learn about available proxy services.  This document describes
       different discovery mechanisms for non-transparent proxies that are
       either located in the local network, e.g. home or enterprise network,
       in the access network, or somewhere else on the Internet usually
       close to the target server or even in the same network as the target
       server.

       This document assumes that the non-transparent proxy server is
       connected via QUIC and discusses potential discovery mechanisms for
       such a QUIC-based, non-transparent proxy.




    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org<https://protect2.fireeye.com/v1/url?k=d9509e83-85d931e8-d950de18-0cc47ad93ea2-b80e92b2a6c2cfef&q=1&e=2f71b81e-3b7f-407d-94ee-477723065acb&u=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Ftools.ietf.org__%3B%210rLxnc5oh4s%21jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PNQh7NkuA%24>.

    The IETF Secretariat



--
Masque mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/masque<https://protect2.fireeye.com/v1/url?k=d61a88ef-8a932784-d61ac874-0cc47ad93ea2-822ab952eb4de87c&q=1&e=2f71b81e-3b7f-407d-94ee-477723065acb&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmasque__%3B%210rLxnc5oh4s%21jPosQt26EajScgUupoiCIMKOtu1eu9R0tg2CEkMXNq8Cx56sCmkL7PmI9PO4I6Apdw%24>
--
Masque mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/masque