IETF Logo Mail Archive

Re: [Masque] QUIC proxy scenarios

David Schinazi <dschinazi.ietf@gmail.com> Tue, 21 May 2019 10:59 UTC

Return-Path: <dschinazi.ietf@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 4F25F1200D7 for <masque@ietfa.amsl.com>; Tue, 21 May 2019 03:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 mt_onWlsdMOr for <masque@ietfa.amsl.com>; Tue, 21 May 2019 03:59:32 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 2CAE2120048 for <masque@ietf.org>; Tue, 21 May 2019 03:59:32 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id q62so5933424ljq.7 for <masque@ietf.org>; Tue, 21 May 2019 03:59:32 -0700 (PDT)
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=kxv5s8qSgcYgXBohTAU4Z1PLbjFPW+RCF0mgGkcTtBM=; b=WKYrOP09VxzUx4O4kh2ZTarz6s8YOMlZXe7VWkiYc+9RPxeQB7LkkGdvjYBsORG0RZ VhV1erTd0SmerJZ8KJJxJ2QI4pHjYEe1ZxS9/nEy7Wh5JljWAs2vCRdvtepR6bKSJwPM b4BwP/ks9SzJi6aaL1K7YrdWi51iqmJCymDNIHpAePYGhb8mwLaaVLKfSlwZkV8coHCL PMV2PAY1y7GyI633um4yQOey2/eq67X9S/GH3ibm6zfhfcvWXVidenMAXt6l6eF8TMPX t0Bx/A7ls0z9keEUAtsLZLqM4SVs0oW0FK/QVMWzg7NvFe31YSYRP+5MoHXoK/E7beVG Rtsg==
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=kxv5s8qSgcYgXBohTAU4Z1PLbjFPW+RCF0mgGkcTtBM=; b=qWcj32/Dr4DQ5Gt4SLyJnigyU4cvwKAIp4qYlrxu9xpre7q+EzvN5PpaiUUQOAdREI 8WKTiwXa+yJ84+P83uCaB2RoouykXzruFq4dAqsxqoecuMFzeHaWsYVaHRe3JQqR1OUc kl2WD0P4RPDWvs7FS64L5S+fNe+QdqOfp1XrAu2ctSfhN7gmH3AfPyj7RZv5c9iyYYFg OOk7UERTZTajgFg7zxBfNRVshatOH9jxX95tGH6K3VrRoz7f9C1Uve7Val5J3ovl7gqK HWVp5wdSF89dhwNJ6FajOiw4b5wCXhBFmeouEM+sWlMbvHqQi50zmiBs0VS7yynoksFN gnkg==
X-Gm-Message-State: APjAAAU/xOTaw6B0kpzwrz+4g+Q9U4jmxJoCHyIK3Pi4XhGaF5qE8uqq 2EWDZk8w5n2BLWfk/FO7PKQGipDjWCOk4B/HU0a8d4ER
X-Google-Smtp-Source: APXvYqy6RBSCSNXa3ojQ3UgCSSa+Fdb/DH/Xv8bxFfeaJswe9yhf3/N0GW+SGskiR6vcsik6rllO3iaSfQQIWXIoEQI=
X-Received: by 2002:a2e:2f03:: with SMTP id v3mr3053176ljv.6.1558436370388; Tue, 21 May 2019 03:59:30 -0700 (PDT)
MIME-Version: 1.0
References: <273b9eaf-5d9d-949f-7d43-95293248f43f@huitema.net>
In-Reply-To: <273b9eaf-5d9d-949f-7d43-95293248f43f@huitema.net>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Tue, 21 May 2019 11:59:19 +0100
Message-ID: <CAPDSy+5neR6j7VCeXs=uqTWDP8EwmFGjW4DCw3t3b8tFMp7AdA@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: masque@ietf.org
Content-Type: multipart/alternative; boundary="000000000000431982058963be43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/nNrGHwL14FgK72FZAPQoNKX5rlo>
Subject: Re: [Masque] QUIC proxy scenarios
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: Tue, 21 May 2019 10:59:35 -0000

Hi Christian,

These are definitely interesting use-cases, and I think the draft could use
more text to that extent.

A pull request would be most welcome!
https://github.com/DavidSchinazi/masque-drafts

In the Home Server Scenario, can you elaborate on who the
client/server/proxy is? Is the goal to access home services from anywhere
in the Internet?

David

On Tue, May 21, 2019 at 10:04 AM Christian Huitema <huitema@huitema.net>
wrote:

> During the first day of the QUIC interop in London, we discussed the
> scenarios for a QUIC proxy. This is what I am looking at:
>
>
> # Scenarios
>
> ## Home Server Scenario
>
> Home server establishes QUIC connection with proxy server "in the
> cloud", publishes name in DNS with address of cloud server.
> Client sends QUIC messages to proxy.
> Proxy recognizes the SNI in Initial packets, or the Destination CID in
> handhsake and short packets.
> Proxy forwards packets to QUIC server as "datagram".
> Home server treat packets as if received on UDP socket.
> Home server forwards packets to proxy as datagram.
> Proxy relays QUIC packets to the client.
>
> Optional: QUIC server may use the "preferred address" mechanism to
> suggest migration to a direct connection, bypassing the proxy.
> Optional: local clients may discover the local server, without using the
> proxy.
>
> ## Hidden client scenario
>
> Client establishes connection with proxy. Sends QUIC messages to proxy
> as datagrams.
> Proxy decapsulates the messages, sends them to destination server.
> Destination server replies to proxy.
> Proxy examines CID, determines which client it belongs to, forwards QUIC
> messages as Datagrams to appropriate destination.
>
> ## Onion scenario
>
> Client establishes connection to proxy, then through that to another,
> etc. This creates a tree of proxies rooted at the client.
> QUIC connections are mapped to a specific branch of the tree.
>
> Hidden server can similarly hide between several layers of proxy. Hidden
> servers should not publish their address in the DNS.
> May use an Onion DHT service instead (see Tor ".onion"), or in fact any
> other mechanism. This is out of scope in this spec.
>
> -- Christian Huitema
>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>

v2.23.0 | Report a Bug | By Email