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

Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 22 January 2020 16:56 UTC

Return-Path: <lucaspardue.24.7@gmail.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC34120130; Wed, 22 Jan 2020 08:56:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Level:
X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrSybmfkyUau; Wed, 22 Jan 2020 08:56:31 -0800 (PST)
Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EEE12011C; Wed, 22 Jan 2020 08:56:31 -0800 (PST)
Received: by mail-vk1-xa34.google.com with SMTP id g7so99816vkl.12; Wed, 22 Jan 2020 08:56:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OJUNGKQekUg+Ah8rn6+ExKLulIZxMZGeI6x7ZmJ8blo=; b=digoN/nZiPpthFusNqn9TxvNdCUSGo78FzvbWOxh4hITX2tRS/smaRjEs27Q9n4Vgd 8GoikDTnKJpXR7eTX30bSzmxqIoBj2s3a0RNGFSlCcUre9t+aiqzV78NsQa7e+u/lcZa lnDh4WIvIYqC9t6ZaR0m3zgFdT8RXDliRe3v2TxcTWEPkIpavkGmX55zzIQBRbims2Wk ZwstUDV4tF5/auPiM7PT1h7RRDl32XTuT/66VWX/iqQO2LiZ5qXq59t0hSQUgJ7YtfGb H9W78n5fAOXOck+aZYZ3RU0VbZPAdAxRmatHfP6XgbVcZYdw9qH3uMBnp35CS8sFSLHY 9qpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OJUNGKQekUg+Ah8rn6+ExKLulIZxMZGeI6x7ZmJ8blo=; b=Xz/YtbG0L97S4N2B2Vc3LzRGB2bNGOnj5MyWd35tAcDdiRbUV9R9mGqz4clFGsnXZ/ Ubv8pIalzhUjDhNUj0j7x3LASQ+gt3ZGf/vSwT3ihUCnWItR8wd21TNUy75DXzRky6Ra Xg/tUepfQIPaGiEsO4EY0jHbo4B/HXdE9oC2+0ABO0ESZ0q/lYAOYUMdpbiUFygyuxla 1pU7zVpTWb70N2EHQq6heID+3vyDzg60vgmGh2EWvrJS2jLt3ECarBYHB70bvjbp1522 fGHkEQUO3GYH1IcEEgTwE+GmgFCh2nzM6w+kqVSFCshgZGXFciMsTbETkc2khFErDkus 7/WA==
X-Gm-Message-State: APjAAAU9PJgdzAsSWIx7dqdGZ4O0I+ts+8CL3cgTb2uk2msOcWNrgKjw zgfKJ/0L3IlX8x6iJaiizvMGLV0DrYJHawt99F4=
X-Google-Smtp-Source: APXvYqzNb3oC3vtivvG5xM2TxMT4rJ5Zaz/FpwWDKY0istONC5ZdVcNzfF0gShoF2C1U1uHdEErSQQMrOeKR5TOVE1E=
X-Received: by 2002:a1f:3fcd:: with SMTP id m196mr6817007vka.28.1579712190230; Wed, 22 Jan 2020 08:56:30 -0800 (PST)
MIME-Version: 1.0
References: <157288641719.16495.4218503379126128243.idtracker@ietfa.amsl.com> <CA5EB3C0-F510-4883-B50B-51A3E46B47CA@ericsson.com> <CALGR9obp-YARLEXDVWvTqZ_h=Ocbn6m2On+uovK-SL-6TaOSXg@mail.gmail.com> <3F20108D-DEED-4AEF-89D3-55F11058110B@ericsson.com> <CALGR9oYHce0mnkj5Kz13EoR-zN3-xSr0igkJF2Z_dJ2vgfVNSQ@mail.gmail.com> <SN6PR11MB3087D25371090E7E40FA32B2CE7F0@SN6PR11MB3087.namprd11.prod.outlook.com> <CAOdDvNruDZuBYp2ABfWCKMF4o6rY5Qk6x6ofH1qCJgLfKpsCUg@mail.gmail.com> <65CD80F2-11BF-4D48-A011-17F6E431D209@ericsson.com>
In-Reply-To: <65CD80F2-11BF-4D48-A011-17F6E431D209@ericsson.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 22 Jan 2020 16:56:19 +0000
Message-ID: <CALGR9obxq-XxzNwTi_UAXZSq61=R_g4D+jrD-2V-PVix_t7Pig@mail.gmail.com>
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, "masque@ietf.org" <masque@ietf.org>, "quic@ietf.org" <quic@ietf.org>, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>, "Su, Chi-Jiun" <Chi-Jiun.Su@hughes.com>
Content-Type: multipart/alternative; boundary="000000000000f235f3059cbd677c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/H4sklPVrbyBCDN987hZ_gMJu4qo>
Subject: Re: [Masque] FW: New Version Notification for draft-kuehlewind-quic-proxy-discovery-00.txt
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2020 16:56:35 -0000

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.

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.

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.

Cheers
Lucas

On Wed, Jan 22, 2020 at 1:54 PM Mirja Kuehlewind <
mirja.kuehlewind@ericsson.com> 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 <masque-bounces@ietf.org> on behalf of Patrick McManus <
> mcmanus@ducksong.com>
> *Date: *Tuesday, 5. November 2019 at 22:37
> *To: *"Su, Chi-Jiun" <Chi-Jiun.Su@hughes.com>
> *Cc: *"masque@ietf.org" <masque@ietf.org>rg>, "quic@ietf.org" <quic@ietf.org>rg>,
> Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>om>, Zaheduzzaman Sarker <
> zaheduzzaman.sarker@ericsson.com>gt;, Lucas Pardue <
> lucaspardue.24.7@gmail.com>
> *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 <Chi-Jiun.Su@hughes.com>
> 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 <masque-bounces@ietf.org> *On Behalf Of *Lucas Pardue
> *Sent:* Monday, November 4, 2019 12:16 PM
> *To:* Mirja Kuehlewind <mirja.kuehlewind@ericsson.com
> <mirja.kuehlewind@ericsson..com>>
> *Cc:* quic@ietf.org; Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>om>;
> masque@ietf.org
> *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 <
> mirja.kuehlewind@ericsson.com> 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 <lucaspardue.24..7@gmail.com
> <lucaspardue.24.7@gmail.com>>
> *Date: *Monday, 4. November 2019 at 18:06
> *To: *Mirja Kuehlewind <mirja.kuehlewind@ericsson.com
> <mirja.kuehlewind@ericsson...com>>
> *Cc: *"quic@ietf.org" <quic@ietf.org>rg>, "masque@ietf.org" <masque@ietf.org>rg>,
> Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
> *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=
> 40ericsson.com@dmarc.ietf.org> 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, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> 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
> Masque@ietf.org
> 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
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>
>