From nobody Mon Nov 1 23:25:14 2021 Return-Path: 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 DA21D3A0B67 for ; Mon, 1 Nov 2021 23:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ZMFYkfqN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J1yIRbG4 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 9gKf_UqK7ayG for ; Mon, 1 Nov 2021 23:25:08 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167043A0B58 for ; Mon, 1 Nov 2021 23:25:07 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 1B2E85C0182 for ; Tue, 2 Nov 2021 02:25:06 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Tue, 02 Nov 2021 02:25:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm3; bh=LJgnIy5MwPj8TBF+eSG/gWZmkwEoczfpIkpJwr7xMrE=; b=ZMFYkfqN p0sn1ZOVG5x6/2cYNwjNA4vr7i0oWafOvE5kH+dXCnD/bGlX8QYlJpSBGiSi4tnW DtC17NXjRz3O5y8X1ziv98UUFj4QMK10NQo3dZUSaV/lEvzclc9MzoVw/3lZl+S2 /q85X5hJvAI7AI7Z3UmEhMdb8GsDxSZm7DT8l/iTs+QjDsIOGGNYy+WNUbEnMHIa 622xy0nIVoHd1Mct27rDF3FWrDkLx3M3AbNuL8M5tlN8VKOy+yrTJQuGJR7hTizB 2WjBm7g3KRe6DlqbCiYCtNhWH9ukiEJd2Hy3dITE8rvRZzZuZlIT5iwErx0T/aW2 RjqOklD/zM+I7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=LJgnIy5MwPj8TBF+eSG/gWZmkwEoc zfpIkpJwr7xMrE=; b=J1yIRbG4K/M6z0rEWtR/vMKXpnr6IEng6/jKQk4yLzLCK zO+igwcRSYtFuKO54F9FeiNUCkh87kTKVahp+KIZDMoHVOtF320pcggO7d5nY/CS 8SaWgr1huOzb2K8sCNqbJYY4q5hRi/+OZD32+T0fb2mH3aS1M5X1KcMWmTvFtCeE LBaNRP19XvzbnNSHmuSdQfF/s6w24mnJyb6gd9USwQJwNtjlEX1lO5sSY920b62e gjp+Q8EyPVnwzCpnteKqr4HUojdwI5xy6M4mF2vyqww61U6g3+KBl41nU3MF1p6A Cl1B6GQZdT/Ol1uc9naeEcTQPnN7eoxbN0DsJUzLA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdehgedgkeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeevgfdutdfgjeefudeuheekhe ekudeugeehfeegveekkeegleevveffueduffehheenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BD1F13C044D; Tue, 2 Nov 2021 02:25:05 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1369-gd055fb5e7c-fm-20211018.002-gd055fb5e Mime-Version: 1.0 Message-Id: <85634900-dbbc-497a-aa97-cd6b29b4cc73@www.fastmail.com> Date: Tue, 02 Nov 2021 17:24:40 +1100 From: "Martin Thomson" To: masque@ietf.org Content-Type: text/plain Archived-At: Subject: [Masque] Capsules X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 06:25:13 -0000 I've just reacquainted myself with the ever-shifting content of draft-ietf-masque-h3-datagram (-05 specifically). My conclusion: this document is about 10x longer and more complex than it needs to be and maybe three or four times more complex than it could be if you accept some of the underlying assumptions. --- The source of this added complexity is a desire to construct an abstract framework that allows intermediaries to participate in the protocols that this document attempts to facilitate. The key functional role for an intermediary here is for it to take datagrams and forward them in a way that best suits the HTTP version in use, allowing the same datagram to traverse different versions. Forwarding in HTTP/3 wants to use native DATAGRAM frames, whereas fowarding elsewhere needs to use the stream established by extended CONNECT. The goal in creating a generic framework was to enable some common handling between different protocols (UDP proxying, IP proxying, WebTransport). This is a bit of narrow use case. An intermediary that understands that a capsule-based protocol can take datagrams from a stream of capsules and send them in DATAGRAM frames. In the opposite direction, they can fold DATAGRAM frames into streams. This forwarding behaviour depends on the intermediary understanding that the protocol in use is a capsule-based protocol. This is done by looking at the :protocol pseudo header field on the extended CONNECT and looking that up in a list of known capsule-based protocols. This is necessary because not all protocols that use extended CONNECT use capsules. After all, the only use of extended CONNECT that currently exists, websockets, doesn't. That's not so far removed from a system where the intermediary understands the contents of different CONNECT-based protocols that do not share a framework. It is possible to have different protocols that use extended CONNECT with shared design elements that maximize code reuse at intermediaries WITHOUT a framework like this. Those protocols can all use the same format, name, and registry if that helps maximize code reuse. At that point that is functionally indistinguishable from the system that uses a framework. >From this perspective, a framework like this becomes something of an academic exercise. A lot of work is done to document the framework and describe its properties, but as the effect on deployed code is non-existent, it has no real effect on what people do. And it comes with risks, like leading people who build intermediaries to start making bad assumptions about how extended CONNECT works generally. The editors of the WebTransport over HTTP/2 draft are currently debating whether to propose the use of capsules there. There, we have some interesting design constraints that might be cause to use a different format. One option that is being considered is reusing design elements from QUIC to make the protocol easier to implement. I don't think that we should feel constrained to use capsules, except to the extent that it might be nice to make implementation in intermediaries easier. --- I'd like to propose a different approach: 1. When datagram support is negotiated at the QUIC transport layer, HTTP uses datagrams by associating them with request streams. This uses the system described in the draft (prepending the stream id divided by four). 2. Different uses of datagrams need to be individually negotiated using settings. (WebTransport negotiates use of both datagrams and extended CONNECT with a single setting.) 3. Each of the protocols we have describe the use of capsules. Separately. That's it. It's perhaps a shade minimal, but it is sufficient. I can see the advantage of a shared registry for capsule types. That has some real advantages in terms of code reuse. This document might be a good home for doing a little unification of the clerical stuff. I'm OK with doing that (this is the 10x saving -> 3x saving I alluded to), but it does not need the supporting machinery in the current draft. It just needs to make a registry, describe the generic capsule format and define the DATAGRAM capsule and forwarding rules for that capsule. The rules that talk about opaque capsules and whatnot is unnecessary. --- This would mean losing all the text about datagram contexts with their format types. I can't see any justification for a generic framework for those functions. I can see protocols in which these might be useful constructs. However, use of those constructs would benefits from closer tuning of the mechanisms to the problem domain, something that a framework cannot do. draft-schwartz-masque-h3-datagram-ping proposes using the format type to create a separation between that and "other" uses of datagrams. It's important to note that identical treatment at intermediaries is a necessary feature for that draft, but I don't think that is necessary. It also depends on datagram contexts being used, which is a big assumption as they are effectively pointless for many protocols. WebTransport doesn't seem inclined to want them. Should WebTransport want this, it has to pay a pretty high price (>=1 byte on every datagram sent), but that should be something that protocol decides. Maybe that protocol can come up with a better means of distinguishing datagrams that results in less overhead. Earlier, it was suggested that datagram contexts might be used for ECN signaling. At the time, it seemed clever. But now I realize that it is more like one-step forward, four-steps backwards compression. --- Sorry for the long missive. I hope that I was able to capture the rationale so we can discuss this next week in more detail. Regards, Martin From nobody Tue Nov 2 08:20:52 2021 Return-Path: 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 12B1F3A03EF for ; Tue, 2 Nov 2021 08:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 W8-M3h8T4Zz0 for ; Tue, 2 Nov 2021 08:20:46 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 5D6063A033F for ; Tue, 2 Nov 2021 08:20:46 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id o26so38612472uab.5 for ; Tue, 02 Nov 2021 08:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iH4Y9+fxUiryxFEJBsk9g3JCWTlqImUSp+HmqE8qHX0=; b=TLwTp2Sfcw5Jw2EP6fq2XjkwYWklkoWl/FSu2ONEpQjeV2VWWKDVYQaaTZ6mGd0JYL Fd9da7iTXSk2lWw729ZFnfOYPaZCu2zkiN+NBFcoZxFZ9kWe+oTkVn7Dr0EZuXvJl3CM UNBP/048Om+e+imLnKU8RD0X3fm82x3a0KDhxiQfrQYmeFm+i6v1WnEr6pki2MD4Fri3 lUDewPZ0vikThcQL0PW+WGVmH+NZl9/zqoel6/8w+jdNkresC9huXRa02rhaDJAGeaeq UAu2L7UGPdvF9Cf6wQ5eSyylbm6zxPKTwRqJkJNU2D9QM7dCPwahuwH9kpfsFfzrFoZX Sf/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iH4Y9+fxUiryxFEJBsk9g3JCWTlqImUSp+HmqE8qHX0=; b=YJjeK9m2U6wVuvYxQ8msYt3jd1uwSHeF21Mul5heWCe4mGieanxSyfn960Jy3zrWum u+1pVtSVmCwv/gvE2HPIJy2atPJ2ELhYwK25Gj9r2Gyq/Ph6W5lUSM17DhVt9A4V4dtK u+5TdcAUHk015J4yW6JCownVEaJZuYpem6mSU5dN4/7CgsH50/axqBLDwne+qPHvgehB xQYJVxvzMwqiWCuhgSRbmmPsH8JQgT6+1T4mq1TFk3IksglmOuA1IEm2PCr2FcsAHa7b WmMAR0tTpFfUimOMJxj/8zHG4XCJ0ixMjTApzkgfvOdUDdvsB0yGzX5Jav7P0OgGi0Tx lWZA== X-Gm-Message-State: AOAM53193bPn4TI7xH6tZEMs8R4WSaWWbAlO/JKFP95Nb+Tfj/XypGu4 8XPs5J2kGR8ri0tUmszFa9gNtXGJPhS6D7wCfnbUwwGHdx8= X-Google-Smtp-Source: ABdhPJzjosCmKke0led5e5K4Vze4V5RD6jIC//IdtyOrM+CsegfwNXewmBNYktCfCJ5cOmBMxuwtiAGzBr5l3br7KX0= X-Received: by 2002:a67:ca1c:: with SMTP id z28mr41074327vsk.11.1635866441868; Tue, 02 Nov 2021 08:20:41 -0700 (PDT) MIME-Version: 1.0 References: <85634900-dbbc-497a-aa97-cd6b29b4cc73@www.fastmail.com> In-Reply-To: <85634900-dbbc-497a-aa97-cd6b29b4cc73@www.fastmail.com> From: Ben Schwartz Date: Tue, 2 Nov 2021 11:20:30 -0400 Message-ID: To: Martin Thomson Cc: masque@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000031ea5e05cfcfd6df" Archived-At: Subject: Re: [Masque] Capsules X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 15:20:51 -0000 --00000000000031ea5e05cfcfd6df Content-Type: multipart/alternative; boundary="0000000000002b5ef005cfcfd638" --0000000000002b5ef005cfcfd638 Content-Type: text/plain; charset="UTF-8" It seems like a lot of these concerns are about document refactoring. For example, the special behaviors for HTTP 2<->3 intermediaries could be extracted into a separate document and described as an optimization, but that's not functionally different from the current text. However, you also identified some technical issues that we should explore. On Tue, Nov 2, 2021 at 2:25 AM Martin Thomson wrote: ... > This forwarding behaviour depends on the intermediary understanding that > the protocol in use is a capsule-based protocol. This is done by looking > at the :protocol pseudo header field on the extended CONNECT and looking > that up in a list of known capsule-based protocols. This is necessary > because not all protocols that use extended CONNECT use capsules. After > all, the only use of extended CONNECT that currently exists, websockets, > doesn't. > This is a good observation, and we can correct it. We can define an additional request header to indicate that the datagram+capsule system is in use (like the old Transfer-Encoding header), to decouple this from the :protocol. The editors of the WebTransport over HTTP/2 draft are currently debating > whether to propose the use of capsules there. There, we have some > interesting design constraints that might be cause to use a different > format. One option that is being considered is reusing design elements > from QUIC to make the protocol easier to implement. I don't think that we > should feel constrained to use capsules, except to the extent that it might > be nice to make implementation in intermediaries easier. > I think the purpose of a standards body is to avoid producing multiple similar but incompatible systems if it can be avoided. If WebTransport has additional requirements, MASQUE might be able to adopt a subset of its framing. --0000000000002b5ef005cfcfd638 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems like a lot of these concerns are about docum= ent refactoring.=C2=A0 For example, the special behaviors for HTTP 2<-&g= t;3 intermediaries could be extracted into a separate document and=C2=A0des= cribed as an optimization, but that's not functionally different from t= he current text.

However, you also identified some= technical issues that we should explore.

On Tue, Nov 2, 2021 at 2:25 AM Mar= tin Thomson <mt@lowentropy.net&= gt; wrote:
...
This forwarding behaviour depends= on the intermediary understanding that the protocol in use is a capsule-ba= sed protocol.=C2=A0 This is done by looking at the :protocol pseudo header = field on the extended CONNECT and looking that up in a list of known capsul= e-based protocols.=C2=A0 This is necessary because not all protocols that u= se extended CONNECT use capsules.=C2=A0 After all, the only use of extended= CONNECT that currently exists, websockets, doesn't.

This is a good observation, and we can correct it.=C2=A0 = We can define an additional request header to indicate that the datagram+ca= psule system=C2=A0is in use (like the old Transfer-Encoding header), to dec= ouple this from the :protocol.

The editors of the WebTransport over HTTP/2 draft= are currently debating whether to propose the use of capsules there.=C2=A0= There, we have some interesting design constraints that might be cause to = use a different format.=C2=A0 One option that is being considered is reusin= g design elements from QUIC to make the protocol easier to implement.=C2=A0= I don't think that we should feel constrained to use capsules, except = to the extent that it might be nice to make implementation in intermediarie= s easier.

I think the purpose of a stan= dards body is to avoid producing multiple similar but incompatible systems = if it can be avoided.=C2=A0 If WebTransport has additional requirements, MA= SQUE might be able to adopt a subset of its framing.
--0000000000002b5ef005cfcfd638-- --00000000000031ea5e05cfcfd6df Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAEPeo9/GxknaxVybmbU vmIwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMTEwMTgx MzI4MjFaFw0yMjA0MTYxMzI4MjFaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Og2McfM9XYxay9lQdacWd75OScDFx75 QNs68foESjDzjCyh2pg+v1chyqSuCIt/79bjwTJTFmaXKLgdbd51VD6v1gPRkO8YVHJ/YqXBSF1o 3YgiLMmt6fG4kjqcniKBxMiFXvt5tKbW16aM5Z1iAeegQWuotS2ejvCqcmx98l8dXJMaWTX0EJ7v vZeZn9plzQw3JTAeVUi4c4UtRIXPeC+CT8xzcFFmAYKGAsFuQEPISAwi60+ao7RuMhNAltVL7ZSG +/04uzRd7k2TWBJnp86zzg/y0XEwdNYWwV0oL4kNZPxcUXbxNXFB4v7reLZK5t+RJXFNCb1d7y+j 7k+keQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUzoIjhzUXsKy1 m4Ay0XMzONSDXt0wTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAKah4EqFB7nuTg1M3QGI963Z HaE551W8LWOHfTZf4zmOeoXCNoeyLN9D8qRz3+lHR8kME/T5q/F5KLThPCM4BTTzPGF59tMSebum Afvzbn1X8bFW4Q1boaF0HXKEHIZS3PHUBqH3Xbd6+hCb8hh2KRQl7iGxYJrAKQpTuC++Tw+rPGkl F6/NcliGHu2xiRBsyeDh1mkzZBAvugrisg0vnmuaWz/jxYVHgSK00NNiypuK/0Aggs95eeoB6m1R dZbXdPzEYrRk2o93YrZOi7Xabj7fBDk2VbMYyyqMbjalA5CDbxk4TK0OfXFE2sMEi8ojnONBpINK X9kRA5udV0GDqmoxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAEP eo9/GxknaxVybmbUvmIwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIKiY6Y67xJSM RHOsAo7QXUhRkzX+XIjchyBZTavS51nxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIxMTEwMjE1MjA0MlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQAicop+UPBT8nFD2Ya0Z+SoXP8Iojob gPPlIAzn1OoR4lzSonoQLUFU9rGQZfIQAEFizOBzZp/qTpeqy2ilZzJOyxy8E0jf9PZv/cGmIKFm JIVjDS2CLc9jxVwOX9rKv59FKxOS/SH6vJeIxpl0ajaIxoeqRlu6v0i6ifqGLQ5OZka8JXU1ShBN ePz1qAtxbNYRwPZWWqa6NizWSWzjPSlYWNiyIadSznASVRE3uLcn7Uj7dSPwtOtLzrghlfHPp05r NJvkCb1pERoi2i/eyq+uoHgw0OEYgscUYb1Juttp7e+nYrd6TE5xFSmtUGkD8JcyU1mQLaDb3gwR 4OcwqQkn --00000000000031ea5e05cfcfd6df-- From nobody Tue Nov 2 10:28:02 2021 Return-Path: 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 5812C3A08FE for ; Tue, 2 Nov 2021 10:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Nu80OgF2cOWf for ; Tue, 2 Nov 2021 10:27:56 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 9CD1C3A08FD for ; Tue, 2 Nov 2021 10:27:56 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id n8so6717047plf.4 for ; Tue, 02 Nov 2021 10:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=askOU1f9Ia01QGj4BWNC9JqgtjnJL6L+hJdfbt8lPWc=; b=E9SKR1U740Uq/A8P4MnOXvUISDK8mKOkoV0FiM6Gt35WXq0Ps5UkqcsqovUV12gtFx A2u2fvcgr9qh/Ypibk8GWuzarBJjQhIZhri5T46f8IP9uabiU4xd/fAYL6HDABIv0VRP iqjCVQs3LaCgAY1zBPa9k6VIfBrM+ZmkWA/fICChiLhBFeofPLG9Ti+of5yWNcBneFHU zv7Rv7F24lCL0bgIbMqVYvotMwduZEo+L+A8AQMteamhpYWlLUtPQB8FeK1UlCQJLGdd oYpIDUNLFxTG8/3sn6j5G5A6NYYHLtde5BA/62z/9pUi8mPKPOWDcpo6wW9XggvXJ2LK BD0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=askOU1f9Ia01QGj4BWNC9JqgtjnJL6L+hJdfbt8lPWc=; b=71EiyvYIOsle8jkN3rRHW7LH5b/aIj7TszvrnZ7JITCYi+ZGNSwn3TiCkuEPkE0aHK XxhS8TLRabY4EHPQZ6upG6xAbzaov3xUL6GhyvvTzCOBjGQBygZQfK6Yss7bvFbnacnh j7G91Dyms6I2rHF/qnrtiDp7l/5lDO/HFJ87yHV1UKSYX3bXZr6ueIE8CvzpCTZ79f9D jUo49Jq6o3jNvT1TbpeKBTwBQ10oMDNOGOaWHxQp/e880/klmkOAJHAQjQKBfor+WS7t MGQL2TZnFTrbVMAgOCLVktjkHIFv0TRzCm+z/rsj8VnxUm7zBqGGYACLoY1FzOMjUgtk ITFg== X-Gm-Message-State: AOAM531HNPh1fAzgpVq6TKActieypfhCK1wFnarUOgMcp0qcPKNzCmWb yhDNut3hDyxssP8pzDbW5YS6GxzUrzXIPL5TrKKHGtdB3UI= X-Google-Smtp-Source: ABdhPJy3eCSSameAdcBRakiSmyIqB67XC/+HmYgLKLOxSF1xl0eyWeU8WkhExyLYtUAjjEDmH3Fv4CxsMn6ib0aBr9E= X-Received: by 2002:a17:90b:388a:: with SMTP id mu10mr8185590pjb.221.1635874074243; Tue, 02 Nov 2021 10:27:54 -0700 (PDT) MIME-Version: 1.0 References: <85634900-dbbc-497a-aa97-cd6b29b4cc73@www.fastmail.com> In-Reply-To: <85634900-dbbc-497a-aa97-cd6b29b4cc73@www.fastmail.com> From: David Schinazi Date: Tue, 2 Nov 2021 10:27:42 -0700 Message-ID: To: Martin Thomson Cc: MASQUE Content-Type: multipart/alternative; boundary="00000000000017b43405cfd19db3" Archived-At: Subject: Re: [Masque] Capsules X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 17:28:01 -0000 --00000000000017b43405cfd19db3 Content-Type: text/plain; charset="UTF-8" Hi Martin, thanks for reading the latest draft. Responses inline. David On Mon, Nov 1, 2021 at 11:25 PM Martin Thomson wrote: > I've just reacquainted myself with the ever-shifting content of > draft-ietf-masque-h3-datagram (-05 specifically). > > My conclusion: this document is about 10x longer and more complex than it > needs to be and maybe three or four times more complex than it could be if > you accept some of the underlying assumptions. > > --- > The source of this added complexity is a desire to construct an abstract > framework that allows intermediaries to participate in the protocols that > this document attempts to facilitate. > Speaking for myself as co-author of the draft, constructing an abstract framework was never my desire. I care about the properties of the system we're building, not about abstract concepts. The key functional role for an intermediary here is for it to take > datagrams and forward them in a way that best suits the HTTP version in > use, allowing the same datagram to traverse different versions. Forwarding > in HTTP/3 wants to use native DATAGRAM frames, whereas fowarding elsewhere > needs to use the stream established by extended CONNECT. The goal in > creating a generic framework was to enable some common handling between > different protocols (UDP proxying, IP proxying, WebTransport). > Agreed. My implementation supports both WebTransport and CONNECT-UDP, and there's definitely value in reusing the code that sends and parses datagrams and capsules. This is a bit of narrow use case. An intermediary that understands that a > capsule-based protocol can take datagrams from a stream of capsules and > send them in DATAGRAM frames. In the opposite direction, they can fold > DATAGRAM frames into streams. > > This forwarding behaviour depends on the intermediary understanding that > the protocol in use is a capsule-based protocol. This is done by looking > at the :protocol pseudo header field on the extended CONNECT and looking > that up in a list of known capsule-based protocols. This is necessary > because not all protocols that use extended CONNECT use capsules. After > all, the only use of extended CONNECT that currently exists, websockets, > doesn't. > > That's not so far removed from a system where the intermediary understands > the contents of different CONNECT-based protocols that do not share a > framework. It is possible to have different protocols that use extended > CONNECT with shared design elements that maximize code reuse at > intermediaries WITHOUT a framework like this. Those protocols can all use > the same format, name, and registry if that helps maximize code reuse. At > that point that is functionally indistinguishable from the system that uses > a framework. > I'm confused here. In order to reuse code, it makes sense for multiple protocols to share the capsule TLV wire format and the IANA capsule type registry. Since protocols will share the IANA registry, you need to define it in this doc. At that point it makes sense to also define the capsule TLV format here as well since we see value in reusing it. Copy-pasting the TLV format in every protocol document doesn't help us. If you don't like the word "framework", then don't use that word? draft-ietf-masque-h3-datagram-05 doesn't contain the word framework, because it doesn't attempt to create a framework. Only to define pieces that can be reused. >From this perspective, a framework like this becomes something of an > academic exercise. A lot of work is done to document the framework and > describe its properties, but as the effect on deployed code is > non-existent, it has no real effect on what people do. And it comes with > risks, like leading people who build intermediaries to start making bad > assumptions about how extended CONNECT works generally. > I fully agree with you that we would get the exact same software if we took some parts out of this document and copied them verbatim into every protocol that uses datagrams. I don't see that as helpful though. The editors of the WebTransport over HTTP/2 draft are currently debating > whether to propose the use of capsules there. There, we have some > interesting design constraints that might be cause to use a different > format. One option that is being considered is reusing design elements > from QUIC to make the protocol easier to implement. I don't think that we > should feel constrained to use capsules, except to the extent that it might > be nice to make implementation in intermediaries easier. > You shouldn't feel constrained to use capsules, you should only use them if they provide value. Out of curiosity: what are the design constraints that would steer you to a different protocol? --- > I'd like to propose a different approach: > > 1. When datagram support is negotiated at the QUIC transport layer, HTTP > uses datagrams by associating them with request streams. This uses the > system described in the draft (prepending the stream id divided by four). > > 2. Different uses of datagrams need to be individually negotiated using > settings. (WebTransport negotiates use of both datagrams and extended > CONNECT with a single setting.) > What does "different uses of datagrams" mean? If one of my backends supports CONNECT-UDP, why do I need a SETTING on the client-frontend leg? 3. Each of the protocols we have describe the use of capsules. Separately. > This is just moving rocks, and increases the total number of lines of spec written. What's the benefit of copy-pasting something in multiple documents if they all depend on a common draft? That's it. It's perhaps a shade minimal, but it is sufficient. > > I can see the advantage of a shared registry for capsule types. That has > some real advantages in terms of code reuse. This document might be a good > home for doing a little unification of the clerical stuff. I'm OK with > doing that (this is the 10x saving -> 3x saving I alluded to), but it does > not need the supporting machinery in the current draft. It just needs to > make a registry, describe the generic capsule format and define the > DATAGRAM capsule and forwarding rules for that capsule. The rules that > talk about opaque capsules and whatnot is unnecessary. > The introduction of opaque and transparent capsules was done as an editorial clarification to help readers understand the concept of capsules. We can remove those terms, but we still need the concept of injecting a datagram into the stream when going from h3 to h2. --- > This would mean losing all the text about datagram contexts with their > format types. I can't see any justification for a generic framework for > those functions. I can see protocols in which these might be useful > constructs. However, use of those constructs would benefits from closer > tuning of the mechanisms to the problem domain, something that a framework > cannot do. > > draft-schwartz-masque-h3-datagram-ping proposes using the format type to > create a separation between that and "other" uses of datagrams. It's > important to note that identical treatment at intermediaries is a necessary > feature for that draft, but I don't think that is necessary. It also > depends on datagram contexts being used, which is a big assumption as they > are effectively pointless for many protocols. WebTransport doesn't seem > inclined to want them. Should WebTransport want this, it has to pay a > pretty high price (>=1 byte on every datagram sent), but that should be > something that protocol decides. Maybe that protocol can come up with a > better means of distinguishing datagrams that results in less overhead. > I think the value here is the definition of extensions that work across multiple protocols. draft-schwartz-masque-h3-datagram-ping is a perfect example of that: there's been discussion in WebTransport of adding a JavaScript API at some later date that would tell the JavaScript what the datagram MTU is. Having this MTU information would also be useful for CONNECT-UDP and CONNECT-IP. What you're suggesting is that every single protocol redefines this. That's not reducing any complexity, just kicking the can down the road. Earlier, it was suggested that datagram contexts might be used for ECN > signaling. At the time, it seemed clever. But now I realize that it is > more like one-step forward, four-steps backwards compression. > > --- > Sorry for the long missive. I hope that I was able to capture the > rationale so we can discuss this next week in more detail. > Can you clarify what your goal is? It sounds like you would prefer for this document to be shorter. I agree with that goal, but it shouldn't be done in a vacuum - we should look at the total length of the MASQUE/WebTransport documents. Regards, > Martin > > -- > Masque mailing list > Masque@ietf.org > https://www.ietf.org/mailman/listinfo/masque > --00000000000017b43405cfd19db3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin, thanks for reading the latest = draft. Responses inline.

David

On Mon, Nov 1, 2021 = at 11:25 PM Martin Thomson <mt@lowe= ntropy.net> wrote:
I've just reacquainted myself with the ever-shifting content= of draft-ietf-masque-h3-datagram (-05 specifically).

My conclusion: this document is about 10x longer and more complex than it n= eeds to be and maybe three or four times more complex than it could be if y= ou accept some of the underlying assumptions.

---
The source of this added complexity is a desire to construct an abstract fr= amework that allows intermediaries to participate in the protocols that thi= s document attempts to facilitate.

Spea= king for myself as co-author of the draft, constructing an abstract framewo= rk was never my desire. I care about the properties of the system we're= building, not about abstract concepts.

The key functional role for an intermediary here is for it to take datagram= s and forward them in a way that best suits the HTTP version in use, allowi= ng the same datagram to traverse different versions.=C2=A0 Forwarding in HT= TP/3 wants to use native DATAGRAM frames, whereas fowarding elsewhere needs= to use the stream established by extended CONNECT.=C2=A0 The goal in creat= ing a generic framework was to enable some common handling between differen= t protocols (UDP proxying, IP proxying, WebTransport).

Agreed. My implementation supports both WebTransport and CO= NNECT-UDP, and there's definitely value in reusing the code that sends = and parses datagrams and capsules.

This is a bit of narrow use case.=C2=A0 =C2=A0An intermediary that understa= nds that a capsule-based protocol can take datagrams from a stream of capsu= les and send them in DATAGRAM frames.=C2=A0 In the opposite direction, they= can fold DATAGRAM frames into streams.

This forwarding behaviour depends on the intermediary understanding that th= e protocol in use is a capsule-based protocol.=C2=A0 This is done by lookin= g at the :protocol pseudo header field on the extended CONNECT and looking = that up in a list of known capsule-based protocols.=C2=A0 This is necessary= because not all protocols that use extended CONNECT use capsules.=C2=A0 Af= ter all, the only use of extended CONNECT that currently exists, websockets= , doesn't.

That's not so far removed from a system where the intermediary understa= nds the contents of different CONNECT-based protocols that do not share a f= ramework.=C2=A0 It is possible to have different protocols that use extende= d CONNECT with shared design elements that maximize code reuse at intermedi= aries WITHOUT a framework like this.=C2=A0 Those protocols can all use the = same format, name, and registry if that helps maximize code reuse.=C2=A0 At= that point that is functionally indistinguishable from the system that use= s a framework.

I'm confused here. I= n order to reuse code, it makes sense for multiple protocols to share the c= apsule TLV wire format and the IANA capsule type registry. Since protocols = will share the IANA registry, you need to define it in this doc. At that po= int it makes sense to also define the capsule TLV format here as well since= we see value in reusing it. Copy-pasting the TLV format in every protocol = document doesn't help us. If you don't like the word "framewor= k", then don't use that word? draft-ietf-masque-h3-datagram-05 doe= sn't contain the word framework, because it doesn't attempt to crea= te a framework. Only to define pieces that can be reused.

>From this perspective, a framework like this becomes something of an ac= ademic exercise.=C2=A0 A lot of work is done to document the framework and = describe its properties, but as the effect on deployed code is non-existent= , it has no real effect on what people do.=C2=A0 And it comes with risks, l= ike leading people who build intermediaries to start making bad assumptions= about how extended CONNECT works generally.

I fully agree with you that we would get the exact same software if w= e took some parts out of this document and copied them verbatim into every = protocol that uses datagrams. I don't see that as helpful though.
=

The editors of the WebTransport over HTTP/2 draft are currently debating wh= ether to propose the use of capsules there.=C2=A0 There, we have some inter= esting design constraints that might be cause to use a different format.=C2= =A0 One option that is being considered is reusing design elements from QUI= C to make the protocol easier to implement.=C2=A0 I don't think that we= should feel constrained to use capsules, except to the extent that it migh= t be nice to make implementation in intermediaries easier.
=

You shouldn't feel constrained to use capsules, you= should only use them if they provide value. Out of curiosity: what are the= design constraints that would steer you to a different protocol?

---
I'd like to propose a different approach:

1. When datagram support is negotiated at the QUIC transport layer, HTTP us= es datagrams by associating them with request streams.=C2=A0 This uses the = system described in the draft (prepending the stream id divided by four).
2. Different uses of datagrams need to be individually negotiated using set= tings.=C2=A0 (WebTransport negotiates use of both datagrams and extended CO= NNECT with a single setting.)

What does= "different uses of datagrams" mean? If one of my backends suppor= ts CONNECT-UDP, why do I need a SETTING on the client-frontend leg?

3. Each of the protocols we have describe the use of capsules.=C2=A0 Separa= tely.

This is just moving rocks, and in= creases the total number of lines of spec written. What's the benefit o= f copy-pasting something in multiple documents if they all depend on a comm= on draft?

That's it.=C2=A0 It's perhaps a shade minimal, but it is sufficient= .

I can see the advantage of a shared registry for capsule types.=C2=A0 That = has some real advantages in terms of code reuse.=C2=A0 This document might = be a good home for doing a little unification of the clerical stuff.=C2=A0 = I'm OK with doing that (this is the 10x saving -> 3x saving I allude= d to), but it does not need the supporting machinery in the current draft.= =C2=A0 It just needs to make a registry, describe the generic capsule forma= t and define the DATAGRAM capsule and forwarding rules for that capsule.=C2= =A0 The rules that talk about opaque capsules and whatnot is unnecessary.

The introduction of opaque and transpare= nt capsules was done as an editorial clarification to help readers understa= nd the concept of capsules. We can remove those terms, but we still need th= e concept of injecting a datagram into the stream when going from h3 to h2.=

---
This would mean losing all the text about datagram contexts with their form= at types.=C2=A0 I can't see any justification for a generic framework f= or those functions.=C2=A0 I can see protocols in which these might be usefu= l constructs.=C2=A0 However, use of those constructs would benefits from cl= oser tuning of the mechanisms to the problem domain, something that a frame= work cannot do.

draft-schwartz-masque-h3-datagram-ping proposes using the format type to cr= eate a separation between that and "other" uses of datagrams.=C2= =A0 It's important to note that identical treatment at intermediaries i= s a necessary feature for that draft, but I don't think that is necessa= ry.=C2=A0 It also depends on datagram contexts being used, which is a big a= ssumption as they are effectively pointless for many protocols.=C2=A0 WebTr= ansport doesn't seem inclined to want them.=C2=A0 Should WebTransport w= ant this, it has to pay a pretty high price (>=3D1 byte on every datagra= m sent), but that should be something that protocol decides.=C2=A0 Maybe th= at protocol can come up with a better means of distinguishing datagrams tha= t results in less overhead.

I think the= value here is the definition of extensions that work across multiple proto= cols.=C2=A0draft-schwartz-masque-h3-datagram-ping is a perfect example of t= hat: there's been discussion in WebTransport of adding a JavaScript API= at some later date that would tell the JavaScript what the datagram MTU is= . Having this MTU information would also be useful for CONNECT-UDP and CONN= ECT-IP. What you're suggesting is that every single protocol redefines = this. That's not reducing any complexity, just kicking the can down the= road.

Regards,
Martin

--
Masque mailing list
Masque@ietf.org https://www.ietf.org/mailman/listinfo/masque
--00000000000017b43405cfd19db3-- From nobody Tue Nov 2 12:45:32 2021 Return-Path: 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 8548E3A085B for ; Tue, 2 Nov 2021 12:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=pmf74+UK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IRpCOFng 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 RLN7RH7pG7bb for ; Tue, 2 Nov 2021 12:45:24 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC923A085A for ; Tue, 2 Nov 2021 12:45:24 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 1A53F5C0145 for ; Tue, 2 Nov 2021 15:45:24 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Tue, 02 Nov 2021 15:45:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=zGv69jMni8CnNlg1kSJYQw47kxEmO4iSYl4mTebH/Q8=; b=pmf74+UK GL3hJlpQwsJs4FbIJeMcx4FVDWTDx+DK/8tB7K2ue/EaECFWvy4h3ezMmHkptT2E m6Bb2SIOclm96nVZdk3PGM1oX04FSx/A9jCMdqszdveemt5wnSYDWo2+MDLaUI+7 Dx4cJoqy3TrkgSDlPShAiid1HcJlDjXO1sDE7rlOpuZ9JwUwsDPLEo4k/FdvoLXn CiQQmOxOMNFTpm/xuTxcI2/nK039XxUAxQWoWkLXhX+WsYps/nP2VICpu5WqADfI U4k5Y1yg+7SE5GUIqZu6Mjqi2xx0LGy8Cj0tQzzr7ZBo1PibLjWegARWP2dXojrx IiuMgS6udhfe4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=zGv69jMni8CnNlg1kSJYQw47kxEmO 4iSYl4mTebH/Q8=; b=IRpCOFngHGmziG9JvRVzywrSkZA3g5yc3Y/Iis57riKNO 4MBB1MSZtYeByN/OQjYvuCqZt20CaM4PkKw9AW44yUQp5Lw4J+MSEmTHncWvNSou WFLC/EIQ4Cv+/EN1BfeoipsczWywsVfCIUr9vSr+QcO3L/MaKa8rneJ/VYnt0h98 UUG82UjaqvGCzprAthDgkvkuuSkxe/JwLpsGpctgZfhrKP8GrUCpE5RJ+etLwnQ2 F/vnm8lNSkTvCpgP7xVH2SXDNfTLEQYOqM6GdE4GW+vyAjyKQ+prhk/YOWYZ+CQU v4c3ckfB8B5O+NVJd8kah5ixJOCm6ADCl3yY7nP1w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrtddtgddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehh vggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeekjeejleekfeelge dtveeiheekgedvhedvgeeivedtlefhvdfhjeffkeejffeuueenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DF9B53C0C77; Tue, 2 Nov 2021 15:45:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1369-gd055fb5e7c-fm-20211018.002-gd055fb5e Mime-Version: 1.0 Message-Id: Date: Tue, 02 Nov 2021 12:44:43 -0700 From: "Christopher Wood" To: masque@ietf.org Content-Type: text/plain Archived-At: Subject: [Masque] IETF 112 meeting X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 19:45:30 -0000 Hi folks, The agenda for next week's meeting is now online: https://datatracker.ietf.org/doc/agenda-112-masque/ We need a note taker and jabber scribe ahead of the meeting. Please let the chairs know if you're willing to volunteer for either role. Thanks, and see you (online) next week! Best, Chris and Eric From nobody Tue Nov 2 15:04:53 2021 Return-Path: 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 3FCED3A0DEB for ; Tue, 2 Nov 2021 15:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.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 B7v37Zo9Cp3f for ; Tue, 2 Nov 2021 15:04:46 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03C63A0DE6 for ; Tue, 2 Nov 2021 15:04:46 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.1.2/8.16.1.2) with SMTP id 1A2LbPTA020306; Tue, 2 Nov 2021 15:04:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=6tym9pJPBNbfO4l8/FaF5wQ7kmpp8bFsOTbHdXkKjas=; b=fWzVjXhguN0DF++0IczB3VxbKWJn9KD63mvJPbGC05/aOiImaZw1j12OqQBZTNe3xXhC SRLRFiUP07MnbeJL8JuuOYquyuThAH8F5BOsKL/uAELR4xR92UIuHzQJsCFt20fY8ZQq ZcRlLKLECJMXgYHa1ozJpAokvIIiVLLlHeM= Received: from maileast.thefacebook.com ([163.114.130.16]) by m0089730.ppops.net with ESMTP id 3c3ddbg79w-16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 02 Nov 2021 15:04:44 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.35.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Tue, 2 Nov 2021 15:04:43 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZHNmJJarEtn8s6YoN/Cgl7y5JYQ845pXVzKFLLQ5dS3FkKuOjbMFUgNKtTUHkDNG8szvRSMhbieHIIkbKspAzhg/WJMtJFXNKmxtI3XkYPlIjjJpHccX0rKhppVhQhTDDT6r72qBwyujLyuzfEC10P/LzR8Hf0RJFobS5vJouJJTE6mp4F3UFKV1g7EqjzFhQTuDUZvSpkRz/+X29h8aFClHqrDstw+HsE0sZZAloaVCNmJ3mlF+SLn4ItVjZpFjchiQotkIWP6CaS1MRGy4d57UP0Sx3QhShA1TyBbLp468Tz0vb41nyG52dNTdIIhRhanGFSOeYU6QRIXnslIlRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6tym9pJPBNbfO4l8/FaF5wQ7kmpp8bFsOTbHdXkKjas=; b=SXeyakT/P1/ys/QQ0UMG3Xtm9RDuqBoPbJlh4M8i6uS4gTyJ8WbN15QMIk+u44qrrQ2T70tD8x38xbS57ONkQuwap0wviOupRRIk5BrEf1bGm5H4OulYShmDePAubP3BZkzP0vfAk/0wAZU9DTX1CJfyvIClp7cDlvaSb5MI5LLZtn/nSKa7fLpGV+AyFfvuFW19m2rzv0RbATN0MBZOLK16i71chZiGmBsRp5zo072YtH/ZnapsQBCEGeXOpaCF2EfnN3OYddc+MW+ogd8EtxXp0MUYQnw2oHSd2EVs75j5uyeq0yuMcTHMDibLXh8LqdX3g4twqBlh6s7xDGERtg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none Received: from MW3PR15MB3772.namprd15.prod.outlook.com (2603:10b6:303:4c::14) by MW3PR15MB3753.namprd15.prod.outlook.com (2603:10b6:303:50::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.10; Tue, 2 Nov 2021 22:04:43 +0000 Received: from MW3PR15MB3772.namprd15.prod.outlook.com ([fe80::117f:de20:178d:93cd]) by MW3PR15MB3772.namprd15.prod.outlook.com ([fe80::117f:de20:178d:93cd%7]) with mapi id 15.20.4649.019; Tue, 2 Nov 2021 22:04:43 +0000 From: Alan Frindell To: David Schinazi , Martin Thomson CC: MASQUE Thread-Topic: [Masque] Capsules Thread-Index: AQHXz7JpvjBQrGjoPUayOLIdKsKiV6vwfnwA///YDAA= Date: Tue, 2 Nov 2021 22:04:43 +0000 Message-ID: References: <85634900-dbbc-497a-aa97-cd6b29b4cc73@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.53.21091200 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fb.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b332921-71bf-4043-1186-08d99e4cc674 x-ms-traffictypediagnostic: MW3PR15MB3753: x-microsoft-antispam-prvs: x-fb-source: Internal x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +JBoqgWWA/z4DHmDyQ5LWrmrT9qHTx2ITR5fgVW/sqa/sOuvmqAZg0yv1Ygv2wbHbsh6y01XPqWBYE+bPjTLM1N5+xTMOlG6fG9FmB++jXdv0e2JTbposGZzCqxgMHaW6xiXrC4Nb+E4F24zrWxkbaXHS3t4bRBdq2ebBKcdlzYepSR48bDaE/ObiWD2mPgIArdrvt2GHULTaRxiY62bn7DVxJ+N3gM4fwjPBARkie6cjxuTY5j0GxKpQXo9HMPt3lJvhCslLvYabPFJXSvFhaEhiFKCLO0d4FrhFPlFIZnNkpxJh8yBYVjYT2pcqC3fxCmEm09aLZoFXIaZn1gz/kABe6floOsZ1IFoczdBLs3gTk4a243/2d2ZEn3wIQs9d3YZ42xq6lw5pE+mthpXDVwO6DPoNzBqoaTgMJBO1AzEF1W2qSywcewbFkkeZ1JXGeAf049erds1eAij0ZFs8NQMUjW1zga+TFOLF3wVmBXMSvvEHqdUlbsD1CUiCzucStfHU8DHeitVClR0KSbTMrFGiEqB4tT7pSN1WbTF3qpyyiCFoWVUVAp2UQ/wznbAC7IQOcHB/K3cRf9r/LS5caCrME94kcVL4Njgl6DZPaa3y6NPeRFzTOwSaMokAlJC2KOnhb+m6kLWZ9iFoZMpuSruSuaK8IQ5l2AFmaDOclq0QzhPxHk2myUQ78L4SnXP663EaAvX7LlQ3Y9mTPEfBesfSj6mlA89vOQMWWEniLXRq9S4aOWhH4g2evvZUe/TfN7sybeTqo3kP8XMqylZKJ/XctaGowI1rXa3RLBgoiAmt+G7TGjv51D8uZSvUxMk x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR15MB3772.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(4326008)(508600001)(316002)(83380400001)(76116006)(110136005)(38070700005)(2616005)(8936002)(166002)(66946007)(6486002)(2906002)(86362001)(6512007)(8676002)(33656002)(71200400001)(966005)(64756008)(66556008)(66446008)(66476007)(5660300002)(6506007)(36756003)(122000001)(38100700002)(186003)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SUoyNFJLLzRpR3Q1UWE1cEV4MTdoWStoaDRjTzQxbWMrM1JHd040RmVoRjFx?= =?utf-8?B?S1hscXR4Ym1JQmRaM3hBZUpiYmVwbGJDOVFHTFdLUmhIaWZRVlFzZTBFOStn?= =?utf-8?B?cFJCcldNbFJEMFQ4dGVqbjRwQ2JQRHNQdVJWaTdzbXpXWm5vZTZwUDJjbXpa?= =?utf-8?B?a01zZng2NXNsbzc2dXpqSWtBQlhWWUhCSXB2cE8zbUtEWE1MQkVTcFZscUlw?= =?utf-8?B?S3BFZjNEL0JqekMzQkR4ckVXWlVSNUpjQ2o4ZnV6MWNEM3BJMmZwc2lhNFNP?= =?utf-8?B?UXVISWNaa1p0NzRLenRSRC9VQURKY2YvVUxUMnFXSGtva0xpb1A1S2Y4N0Nw?= =?utf-8?B?VnhTWWJ4UjF5dDdwRjZZSXd1L29VdUs4YW5yQ2xKSmFiVTV1V0E4dGxxN2x3?= =?utf-8?B?SjA4SEUxaDBnSEFLOVIrR0tSUlpvTzFDb1c3QXN6aWhmN1ErTlhhZXh3UGxM?= =?utf-8?B?MmdmUHRlSitsaUg0R0hFTDM3VE5ReGR4ZDdIdUZwdSswaU1DUlFkT0owOXlJ?= =?utf-8?B?K0s5T1lIR244UWdGMnhVYU9UbVBnWC9zQmkyREwvNXBIaENEWFdiTEt0OGly?= =?utf-8?B?ZjR4M1lhdHFieDdGbHV3ak13akhjUW1wWisyaE80YnV0QmdtMnZpRmZSb3dh?= =?utf-8?B?Vm9oUTB3aFJ5dGRJV3RlN25CODlEUnJUUmR3VnJSSkUrUXlvNWFzOHBnNGVu?= =?utf-8?B?SDlaQUZObjFZM3JYTWtiOTlUdXN1eXdSUkV4YXEzL05kMHkxNVFRK2dZUXNQ?= =?utf-8?B?MnhLTFZkVFpOSW03V0x5V0dCU283UFJoNEphaTRsNngyQmpiS3BucE4zNHVR?= =?utf-8?B?M09BK2JidVlMaUNKL2EwejU2YWtWZjhsVklaZkJDMUpDd1RraTFZVkI3dXJY?= =?utf-8?B?SC8wTFVTRVE5Uk95TEZ5czRmNjNETE5aVmVYMjVUell2R0xxcmZCR253OUQx?= =?utf-8?B?VmVNY3IzTkdISlF3bjlMWXNSbGlMenBIaHIyMXAyZUd2dVhkR0l3UEExb2Nu?= =?utf-8?B?dDEySzhleXNkNlVHakRPaFdCdHJlbjZ2VVN4Z1JSTUdrdS9LRGRiWUZTOXpm?= =?utf-8?B?MDBuZElxRW5yMjRrTmkwZGNxU1ROSEp3V09VeGlTUWwwejZpQlNPb1pzS20z?= =?utf-8?B?NGdUUkZwaUI1TVdkR1NXUmRHYmoyQkpqdDlEMVJHRW04a01EWXpIV05nZWJq?= =?utf-8?B?ZlcvWnVuK0pSZmhxU0Q0UFJMWjByem9LN0l2YmVXeEUwdUlLeHVuNlpGdUNw?= =?utf-8?B?c0c2REt0dHhrd0c0ZzNuR3ZMNkMzSGFiYUR4enJwMmUvUnpFRkIzNEp6ZGtr?= =?utf-8?B?a3Fwdm5iT3Zza2pKR3hjc2Rvb3N2QzBkdmhGSkZiWTNMWml0ekI5Qkp2LzVw?= =?utf-8?B?ZHZkWVN3anJmWXREK2VBb0ZvbGJueVU1aVRvK2VFMGlIeURYYnF4TE9hUWRX?= =?utf-8?B?R2VEa1l0NFMvWVdvajc3aFdvMXlKV1RDNGluSHF2RUVqa1o1dEpHbnA3Yk9i?= =?utf-8?B?WXVNTlMyelFqbnNSNVpwYmJLZnUrZkYxblZOaXg2K2IwTktRVXhPOHM3UlRF?= =?utf-8?B?QllzOEhpYUk4T0VtTWN5RWdNV05KaVQvelVlZW00bjE0T2w5dkwwTkE2VHYz?= =?utf-8?B?Um90a2JlUDJWVm16aVFKaE1ZNVRCSlRPSXFmVXdDWkhlVEQvOW9EOEVQQll6?= =?utf-8?B?dGtCaXM4VGFXUXNSalU0L3J3aFBkRGVPb0NWTUZwL2VjcjdmSmZOU2ZyK20x?= =?utf-8?B?VTRHOUJRSjd3cXFNanBVRUJLbms1azMxVU5tSUcxQW1wMnVSelJlM1FHSy9x?= =?utf-8?B?a2tvVnZseTRKMnE4aEpNUUlyZjJRdmFkajRKRWsrTWpIQVFJbDVLWFNmTktC?= =?utf-8?B?cGJOWXZmMzMxalFtSU0xY0IrVURzRExmTzJVMmFibExoMWk2cDFnU2lDVUNO?= =?utf-8?B?WnE0V3YwQnVLZWw4WW5lK1JuL3RkbSs5UU9tbjh1VWVJM0pLQTBPeVhNcXRa?= =?utf-8?B?cFlDVWFZYXZSeUZQUnlwSFhwR3VUUTNwbEdWdUxubUFIQ2s5UHNZa1B5M3lj?= =?utf-8?B?S251bXVRSUJYU3hNVEltamtZbFN3N3JZSVYvanlOVVpPQ1pseW82TXpLWXJn?= =?utf-8?B?UmxVbzdleWdMUkUra3poZmFKRmtIVHJ3MVQ4ZkR6MXdTTjdVaW1nKzlJbE05?= =?utf-8?B?dnc9PQ==?= Content-Type: multipart/alternative; boundary="_000_A42C015FE3FD4B8EB1A44F896E161974fbcom_" X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR15MB3772.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b332921-71bf-4043-1186-08d99e4cc674 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2021 22:04:43.3227 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yZW0pJvVrNep/rnfBEnpeByJai0ozwMEEpl/8ow7bWX68LKN/33uyi3uE78SU7/G X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR15MB3753 X-OriginatorOrg: fb.com X-Proofpoint-GUID: agWDsJYqe0Oo_qpjMtpto7RcR3YWBF2Z X-Proofpoint-ORIG-GUID: agWDsJYqe0Oo_qpjMtpto7RcR3YWBF2Z X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-11-02_08,2021-11-02_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 suspectscore=0 impostorscore=0 priorityscore=1501 spamscore=0 lowpriorityscore=0 mlxlogscore=446 mlxscore=0 phishscore=0 adultscore=0 clxscore=1011 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111020115 X-FB-Internal: deliver Archived-At: Subject: Re: [Masque] Capsules X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 22:04:51 -0000 --_000_A42C015FE3FD4B8EB1A44F896E161974fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBPdXQgb2YgY3VyaW9zaXR5OiB3aGF0IGFyZSB0aGUgZGVzaWduIGNvbnN0cmFpbnRzIHRoYXQg d291bGQgc3RlZXIgeW91IHRvIGEgZGlmZmVyZW50IHByb3RvY29sPw0KDQpGb3IgY29udGV4dCBv biB0aGUgV2ViVHJhbnNwb3J0IG92ZXIgSDIgcG90ZW50aWFsIHVzZSBvZiBDYXBzdWxlcywgc2Vl IGh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLXdlYnRyYW5zL2RyYWZ0LXdlYnRyYW5zcG9ydC1o dHRwMi9pc3N1ZXMvMjkNCg0KV2ViVHJhbnNwb3J0IG92ZXIgSDIgaW4gaXRzIGN1cnJlbnQgZm9y bSBkZWZpbmVzIOKAnFdlYlRyYW5zcG9ydCBGcmFtZXPigJ0sIHdoaWNoIGFyZSBpZGVudGljYWwg dG8gQ2Fwc3VsZXMgKFRMViwgdXNpbmcgUVVJQyBWYXJJbnRzLCBodHRwczovL2lldGYtd2ctd2Vi dHJhbnMuZ2l0aHViLmlvL2RyYWZ0LXdlYnRyYW5zcG9ydC1odHRwMi9kcmFmdC1pZXRmLXdlYnRy YW5zLWh0dHAyLmh0bWwjbmFtZS13ZWJ0cmFuc3BvcnQtZnJhbWVzKS4NCg0KU2luY2UgV2ViVHJh bnNwb3J0IG92ZXIgSDIgY2FuIG1vc3RseSBiZSBhYnN0cmFjdGVkIGFzIOKAnFNvbWUgUVVJQyBm cmFtZXMgb3ZlciBhIGJ5dGUtc3RyZWFt4oCdLCB3ZSB3ZXJlIGRpc2N1c3Npbmcgb24gdGhlIGlz c3VlIHdoZXRoZXIgd2UgY291bGQgcmUtdXNlIGV4aXN0aW5nIFFVSUMgZnJhbWUgcGFyc2Vycy4g IFNpbmNlIFFVSUMgZnJhbWVzIGRvIG5vdCBjb250YWluIGEgTGVuZ3RoIGZpZWxkLCB3ZSBkaXNj dXNzZWQgcHV0dGluZyB0aGUgTGVuZ3RoIGZpcnN0IGluIHRoZSBXZWJUcmFuc3BvcnQgRnJhbWUs IHNvIGl0IGNvdWxkIGJlIHN0cmlwcGVkIGJlZm9yZSB1c2luZyBhbiBleGlzdGluZyBmcmFtZSBw YXJzZXIuICBBbHRlcm5hdGVseSwgd2UgY291bGQgcmVtb3ZlIHRoZSBnZW5lcmljIEZyYW1lIHR5 cGUgYWx0b2dldGhlciAoYXMgUVVJQyBoYXMpLCBhbmQganVzdCBraWxsIHRoZSBzdHJlYW0gd2hl biBhbiB1bmtub3duIEZyYW1lIHR5cGUgaXMgZGV0ZWN0ZWQuICBFaXRoZXIgb2YgdGhvc2UgdHdv IGFsdGVybmF0aXZlcyBhcmUgaW5jb21wYXRpYmxlIHdpdGggQ2Fwc3VsZXMgYXMgY3VycmVudGx5 IHNwZWNpZmllZC4NCg0KLUFsYW4NCg== --_000_A42C015FE3FD4B8EB1A44F896E161974fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <267DD9C819BBD64CB620849DD251DB7C@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgT3V0IG9mIGN1cmlvc2l0eTogd2hhdCBhcmUgdGhlIGRl c2lnbiBjb25zdHJhaW50cyB0aGF0IHdvdWxkIHN0ZWVyIHlvdSB0byBhIGRpZmZlcmVudCBwcm90 b2NvbD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGNvbnRleHQgb24gdGhlIFdlYlRyYW5z cG9ydCBvdmVyIEgyIHBvdGVudGlhbCB1c2Ugb2YgQ2Fwc3VsZXMsIHNlZQ0KPGEgaHJlZj0iaHR0 cHM6Ly9naXRodWIuY29tL2lldGYtd2ctd2VidHJhbnMvZHJhZnQtd2VidHJhbnNwb3J0LWh0dHAy L2lzc3Vlcy8yOSI+DQpodHRwczovL2dpdGh1Yi5jb20vaWV0Zi13Zy13ZWJ0cmFucy9kcmFmdC13 ZWJ0cmFuc3BvcnQtaHR0cDIvaXNzdWVzLzI5PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X ZWJUcmFuc3BvcnQgb3ZlciBIMiBpbiBpdHMgY3VycmVudCBmb3JtIGRlZmluZXMg4oCcV2ViVHJh bnNwb3J0IEZyYW1lc+KAnSwgd2hpY2ggYXJlIGlkZW50aWNhbCB0byBDYXBzdWxlcyAoVExWLCB1 c2luZyBRVUlDIFZhckludHMsDQo8YSBocmVmPSJodHRwczovL2lldGYtd2ctd2VidHJhbnMuZ2l0 aHViLmlvL2RyYWZ0LXdlYnRyYW5zcG9ydC1odHRwMi9kcmFmdC1pZXRmLXdlYnRyYW5zLWh0dHAy Lmh0bWwjbmFtZS13ZWJ0cmFuc3BvcnQtZnJhbWVzIj4NCmh0dHBzOi8vaWV0Zi13Zy13ZWJ0cmFu cy5naXRodWIuaW8vZHJhZnQtd2VidHJhbnNwb3J0LWh0dHAyL2RyYWZ0LWlldGYtd2VidHJhbnMt aHR0cDIuaHRtbCNuYW1lLXdlYnRyYW5zcG9ydC1mcmFtZXM8L2E+KS4mbmJzcDsNCjxicj4NCjxi cj4NClNpbmNlIFdlYlRyYW5zcG9ydCBvdmVyIEgyIGNhbiBtb3N0bHkgYmUgYWJzdHJhY3RlZCBh cyDigJxTb21lIFFVSUMgZnJhbWVzIG92ZXIgYSBieXRlLXN0cmVhbeKAnSwgd2Ugd2VyZSBkaXNj dXNzaW5nIG9uIHRoZSBpc3N1ZSB3aGV0aGVyIHdlIGNvdWxkIHJlLXVzZSBleGlzdGluZyBRVUlD IGZyYW1lIHBhcnNlcnMuICZuYnNwO1NpbmNlIFFVSUMgZnJhbWVzIGRvIG5vdCBjb250YWluIGEg TGVuZ3RoIGZpZWxkLCB3ZSBkaXNjdXNzZWQgcHV0dGluZyB0aGUgTGVuZ3RoDQogZmlyc3QgaW4g dGhlIFdlYlRyYW5zcG9ydCBGcmFtZSwgc28gaXQgY291bGQgYmUgc3RyaXBwZWQgYmVmb3JlIHVz aW5nIGFuIGV4aXN0aW5nIGZyYW1lIHBhcnNlci4gJm5ic3A7QWx0ZXJuYXRlbHksIHdlIGNvdWxk IHJlbW92ZSB0aGUgZ2VuZXJpYyBGcmFtZSB0eXBlIGFsdG9nZXRoZXIgKGFzIFFVSUMgaGFzKSwg YW5kIGp1c3Qga2lsbCB0aGUgc3RyZWFtIHdoZW4gYW4gdW5rbm93biBGcmFtZSB0eXBlIGlzIGRl dGVjdGVkLiZuYnNwOyBFaXRoZXIgb2YgdGhvc2UNCiB0d28gYWx0ZXJuYXRpdmVzIGFyZSBpbmNv bXBhdGlibGUgd2l0aCBDYXBzdWxlcyBhcyBjdXJyZW50bHkgc3BlY2lmaWVkLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tQWxhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_A42C015FE3FD4B8EB1A44F896E161974fbcom_-- From nobody Tue Nov 2 16:24:31 2021 Return-Path: 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 5C6FF3A0FCC for ; Tue, 2 Nov 2021 16:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=YKyChnu5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Th6P1COK 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 iAUneEUkSQDA for ; Tue, 2 Nov 2021 16:24:24 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9623A0FCB for ; Tue, 2 Nov 2021 16:24:24 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 39C633201E1E; Tue, 2 Nov 2021 19:24:21 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Tue, 02 Nov 2021 19:24:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=2TeW8bK6y6UuLmwprh07aDqg+5Yk S2TwsngTqcQ3T8M=; b=YKyChnu5zuBJ5HL4gkKtm7s2gQRx4RjYLRevcTYgD1VP kc2jll7C/XI5gd50dYqNPfF69y2wcuEL3ezrYg/UYdzJeiVt1aB+WI3Ar2nbMKK0 zyHaw3rNfYSC5GuyHngdpYeKPE82gXkzKViPY1zVLlfYkSsFcsKa7tt7RtUWZ1Dp MFfPRNybkXrLNRI61NK9R3Ud7u1DbLMPY49Ua8FMBr/92khU2DT1wW3UcOvnlxKB WUywt7R+eEZTK5KoNRnxkj7Vw3Jvr2TAlLfIDZ9yZtBaJdg8xodKBguiT2McRvtt SUKR8paK5wO5p3jE6wEzejOuVsYLG737oE478Br4Pg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=2TeW8b K6y6UuLmwprh07aDqg+5YkS2TwsngTqcQ3T8M=; b=Th6P1COKpUqf0ufy0adkkO maiMTkwx5ndB4zP58d8b6YYA3kOGpSnlSlFKLu6ny44fI6Ymzs1ewarKNtkeqINK d5QbroHpUdxK0za9eafdLyrzuy4JMlMCCizHEn8l4PF4CLr2g6ebIcxW/Ox0uW6R aJoiz6vm04g7dxN6YosXN5YDLx0awle+NDNSlQ+k98HbAajRp3lLIcv9ZIebCNex OUhIvBO7O2aC3nJRlNM9E1CYA4pXWSc+mPXWcjd71ZkC+jW8g6rr/YPduP2qaqxb s7yfhOwgcd1jW3pU6p5w58JNhvj94KHvMwg6uvfid2yXYRyFfSAU9cYa3i5fB6zg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrtddugddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8C9193C0AEC; Tue, 2 Nov 2021 19:24:20 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1369-gd055fb5e7c-fm-20211018.002-gd055fb5e Mime-Version: 1.0 Message-Id: <425a7f4f-6e26-441b-b959-630a46287c23@www.fastmail.com> In-Reply-To: References: <85634900-dbbc-497a-aa97-cd6b29b4cc73@www.fastmail.com> Date: Wed, 03 Nov 2021 10:24:03 +1100 From: "Martin Thomson" To: "Ben Schwartz" Cc: masque@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Masque] Capsules X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 23:24:29 -0000 > This is a good observation, and we can correct it. We can define an > additional request header to indicate that the datagram+capsule system > is in use (like the old Transfer-Encoding header), to decouple this > from the :protocol. It's good to know that we disagree. You seem to think that the addition of another protocol layer is desirable. I do not. That shouldn't be a surprise: I asked if we could simplify things; your response was to propose making them more complex. What I'm saying is that it would be better to NOT have a generic framework that exists to serve the intermediation use case. Instead, intermediaries can understand all the protocols if they want to interact with the protocol more extensively. That is the purpose of using settings to negotiate support (a decision already made). Of course, that negotiation is only necessary if the protocol wants to escape the confines of a single stream. Document factoring is secondary to that, of course. >> The editors of the WebTransport over HTTP/2 draft are currently debating whether to propose the use of capsules there. There, we have some interesting design constraints that might be cause to use a different format. One option that is being considered is reusing design elements from QUIC to make the protocol easier to implement. I don't think that we should feel constrained to use capsules, except to the extent that it might be nice to make implementation in intermediaries easier. > > I think the purpose of a standards body is to avoid producing multiple > similar but incompatible systems if it can be avoided. If WebTransport > has additional requirements, MASQUE might be able to adopt a subset of > its framing. I don't agree that that is the purpose of a standards body at all. We're here so that different parties can agree in their (and hopefully everybody's) shared interest. What you might be looking for here is good engineering practice, which says that you don't want too much diversity in how the same problem is solved in different contexts. For this example, we have overlapping contexts. HTTP/2 puts length fields ahead of type fields (fixed LTVs), Capsules have varint TLVs, QUIC has TVs. These are not naturally compatible and so we have to decide how to align the format with these existing things. Of course, this is an easy thing to answer if you are predisposed toward the addition of another protocol layer. From nobody Tue Nov 2 16:48:02 2021 Return-Path: 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 080993A103E for ; Tue, 2 Nov 2021 16:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Ui//1mOw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=n9zU7hdE 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 pjd0b_UHyt2U for ; Tue, 2 Nov 2021 16:47:56 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6448F3A1043 for ; Tue, 2 Nov 2021 16:47:56 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id D53E63201FB7; Tue, 2 Nov 2021 19:47:53 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Tue, 02 Nov 2021 19:47:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=1YDaBXxbHsQJY/RF+1xOEK8hmBxv xaSgG99u9ppKJM8=; b=Ui//1mOwMNBdMuHgv+H3V4dS5KerUb5A30Z7RCvhEI2U RvFnEjffIdS6QBRQjKcsvivsufZSKuf77NNC2mN9MaRT5bupE5tE/UULgY00FZNc iBRohLy6bO+BXZ6pYH9IzwdX5DHfry7qSiBW8Q8dpCohvHQORxdwO+o3nhLyQ3GE tD9oJUA5rPjs6mqrgWYpD/IGiLp+qCtWLVRWk2NbQNnPuSYKgxpX0R2gSJSEFw8z bu/uwxL+IxDejKSePeLGtXQp0j7s2c4hyXXHaTmF+an6B195gSBqd2RRedtp/A6/ DK6uajCA16iOo4I2crNHhpmETuATu+b9pN9j9AkvUA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=1YDaBX xbHsQJY/RF+1xOEK8hmBxvxaSgG99u9ppKJM8=; b=n9zU7hdEHGvT9TeVQSaZxB wm3kXfXeVCXoq9l8VkvjlyDjTchHzsw0n89iMb7V9dPxQB17F27OoRhcEbecenrV yDpU0IAeM95ZVe7GvathqkFNk8lvrLVbkRmigrg/9pk/LSBI9oX5vJDCTe0OJLAa QmJcmPWIBOHoFNPB3oVrJiPwxBmj1dnX1EUvs45+e1hnYKU88zcSeFbmEL+NCmvS fUqDZwHfF7iXsdX4h6pscvaEN/liHOe1bd2PGQgp9Nkr/yDZ44rf8U08W2pzsEpJ LLMbv7NfuEHbTegfRiv9mIRxQ/fTEKnjTDHz0m6L3yuXhC9KTioYBmI0IGaCu5qQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrtddugddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3F9163C0AEC; Tue, 2 Nov 2021 19:47:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1369-gd055fb5e7c-fm-20211018.002-gd055fb5e Mime-Version: 1.0 Message-Id: <562b8750-32cd-4981-8535-20b3fe9c65e1@www.fastmail.com> In-Reply-To: References: <85634900-dbbc-497a-aa97-cd6b29b4cc73@www.fastmail.com> Date: Wed, 03 Nov 2021 10:47:35 +1100 From: "Martin Thomson" To: "David Schinazi" Cc: MASQUE Content-Type: text/plain Archived-At: Subject: Re: [Masque] Capsules X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 23:48:01 -0000 On Wed, Nov 3, 2021, at 04:27, David Schinazi wrote: > I'm confused here. In order to reuse code, it makes sense for multiple > protocols to share the capsule TLV wire format and the IANA capsule > type registry. Since protocols will share the IANA registry, you need > to define it in this doc. At that point it makes sense to also define > the capsule TLV format here as well since we see value in reusing it. > Copy-pasting the TLV format in every protocol document doesn't help us. > If you don't like the word "framework", then don't use that word? > draft-ietf-masque-h3-datagram-05 doesn't contain the word framework, > because it doesn't attempt to create a framework. Only to define pieces > that can be reused. I'm curious, how much of a hit to reuse would it be if: 1. The protocols had their own registries? 2. The protocols used different framing layouts (TLV vs. LTV or varint vs. fixed)? My guess is that the incremental cost is tiny. I know that I never reuse framing code from an old project, because it's generally just as easy to copy-paste or even just retype that tiny bit of code. And you always have different rules regarding which frame/capsule/packet types are permitted in different contexts, making reuse more complex. > You shouldn't feel constrained to use capsules, you should only use > them if they provide value. Out of curiosity: what are the design > constraints that would steer you to a different protocol? I hinted at these in my response to Ben, but we're essentially putting QUIC frames into the data stream, which has some interesting implications. There are a few options being tossed around: * Encapsulate QUIC frames by adding a leading length field (which would make them look like LTV format, mostly) * Use capsules and do some sort of mapping of QUIC frame types into that space (mapping TBD) * Use HTTP/2 framing (I don't think that this is serious) > What does "different uses of datagrams" mean? If one of my backends > supports CONNECT-UDP, why do I need a SETTING on the client-frontend > leg? That's a good question. I started a thread in HTTPbis about that exact question. The answer being "I don't know" or maybe "it depends". > The introduction of opaque and transparent capsules was done as an > editorial clarification to help readers understand the concept of > capsules. We can remove those terms, but we still need the concept of > injecting a datagram into the stream when going from h3 to h2. I think that the only thing you need is the special treatment for datagram capsules. > I think the value here is the definition of extensions that work across > multiple protocols. draft-schwartz-masque-h3-datagram-ping is a perfect > example of that: there's been discussion in WebTransport of adding a > JavaScript API at some later date that would tell the JavaScript what > the datagram MTU is. Having this MTU information would also be useful > for CONNECT-UDP and CONNECT-IP. What you're suggesting is that every > single protocol redefines this. That's not reducing any complexity, > just kicking the can down the road. I don't think that I was suggesting kicking the can down the road. I was suggesting that building a framework is unnecessary, especially when you have just one use case for it. If MTU probing is useful - and I have some reservations about that - probing can be added to this draft. Or it could be added in a separate document as a capsule type with identical rules for forwarding as datagram capsules, though that creates some uncertainty that it isn't fully supported on the path. The whole datagram contexts and datagram formats framework is extraordinarily heavyweight for those cases that aren't using it (i.e., most of them), even if it makes this one thing a tiny bit easier. > Can you clarify what your goal is? It sounds like you would prefer for > this document to be shorter. I agree with that goal, but it shouldn't > be done in a vacuum - we should look at the total length of the > MASQUE/WebTransport documents. My goal is to make it easier to implement the whole suite. It starts here, but I expect the simplifications to flow on to the other documents also. It's conceptually easier to reason about this when each protocol is self-contained. I think that you can get that - and shared design elements - without working nearly so hard. From nobody Tue Nov 2 16:56:56 2021 Return-Path: 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 1FF373A1072 for ; Tue, 2 Nov 2021 16:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 RfasNQbQnyuZ for ; Tue, 2 Nov 2021 16:56:51 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 AE8F93A106F for ; Tue, 2 Nov 2021 16:56:50 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id b12so937772wrh.4 for ; Tue, 02 Nov 2021 16:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X1i1ZUTaC0jszlYFa6icvQWr8Uxosdlpm91Yf7YBHME=; b=erTRuUiCOiTe1FskvWgTdElOUjNDh6jKDBT/vTDG68QlMsL0bUJ6bdzXeDqCiYiOeo iEUWsg2XO7ZSApLS6Kh6EZom1aS/oqQnWSqx4Jzlct7h7JgD7tOMRfebu7C5oVVn7Sf6 SFVfjApn2LmBka+2tJ3QrB9l1xCnyuRkaAXOnnM6u7XWbIaNXNFcSOmg2NMjKfdR23hQ RJZDC+FjwjCp+S5aqWbnxL74DGRvj0mDVbyeX+oZX8p5DJxNfm+kstMa1hxAL0VNROXA UwxSsyiCVA8wR4x+DHo2mZvKJOjc+NkVI5XRwyg3jf6oPAQ/zvCOaqTJY40anf3OjALf HGEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X1i1ZUTaC0jszlYFa6icvQWr8Uxosdlpm91Yf7YBHME=; b=q+9i8ZdiRgMmSwRf7pHlmq2l0OB1yR1BryP+B+OluKw4gXfeH7gzZBFwmJkzazCak6 y99SXbBla7Vcn8oiOtCAQ5VCKNm7tW2IkaQFKWbObFSBkom2oEw7dMO6w/Fd05eeXiUA hWXZoSQpFcXQy8a0CliaR5Nn3LBIEMX0ZMBHJaVTD6lSUSi+eKYAuDp36eKbb/qdea3I gQdJFKe5lvadfWYVLrhgXr6z/ZF2iyaqcdPSM4zCY0NguxHufnF4FpsRGtmrU5X/GV0i lXdm0+tHDnJ8qkKqokE3EkGqrNOyl/HK/h1mZ8YJ6ChuKvSEKo5C6oUUV7BaR2JO/8df d3tQ== X-Gm-Message-State: AOAM53225rSBL0V1RNtKoJhHgLQYgDZB2zIUPXZTDtcMj9r+NXEZN5UJ KB7amdqpQ+MZvbdrNjnz/uoj6eDH82le1rWLjYfyR2qfLhc= X-Google-Smtp-Source: ABdhPJw7hOjZIqt/2aJ7WKnwXX90QbqnsdlNlBBUGFrux6zB7ofKYu5YHlkYfVysO5xwafqfn0MmCdVTkBiblSZVVYM= X-Received: by 2002:a5d:47c7:: with SMTP id o7mr17590539wrc.204.1635897408268; Tue, 02 Nov 2021 16:56:48 -0700 (PDT) MIME-Version: 1.0 References: <85634900-dbbc-497a-aa97-cd6b29b4cc73@www.fastmail.com> <425a7f4f-6e26-441b-b959-630a46287c23@www.fastmail.com> In-Reply-To: <425a7f4f-6e26-441b-b959-630a46287c23@www.fastmail.com> From: Victor Vasiliev Date: Tue, 2 Nov 2021 19:56:37 -0400 Message-ID: To: Martin Thomson Cc: Ben Schwartz , masque@ietf.org Content-Type: multipart/alternative; boundary="000000000000e91dfe05cfd70b99" Archived-At: Subject: Re: [Masque] Capsules X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 23:56:55 -0000 --000000000000e91dfe05cfd70b99 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 2, 2021 at 7:24 PM Martin Thomson wrote: > What I'm saying is that it would be better to NOT have a generic framework > that exists to serve the intermediation use case. Instead, intermediaries > can understand all the protocols if they want to interact with the protocol > more extensively. That is the purpose of using settings to negotiate > support (a decision already made). Of course, that negotiation is only > necessary if the protocol wants to escape the confines of a single stream. > >From what I understand, the only reason you need to negotiate a SETTINGS parameter is if you need to use native HTTP/3 datagrams. There's nothing fundamentally preventing anyone from using any capsule protocols in the current iterations of H2/H3, provided that you support extended CONNECT. --000000000000e91dfe05cfd70b99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 2, 2021 at 7:24 PM Martin Tho= mson <mt@lowentropy.net> wro= te:
What I'm saying is that it would be better to NOT have a= generic framework that exists to serve the intermediation use case.=C2=A0 = Instead, intermediaries can understand all the protocols if they want to in= teract with the protocol more extensively.=C2=A0 That is the purpose of usi= ng settings to negotiate support (a decision already made).=C2=A0 Of course= , that negotiation is only necessary if the protocol wants to escape the co= nfines of a single stream.

From what I = understand, the only reason you need to negotiate a SETTINGS parameter is i= f you need to use native HTTP/3 datagrams.=C2=A0 There's nothing fundam= entally preventing anyone from using any=C2=A0capsule=C2=A0protocols in the= current iterations of H2/H3, provided that you support extended CONNECT.
--000000000000e91dfe05cfd70b99-- From nobody Tue Nov 2 17:17:51 2021 Return-Path: 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 AC4E33A10A1 for ; Tue, 2 Nov 2021 17:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nMurrz0lLFJk for ; Tue, 2 Nov 2021 17:17:45 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 1EB603A10A0 for ; Tue, 2 Nov 2021 17:17:45 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id x66so553074pfx.13 for ; Tue, 02 Nov 2021 17:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r+RTxWq/5ZMqL9QTXNghQSXU6cmw1h8kx5B9X7kVdL8=; b=pQBY6wzdba4DISpLnnyqeq6AsjEaUGj5EgxBPyqcSOpA0iZOgR6gUUR+ZEFqhrf+yJ pwzXq0/J/cP9Kk8neS/v0Nzz/giHlWzF0qM8imjtbsA3CiK94lNC+VBca1RKcGHkiJAZ pBO1QwIGGkCXsE+3fJ3sQC063mVSuxxlAGVUOq16BeXMwo49km0sSI2Bmux7aIOIT8m0 KskwZ87k3wkwpb0nJC+9BiEDjh6AP22rF6+boFjNqMnfl/5pF03Up7OTBtXOMFIsmHkF 9pAqiseSjAk1ulvydWq887a2k8khf9hXxYN2b1k4n5CcOSK+LIEYW2ntFbieVView3Fl b22w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r+RTxWq/5ZMqL9QTXNghQSXU6cmw1h8kx5B9X7kVdL8=; b=lkuaz7OAG30TsmKaqlHXsCDXQgcuWyv93XvVjbvHFa8cggCaV0y+ZNrqf+dYsZ+0Y0 URmRBMa7poI/2RcxjcQIhHaVMYlluGTnr6l/BeXFtwGegM8BpqIvtwxkJpr0PnvN814O 4detlR8uAN3uX8dYOoxOII0vHTLnO4q/9CkkuSU757pZW7HWwYJFaKEYmEourLSeF9Br 7NwQ2Pn3/RuXrvopo8IlLbY/KHK1TwOLDxGg42hz/D7jKGq4WsQoRoVHj8vURuaEfVVA 3GYY7K0PiLYJ591oWittYL0TSus1CyLumpQlGZAjzAOHaqUDi+PJ7IxNUQ0SKpAh+t/a mlhA== X-Gm-Message-State: AOAM530/14L2Cv/Bb6MpEng38eBvInSpr85mYFertac7LZ1MuUEGzYHE PqH215VRfxVGVa0ahhZGTvgtSu2J33MO4IR3ruDIiYdC X-Google-Smtp-Source: ABdhPJwZLydDDljvLgTuRU9DX8U5YoEdZJ0Q0Y5BMV2/Bsq1/NRkSxjM0qRLli86rFxX6szuo27r/EF1jAZk/wS0pqE= X-Received: by 2002:a63:e214:: with SMTP id q20mr21369107pgh.431.1635898664054; Tue, 02 Nov 2021 17:17:44 -0700 (PDT) MIME-Version: 1.0 References: <85634900-dbbc-497a-aa97-cd6b29b4cc73@www.fastmail.com> <562b8750-32cd-4981-8535-20b3fe9c65e1@www.fastmail.com> In-Reply-To: <562b8750-32cd-4981-8535-20b3fe9c65e1@www.fastmail.com> From: David Schinazi Date: Tue, 2 Nov 2021 17:17:32 -0700 Message-ID: To: Martin Thomson Cc: MASQUE Content-Type: multipart/alternative; boundary="000000000000c2728105cfd75665" Archived-At: Subject: Re: [Masque] Capsules X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2021 00:17:50 -0000 --000000000000c2728105cfd75665 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 2, 2021 at 4:47 PM Martin Thomson wrote: > On Wed, Nov 3, 2021, at 04:27, David Schinazi wrote: > > I'm confused here. In order to reuse code, it makes sense for multiple > > protocols to share the capsule TLV wire format and the IANA capsule > > type registry. Since protocols will share the IANA registry, you need > > to define it in this doc. At that point it makes sense to also define > > the capsule TLV format here as well since we see value in reusing it. > > Copy-pasting the TLV format in every protocol document doesn't help us. > > If you don't like the word "framework", then don't use that word? > > draft-ietf-masque-h3-datagram-05 doesn't contain the word framework, > > because it doesn't attempt to create a framework. Only to define pieces > > that can be reused. > > I'm curious, how much of a hit to reuse would it be if: > > 1. The protocols had their own registries? > > 2. The protocols used different framing layouts (TLV vs. LTV or varint vs. > fixed)? > Right now I have one class called CapsuleParser that is used for both WebTransport and CONNECT-UDP. If either (1) or (2), then I'd need separate classes (or some non-trivial inheritance) which leads to the usual set of bugs where you modify one class and forget to update the other. My guess is that the incremental cost is tiny. I know that I never reuse > framing code from an old project, because it's generally just as easy to > copy-paste or even just retype that tiny bit of code. And you always have > different rules regarding which frame/capsule/packet types are permitted in > different contexts, making reuse more complex. > I'm not too worried about the incremental cost - copy-paste is easy - but I am concerned about the maintenance costs that come from code duplication. > You shouldn't feel constrained to use capsules, you should only use > > them if they provide value. Out of curiosity: what are the design > > constraints that would steer you to a different protocol? > > I hinted at these in my response to Ben, but we're essentially putting > QUIC frames into the data stream, which has some interesting implications. > There are a few options being tossed around: > > * Encapsulate QUIC frames by adding a leading length field (which would > make them look like LTV format, mostly) > * Use capsules and do some sort of mapping of QUIC frame types into that > space (mapping TBD) > Defining one new capsule type per QUIC frame type you care about sounds fairly straightforward to me, am I missing something? > * Use HTTP/2 framing (I don't think that this is serious) > > > What does "different uses of datagrams" mean? If one of my backends > > supports CONNECT-UDP, why do I need a SETTING on the client-frontend > > leg? > > That's a good question. I started a thread in HTTPbis about that exact > question. The answer being "I don't know" or maybe "it depends". > > > The introduction of opaque and transparent capsules was done as an > > editorial clarification to help readers understand the concept of > > capsules. We can remove those terms, but we still need the concept of > > injecting a datagram into the stream when going from h3 to h2. > > I think that the only thing you need is the special treatment for datagram > capsules. > Sounds like we agree. These are just two different ways to frame the discussion: 1) all capsules must be forwarded without messing with them, except datagram 2) define concepts of opaque vs transparent, with datagram being the only transparent one This is just an editorial matter. > I think the value here is the definition of extensions that work across > > multiple protocols. draft-schwartz-masque-h3-datagram-ping is a perfect > > example of that: there's been discussion in WebTransport of adding a > > JavaScript API at some later date that would tell the JavaScript what > > the datagram MTU is. Having this MTU information would also be useful > > for CONNECT-UDP and CONNECT-IP. What you're suggesting is that every > > single protocol redefines this. That's not reducing any complexity, > > just kicking the can down the road. > > I don't think that I was suggesting kicking the can down the road. I was > suggesting that building a framework is unnecessary, especially when you > have just one use case for it. > I still don't think there's any framework happening here, just reuse of spec text and code between WebTransport, CONNECT-UDP and CONNECT-IP. If MTU probing is useful - and I have some reservations about that - > probing can be added to this draft. Or it could be added in a separate > document as a capsule type with identical rules for forwarding as datagram > capsules, though that creates some uncertainty that it isn't fully > supported on the path. I think this is the key property we're after here: being able to deploy extensions by modifying the endpoints but without having to modify intermediaries. > The whole datagram contexts and datagram formats framework is > extraordinarily heavyweight for those cases that aren't using it (i.e., > most of them), even if it makes this one thing a tiny bit easier. > > > Can you clarify what your goal is? It sounds like you would prefer for > > this document to be shorter. I agree with that goal, but it shouldn't > > be done in a vacuum - we should look at the total length of the > > MASQUE/WebTransport documents. > > My goal is to make it easier to implement the whole suite. It starts > here, but I expect the simplifications to flow on to the other documents > also. It's conceptually easier to reason about this when each protocol is > self-contained. I think that you can get that - and shared design elements > - without working nearly so hard. > What are your thoughts on extensibility? Most of the perceived complexities in the design stem from ensuring future-proof extensibility, so perhaps we need to agree on how much extensibility we want before deciding how to implement it. --000000000000c2728105cfd75665 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 2, 2021 at 4:47 PM Martin= Thomson <mt@lowentropy.net>= wrote:
On Wed, = Nov 3, 2021, at 04:27, David Schinazi wrote:
> I'm confused here. In order to reuse code, it makes sense for mult= iple
> protocols to share the capsule TLV wire format and the IANA capsule > type registry. Since protocols will share the IANA registry, you need =
> to define it in this doc. At that point it makes sense to also define =
> the capsule TLV format here as well since we see value in reusing it. =
> Copy-pasting the TLV format in every protocol document doesn't hel= p us.
> If you don't like the word "framework", then don't u= se that word?
> draft-ietf-masque-h3-datagram-05 doesn't contain the word framewor= k,
> because it doesn't attempt to create a framework. Only to define p= ieces
> that can be reused.

I'm curious, how much of a hit to reuse would it be if:

1. The protocols had their own registries?

2. The protocols used different framing layouts (TLV vs. LTV or varint vs. = fixed)?

Right now I have one class call= ed CapsuleParser that=C2=A0is used for both WebTransport and CONNECT-UDP. I= f either (1) or (2), then I'd need separate classes (or some non-trivia= l inheritance) which leads to the usual set of bugs where you modify one cl= ass and forget to update the other.

My guess is that the incremental cost is tiny.=C2=A0 I know that I never re= use framing code from an old project, because it's generally just as ea= sy to copy-paste or even just retype that tiny bit of code.=C2=A0 And you a= lways have different rules regarding which frame/capsule/packet types are p= ermitted in different contexts, making reuse more complex.
=

I'm not too worried about the incremental cost - co= py-paste is easy - but I am concerned about the maintenance costs that come= from code duplication.

> You shouldn't feel constrained to use capsules, you should only us= e
> them if they provide value. Out of curiosity: what are the design
> constraints that would steer you to a different protocol?

I hinted at these in my response to Ben, but we're essentially putting = QUIC frames into the data stream, which has some interesting implications.= =C2=A0 There are a few options being tossed around:

* Encapsulate QUIC frames by adding a leading length field (which would mak= e them look like LTV format, mostly)
* Use capsules and do some sort of mapping of QUIC frame types into that sp= ace (mapping TBD)

Defining one new caps= ule type per QUIC frame type you care about sounds fairly straightforward t= o me, am I missing something?
=C2=A0
* Use HTTP/2 framing (I don't think that this is serious)

> What does "different uses of datagrams" mean? If one of my b= ackends
> supports CONNECT-UDP, why do I need a SETTING on the client-frontend <= br> > leg?

That's a good question.=C2=A0 I started a thread in HTTPbis about that = exact question.=C2=A0 The answer being "I don't know" or mayb= e "it depends".

> The introduction of opaque and transparent capsules was done as an > editorial clarification to help readers understand the concept of
> capsules. We can remove those terms, but we still need the concept of =
> injecting a datagram into the stream when going from h3 to h2.

I think that the only thing you need is the special treatment for datagram = capsules.

Sounds like we agree. These a= re just two different ways to frame the discussion:
1) all capsul= es must be forwarded without messing with them, except datagram
2= ) define concepts of opaque vs transparent, with datagram being the only tr= ansparent one
This is just an editorial matter.

> I think the value here is the definition of extensions that work acros= s
> multiple protocols. draft-schwartz-masque-h3-datagram-ping is a perfec= t
> example of that: there's been discussion in WebTransport of adding= a
> JavaScript API at some later date that would tell the JavaScript what =
> the datagram MTU is. Having this MTU information would also be useful =
> for CONNECT-UDP and CONNECT-IP. What you're suggesting is that eve= ry
> single protocol redefines this. That's not reducing any complexity= ,
> just kicking the can down the road.

I don't think that I was suggesting kicking the can down the road. I wa= s suggesting that building a framework is unnecessary, especially when you = have just one use case for it.

I still = don't think there's any framework happening here, just reuse of spe= c text and code between WebTransport, CONNECT-UDP and CONNECT-IP.

If MTU probing is useful - and I have some reservations about that - probin= g can be added to this draft.=C2=A0 Or it could be added in a separate docu= ment as a capsule type with identical rules for forwarding as datagram caps= ules, though that creates some uncertainty that it isn't fully supporte= d on the path.

I think this is the key prop= erty we're after here: being able to deploy extensions by modifying the= endpoints but without having to modify intermediaries.
=C2=A0
The whole datagram con= texts and datagram formats framework is extraordinarily heavyweight for tho= se cases that aren't using it (i.e., most of them), even if it makes th= is one thing a tiny bit easier.

> Can you clarify what your goal is? It sounds like you would prefer for=
> this document to be shorter. I agree with that goal, but it shouldn= 9;t
> be done in a vacuum - we should look at the total length of the
> MASQUE/WebTransport documents.

My goal is to make it easier to implement the whole suite.=C2=A0 It starts = here, but I expect the simplifications to flow on to the other documents al= so.=C2=A0 It's conceptually easier to reason about this when each proto= col is self-contained.=C2=A0 I think that you can get that - and shared des= ign elements - without working nearly so hard.

What are your thoughts on extensibility? Most of the perceived comp= lexities in the design stem from ensuring future-proof extensibility, so pe= rhaps we need to agree on how much extensibility we want before deciding ho= w to implement it.
--000000000000c2728105cfd75665-- From nobody Sun Nov 7 14:09:30 2021 Return-Path: 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 35F923A0F49 for ; Sun, 7 Nov 2021 14:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.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 D80mL4Xn4z06 for ; Sun, 7 Nov 2021 14:09:24 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 262CC3A0F44 for ; Sun, 7 Nov 2021 14:09:24 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id f10so15105874ilu.5 for ; Sun, 07 Nov 2021 14:09:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z5x6xFMQ9dUU+C0pCuL1+TtAXXhM+Iw4ycTlR3PLJuY=; b=SejHcEAaYM9nY8wgSkTeL1srgTyW/eIIMFYdPPhfGKSxGppCQMefCd6imawZLklRMW DczQ0Tar7AkYvWymNHUwZCS4pudHm6qJrc64U/W0KMeBIUe1jW6lrCrE+bCbQkW6UIUR 9h4Jl0JQOqyeHbMWL3ckYn3dEGE+tp/BeW+UvFDBIoIDjkt6KaPnME92jdcOMLqadTRn Z5mYfvXGnbnS3n/5pqZ2GOPSAv4Y9QCOn3tgoPEz9MmPDTSxgEEPpfYyE0kmpg/4qaeB 5TzXNcPAgEee8FOEKv9WtyIO3PfuNV1btT2MyayCmFWnPE4twtvbecHGvSKi54R5MDX4 kD5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z5x6xFMQ9dUU+C0pCuL1+TtAXXhM+Iw4ycTlR3PLJuY=; b=sYlPPxqIhfVwpwlYB7qH4fioPFf1C4LDaOqfVPyQyEAR6TqlzQ1Miqv7CXA2022qIB +4W2fVT2EIDbDEiXMB9H7d9jxvmpSyhWyfZVFxsr04KL7J/F+votXWU/btWZ5b+zh70n L+KtTP1lk5rVGbBLNIGSfxE7aMKKWoK7DhUTiAuKVvbJs/6MMtZ24IzzXCk7XZhW2l7l R9jxZPO+9kNGDOSMy6HsUggDvWn1U2g97BVgjnZuLu0Ww9oagrKMwF6svUJGyX0n9hfe Pgdsgq1KmioRmrKcWN7WzXD4si035rbesMLaPQhVLiyLOeV0FRHd7bBg3G6rl2yFGOLs GnnA== X-Gm-Message-State: AOAM532Jm83smzS7M455jFvO6UiP3EYyDMlZKRG9a/50ezdNIqf5t0HM dh/RDLnesUqM8Cydv5BIF1dXT1lLXEb9p5sn4T6bygeBHcywTg== X-Google-Smtp-Source: ABdhPJzcyRw87Ktqgw+44YxZqv6dmjDGqawyHmgycVgz4aepRYAC3XcPVTKPwDTFhPvW38LG2xSBz4/UGff7/Yo0N7g= X-Received: by 2002:a05:6e02:20ea:: with SMTP id q10mr27386732ilv.10.1636322962960; Sun, 07 Nov 2021 14:09:22 -0800 (PST) MIME-Version: 1.0 References: <85634900-dbbc-497a-aa97-cd6b29b4cc73@www.fastmail.com> In-Reply-To: <85634900-dbbc-497a-aa97-cd6b29b4cc73@www.fastmail.com> From: Eric Rescorla Date: Sun, 7 Nov 2021 14:08:47 -0800 Message-ID: To: Martin Thomson Cc: MASQUE Content-Type: multipart/alternative; boundary="000000000000f2068c05d03a2087" Archived-At: Subject: Re: [Masque] Capsules X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 22:09:29 -0000 --000000000000f2068c05d03a2087 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 1, 2021 at 11:25 PM Martin Thomson wrote: > I've just reacquainted myself with the ever-shifting content of > draft-ietf-masque-h3-datagram (-05 specifically). > > My conclusion: this document is about 10x longer and more complex than it > needs to be and maybe three or four times more complex than it could be if > you accept some of the underlying assumptions. > > --- > The source of this added complexity is a desire to construct an abstract > framework that allows intermediaries to participate in the protocols that > this document attempts to facilitate. > > The key functional role for an intermediary here is for it to take > datagrams and forward them in a way that best suits the HTTP version in > use, allowing the same datagram to traverse different versions. Forwarding > in HTTP/3 wants to use native DATAGRAM frames, whereas fowarding elsewhere > needs to use the stream established by extended CONNECT. The goal in > creating a generic framework was to enable some common handling between > different protocols (UDP proxying, IP proxying, WebTransport). > > This is a bit of narrow use case. An intermediary that understands that > a capsule-based protocol can take datagrams from a stream of capsules and > send them in DATAGRAM frames. In the opposite direction, they can fold > DATAGRAM frames into streams. > I'd actually like to push on this use case a bit. To a first order, there are two ways one can have an HTTP intermediary: 1. It's associated with the client (i.e., a forward proxy) 2. It's associated with the server (i.e., a reverse proxy) To a first order, we no longer need to worry about the first type of proxy: because we are using encrypted transport, if that kind of proxy is in play, we just tunnel through that (effectively using RFC 2817 CONNECT) so it's irrelevant. This leaves us with the situation where the proxy is associated with the server. However, unlike the forward proxy, this is invisible to the client; it's just an internal implementation detail whether the server is implemented as one device, multiple devices with different versions of HTTP in between them, or indeed multiple devices with some totally non-HTTP protocol in between them. For this reason, protocol machinery which is intended to deal with the case where there are multiple chained HTTP elements seems like added complexity that we're imposing on the client for a case which is fundamentally a local matter for the server. I think if we were instead to just assume that the client was talking directly to the server and the server would sort out this kind of internal detail, life would be much simpler and we should consider that. -Ekr --000000000000f2068c05d03a2087 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 1, 2021 at 11:25 PM Marti= n Thomson <mt@low= entropy.net> wrote:
I've just reacquainted myself with the ever-shifting content= of draft-ietf-masque-h3-datagram (-05 specifically).

My conclusion: this document is about 10x longer and more complex than it n= eeds to be and maybe three or four times more complex than it could be if y= ou accept some of the underlying assumptions.

---
The source of this added complexity is a desire to construct an abstract fr= amework that allows intermediaries to participate in the protocols that thi= s document attempts to facilitate.

The key functional role for an intermediary here is for it to take datagram= s and forward them in a way that best suits the HTTP version in use, allowi= ng the same datagram to traverse different versions.=C2=A0 Forwarding in HT= TP/3 wants to use native DATAGRAM frames, whereas fowarding elsewhere needs= to use the stream established by extended CONNECT.=C2=A0 The goal in creat= ing a generic framework was to enable some common handling between differen= t protocols (UDP proxying, IP proxying, WebTransport).

This is a bit of narrow use case.=C2=A0 =C2=A0An intermediary that understa= nds that a capsule-based protocol can take datagrams from a stream of capsu= les and send them in DATAGRAM frames.=C2=A0 In the opposite direction, they= can fold DATAGRAM frames into streams.
I'd actually like to push on this use case a bit.

= To a first order, there are two ways one can have an HTTP
intermediary:<= br>
1. It's associated with the client (i.e., a forward proxy)
2.= It's associated with the server (i.e., a reverse proxy)

To a fi= rst order, we no longer need to worry about the first type of
proxy: bec= ause we are using encrypted transport, if that kind of proxy
is in play,= we just tunnel through that (effectively using RFC 2817
CONNECT) so it&= #39;s irrelevant.

This leaves us with the situation where the proxy = is associated with
the server. However, unlike the forward proxy, this i= s invisible to
the client; it's just an internal implementation deta= il whether the
server is implemented as one device, multiple devices wit= h different
versions of HTTP in between them, or indeed multiple devices= with some
totally non-HTTP protocol in between them.

For this re= ason, protocol machinery which is intended to deal with the
case where t= here are multiple chained HTTP elements seems like added
complexity that= we're imposing on the client for a case which is
fundamentally a lo= cal matter for the server. I think if we were
instead to just assume tha= t the client was talking directly to the
server and the server would sor= t out this kind of internal detail,
life would be much simpler and we sh= ould consider that.

-Ekr



=
--000000000000f2068c05d03a2087-- From nobody Sun Nov 7 15:12:49 2021 Return-Path: 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 4EF7D3A1136 for ; Sun, 7 Nov 2021 15:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.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 UDF7YPQexAtX for ; Sun, 7 Nov 2021 15:12:46 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 C09983A1139 for ; Sun, 7 Nov 2021 15:12:46 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id f10so15178979ilu.5 for ; Sun, 07 Nov 2021 15:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=nCwNIHPRu/Yd0i2FcrxvVZXJ5lQAfYpcAaor/nKHt+A=; b=CHaXU9cz6wAdOG/38zTQ/DKJx65IxNWiSEcnN/Vo7stFRaA5bgms8Fp1SIQvehVELc 8iUZ+sZKqlKaURGeZtz8YhVyAe2wsdSLH8VNj9W3DJRUb46J0oAxwrc2Km4DsiKsl6El A2w5kGYNPrfxd+eBdrOyfiwrTLx/JUMVUWqmb28P+cHQmbw2685jVPVlx+Z6B0r1ClwM AZPJz5k5PbY62dFAE1FcoSW5nKau3qrDf10/ADE1gL/p0gVJGb6QM99pvDFjRBrEkO83 oe5DubCQ9AvR6Xv19mflgZPB/9lMKITYh5GdKLzLeUu17VwW6OEnPvZ0WVXaCQw2zZ72 88FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nCwNIHPRu/Yd0i2FcrxvVZXJ5lQAfYpcAaor/nKHt+A=; b=jS9iPldgwdx2UqIsGRMypfZLnN7kHrpavGqRNc5Mqf/Gva+KZas7fbPVG/EqvZ800u XHCYgzUXUAtTzuUgSly0V3HXQBN903OBUhM95bBCLdI7QeBAgkd+DPEwmQzS7HQisXDD HEnsbQtyg0Gq6siB+XZtegupIn3BWG3qEwYngD8cofqjvPa8aeFsJuGf0ibdWW+CewUQ 0nzTyMzkwaM0XSQC6pYFFvJEC/lUmBFO76/W7vQUDiM7wqwGy7miMLw/EtPS3/zVpwFv S1RLiRCi0fOqw3nMLmZFoT457qxXCq/AOYRoIsofKWMLo6xEPGjeKYX8RE7rDYxO8MXK /u3Q== X-Gm-Message-State: AOAM533uiTaZ+m+f366fqXhFa2siiaCLhQFXk5r/Po4JZrO8YsbsJ0Ks eur5qVGIBBJ85g1TkB358aM4l8XFqlOIbAvvW+bIGcKtRa9bNQ== X-Google-Smtp-Source: ABdhPJzzCl9Zh5vNxVfH+xlyUrszMduEjIMWfKITwZ9V32Z4Li63FdRSO36O+pUlEAYanQDP8EpCGrTG5q9wvkKbZPk= X-Received: by 2002:a92:c569:: with SMTP id b9mr36050959ilj.39.1636326764068; Sun, 07 Nov 2021 15:12:44 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Sun, 7 Nov 2021 15:12:08 -0800 Message-ID: To: MASQUE Content-Type: multipart/alternative; boundary="0000000000008257ba05d03b03d7" Archived-At: Subject: [Masque] Comments on draft-age-masque-connect-ip-01 X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2021 23:12:48 -0000 --0000000000008257ba05d03b03d7 Content-Type: text/plain; charset="UTF-8" This document seems like a reasonable starting point. Good to see the authors converging. Some technical comments below. Overall, I wonder if we should actually forbid the client from using IP addresses in packets when the target is specified. That would avoid goofy situations in which the client does CONNECT 192.0.2.1 And then sends to 192.0.2.2. S 4.1. target: The variable "target" contains a hostname or IP address of a specific host to which the client wants to proxy packets. If the "target" variable is not specified, the client is requesting to communicate with any allowable host. If the target is an IP address, the request will only support a single IP version. If the target is a hostname, the server is expected to perform DNS resolution to determine which route(s) to advertise to the client. The server SHOULD send a ROUTE_ADVERTISEMENT capsule that includes routes for all usable resolved addresses for the requested hostname. This treatment of DNS names seems like it's going to create a lot of additional complexity: for instance, how does the client know which IP to put in the dst field. You don't specify that the ROUTE_ADVERTISEMENT MUST *only* include valid addresses. For instance, suppose that the DNS name resolves to 192.0.2.1 192.0.2.2 192.0.2.4 <-- No 192.0.2.3! 192.0.2.5 192.0.2.6 192.0.2.7 and the server advertises 192.0.2.1-192.0.2.7. Given that this is an IP layer mechanism, I would simply remove the DNS option; clients can always do DNS over the tunnel. S 4.2. Is the server required to send ADDRESS_ASSIGN? If not, what is the client supposed to use as it's source address? Also, what happens if you only get a v6 address but need to talk to a v4 endpoint, or vice versa. S 4.2.3. You should probably say something here about how in many cases you shouldn't trust a ROUTE_ADVERTISEMENT. For instance, it's incoherent for an ordinary consumer VPN client to start advertising routes. --0000000000008257ba05d03b03d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This document seems like a reasonable starting point.= Good to see
the authors converging. Some technical comments belo= w.

Overall, I wonder if we should actually forbid the client fromusing IP addresses in packets when the target is specified.
That would = avoid goofy situations in which the client does

=C2=A0 =C2=A0CONNECT= 192.0.2.1

And then sends to 192.0.2.2.

=C2=A0 =C2=A0 =C2=A0 = =C2=A0
S 4.1.

=C2=A0 =C2=A0target: =C2=A0The variable "targ= et" contains a hostname or IP address of a
=C2=A0 =C2=A0 =C2=A0 spe= cific host to which the client wants to proxy packets.=C2=A0 If the
=C2= =A0 =C2=A0 =C2=A0 "target" variable is not specified, the client = is requesting to
=C2=A0 =C2=A0 =C2=A0 communicate with any allowable hos= t.=C2=A0 If the target is an IP
=C2=A0 =C2=A0 =C2=A0 address, the reques= t will only support a single IP version.=C2=A0 If
=C2=A0 =C2=A0 =C2=A0 t= he target is a hostname, the server is expected to perform DNS
=C2=A0 = =C2=A0 =C2=A0 resolution to determine which route(s) to advertise to the cl= ient.
=C2=A0 =C2=A0 =C2=A0 The server SHOULD send a ROUTE_ADVERTISEMENT = capsule that includes
=C2=A0 =C2=A0 =C2=A0 routes for all usable resolve= d addresses for the requested
=C2=A0 =C2=A0 =C2=A0 hostname.

This= treatment of DNS names seems like it's going to create a lot of
add= itional complexity: for instance, how does the client know which IP
to p= ut in the dst field. You don't specify that the
ROUTE_ADVERTISEMENT = MUST *only* include valid addresses. For instance,
suppose that the DNS = name resolves to

=C2=A0 192.0.2.1
=C2=A0 192.0.2.2
=C2=A0 192.= 0.2.4 <-- No 192.0.2.3!
=C2=A0 192.0.2.5
=C2=A0 192.0.2.6
=C2= =A0 192.0.2.7

and the server advertises 192.0.2.1-192.0.2.7.

= Given that this is an IP layer mechanism, I would simply remove the
DNS = option; clients can always do DNS over the tunnel.



S 4.2.Is the server required to send ADDRESS_ASSIGN? If not, what is the
clie= nt supposed to use as it's source address? Also, what happens
if you= only get a v6 address but need to talk to a v4 endpoint,
or vice versa.=


S 4.2.3.
You should probably say something here about how in= many cases
you shouldn't trust a ROUTE_ADVERTISEMENT. For instance,= it's
incoherent for an ordinary consumer VPN client to start
adv= ertising routes.




--0000000000008257ba05d03b03d7-- From nobody Mon Nov 8 06:05:08 2021 Return-Path: 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 9CD6B3A0A22 for ; Mon, 8 Nov 2021 06:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=YVvtkQUA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Hn9dzNRZ 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 WAY7rWEZOM5F for ; Mon, 8 Nov 2021 06:05:00 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6E13A0A10 for ; Mon, 8 Nov 2021 06:05:00 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 153F95C01D2 for ; Mon, 8 Nov 2021 09:05:00 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute1.internal (MEProxy); Mon, 08 Nov 2021 09:05:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=KX3V2777ITtYTdK4tvTicf7G2RfUggy+uQKcaBS2OlI=; b=YVvtkQUA C3+7s7LC1joNwpvJpQJ85ASiWKf/p3vGWphErs4QZXqxyN+HSjDB9zmwcZKnu7HJ PH7FlXhJPpHEg7Wf2vXWc+DRY1v4H+U6hiEmoUGFLGdK8Q9Q7/sJowxtOBcCPhxa Zw04UddetzZI6DcKhi5rjsBe/C2VyXb9wbKX6RkPCcys2v27rxem/ZdrnEFwMB/0 bqieCYyYhlqvpF/9yKuW0RTWvAUbJxIMvPhArwGDiTAMs18Xq69FUhrMo5dE6YoN HlwN15jRrXh9CpapMjCz0GH33pIBlAaJPNHdl5xb1grnbECyUC5HrrWYTikapdoq 1PfJ89+o+ij/lg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=KX3V2777ITtYTdK4tvTicf7G2RfUg gy+uQKcaBS2OlI=; b=Hn9dzNRZRpqbwx2mSQYHo4RJa9dpEPPpJeuhCk6iGh6Ss qMyNAGwxjREnL6L6ASztzPfWtLSd6yi5YMlgcXfEly4qXKR15xNppknihv1CAN9x HHKq2xx7EUU6jP3A8fVy8lDeF6GR2hjnVqZ1RycPStrsyy2FBmc72HReYHamQ1I1 ERRTT+sHOr5dOh9AjLOvwjFqgFhtTww765VGu/QY0mUscQBFzLlVpEwzKwXylWD7 usqneTRlDZScPqiwsZmUVIXbIpoJs1t3blTxslFD4xks+SMzAK1/hYbCUKgkmMHF JStsLp2ftuBIbLUmOxAuh4tD51WQzDO4GWjfCk2bA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddvgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgv rghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhepudehudegleejveduve eiheehhfetfffgieejheeuhffggfffhfduhfdtleelieehnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtsh drnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B38A33C0C6F; Mon, 8 Nov 2021 09:04:59 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1369-gd055fb5e7c-fm-20211018.002-gd055fb5e Mime-Version: 1.0 Message-Id: Date: Mon, 08 Nov 2021 06:04:39 -0800 From: "Christopher Wood" To: masque@ietf.org Content-Type: text/plain Archived-At: Subject: [Masque] Design Team for HTTP/3 Datagrams X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 14:05:06 -0000 Hi folks, At today's IETF 112 meeting, we had lots of discussion around HTTP datagrams and how they should be shaped, especially around extensibility. To help converge on technical details, we're forming a design team to sort out the points of contention in draft-ietf-masque-h3-dgram. David Schinazi will lead the team, and the chairs will help coordinate as needed. The goal is for this team to identify a proposal we can discuss during an interim meeting before IETF 113. If you'd like to participate on this team, please respond to this message or email the chairs directly (masque-chairs@ietf.org). Thanks, Chris and Eric From nobody Mon Nov 8 06:07:20 2021 Return-Path: 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 039C13A0BA9 for ; Mon, 8 Nov 2021 06:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 FtAfpp3V8uah for ; Mon, 8 Nov 2021 06:07:14 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp24.apple.com (rn-mailsvcp-ppex-lapp24.rno.apple.com [17.179.253.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81B23A0B91 for ; Mon, 8 Nov 2021 06:07:14 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp24.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp24.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 1A8DronK020256 for ; Mon, 8 Nov 2021 06:07:14 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=gtDU/NEGPUx3It1d+nxan/Kq/g2r3ASEnXsKzR7LydI=; b=v6+YN6Z3bcV+rlC1pYXcecTzUMAtcL8y7kI032hIqIaHy2l7q9CJQ2JuP71GUtOE6eq6 FdQz2iBOJdp9JHQlJrXohTsteKAdY8X2+cdsytnGaAHwt1K7Roz+lyX10WC03EJ1+P/W 2ccygWQMbDg/2kgZVbv2/TvcbzFvaK+lNwnnI95Xz/MAE/ROoaal38NtAizO4ZYPZoyL /+6WTTvJ9HeyjaBhAkC3p5303SPyAU6rsVeFvTHiqPtAtqYAAlln7pcDZLaviV1w1Wbm aNeMWWWIo15TpIK70OSMm7nB4EPT/aWNL4bBFHAuZivdahRF10UO/DM4J2zy53/SqG0u 7w== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp24.rno.apple.com with ESMTP id 3c5qaakkjf-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 08 Nov 2021 06:07:14 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R2900D3HB82D9C0@rn-mailsvcp-mta-lapp02.rno.apple.com> for masque@ietf.org; Mon, 08 Nov 2021 06:07:14 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R2900R00AW09V00@rn-mailsvcp-mmp-lapp01.rno.apple.com> for masque@ietf.org; Mon, 08 Nov 2021 06:07:14 -0800 (PST) X-Va-A: X-Va-T-CD: e400c3fca44d6a91d2a8abbcc83a4dcd X-Va-E-CD: 86e81d95a6bdc497c5d97c36c4375536 X-Va-R-CD: bf373fcb0065c4e1e34e171895246cb3 X-Va-CD: 0 X-Va-ID: c27e0da6-c3f2-4a94-b378-ea94aa015bd9 X-V-A: X-V-T-CD: e400c3fca44d6a91d2a8abbcc83a4dcd X-V-E-CD: 86e81d95a6bdc497c5d97c36c4375536 X-V-R-CD: bf373fcb0065c4e1e34e171895246cb3 X-V-CD: 0 X-V-ID: e52c69db-d398-4e09-823b-f74574c06f14 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-08_05:2021-11-08, 2021-11-08 signatures=0 Received: from smtpclient.apple (unknown [17.234.108.216]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R2900COHB81DA00@rn-mailsvcp-mmp-lapp01.rno.apple.com> for masque@ietf.org; Mon, 08 Nov 2021 06:07:14 -0800 (PST) From: Eric Kinnear Content-type: multipart/alternative; boundary="Apple-Mail=_BBCC3585-2A16-43B2-A4C9-E849A3071157" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.36\)) Message-id: Date: Mon, 08 Nov 2021 06:07:13 -0800 To: MASQUE X-Mailer: Apple Mail (2.3693.40.0.1.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-08_05:2021-11-08, 2021-11-08 signatures=0 Archived-At: Subject: [Masque] Adoption call for draft-age-masque-connect-ip X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 14:07:19 -0000 --Apple-Mail=_BBCC3585-2A16-43B2-A4C9-E849A3071157 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all,=20 At IETF 112 there was significant support in the room to adopt = draft-age-masque-connect-ip as a starting point for our CONNECT-IP = efforts. This email begins an adoption call for draft-age-masque-connect-ip. The datatracker page for this document can be found here:=20 https://datatracker.ietf.org/doc/draft-age-masque-connect-ip/ = And the GitHub repository can be found here: https://github.com/tfpauly/draft-age-masque-connect-ip = This call for adoption will conclude on November 22. Thanks,=20 Eric and Chris= --Apple-Mail=_BBCC3585-2A16-43B2-A4C9-E849A3071157 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi all, 

At IETF 112 there was significant support in the room to = adopt draft-age-masque-connect-ip as a starting point for our CONNECT-IP = efforts.

This = email begins an adoption call for draft-age-masque-connect-ip.

The datatracker page for = this document can be found here: 
https://datatracker.ietf.org/doc/draft-age-masque-connect-ip/

And the = GitHub repository can be found here:
https://github.com/tfpauly/draft-age-masque-connect-ip

This call for = adoption will conclude on November 22.

Thanks, 
Eric = and Chris
= --Apple-Mail=_BBCC3585-2A16-43B2-A4C9-E849A3071157-- From nobody Mon Nov 8 06:08:09 2021 Return-Path: X-Original-To: masque@ietf.org Delivered-To: masque@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1F63A0C6D; Mon, 8 Nov 2021 06:08:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163638048678.7633.7093334721227581631@ietfa.amsl.com> Date: Mon, 08 Nov 2021 06:08:06 -0800 Archived-At: Subject: [Masque] The MASQUE WG has placed draft-age-masque-connect-ip in state "Call For Adoption By WG Issued" X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 14:08:07 -0000 The MASQUE WG has placed draft-age-masque-connect-ip in state Call For Adoption By WG Issued (entered by Eric Kinnear) The document is available at https://datatracker.ietf.org/doc/draft-age-masque-connect-ip/ From nobody Mon Nov 8 06:18:46 2021 Return-Path: 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 7CB833A0E8E for ; Mon, 8 Nov 2021 06:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 SE6TOLXSnvcP for ; Mon, 8 Nov 2021 06:18:34 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0972B3A1085 for ; Mon, 8 Nov 2021 06:18:18 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 1A8EI6hu027584 for ; Mon, 8 Nov 2021 06:18:18 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=L6YNvDxdIgWc7fwJA3nk+5xSM2XPqh3F2mqcqy0O+Q0=; b=eTYiZV6fNVDm+zc2/VXkmUi1xRV36Rjb7GWwEyYtxZq5W4YtynWEtJ9SogYWAOh+fyQZ rXGQQ/cjlAyjlKzFrf9zZomPefRF7yLnAkGtjKk4SwjB7lwYmC7wKQDm0M2v/GXL7yv1 G4Ev2nya0+/owEibXzeIl86jn+xg1hlgubJt2817PoRILgeDYSrG6qXgrfivEnno53pr quL4a4UA36eChGznOpR4AWbp0RxqdqrI7ylahr+05QVaMVKTuWBbOwcBLx9avgbrS7zE Vz7HwxnPkryYbh2Hl8PYZvAr4q8Wbxz7NYSePBfeSwHDU31EE1B6cZSYByDlm9rm7IDW 3w== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3c5rc2qeb6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 08 Nov 2021 06:18:18 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R2900L95BQFAQ10@rn-mailsvcp-mta-lapp03.rno.apple.com> for masque@ietf.org; Mon, 08 Nov 2021 06:18:15 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R2900T00BK5AR00@rn-mailsvcp-mmp-lapp01.rno.apple.com> for masque@ietf.org; Mon, 08 Nov 2021 06:18:15 -0800 (PST) X-V-A: X-V-T-CD: e400c3fca44d6a91d2a8abbcc83a4dcd X-V-E-CD: 88b20499efe58b80b2ae5033a6dfcba6 X-V-R-CD: a4c0736689a6edd51981a5f1581fc9b7 X-V-CD: 0 X-V-ID: 1498eb3d-2a03-4c5a-b3a8-c9bc83738aaa X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-08_05:2021-11-08, 2021-11-08 signatures=0 Received: from smtpclient.apple (unknown [17.234.108.216]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R2900107BQE0B00@rn-mailsvcp-mmp-lapp01.rno.apple.com> for masque@ietf.org; Mon, 08 Nov 2021 06:18:15 -0800 (PST) From: Eric Kinnear Content-type: multipart/alternative; boundary="Apple-Mail=_0D9AD012-F155-4E90-896F-F2C2C3768476" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.36\)) Message-id: Date: Mon, 08 Nov 2021 06:18:14 -0800 To: MASQUE X-Mailer: Apple Mail (2.3693.40.0.1.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-08_05:2021-11-08, 2021-11-08 signatures=0 Archived-At: Subject: [Masque] Draft Minutes for IETF 112 X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 14:18:45 -0000 --Apple-Mail=_0D9AD012-F155-4E90-896F-F2C2C3768476 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Many thanks to Robin Marx for taking notes today and to Lucas Pardue for = Jabber scribing. Draft minutes for today=E2=80=99s meeting are now available at: = https://github.com/ietf-wg-masque/wg-materials/blob/main/ietf112/minutes.m= d = Please send any corrections to the list or propose them as PRs against = the repository. Thanks, Eric and Chris --Apple-Mail=_0D9AD012-F155-4E90-896F-F2C2C3768476 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Many = thanks to Robin Marx for taking notes today and to Lucas Pardue for = Jabber scribing.

Draft= minutes for today=E2=80=99s meeting are now available at:
https://github.com/ietf-wg-masque/wg-materials/blob/main/ietf11= 2/minutes.md

Please send any corrections to the list or propose them as = PRs against the repository.

Thanks,
Eric and Chris

= --Apple-Mail=_0D9AD012-F155-4E90-896F-F2C2C3768476-- From nobody Mon Nov 8 07:52:16 2021 Return-Path: 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 1A3F93A109E for ; Mon, 8 Nov 2021 07:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 SceHjWWjg5Or for ; Mon, 8 Nov 2021 07:52:06 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3E13A109F for ; Mon, 8 Nov 2021 07:52:06 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 1A8Fi592044933; Mon, 8 Nov 2021 07:52:04 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=5WVD8d4M3FaEcQ6A0ia/5rBSwt4ZqAbyImuslIIW9Rk=; b=OQhBV6xRFCzBYyccKU9F32t3WCfE1i+i4sDv/r6fulMWbVQVW8cHcyWEcFRkMAVpH01b AO5UGwtz669zoxhuPFVgZj59nDWDTJhLa4fIO9JgXc1Uzu0ROg0kEtqyqu5tCF3e44i7 vPJEHpHM9/l1ZTUT6NA8ALPnIphC241bdMviKRovRbqy+BMl9cvxowX6AuJpUXO7QyO3 fQHnYfd7b+iIDT2bxK1DUSak4kg1IcJURvij3vpYCIi0a8XKh5YRGTyZ+UAOn+C6rb0i FpqOumS4qzWhmy5/6k/EYRDKfqxKNt947CIf7kQStbU7rG2IPDe1TwnS+XZdL13D3+EZ 5A== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3c5rc2s49a-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 08 Nov 2021 07:52:04 -0800 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R2900DS9G2QPO80@rn-mailsvcp-mta-lapp03.rno.apple.com>; Mon, 08 Nov 2021 07:52:02 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R2900K00FXVZU00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Mon, 08 Nov 2021 07:52:02 -0800 (PST) X-V-A: X-V-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-V-E-CD: a61b26eed4e61b2c405a2b1c0712ee7f X-V-R-CD: 623019d6aa5019d09887d7e1d6a7d948 X-V-CD: 0 X-V-ID: 9a21e31b-0809-4c61-bade-596d05b5d54d X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-08_05:2021-11-08, 2021-11-08 signatures=0 Received: from smtpclient.apple (unknown [17.234.36.4]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R2900O3KG2M5U00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Mon, 08 Nov 2021 07:52:02 -0800 (PST) From: Tommy Pauly Message-id: <7C41DE50-EE9B-4084-8A1D-88471664E23E@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_8C1767ED-9F38-405A-ABE2-27315E88E4D5" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3691.0.3\)) Date: Mon, 08 Nov 2021 07:51:58 -0800 In-reply-to: Cc: MASQUE To: Eric Rescorla References: X-Mailer: Apple Mail (2.3691.0.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-08_05:2021-11-08, 2021-11-08 signatures=0 Archived-At: Subject: Re: [Masque] Comments on draft-age-masque-connect-ip-01 X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 15:52:11 -0000 --Apple-Mail=_8C1767ED-9F38-405A-ABE2-27315E88E4D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 7, 2021, at 3:12 PM, Eric Rescorla wrote: >=20 > This document seems like a reasonable starting point. Good to see > the authors converging. Some technical comments below. Thanks for the comments! >=20 > Overall, I wonder if we should actually forbid the client from > using IP addresses in packets when the target is specified. > That would avoid goofy situations in which the client does >=20 > CONNECT 192.0.2.1 >=20 > And then sends to 192.0.2.2. I think it=E2=80=99s more consistent to define the behavior of what = error the sender receives when it sends a packet for which it didn=E2=80=99= t have an assigned source address or a valid destination route. Is this = cause for dropping the packet silently, sending an error capsule, or = closing the request stream with an error? I filed this to discuss: = https://github.com/tfpauly/draft-age-masque-connect-ip/issues/43 = >=20 > =20 > S 4.1. >=20 > target: The variable "target" contains a hostname or IP address of = a > specific host to which the client wants to proxy packets. If = the > "target" variable is not specified, the client is requesting to > communicate with any allowable host. If the target is an IP > address, the request will only support a single IP version. If > the target is a hostname, the server is expected to perform DNS > resolution to determine which route(s) to advertise to the = client. > The server SHOULD send a ROUTE_ADVERTISEMENT capsule that = includes > routes for all usable resolved addresses for the requested > hostname. >=20 > This treatment of DNS names seems like it's going to create a lot of > additional complexity: for instance, how does the client know which IP > to put in the dst field. You don't specify that the > ROUTE_ADVERTISEMENT MUST *only* include valid addresses. For instance, > suppose that the DNS name resolves to >=20 > 192.0.2.1 > 192.0.2.2 > 192.0.2.4 <-- No 192.0.2.3! > 192.0.2.5 > 192.0.2.6 > 192.0.2.7 >=20 > and the server advertises 192.0.2.1-192.0.2.7. >=20 > Given that this is an IP layer mechanism, I would simply remove the > DNS option; clients can always do DNS over the tunnel. I can see this either way. For cases where I don=E2=80=99t want a full tunnel, but just want to = talk to one host, I would need to open an IP flow for a DNS server. I = could of course open one, and then open a proxied flow to each target = address, and request the same local address I got on the first. This would work, but is more back-and-forth, and also doesn=E2=80=99t = give me a way to just ask the proxy to use it=E2=80=99s own DNS cache. = For cases like CONNECT and CONNECT-UDP, we=E2=80=99ve found it very = useful for latency to have the DNS cache run on the proxy, so that we = benefit from all clients going through the proxy sharing the same cache, = and not needing a round trip back to the client. To that end, I=E2=80=99d = like to at least allow connecting by a hostname in the protocol (even if = some proxies wouldn=E2=80=99t choose to support that). >=20 >=20 >=20 > S 4.2. > Is the server required to send ADDRESS_ASSIGN? If not, what is the > client supposed to use as it's source address? Also, what happens > if you only get a v6 address but need to talk to a v4 endpoint, > or vice versa. https://github.com/tfpauly/draft-age-masque-connect-ip/issues/42 = Probably the best thing to say is that any peer that can send packets = MUST first have received an ADDRESS_ASSIGN capsule. Regarding v4 and v6, yes, you do need the right family assigned. >=20 >=20 > S 4.2.3. > You should probably say something here about how in many cases > you shouldn't trust a ROUTE_ADVERTISEMENT. For instance, it's > incoherent for an ordinary consumer VPN client to start > advertising routes. A full-tunnel VPN server may not have a complex routing table, but = it=E2=80=99s still possible to have some =E2=80=9Cexcluded=E2=80=9D = routes that won=E2=80=99t be allowed (private subnets, etc). = Traditionally, most VPN protocols do always include the route = information. The =E2=80=9Ctrust=E2=80=9D here is just about what the = endpoint is willing to route/forward. What kind of warning were you imagining? Best, Tommy >=20 >=20 >=20 >=20 > --=20 > Masque mailing list > Masque@ietf.org > https://www.ietf.org/mailman/listinfo/masque --Apple-Mail=_8C1767ED-9F38-405A-ABE2-27315E88E4D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 7, 2021, at 3:12 PM, Eric Rescorla <ekr@rtfm.com> = wrote:

This document seems like a = reasonable starting point. Good to see
the authors = converging. Some technical comments below.

Thanks= for the comments!

Overall, I wonder if we should actually forbid the client = from
using IP addresses in packets when the target is = specified.
That would avoid goofy situations in which the = client does

   CONNECT = 192.0.2.1

And then sends to 192.0.2.2.

I= think it=E2=80=99s more consistent to define the behavior of what error = the sender receives when it sends a packet for which it didn=E2=80=99t = have an assigned source address or a valid destination route. Is this = cause for dropping the packet silently, sending an error capsule, or = closing the request stream with an error?



       
S 4.1.

   target:  The variable = "target" contains a hostname or IP address of a
  =     specific host to which the client wants to proxy = packets.  If the
      "target" = variable is not specified, the client is requesting to
      communicate with any allowable = host.  If the target is an IP
      = address, the request will only support a single IP version.  If
      the target is a hostname, the server is = expected to perform DNS
      resolution to = determine which route(s) to advertise to the client.
  =     The server SHOULD send a ROUTE_ADVERTISEMENT capsule that = includes
      routes for all usable = resolved addresses for the requested
      = hostname.

This treatment of DNS names seems = like it's going to create a lot of
additional complexity: = for instance, how does the client know which IP
to put in = the dst field. You don't specify that the
ROUTE_ADVERTISEMENT MUST *only* include valid addresses. For = instance,
suppose that the DNS name resolves to

  192.0.2.1
  = 192.0.2.2
  192.0.2.4 <-- No 192.0.2.3!
  192.0.2.5
  192.0.2.6
  192.0.2.7

and the server = advertises 192.0.2.1-192.0.2.7.

Given that = this is an IP layer mechanism, I would simply remove the
DNS= option; clients can always do DNS over the tunnel.


I can see this either = way.

For cases where I don=E2=80=99t = want a full tunnel, but just want to talk to one host, I would need to = open an IP flow for a DNS server. I could of course open one, and then = open a proxied flow to each target address, and request the same local = address I got on the first.

This = would work, but is more back-and-forth, and also doesn=E2=80=99t give me = a way to just ask the proxy to use it=E2=80=99s own DNS cache. For cases = like CONNECT and CONNECT-UDP, we=E2=80=99ve found it very useful for = latency to have the DNS cache run on the proxy, so that we benefit from = all clients going through the proxy sharing the same cache, and not = needing a round trip back to the client. To that end, I=E2=80=99d like = to at least allow connecting by a hostname in the = protocol (even if some proxies wouldn=E2=80=99t choose to support = that).




S 4.2.
Is the server required to = send ADDRESS_ASSIGN? If not, what is the
client supposed = to use as it's source address? Also, what happens
if you = only get a v6 address but need to talk to a v4 endpoint,
or = vice versa.

https://github.com/tfpauly/draft-age-masque-connect-ip/issues/4= 2

Probably the best thing to say = is that any peer that can send packets MUST first have received an = ADDRESS_ASSIGN capsule.

Regarding v4 = and v6, yes, you do need the right family assigned.



S = 4.2.3.
You should probably say something here about how in = many cases
you shouldn't trust a ROUTE_ADVERTISEMENT. For = instance, it's
incoherent for an ordinary consumer VPN = client to start
advertising routes.

A= full-tunnel VPN server may not have a complex routing table, but it=E2=80= =99s still possible to have some =E2=80=9Cexcluded=E2=80=9D routes that = won=E2=80=99t be allowed (private subnets, etc). Traditionally, most VPN = protocols do always include the route information. The =E2=80=9Ctrust=E2=80= =9D here is just about what the endpoint is willing to = route/forward.

What kind of warning = were you imagining?

Best,
Tommy





--
Masque mailing list
Masque@ietf.org
https://www.ietf.org/mailman/listinfo/masque

= --Apple-Mail=_8C1767ED-9F38-405A-ABE2-27315E88E4D5-- From nobody Mon Nov 8 07:56:33 2021 Return-Path: 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 40D8B3A1066 for ; Mon, 8 Nov 2021 07:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.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 XJ_PwpRs0doe for ; Mon, 8 Nov 2021 07:56:28 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 EFC553A10A9 for ; Mon, 8 Nov 2021 07:56:27 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id f10so17429534ilu.5 for ; Mon, 08 Nov 2021 07:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rOdD6m0AySN3ZTHmADdLT/U8hK477SriUlozkLXyHcE=; b=bQGx49la8H3fvT8cLniwPIcXifetsPbFu80XbVKyMiHMGBPRAto/BcIWVnpEuZuuZ4 qi91spjySJdzuzxQ9OTz5armqiqFvDH3/pkuNbbiQuhAFTQVWLhU7ghKalKYGLt8sJ1m rSmnO/caEtMocK/g4igvZFlAuz6ic6UqCDPjnAxqXfvxpFF1FNYCi8QiwM9ILAQlgnmU KcUBmRu4VlJTQRG9+WIGF+TWhVhhPiE7KE5jLE8wUHAUyx0OjYYYXu8o/9rfU1BleDyl hf9nZY9m8Zy288MaBw1ruol6XbOjNaTQmzvYZNPD2hxIVgWbPt672OfoyTWpiMUGj58j sTng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rOdD6m0AySN3ZTHmADdLT/U8hK477SriUlozkLXyHcE=; b=IFnsfhfpMTVMMgk9Kg8vrX6bMpE/mXKX/a2PdxNphBdHp83tdIFQ+j4zCC/SncRpvX HMaoNm3MSf3uiliKeOIvwXwq72OqhNeNB6qySBYIQzeo/vWc094V0VL0FB7gukvM5tCp lB7zTJEGtS5Klm4YjUr+/mgKefZZrrH8++F+V8nT7JGBxKZq3vJeA0HZdNn7wdAOXO0+ 33lADd7BqWLZFCyMM9mzrkXb5ETt2l/QWHojnhMt2kFIK1wiZSXqGdb1KV64apnRbC2S 6/hPoSnndlig9yrL6SvuDe536AKsyrP1o5c4W62XhivFbRTvQ8St067OPKoYbz/MlE5/ 7mMQ== X-Gm-Message-State: AOAM532tySJb5ehCzirK6IE9uJ20kd87sr0Ft+xYhmffsMRKeliT4HsW 0lDAx8XwUKO+hc9gaSp9Mm4IYi/ka6GrUPwL8Qr4V/j1hVo= X-Google-Smtp-Source: ABdhPJz8t/4HEKUA7/erbwi7gTrc/52al0F4kjhEWXQDFXQmpxYZmg7+i8ut4kGYylvwWwPmmApJ6TnDCu6XwLQ4bXg= X-Received: by 2002:a92:c569:: with SMTP id b9mr37264ilj.39.1636386985271; Mon, 08 Nov 2021 07:56:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 8 Nov 2021 07:55:49 -0800 Message-ID: To: Eric Kinnear Cc: MASQUE Content-Type: multipart/alternative; boundary="000000000000f8fb3705d04908da" Archived-At: Subject: Re: [Masque] Adoption call for draft-age-masque-connect-ip X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 15:56:32 -0000 --000000000000f8fb3705d04908da Content-Type: text/plain; charset="UTF-8" As I said at the microphone, I favor adoption On Mon, Nov 8, 2021 at 6:07 AM Eric Kinnear wrote: > Hi all, > > At IETF 112 there was significant support in the room to adopt > draft-age-masque-connect-ip as a starting point for our CONNECT-IP efforts. > > This email begins an adoption call for draft-age-masque-connect-ip. > > The datatracker page for this document can be found here: > https://datatracker.ietf.org/doc/draft-age-masque-connect-ip/ > > And the GitHub repository can be found here: > https://github.com/tfpauly/draft-age-masque-connect-ip > > This call for adoption will conclude on November 22. > > Thanks, > Eric and Chris > -- > Masque mailing list > Masque@ietf.org > https://www.ietf.org/mailman/listinfo/masque > --000000000000f8fb3705d04908da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I said at the microphone, I favor adoption
On Mon, N= ov 8, 2021 at 6:07 AM Eric Kinnear <ekinnear=3D40apple.com@dmarc.ietf.org> wrote:
Hi all,=C2=A0

At IETF 112 there= was significant support in the room to adopt draft-age-masque-connect-ip a= s a starting point for our CONNECT-IP efforts.

Thi= s email begins an adoption call for draft-age-masque-connect-ip.
=
The datatracker page for this document can be found here:=C2= =A0

And the GitHub repository ca= n be found here:

This call for adoption will c= onclude on November 22.

Thanks,=C2=A0
Er= ic and Chris
--
Masque mailing list
Masque@ietf.org https://www.ietf.org/mailman/listinfo/masque
--000000000000f8fb3705d04908da-- From nobody Mon Nov 8 08:44:20 2021 Return-Path: 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 1B5673A11D1 for ; Mon, 8 Nov 2021 08:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.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 hjs4Cf1o0LU2 for ; Mon, 8 Nov 2021 08:44:14 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 2DF243A0ED6 for ; Mon, 8 Nov 2021 08:44:14 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id i11so8357099ilv.13 for ; Mon, 08 Nov 2021 08:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K/GGir03JfELbpVO6oOGuHmMTGgCIsAarBJSmLVYGNk=; b=qmRLLY1yxTKkSMYuEqDBvB/B9+wXjcTEVAlGvYo/xBQC6xX1DaPxrWvF6/4mgRGMAo +i7Fcu/ZbfcFGhXafzdEbo9nmIlhJKL9jcUp79QUnvzivz1sOq1NM2rhYhAeZE2UcqjI zqqLOKIpXKM8GqPcXAglvpIvS5cwRqUA76DLip9QMgu3Ly+vF6e/YSjnZTPzj9+xBCm7 VBVWdq7/no8t6yzqongQePgXTo0aUYNN5c9gQhsr+myo8gzUyyD2xMz5bMF2HkmK4U/w 4DwUbXIe6yOlRpL4bH/s5M+h3aDvdoOmb66a7b1+R2YAkt218HrvGY4heo6TN/XRx1Ft IZnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K/GGir03JfELbpVO6oOGuHmMTGgCIsAarBJSmLVYGNk=; b=g418Od3gskyudi6IglErVyG13GnrL7PEv1UDeVu3vcFFuaaY+vBm9n86t+Rw7UtYrm WHPxBW7/iwX2LYR3qTvF0P6+zWnY1uiN2Gv9eydtpaHFeTVJGby0ZVvrqZZpSbjo3BaR Nl749QW9ikrRIh2UKfB9mh+Rbg+v5c/6SxyJ8f8+I2djhPqt4thc/goOhRwfuWoAeKq/ sO110jhRXepF9Bd4Tt1NexR+4x0w2E/gZdunKqPhFYUp9vHcHBt/yu/a9pgXNfGoT2kn PFA62YS78XwyjFFuXJbcNE/LTU7mHz+4B8DjXz4npn/N0AF/lz7lQEHGzdwAa0czBame ogIg== X-Gm-Message-State: AOAM531uwZOJax/RaZqQDIaw986viQwhsCB8GXi0ACvAsDp0bdoexTAr snIMNh8EMbR22cg8wh91EMB8oVFW1ZbedOZgydDQjQ== X-Google-Smtp-Source: ABdhPJwOI34pJ7U3FJu+KwA91GvO1fcHTIaoHzC74R+kUoJPGD4sk2WTndOH4eQ9OOcxHniwHyLhITC8FkfrnI+tvDg= X-Received: by 2002:a92:c051:: with SMTP id o17mr305710ilf.276.1636389850008; Mon, 08 Nov 2021 08:44:10 -0800 (PST) MIME-Version: 1.0 References: <7C41DE50-EE9B-4084-8A1D-88471664E23E@apple.com> In-Reply-To: <7C41DE50-EE9B-4084-8A1D-88471664E23E@apple.com> From: Eric Rescorla Date: Mon, 8 Nov 2021 08:43:33 -0800 Message-ID: To: Tommy Pauly Cc: MASQUE Content-Type: multipart/alternative; boundary="000000000000b9629605d049b398" Archived-At: Subject: Re: [Masque] Comments on draft-age-masque-connect-ip-01 X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 16:44:19 -0000 --000000000000b9629605d049b398 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 8, 2021 at 7:52 AM Tommy Pauly wrote: > > > On Nov 7, 2021, at 3:12 PM, Eric Rescorla wrote: > > This document seems like a reasonable starting point. Good to see > the authors converging. Some technical comments below. > > > Thanks for the comments! > > > Overall, I wonder if we should actually forbid the client from > using IP addresses in packets when the target is specified. > That would avoid goofy situations in which the client does > > CONNECT 192.0.2.1 > > And then sends to 192.0.2.2. > > > I think it=E2=80=99s more consistent to define the behavior of what error= the > sender receives when it sends a packet for which it didn=E2=80=99t have a= n assigned > source address or a valid destination route. Is this cause for dropping t= he > packet silently, sending an error capsule, or closing the request stream > with an error? > > I filed this to discuss: > https://github.com/tfpauly/draft-age-masque-connect-ip/issues/43 > I could live with that, though I do like to make it impossible to do bad things. > S 4.1. > > target: The variable "target" contains a hostname or IP address of a > specific host to which the client wants to proxy packets. If the > "target" variable is not specified, the client is requesting to > communicate with any allowable host. If the target is an IP > address, the request will only support a single IP version. If > the target is a hostname, the server is expected to perform DNS > resolution to determine which route(s) to advertise to the client. > The server SHOULD send a ROUTE_ADVERTISEMENT capsule that includes > routes for all usable resolved addresses for the requested > hostname. > > This treatment of DNS names seems like it's going to create a lot of > additional complexity: for instance, how does the client know which IP > to put in the dst field. You don't specify that the > ROUTE_ADVERTISEMENT MUST *only* include valid addresses. For instance, > suppose that the DNS name resolves to > > 192.0.2.1 > 192.0.2.2 > 192.0.2.4 <-- No 192.0.2.3! > 192.0.2.5 > 192.0.2.6 > 192.0.2.7 > > and the server advertises 192.0.2.1-192.0.2.7. > > Given that this is an IP layer mechanism, I would simply remove the > DNS option; clients can always do DNS over the tunnel. > > > > I can see this either way. > > For cases where I don=E2=80=99t want a full tunnel, but just want to talk= to one > host, I would need to open an IP flow for a DNS server. I could of course > open one, and then open a proxied flow to each target address, and reques= t > the same local address I got on the first. > > This would work, but is more back-and-forth, and also doesn=E2=80=99t giv= e me a > way to just ask the proxy to use it=E2=80=99s own DNS cache. For cases li= ke CONNECT > and CONNECT-UDP, we=E2=80=99ve found it very useful for latency to have t= he DNS > cache run on the proxy, so that we benefit from all clients going through > the proxy sharing the same cache, and not needing a round trip back to th= e > client. To that end, I=E2=80=99d like to at least *allow* connecting by a > hostname in the protocol (even if some proxies wouldn=E2=80=99t choose to= support > that). > I would make several points here. First, while it's desirable to be able to use the proxy's DNS cache, it's increasingly insufficient to simply get the A/AAAA records, for reasons such as SVCB. For instance, you wouldn't be able to do ECH using the DNS version alone because you would need to look up the SVCB. So, while it does incur a round trip, it seems like you are going to need to do a DNS resolution for this case. Second, even taken on its own terms, if I understand this mechanism correctly, I think it's still broken for the reason I mentioned above. The problem is that you are using the ROUTE_ADVERTISEMENT as an implicit DNS resolution--to tell you what to put in the dst-addr. If that's true, then I think you need to require that the ROUTE_ADVERTISEMENT to be strict. > > > S 4.2. > Is the server required to send ADDRESS_ASSIGN? If not, what is the > client supposed to use as it's source address? Also, what happens > if you only get a v6 address but need to talk to a v4 endpoint, > or vice versa. > > > https://github.com/tfpauly/draft-age-masque-connect-ip/issues/42 > > Probably the best thing to say is that any peer that can send packets MUS= T > first have received an ADDRESS_ASSIGN capsule. > > Regarding v4 and v6, yes, you do need the right family assigned. > > > > S 4.2.3. > You should probably say something here about how in many cases > you shouldn't trust a ROUTE_ADVERTISEMENT. For instance, it's > incoherent for an ordinary consumer VPN client to start > advertising routes. > > > A full-tunnel VPN server may not have a complex routing table, but it=E2= =80=99s > still possible to have some =E2=80=9Cexcluded=E2=80=9D routes that won=E2= =80=99t be allowed > (private subnets, etc). Traditionally, most VPN protocols do always inclu= de > the route information. The =E2=80=9Ctrust=E2=80=9D here is just about wha= t the endpoint is > willing to route/forward. > > What kind of warning were you imagining? > "Note: peers MUST NOT blindly trust ROUTE_ADVERTISEMENT. They MUST filter it through local policy" -Ekr > Best, > Tommy > > > > > > -- > Masque mailing list > Masque@ietf.org > https://www.ietf.org/mailman/listinfo/masque > > > --000000000000b9629605d049b398 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 8, 2021 at 7:52 AM Tommy = Pauly <tpauly@apple.com> wrot= e:


On= Nov 7, 2021, at 3:12 PM, Eric Rescorla <ekr@rtfm.com> wrote:

This document seems like a reasonable starting point. Good to see
the authors converging. Some technical comments below.

Thanks for the comments!

Overall, I wonder if we sho= uld actually forbid the client from
using IP addresses in packets when t= he target is specified.
That would avoid goofy situations in which the c= lient does

=C2=A0 =C2=A0CONNECT 192.0.2.1

And then sends to 1= 92.0.2.2.

I think it= =E2=80=99s more consistent to define the behavior of what error the sender = receives when it sends a packet for which it didn=E2=80=99t have an assigne= d source address or a valid destination route. Is this cause for dropping t= he packet silently, sending an error capsule, or closing the request stream= with an error?


I could live wi= th that, though I do like to make it impossible to do bad things.


<= div>

S 4.1.

=C2=A0 =C2=A0target: =C2=A0The = variable "target" contains a hostname or IP address of a
=C2= =A0 =C2=A0 =C2=A0 specific host to which the client wants to proxy packets.= =C2=A0 If the
=C2=A0 =C2=A0 =C2=A0 "target" variable is not sp= ecified, the client is requesting to
=C2=A0 =C2=A0 =C2=A0 communicate wi= th any allowable host.=C2=A0 If the target is an IP
=C2=A0 =C2=A0 =C2=A0= address, the request will only support a single IP version.=C2=A0 If
= =C2=A0 =C2=A0 =C2=A0 the target is a hostname, the server is expected to pe= rform DNS
=C2=A0 =C2=A0 =C2=A0 resolution to determine which route(s) to= advertise to the client.
=C2=A0 =C2=A0 =C2=A0 The server SHOULD send a = ROUTE_ADVERTISEMENT capsule that includes
=C2=A0 =C2=A0 =C2=A0 routes fo= r all usable resolved addresses for the requested
=C2=A0 =C2=A0 =C2=A0 h= ostname.

This treatment of DNS names seems like it's going to cr= eate a lot of
additional complexity: for instance, how does the client k= now which IP
to put in the dst field. You don't specify that the
= ROUTE_ADVERTISEMENT MUST *only* include valid addresses. For instance,
s= uppose that the DNS name resolves to

=C2=A0 192.0.2.1
=C2=A0 192.= 0.2.2
=C2=A0 192.0.2.4 <-- No 192.0.2.3!
=C2=A0 192.0.2.5
=C2= =A0 192.0.2.6
=C2=A0 192.0.2.7

and the server advertises 192.0.2.= 1-192.0.2.7.

Given that this is an IP layer mechanism, I would simpl= y remove the
DNS option; clients can always do DNS over the tunnel.
<= /div>


I can see = this either way.

For cases where I don=E2=80=99t w= ant a full tunnel, but just want to talk to one host, I would need to open = an IP flow for a DNS server. I could of course open one, and then open a pr= oxied flow to each target address, and request the same local address I got= on the first.

This would work, but is more back-a= nd-forth, and also doesn=E2=80=99t give me a way to just ask the proxy to u= se it=E2=80=99s own DNS cache. For cases like CONNECT and CONNECT-UDP, we= =E2=80=99ve found it very useful for latency to have the DNS cache run on t= he proxy, so that we benefit from all clients going through the proxy shari= ng the same cache, and not needing a round trip back to the client. To that= end, I=E2=80=99d like to at least allow=C2=A0connecting by a hostna= me in the protocol (even if some proxies wouldn=E2=80=99t choose to support= that).

I would make seve= ral points here.

First, while it's desirable t= o be able to use the proxy's DNS cache, it's increasingly insuffici= ent to simply get the A/AAAA records, for reasons such as SVCB. For instanc= e, you wouldn't be able to do ECH using the DNS version alone because y= ou would need to look up the SVCB. So, while it does incur a round trip, it= seems like you are going to need to do a DNS resolution for this case.

Second, even taken on its own terms, if I understand = this mechanism correctly, I think it's still broken for the reason I me= ntioned above. The problem is that you are using the ROUTE_ADVERTISEMENT as= an implicit DNS resolution--to tell you what to put in the dst-addr. If th= at's true, then I think you need to require that the ROUTE_ADVERTISEMEN= T to be strict.





S 4.2.
Is= the server required to send ADDRESS_ASSIGN? If not, what is the
client = supposed to use as it's source address? Also, what happens
if you on= ly get a v6 address but need to talk to a v4 endpoint,
or vice versa.

https://= github.com/tfpauly/draft-age-masque-connect-ip/issues/42

=
Probably the best thing to say is that any peer that can send pa= ckets MUST first have received an ADDRESS_ASSIGN capsule.

Regarding v4 and v6, yes, you do need the right family assigned.



S = 4.2.3.
You should probably say something here about how in many casesyou shouldn't trust a ROUTE_ADVERTISEMENT. For instance, it's
i= ncoherent for an ordinary consumer VPN client to start
advertising route= s.

A full-tunnel VPN = server may not have a complex routing table, but it=E2=80=99s still possibl= e to have some =E2=80=9Cexcluded=E2=80=9D routes that won=E2=80=99t be allo= wed (private subnets, etc). Traditionally, most VPN protocols do always inc= lude the route information. The =E2=80=9Ctrust=E2=80=9D here is just about = what the endpoint is willing to route/forward.

Wha= t kind of warning were you imagining?
"Note: peers MUST NOT blindly trust ROUTE_ADVERTISEMENT. = They MUST filter it through local policy"

-Ek= r


--000000000000b9629605d049b398-- From nobody Mon Nov 8 10:04:15 2021 Return-Path: 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 4C2023A0C6E for ; Mon, 8 Nov 2021 10:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 cczvHhgS4E_X for ; Mon, 8 Nov 2021 10:04:09 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.rno.apple.com [17.179.253.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281973A0C71 for ; Mon, 8 Nov 2021 10:04:09 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 1A8I2lG1020875; Mon, 8 Nov 2021 10:04:08 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=/zynrbpjp5mo4UmL+B61iUCTbqpOB89KOASapej72jQ=; b=GyDf4UjYQmuaeLVUiNHyvghtW/SJ8aF5Tox+oZprSvVxYPRtrynvDSAYvYHw9ZDIGs3S qjAY4NSbDL+MzjiIkufKpfr8RsOPPLdjpDXSD6wT+g7YpLoHn0o88TaCKK3DfvZ7eooK Nnf4R8pYfCLLDqKVm2VVFjEJWN3cxljmzjCSTTXhLzFvW3YqSZo5xsR0NZ4hky4yrDmg NRdm4njKG35N5aA9QhiA7JWVPJjUkMEp07ZN8gCU5KMigxvDu11VtL/XEqRhVjQ8X1SQ YzVGaWwoRw62ekE5ZQNv0Z0iHd5z/O+wgU/MlCyxmYMnYFIEMVQJ6yOdikcDSAnCfCm1 MQ== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 3c5n8702pr-10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 08 Nov 2021 10:04:08 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R2900ZN2M6BJJF0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Mon, 08 Nov 2021 10:03:47 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R2900H00M1GRA00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 08 Nov 2021 10:03:47 -0800 (PST) X-Va-A: X-Va-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-Va-E-CD: a61b26eed4e61b2c405a2b1c0712ee7f X-Va-R-CD: 623019d6aa5019d09887d7e1d6a7d948 X-Va-CD: 0 X-Va-ID: cb4d7a36-0cdd-4b64-b437-a0e57f21c45f X-V-A: X-V-T-CD: 7a77f9138d60728e010dfb6f2118f5e7 X-V-E-CD: a61b26eed4e61b2c405a2b1c0712ee7f X-V-R-CD: 623019d6aa5019d09887d7e1d6a7d948 X-V-CD: 0 X-V-ID: 17677f87-bee5-494a-a433-21170ae868ad X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-08_05:2021-11-08, 2021-11-08 signatures=0 Received: from smtpclient.apple (unknown [17.234.36.4]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R2900YGJM6AIZ00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 08 Nov 2021 10:03:46 -0800 (PST) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_74955FB9-3D7D-459B-8699-5DB3536DA352" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3691.0.3\)) Date: Mon, 08 Nov 2021 10:03:45 -0800 In-reply-to: Cc: MASQUE To: Eric Rescorla References: <7C41DE50-EE9B-4084-8A1D-88471664E23E@apple.com> X-Mailer: Apple Mail (2.3691.0.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-08_06:2021-11-08, 2021-11-08 signatures=0 Archived-At: Subject: Re: [Masque] Comments on draft-age-masque-connect-ip-01 X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 18:04:13 -0000 --Apple-Mail=_74955FB9-3D7D-459B-8699-5DB3536DA352 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 8, 2021, at 8:43 AM, Eric Rescorla wrote: >=20 >=20 >=20 > On Mon, Nov 8, 2021 at 7:52 AM Tommy Pauly > wrote: >=20 >=20 >> On Nov 7, 2021, at 3:12 PM, Eric Rescorla > wrote: >>=20 >> This document seems like a reasonable starting point. Good to see >> the authors converging. Some technical comments below. >=20 > Thanks for the comments! >>=20 >> Overall, I wonder if we should actually forbid the client from >> using IP addresses in packets when the target is specified. >> That would avoid goofy situations in which the client does >>=20 >> CONNECT 192.0.2.1 >>=20 >> And then sends to 192.0.2.2. >=20 > I think it=E2=80=99s more consistent to define the behavior of what = error the sender receives when it sends a packet for which it didn=E2=80=99= t have an assigned source address or a valid destination route. Is this = cause for dropping the packet silently, sending an error capsule, or = closing the request stream with an error? >=20 > I filed this to discuss: = https://github.com/tfpauly/draft-age-masque-connect-ip/issues/43 = >=20 > I could live with that, though I do like to make it impossible to do = bad things. Okay, let=E2=80=99s discuss on the issue. >=20 >=20 >>=20 >> S 4.1. >>=20 >> target: The variable "target" contains a hostname or IP address = of a >> specific host to which the client wants to proxy packets. If = the >> "target" variable is not specified, the client is requesting to >> communicate with any allowable host. If the target is an IP >> address, the request will only support a single IP version. If >> the target is a hostname, the server is expected to perform DNS >> resolution to determine which route(s) to advertise to the = client. >> The server SHOULD send a ROUTE_ADVERTISEMENT capsule that = includes >> routes for all usable resolved addresses for the requested >> hostname. >>=20 >> This treatment of DNS names seems like it's going to create a lot of >> additional complexity: for instance, how does the client know which = IP >> to put in the dst field. You don't specify that the >> ROUTE_ADVERTISEMENT MUST *only* include valid addresses. For = instance, >> suppose that the DNS name resolves to >>=20 >> 192.0.2.1 >> 192.0.2.2 >> 192.0.2.4 <-- No 192.0.2.3! >> 192.0.2.5 >> 192.0.2.6 >> 192.0.2.7 >>=20 >> and the server advertises 192.0.2.1-192.0.2.7. >>=20 >> Given that this is an IP layer mechanism, I would simply remove the >> DNS option; clients can always do DNS over the tunnel. >=20 >=20 > I can see this either way. >=20 > For cases where I don=E2=80=99t want a full tunnel, but just want to = talk to one host, I would need to open an IP flow for a DNS server. I = could of course open one, and then open a proxied flow to each target = address, and request the same local address I got on the first. >=20 > This would work, but is more back-and-forth, and also doesn=E2=80=99t = give me a way to just ask the proxy to use it=E2=80=99s own DNS cache. = For cases like CONNECT and CONNECT-UDP, we=E2=80=99ve found it very = useful for latency to have the DNS cache run on the proxy, so that we = benefit from all clients going through the proxy sharing the same cache, = and not needing a round trip back to the client. To that end, I=E2=80=99d = like to at least allow connecting by a hostname in the protocol (even if = some proxies wouldn=E2=80=99t choose to support that). >=20 > I would make several points here. >=20 > First, while it's desirable to be able to use the proxy's DNS cache, = it's increasingly insufficient to simply get the A/AAAA records, for = reasons such as SVCB. For instance, you wouldn't be able to do ECH using = the DNS version alone because you would need to look up the SVCB. So, = while it does incur a round trip, it seems like you are going to need to = do a DNS resolution for this case. Yes, ECH does require doing a DNS lookup, but (a) ECH may not be = applicable to the type of connection I=E2=80=99m doing with CONNECT-IP = and (b) the records for A / AAAA / HTTPS / SVCB may have different TTLs = and thus have different caching benefits. >=20 > Second, even taken on its own terms, if I understand this mechanism = correctly, I think it's still broken for the reason I mentioned above. = The problem is that you are using the ROUTE_ADVERTISEMENT as an implicit = DNS resolution--to tell you what to put in the dst-addr. If that's true, = then I think you need to require that the ROUTE_ADVERTISEMENT to be = strict. Yes, I agree that the route advertisement needs to be strict if this is = allowed. >=20 >=20 >>=20 >>=20 >>=20 >> S 4.2. >> Is the server required to send ADDRESS_ASSIGN? If not, what is the >> client supposed to use as it's source address? Also, what happens >> if you only get a v6 address but need to talk to a v4 endpoint, >> or vice versa. >=20 > https://github.com/tfpauly/draft-age-masque-connect-ip/issues/42 = >=20 > Probably the best thing to say is that any peer that can send packets = MUST first have received an ADDRESS_ASSIGN capsule. >=20 > Regarding v4 and v6, yes, you do need the right family assigned. >=20 >>=20 >>=20 >> S 4.2.3. >> You should probably say something here about how in many cases >> you shouldn't trust a ROUTE_ADVERTISEMENT. For instance, it's >> incoherent for an ordinary consumer VPN client to start >> advertising routes. >=20 > A full-tunnel VPN server may not have a complex routing table, but = it=E2=80=99s still possible to have some =E2=80=9Cexcluded=E2=80=9D = routes that won=E2=80=99t be allowed (private subnets, etc). = Traditionally, most VPN protocols do always include the route = information. The =E2=80=9Ctrust=E2=80=9D here is just about what the = endpoint is willing to route/forward. >=20 > What kind of warning were you imagining? >=20 > "Note: peers MUST NOT blindly trust ROUTE_ADVERTISEMENT. They MUST = filter it through local policy" Hm, OK. What would =E2=80=9Clocal policy=E2=80=9D be here? I guess in = the case of personal VPN, my client may expect a full tunnel, but if the = server tells me I can=E2=80=99t route to a specific subnet (maybe it = doesn=E2=80=99t allow 10.0.0/24, reasonably), my only recourse would be = to fail the connection, not to try to send to addresses that are = disallowed. Tommy >=20 > -Ekr >=20 >=20 > Best, > Tommy >=20 >>=20 >>=20 >>=20 >>=20 >> --=20 >> Masque mailing list >> Masque@ietf.org >> https://www.ietf.org/mailman/listinfo/masque = >=20 > --=20 > Masque mailing list > Masque@ietf.org > https://www.ietf.org/mailman/listinfo/masque = --Apple-Mail=_74955FB9-3D7D-459B-8699-5DB3536DA352 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 8, 2021, at 8:43 AM, Eric Rescorla <ekr@rtfm.com> = wrote:



On Mon, Nov = 8, 2021 at 7:52 AM Tommy Pauly <tpauly@apple.com> wrote:


On Nov = 7, 2021, at 3:12 PM, Eric Rescorla <ekr@rtfm.com> wrote:

This document seems like a reasonable starting point. Good to = see
the authors converging. Some technical comments = below.

Thanks for the comments!

Overall, I wonder if we should actually forbid = the client from
using IP addresses in packets when the = target is specified.
That would avoid goofy situations in = which the client does

   CONNECT = 192.0.2.1

And then sends to 192.0.2.2.

I think it=E2=80=99s more consistent to = define the behavior of what error the sender receives when it sends a = packet for which it didn=E2=80=99t have an assigned source address or a = valid destination route. Is this cause for dropping the packet silently, = sending an error capsule, or closing the request stream with an = error?

I filed = this to discuss: https://github.com/tfpauly/draft-age-masque-connect-ip/issues/4= 3

I could live with that, though I do = like to make it impossible to do bad = things.

Okay, let=E2=80=99s discuss on the issue.


S 4.1.

   target: =  The variable "target" contains a hostname or IP address of a
      specific host to which the = client wants to proxy packets.  If the
    =   "target" = variable is not specified, the client is requesting to
      communicate with any = allowable host.  If the target is an IP
    =   address, the = request will only support a single IP version.  If
      the target is a hostname, = the server is expected to perform DNS
    =   resolution to = determine which route(s) to advertise to the client.
  =     The = server SHOULD send a ROUTE_ADVERTISEMENT capsule that includes
      routes for all usable = resolved addresses for the requested
    =   hostname.

This treatment of DNS names seems like it's = going to create a lot of
additional complexity: for = instance, how does the client know which IP
to put in the = dst field. You don't specify that the
ROUTE_ADVERTISEMENT = MUST *only* include valid addresses. For instance,
suppose = that the DNS name resolves to

  192.0.2.1
  192.0.2.2
  192.0.2.4 <-- No = 192.0.2.3!
  192.0.2.5
  192.0.2.6
  192.0.2.7

and the server advertises 192.0.2.1-192.0.2.7.

Given that this is an IP layer mechanism, I = would simply remove the
DNS option; clients can always do = DNS over the tunnel.


I can see this either way.

For cases where I don=E2=80=99t want a = full tunnel, but just want to talk to one host, I would need to open an = IP flow for a DNS server. I could of course open one, and then open a = proxied flow to each target address, and request the same local address = I got on the first.

This would work, but is more back-and-forth, and also = doesn=E2=80=99t give me a way to just ask the proxy to use it=E2=80=99s = own DNS cache. For cases like CONNECT and CONNECT-UDP, we=E2=80=99ve = found it very useful for latency to have the DNS cache run on the proxy, = so that we benefit from all clients going through the proxy sharing the = same cache, and not needing a round trip back to the client. To that = end, I=E2=80=99d like to at least allow connecting by a hostname in the protocol (even = if some proxies wouldn=E2=80=99t choose to support = that).

I would make several points = here.

First, = while it's desirable to be able to use the proxy's DNS cache, it's = increasingly insufficient to simply get the A/AAAA records, for reasons = such as SVCB. For instance, you wouldn't be able to do ECH using the DNS = version alone because you would need to look up the SVCB. So, while it = does incur a round trip, it seems like you are going to need to do a DNS = resolution for this case.

Yes, ECH does require doing a DNS lookup, but (a) = ECH may not be applicable to the type of connection I=E2=80=99m doing = with CONNECT-IP and (b) the records for A / AAAA / HTTPS / SVCB may have = different TTLs and thus have different caching benefits.


Second, even taken on its own terms, if = I understand this mechanism correctly, I think it's still broken for the = reason I mentioned above. The problem is that you are using the = ROUTE_ADVERTISEMENT as an implicit DNS resolution--to tell you what to = put in the dst-addr. If that's true, then I think you need to require = that the ROUTE_ADVERTISEMENT to be = strict.

Yes,= I agree that the route advertisement needs to be strict if this is = allowed.





S 4.2.
Is the server required to send = ADDRESS_ASSIGN? If not, what is the
client supposed to use = as it's source address? Also, what happens
if you only get = a v6 address but need to talk to a v4 endpoint,
or vice = versa.

https://github.com/tfpauly/draft-age-masque-connect-ip/issues/4= 2

Probably = the best thing to say is that any peer that can send packets MUST first = have received an ADDRESS_ASSIGN capsule.

Regarding v4 and v6, yes, you do need = the right family assigned.



S 4.2.3.
You = should probably say something here about how in many cases
you shouldn't trust a ROUTE_ADVERTISEMENT. For instance, = it's
incoherent for an ordinary consumer VPN client to = start
advertising routes.

A full-tunnel VPN server may not have a = complex routing table, but it=E2=80=99s still possible to have some = =E2=80=9Cexcluded=E2=80=9D routes that won=E2=80=99t be allowed (private = subnets, etc). Traditionally, most VPN protocols do always include the = route information. The =E2=80=9Ctrust=E2=80=9D here is just about what = the endpoint is willing to route/forward.

What kind of warning were you = imagining?

"Note: peers MUST NOT blindly trust = ROUTE_ADVERTISEMENT. They MUST filter it through local = policy"

Hm, OK. What would =E2=80=9Clocal policy=E2=80=9D = be here? I guess in the case of personal VPN, my client may expect a = full tunnel, but if the server tells me I can=E2=80=99t route to a = specific subnet (maybe it doesn=E2=80=99t allow 10.0.0/24, reasonably), = my only recourse would be to fail the connection, not to try to send to = addresses that are disallowed.

Tommy


-Ekr

-- Masque mailing list
Masque@ietf.org
https://www.ietf.org/mailman/listinfo/masque

= --Apple-Mail=_74955FB9-3D7D-459B-8699-5DB3536DA352-- From nobody Mon Nov 8 10:08:45 2021 Return-Path: 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 A74623A0CB0 for ; Mon, 8 Nov 2021 10:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 SUIHe58p2gfe for ; Mon, 8 Nov 2021 10:08:38 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 5F90C3A0CAF for ; Mon, 8 Nov 2021 10:08:38 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id b11so3130419pld.12 for ; Mon, 08 Nov 2021 10:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dvIm+X1JYFdEGpRw7lPLyV5Hb2SNidvlKgP/6gqYGuA=; b=f2wnDl9qYtUti6H7X6TynzSFiI3GAhcnS5gh/SI1OymQS55vKlwQy2eGeq56srMp7F nU+KH1zUQ3cR3CZcr4jCQzk2AiM97zqGoQmpfCEi/v+KmDzWmP0MTpPAE3xbDg5akf8e T+A84qJ7CnxOmvtkjMilFAD8E6o1OC1x3rtxqUm9/1/YhZmQ0lZ5JXemR42NpbHe/e+k 8Ttqu5fnqGzzn5P0TosRX7S3SI0y6OcbzXljJDK9HQE91/7ZXy7kCDR/cwqa16UH+hyB c+sLsi8Eh/chiAkCKQ8WQpxVadXuwwBQN6RwGBu4yKIhw6ZxK1kIdH+tvIh9cIbsph2v Go1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dvIm+X1JYFdEGpRw7lPLyV5Hb2SNidvlKgP/6gqYGuA=; b=d2qFt3GbnrMRlMR5sD0fvsjgusUy22Q88SEdHD35pa+6cD/s22Pw1gVRm9JHwNp2nk XZ+FMuzA2dr4oBc7jjWIxpYPKckNYbqR0+CuA5vDSlJz8yDki7Ced90ygIPfaMOhZDTM a+7dU21+o7T5o6NQ53AjgYiMPlmW8+2rI7ROF2u3lJePA53cul/EROK0/QmLGdUs9dIL bu/b3C8iuqbomXvJhE0125uAhd3km2MAMkd/AsLQsS2w5z2Da1uyF9m0LvyEx8ST8k9R z0ygjw3B4LAUEXrthReVaWrZAFd8OoCh5eO18xdWsbMQnKgRgfENxomrmum9olV1eh/I WKmA== X-Gm-Message-State: AOAM532k99dViBXTcEfJHrNkyNScRbiwwQoa9967uEQRH9cW+cWjm/S1 3CAl33nJHQ0YWd2mtUqnOFCMv4Eo0dd3gWTqdJW3F+/KZjA= X-Google-Smtp-Source: ABdhPJyNypkXmWr4pYjuVwzJ9g2PB/e5liY4lyzlARHLirmxZ5fHbZfWSZ4loUOveodbG4Wh2ZWMgqxmGmD78+Zi+Ic= X-Received: by 2002:a17:90b:1bca:: with SMTP id oa10mr288875pjb.20.1636394915721; Mon, 08 Nov 2021 10:08:35 -0800 (PST) MIME-Version: 1.0 References: <7C41DE50-EE9B-4084-8A1D-88471664E23E@apple.com> In-Reply-To: From: David Schinazi Date: Mon, 8 Nov 2021 10:08:24 -0800 Message-ID: To: Tommy Pauly Cc: Eric Rescorla , MASQUE Content-Type: multipart/alternative; boundary="000000000000a9f56505d04ae12d" Archived-At: Subject: Re: [Masque] Comments on draft-age-masque-connect-ip-01 X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 18:08:44 -0000 --000000000000a9f56505d04ae12d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If I may jump in, Tommy I think you misunderstood EKR's point. EKR is saying that in the common consumer VPN scenario it doesn't make sense for the CLIENT to send routes to the SERVER. I think we can resolve EKR's concern by taking this text from draft-cms-masque-connect-ip and copying it to draft-age-masque-connect-ip: In theory, endpoints could use ROUTE_ADVERTISEMENT capsules to divert traffic from naive endpoints. To avoid this, receivers of ROUTE_ADVERTISEMENT capsules MUST check their local policy before acting on such capsules, see Section 5. https://datatracker.ietf.org/doc/html/draft-cms-masque-connect-ip-01#sectio= n-8 On Mon, Nov 8, 2021 at 10:04 AM Tommy Pauly wrote: > > > On Nov 8, 2021, at 8:43 AM, Eric Rescorla wrote: > > > > On Mon, Nov 8, 2021 at 7:52 AM Tommy Pauly wrote: > >> >> >> On Nov 7, 2021, at 3:12 PM, Eric Rescorla wrote: >> >> This document seems like a reasonable starting point. Good to see >> the authors converging. Some technical comments below. >> >> >> Thanks for the comments! >> >> >> Overall, I wonder if we should actually forbid the client from >> using IP addresses in packets when the target is specified. >> That would avoid goofy situations in which the client does >> >> CONNECT 192.0.2.1 >> >> And then sends to 192.0.2.2. >> >> >> I think it=E2=80=99s more consistent to define the behavior of what erro= r the >> sender receives when it sends a packet for which it didn=E2=80=99t have = an assigned >> source address or a valid destination route. Is this cause for dropping = the >> packet silently, sending an error capsule, or closing the request stream >> with an error? >> >> I filed this to discuss: >> https://github.com/tfpauly/draft-age-masque-connect-ip/issues/43 >> > > I could live with that, though I do like to make it impossible to do bad > things. > > > Okay, let=E2=80=99s discuss on the issue. > > > > >> S 4.1. >> >> target: The variable "target" contains a hostname or IP address of a >> specific host to which the client wants to proxy packets. If the >> "target" variable is not specified, the client is requesting to >> communicate with any allowable host. If the target is an IP >> address, the request will only support a single IP version. If >> the target is a hostname, the server is expected to perform DNS >> resolution to determine which route(s) to advertise to the client. >> The server SHOULD send a ROUTE_ADVERTISEMENT capsule that includes >> routes for all usable resolved addresses for the requested >> hostname. >> >> This treatment of DNS names seems like it's going to create a lot of >> additional complexity: for instance, how does the client know which IP >> to put in the dst field. You don't specify that the >> ROUTE_ADVERTISEMENT MUST *only* include valid addresses. For instance, >> suppose that the DNS name resolves to >> >> 192.0.2.1 >> 192.0.2.2 >> 192.0.2.4 <-- No 192.0.2.3! >> 192.0.2.5 >> 192.0.2.6 >> 192.0.2.7 >> >> and the server advertises 192.0.2.1-192.0.2.7. >> >> Given that this is an IP layer mechanism, I would simply remove the >> DNS option; clients can always do DNS over the tunnel. >> >> >> >> I can see this either way. >> >> For cases where I don=E2=80=99t want a full tunnel, but just want to tal= k to one >> host, I would need to open an IP flow for a DNS server. I could of cours= e >> open one, and then open a proxied flow to each target address, and reque= st >> the same local address I got on the first. >> >> This would work, but is more back-and-forth, and also doesn=E2=80=99t gi= ve me a >> way to just ask the proxy to use it=E2=80=99s own DNS cache. For cases l= ike CONNECT >> and CONNECT-UDP, we=E2=80=99ve found it very useful for latency to have = the DNS >> cache run on the proxy, so that we benefit from all clients going throug= h >> the proxy sharing the same cache, and not needing a round trip back to t= he >> client. To that end, I=E2=80=99d like to at least *allow* connecting by = a >> hostname in the protocol (even if some proxies wouldn=E2=80=99t choose t= o support >> that). >> > > I would make several points here. > > First, while it's desirable to be able to use the proxy's DNS cache, it's > increasingly insufficient to simply get the A/AAAA records, for reasons > such as SVCB. For instance, you wouldn't be able to do ECH using the DNS > version alone because you would need to look up the SVCB. So, while it do= es > incur a round trip, it seems like you are going to need to do a DNS > resolution for this case. > > > Yes, ECH does require doing a DNS lookup, but (a) ECH may not be > applicable to the type of connection I=E2=80=99m doing with CONNECT-IP an= d (b) the > records for A / AAAA / HTTPS / SVCB may have different TTLs and thus have > different caching benefits. > > > Second, even taken on its own terms, if I understand this mechanism > correctly, I think it's still broken for the reason I mentioned above. Th= e > problem is that you are using the ROUTE_ADVERTISEMENT as an implicit DNS > resolution--to tell you what to put in the dst-addr. If that's true, then= I > think you need to require that the ROUTE_ADVERTISEMENT to be strict. > > > Yes, I agree that the route advertisement needs to be strict if this is > allowed. > > > > >> >> >> S 4.2. >> Is the server required to send ADDRESS_ASSIGN? If not, what is the >> client supposed to use as it's source address? Also, what happens >> if you only get a v6 address but need to talk to a v4 endpoint, >> or vice versa. >> >> >> https://github.com/tfpauly/draft-age-masque-connect-ip/issues/42 >> >> Probably the best thing to say is that any peer that can send packets >> MUST first have received an ADDRESS_ASSIGN capsule. >> >> Regarding v4 and v6, yes, you do need the right family assigned. >> >> >> >> S 4.2.3. >> You should probably say something here about how in many cases >> you shouldn't trust a ROUTE_ADVERTISEMENT. For instance, it's >> incoherent for an ordinary consumer VPN client to start >> advertising routes. >> >> >> A full-tunnel VPN server may not have a complex routing table, but it=E2= =80=99s >> still possible to have some =E2=80=9Cexcluded=E2=80=9D routes that won= =E2=80=99t be allowed >> (private subnets, etc). Traditionally, most VPN protocols do always incl= ude >> the route information. The =E2=80=9Ctrust=E2=80=9D here is just about wh= at the endpoint is >> willing to route/forward. >> >> What kind of warning were you imagining? >> > > "Note: peers MUST NOT blindly trust ROUTE_ADVERTISEMENT. They MUST filter > it through local policy" > > > Hm, OK. What would =E2=80=9Clocal policy=E2=80=9D be here? I guess in the= case of personal > VPN, my client may expect a full tunnel, but if the server tells me I can= =E2=80=99t > route to a specific subnet (maybe it doesn=E2=80=99t allow 10.0.0/24, rea= sonably), > my only recourse would be to fail the connection, not to try to send to > addresses that are disallowed. > > Tommy > > > -Ekr > > >> Best, >> Tommy >> >> >> >> >> >> -- >> Masque mailing list >> Masque@ietf.org >> https://www.ietf.org/mailman/listinfo/masque >> >> >> -- > Masque mailing list > Masque@ietf.org > https://www.ietf.org/mailman/listinfo/masque > > > -- > Masque mailing list > Masque@ietf.org > https://www.ietf.org/mailman/listinfo/masque > --000000000000a9f56505d04ae12d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I may jump in, Tommy I think you misunderstood EKR'= s=C2=A0point. EKR is saying that in the common consumer VPN scenario it doe= sn't make sense for the CLIENT to send routes to the SERVER. I think we= can resolve EKR's concern by taking this text from=C2=A0draft-cms-masq= ue-connect-ip and copying it to=C2=A0draft-age-masque-connect-ip:

= =C2=A0 =C2=A0In theory, endpoints could use ROUTE_ADVERTISEMENT capsules to= divert
=C2=A0 =C2=A0traffic from naive endpoints.=C2=A0 To avoid this, = receivers of
=C2=A0 =C2=A0ROUTE_ADVERTISEMENT capsules MUST check their = local policy before
=C2=A0 =C2=A0acting on such capsules, see Section 5.=


On Mon, Nov = 8, 2021 at 10:04 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:


On Nov 8, 2021, at 8:4= 3 AM, Eric Rescorla <e= kr@rtfm.com> wrote:

<= br>
On = Mon, Nov 8, 2021 at 7:52 AM Tommy Pauly <tpauly@apple.com> wrote:


On Nov 7, 2021, at 3:12 PM, Eric Rescorla <ekr@rtfm.com> wrote:

This document seems like a reasonable starting poi= nt. Good to see
the authors converging. Some technical comments b= elow.

Thanks for the comme= nts!

Overall, I= wonder if we should actually forbid the client from
using IP addresses = in packets when the target is specified.
That would avoid goofy situatio= ns in which the client does

=C2=A0 =C2=A0CONNECT 192.0.2.1

An= d then sends to 192.0.2.2.

I think it=E2=80=99s more consistent to define the behavior of what e= rror the sender receives when it sends a packet for which it didn=E2=80=99t= have an assigned source address or a valid destination route. Is this caus= e for dropping the packet silently, sending an error capsule, or closing th= e request stream with an error?


I could live with that, though I do like to make it impossible to do bad t= hings.

Okay, let=E2=80= =99s discuss on the issue.



S 4.1.

=C2=A0 =C2=A0targe= t: =C2=A0The variable "target" contains a hostname or IP address = of a
=C2=A0 =C2=A0 =C2=A0=C2=A0specific host to which the c= lient wants to proxy packets.=C2=A0 If the
=C2=A0 =C2=A0 =C2=A0=C2= =A0"target" variable is not specified, the client is reque= sting to
=C2=A0 =C2=A0 =C2=A0=C2=A0communicate with any all= owable host.=C2=A0 If the target is an IP
=C2=A0 =C2=A0 =C2=A0=C2= =A0address, the request will only support a single IP version.=C2=A0= If
=C2=A0 =C2=A0 =C2=A0=C2=A0the target is a hostname, the= server is expected to perform DNS
=C2=A0 =C2=A0 =C2=A0=C2=A0resolution to determine which route(s) to advertise to the client.
=C2= =A0 =C2=A0 =C2=A0=C2=A0The server SHOULD send a ROUTE_ADVERTIS= EMENT capsule that includes
=C2=A0 =C2=A0 =C2=A0=C2=A0route= s for all usable resolved addresses for the requested
=C2=A0 =C2=A0 =C2= =A0=C2=A0hostname.

This treatment of DNS names seems li= ke it's going to create a lot of
additional complexity: for instance= , how does the client know which IP
to put in the dst field. You don'= ;t specify that the
ROUTE_ADVERTISEMENT MUST *only* include valid addres= ses. For instance,
suppose that the DNS name resolves to

=C2=A0=C2=A0192.0.2.1
=C2=A0=C2=A0192.0.2.2
=C2=A0<= span>=C2=A0192.0.2.4 <-- No 192.0.2.3!
=C2=A0=C2=A0192.0.2.5
=C2=A0=C2=A0192.0.2.6
=C2=A0=C2=A0192.0.2.7

and the server advertises 192.0.2.1-192.0.2.7.

G= iven that this is an IP layer mechanism, I would simply remove the
DNS o= ption; clients can always do DNS over the tunnel.


I can see this either way.

For cases where I don=E2=80=99t want a full tunnel, bu= t just want to talk to one host, I would need to open an IP flow for a DNS = server. I could of course open one, and then open a proxied flow to each ta= rget address, and request the same local address I got on the first.
<= div>
This would work, but is more back-and-forth, and also do= esn=E2=80=99t give me a way to just ask the proxy to use it=E2=80=99s own D= NS cache. For cases like CONNECT and CONNECT-UDP, we=E2=80=99ve found it ve= ry useful for latency to have the DNS cache run on the proxy, so that we be= nefit from all clients going through the proxy sharing the same cache, and = not needing a round trip back to the client. To that end, I=E2=80=99d like = to at least=C2=A0allow=C2=A0connecting by a hostname in= the protocol (even if some proxies wouldn=E2=80=99t choose to support that= ).

I would make several p= oints here.

First, while it's desirable to be = able to use the proxy's DNS cache, it's increasingly insufficient t= o simply get the A/AAAA records, for reasons such as SVCB. For instance, yo= u wouldn't be able to do ECH using the DNS version alone because you wo= uld need to look up the SVCB. So, while it does incur a round trip, it seem= s like you are going to need to do a DNS resolution for this case.

Yes, ECH does require doing= a DNS lookup, but (a) ECH may not be applicable to the type of connection = I=E2=80=99m doing with CONNECT-IP and (b) the records for A / AAAA / HTTPS = / SVCB may have different TTLs and thus have different caching benefits.

Second, even taken on its own te= rms, if I understand this mechanism correctly, I think it's still broke= n for the reason I mentioned above. The problem is that you are using the R= OUTE_ADVERTISEMENT as an implicit DNS resolution--to tell you what to put i= n the dst-addr. If that's true, then I think you need to require that t= he ROUTE_ADVERTISEMENT to be strict.

Yes, I agree that the route advertisement needs to be strict i= f this is allowed.





S 4.2.
Is the server required= to send ADDRESS_ASSIGN? If not, what is the
client supposed to use as i= t's source address? Also, what happens
if you only get a v6 address = but need to talk to a v4 endpoint,
or vice versa.
<= /blockquote>

https://github.com/tfpauly/d= raft-age-masque-connect-ip/issues/42

Probably = the best thing to say is that any peer that can send packets MUST first hav= e received an ADDRESS_ASSIGN capsule.

Regarding v4= and v6, yes, you do need the right family assigned.



S 4.2.3.
You should= probably say something here about how in many cases
you shouldn't t= rust a ROUTE_ADVERTISEMENT. For instance, it's
incoherent for an ord= inary consumer VPN client to start
advertising routes.

A full-tunnel VPN server may not have = a complex routing table, but it=E2=80=99s still possible to have some =E2= =80=9Cexcluded=E2=80=9D routes that won=E2=80=99t be allowed (private subne= ts, etc). Traditionally, most VPN protocols do always include the route inf= ormation. The =E2=80=9Ctrust=E2=80=9D here is just about what the endpoint = is willing to route/forward.

What kind of warning = were you imagining?

"= ;Note: peers MUST NOT blindly trust ROUTE_ADVERTISEMENT. They MUST filter i= t through local policy"

<= /div>
Hm, OK. What would =E2=80=9Clocal policy=E2=80=9D be here? I gues= s in the case of personal VPN, my client may expect a full tunnel, but if t= he server tells me I can=E2=80=99t route to a specific subnet (maybe it doe= sn=E2=80=99t allow 10.0.0/24, reasonably), my only recourse would be to fai= l the connection, not to try to send to addresses that are disallowed.

Tommy


-Ek= r


--=C2=A0
Mas= que mailing list
Masque@ietf.org
https://www.ietf.org/mail= man/listinfo/masque

--
Masque mailing list
Masque@ietf.org https://www.ietf.org/mailman/listinfo/masque
--000000000000a9f56505d04ae12d-- From nobody Mon Nov 8 10:26:17 2021 Return-Path: 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 E3D8C3A0DAB for ; Mon, 8 Nov 2021 10:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 gtkN4i3x0fFg for ; Mon, 8 Nov 2021 10:26:12 -0800 (PST) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 E91483A0DBD for ; Mon, 8 Nov 2021 10:26:11 -0800 (PST) Received: by mail-ua1-x92d.google.com with SMTP id t13so18034450uad.9 for ; Mon, 08 Nov 2021 10:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YDEOjJzjLJwUhvG5CC7RklJMXwWYDA32gn60QcijAmo=; b=O4py8p0dLWoJ8ZGqpKDoX1BBx9enXuFlVacRnUC7q6xoOPZvW4mx0T8MZb3z3efyd4 LEYCV74Hu19waNqU7ZksJWGVoJzvLeCOq+RtlTVHjwuuzAvjFtuMj7aAr/Pt6zVnwqA5 3zVrPG818rFYvqGsKVrW+p1ejS1oNvRLvrXYEMt2RgvUj4jIw9C6zUYMBG6+Kttt1fSg En/NnTh7SDAZY5uqp8soADFRYgImySwmiI+WDrQqD5HxJxLz4dVeNn1XnPMS3qaj/jMY KbzYMzM1NTBO6LvxbAukRUD8rPWRP/+BV9QmDqyIAKJO+nzgx/naTT77heYiG0N77ejU KDow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YDEOjJzjLJwUhvG5CC7RklJMXwWYDA32gn60QcijAmo=; b=HET+ss3ueFd4pjT5qWxTyJGZ0n6KThJYYmL+uGGm4i2+yeFWhBBl1UUS/HieHsqlN9 WjZ911p2Q6AeAuBfZLsbp0cgRpe5Rg5zgzBChFkVl5qGgibQTxsBjJT5n9tublQtUXSy 79Ep03sknZrC57osZr8B/7gdugEk1iST9S1yIXqZhSXTNsdAJECVSeHut27mv3liypWh uHftgu7hIICkyFz4CYTeWPOF552tRZmeDJDWTAacfoktCEUr2S8IQZP/T0me68azQr4N +mM9bAibyTtdGv5OW2WE2Cvh6ntCqVepPgXn7lWyPoIJ+7b+EwIYIvOCLNApNSqysT94 daRA== X-Gm-Message-State: AOAM530c7O68b99bzC42yWDWvJVlCS8aklDcDI285mB+KjaDD554WUnB 59CWHvijQQkP+RjbZWJGefb/UZwFV1bqGFDlskk8AA== X-Google-Smtp-Source: ABdhPJygmuWfSrNyBhHZ/bDVqiByrR0wXM0ApZa/WukKS4Kc5nML+DrJRcqiFUyMk9hKAei8+a5uQPHP1D8v+o/oqK4= X-Received: by 2002:ab0:6883:: with SMTP id t3mr1343395uar.66.1636395969475; Mon, 08 Nov 2021 10:26:09 -0800 (PST) MIME-Version: 1.0 References: <7C41DE50-EE9B-4084-8A1D-88471664E23E@apple.com> In-Reply-To: <7C41DE50-EE9B-4084-8A1D-88471664E23E@apple.com> From: Ben Schwartz Date: Mon, 8 Nov 2021 13:25:57 -0500 Message-ID: To: Tommy Pauly Cc: Eric Rescorla , MASQUE Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000008140ce05d04b200d" Archived-At: Subject: Re: [Masque] Comments on draft-age-masque-connect-ip-01 X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 18:26:17 -0000 --0000000000008140ce05d04b200d Content-Type: multipart/alternative; boundary="000000000000795cbd05d04b200c" --000000000000795cbd05d04b200c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 8, 2021 at 10:52 AM Tommy Pauly wrote: > > > On Nov 7, 2021, at 3:12 PM, Eric Rescorla wrote: > > ... > > Given that this is an IP layer mechanism, I would simply remove the > DNS option; clients can always do DNS over the tunnel. > > > > I can see this either way. > > For cases where I don=E2=80=99t want a full tunnel, but just want to talk= to one > host, I would need to open an IP flow for a DNS server. I could of course > open one, and then open a proxied flow to each target address, and reques= t > the same local address I got on the first. > > This would work, but is more back-and-forth, and also doesn=E2=80=99t giv= e me a > way to just ask the proxy to use it=E2=80=99s own DNS cache. > I think we need to be clear about what the alternatives are. Suppose we compare A. CONNECT-IP supports DNS names. [current draft] B. CONNECT-IP doesn't support hostnames but is co-located with a DoH server= . Then either way, the client benefits from a DNS cache at the proxy. > For cases like CONNECT and CONNECT-UDP, we=E2=80=99ve found it very usefu= l for > latency to have the DNS cache run on the proxy, so that we benefit from a= ll > clients going through the proxy sharing the same cache, and not needing a > round trip back to the client. > That benefit does not apply to CONNECT-IP, because the client must specify an IP address, but it doesn't know what IP address to specify. It therefore has to wait the same full roundtrip anyway. Compare A. - [C->S] CONNECT-IP https://proxy.example/ip?target_host=3Dtarget.example.= com - [S->C] 200 OK, ROUTE_ADVERTISEMENT [192.0.2.1] - [C->S] IP Packet to 192.0.2.1 B. - [C->S] GET https://proxy.example/dns-query?dns=3D - [S->C] 200 OK, - [C->S] CONNECT-IP https://proxy.example/ip?target_host=3D192.0.2.1 - [C->S] IP Packet to 192.0.2.1 (False Start) CONNECT (TCP) and CONNECT-UDP are different. TCP allows the server to act on the resolved address without having to return it to the client. CONNECT-UDP allows false-start with hostname targets (although CONNECT-UDP with hostname targets is pretty crummy: it breaks failover, Happy Eyeballs, etc.). To that end, I=E2=80=99d like to at least *allow* connecting by a hostname = in the > protocol > I don't object to this functionality, but I don't think it is a performance optimization. > (even if some proxies wouldn=E2=80=99t choose to support that). > I don't think it can be optional. If it's optional, it might as well not be mentioned at all, since clients can't rely on it. --000000000000795cbd05d04b200c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 8, 2021 at 10:52 AM Tommy= Pauly <tpauly=3D40apple.c= om@dmarc.ietf.org> wrote:


On Nov 7, 2021, at 3:12 PM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote= :
...=C2=A0=C2=A0

= Given that this is an IP layer mechanism, I would simply remove the
DNS = option; clients can always do DNS over the tunnel.


I can see this either way.

For cases where I don=E2=80=99t want a full tunnel, b= ut just want to talk to one host, I would need to open an IP flow for a DNS= server. I could of course open one, and then open a proxied flow to each t= arget address, and request the same local address I got on the first.
=

This would work, but is more back-and-forth, and also d= oesn=E2=80=99t give me a way to just ask the proxy to use it=E2=80=99s own = DNS cache.

I think we nee= d to be clear about what the alternatives are.=C2=A0 Suppose we compare

A. CONNECT-IP supports DNS names. [current draft]
B. CONNECT-IP doesn't support hostnames but is co-located with a= DoH server.

Then either way, the client benefits = from a DNS cache at the proxy.
=C2=A0
=
For cases like CONNECT and CONNECT-UDP, we=E2=80=99ve found it very u= seful for latency to have the DNS cache run on the proxy, so that we benefi= t from all clients going through the proxy sharing the same cache, and not = needing a round trip back to the client.

That benefit does not apply to CONNECT-IP, because the clie= nt must specify an IP address, but it doesn't know what IP address to s= pecify.=C2=A0 It therefore has to wait the=C2=A0same full roundtrip anyway.= =C2=A0 Compare

A.
= =C2=A0- [S->C] 200 OK, ROUTE_ADVERTISEMENT [192.0.2.1]
=C2=A0-= [C->S] IP Packet to 192.0.2.1

B.
=C2=A0- [S->C] 200 OK, <DNS = Answer: 192.0.2.1>
=C2=A0- [C->S] IP Packet to 192.0.2.1= (False Start)
=C2=A0
CONNECT (TCP) and CONNECT-UDP are= different.=C2=A0 TCP allows the server to act on the resolved address with= out having to return it to the client.=C2=A0 CONNECT-UDP allows false-start= with hostname targets (although CONNECT-UDP with hostname targets is prett= y crummy: it breaks failover, Happy Eyeballs, etc.).

To that end, I=E2=80=99d like to at least allo= w=C2=A0connecting by a hostname in the protocol

I don't object to this functionality, but I = don't think it is a performance optimization.
=C2=A0
(even if some proxies wouldn=E2=80=99t choose to s= upport that).

I don't= think it can be optional.=C2=A0 If it's optional, it might as well not= be mentioned at all, since clients can't rely on it.
--000000000000795cbd05d04b200c-- --0000000000008140ce05d04b200d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAEPeo9/GxknaxVybmbU vmIwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMTEwMTgx MzI4MjFaFw0yMjA0MTYxMzI4MjFaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Og2McfM9XYxay9lQdacWd75OScDFx75 QNs68foESjDzjCyh2pg+v1chyqSuCIt/79bjwTJTFmaXKLgdbd51VD6v1gPRkO8YVHJ/YqXBSF1o 3YgiLMmt6fG4kjqcniKBxMiFXvt5tKbW16aM5Z1iAeegQWuotS2ejvCqcmx98l8dXJMaWTX0EJ7v vZeZn9plzQw3JTAeVUi4c4UtRIXPeC+CT8xzcFFmAYKGAsFuQEPISAwi60+ao7RuMhNAltVL7ZSG +/04uzRd7k2TWBJnp86zzg/y0XEwdNYWwV0oL4kNZPxcUXbxNXFB4v7reLZK5t+RJXFNCb1d7y+j 7k+keQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUzoIjhzUXsKy1 m4Ay0XMzONSDXt0wTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAKah4EqFB7nuTg1M3QGI963Z HaE551W8LWOHfTZf4zmOeoXCNoeyLN9D8qRz3+lHR8kME/T5q/F5KLThPCM4BTTzPGF59tMSebum Afvzbn1X8bFW4Q1boaF0HXKEHIZS3PHUBqH3Xbd6+hCb8hh2KRQl7iGxYJrAKQpTuC++Tw+rPGkl F6/NcliGHu2xiRBsyeDh1mkzZBAvugrisg0vnmuaWz/jxYVHgSK00NNiypuK/0Aggs95eeoB6m1R dZbXdPzEYrRk2o93YrZOi7Xabj7fBDk2VbMYyyqMbjalA5CDbxk4TK0OfXFE2sMEi8ojnONBpINK X9kRA5udV0GDqmoxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAEP eo9/GxknaxVybmbUvmIwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIH6X9m3JiC9P beKQQjgmoGFjQSvXRwxZ9o19EQqtZD2ZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIxMTEwODE4MjYxMFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQBZ5PxjYu68vOzLmYBvLgcYl0Pqp9Lt jqx56dEBg9qK83TyMX2pFCKySzzvvpGcQksT29LMy7vW16Hz2Jw2wPvogJGlq+C1ogLHjGfH3B/c 91wm0BzvQ8y8H2UVqZvfodwBJYRnKJYQuNTyCNe2/t6AoLGJkW5yDg6eujTv8N7nhOKv0/mwhYov nz6e1F7DlqCyvOS+k6XidG4OM2YVZysl/8h4ynOK1W2as82xFAXVIfPXBK7UaeDbm7RMir2luOW+ +JPuT3LlHGBeQPQyxqRaHOrDgeDYLLlKzqvOwWdg4vuoXCEL4whrt3dW78vIhB+7DTGTt6bMt0h2 MzI3lA07 --0000000000008140ce05d04b200d-- From nobody Mon Nov 8 10:32:17 2021 Return-Path: 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 05A233A0E1F for ; Mon, 8 Nov 2021 10:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.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 8VPIq-mOpcUg for ; Mon, 8 Nov 2021 10:32:10 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 E57883A0E19 for ; Mon, 8 Nov 2021 10:32:09 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id y16so2386497ioc.8 for ; Mon, 08 Nov 2021 10:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mw/ce8clRRdTPE27UzU2h4o36KEv/KFz/tqRwc1/uk4=; b=U6dovug+dFwI8iytrPNzi2Lyiohj90OU0p/MPGUxCGQwAKAXxqieVIF6r2tb8HrKXn U0327VwdJLqmrhvP4OlxzhqHl0sOTt100J0sSehuPJnry/ECcRy+XfYDDYVJmhiXi/8N bPqYaryp7w2OKLtnxKdxkeYGDSXMXHCfB5tfwRYJK04R+A06Wop9atkTnSGUprRFXS4A Kp/nzmkOdi3F3r41JiNm6b8VeQWqnqEB6W2B66Q4/LZ9VQqCY/IkDCUAp0V7XcrttFQo 4rqWjNdaiFbvxDzrP6TwusTAAA7uj7SBqU5Jw/EAKX2WPXdeTf4mlhxzZ0SweLf8967+ r8MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mw/ce8clRRdTPE27UzU2h4o36KEv/KFz/tqRwc1/uk4=; b=liuBdBy06hiNbRV3tXmJCZH7y5rvZAEtGkXnss8kQFe9ZheURWJxJHKSkRtqwedIwX CjArzM9Ck168jjU5Az9KN/uwBkLt8JpcEvOpWTt5PAZFVWu6/gyyYIpPPChM34gmu07S 4mI8YLxerNb51Nmnuwoxi8YY6ahpIBRNi9jhLWbi6QYHwPHNHUjG9EbvjTYp28JeNWz1 XMFVTH6JYfKQ7mNDKNc2V4TveeNvLgj9B9nja7dwrbJSpeJ7yeJ4nlSpBBj3xxuGpd05 BnEbuzYpp1J0vrtnkyQd+H3KANiNlJl3Kkz3gQOeF1XsF8cT+IMQVBVwo5nugoj3hEjZ FP3Q== X-Gm-Message-State: AOAM532lTVUiE3yvkP8yyJy8Ld7Jk77zLjHDOVPKP9EC5I/C248CVSdR BwkAGz/CK74/8fo7jTlJ+Wef+d8Q/CsxiHDctkLvQw== X-Google-Smtp-Source: ABdhPJy+7rCcEWu4n6LzHit0UpidweBY+LhLWcYcFJFn/94q3oBvSVZz+moW5rIczuzavXRDeU5s+QshM20mWcZjIkA= X-Received: by 2002:a05:6638:190f:: with SMTP id p15mr939243jal.82.1636396325123; Mon, 08 Nov 2021 10:32:05 -0800 (PST) MIME-Version: 1.0 References: <7C41DE50-EE9B-4084-8A1D-88471664E23E@apple.com> In-Reply-To: From: Eric Rescorla Date: Mon, 8 Nov 2021 10:31:28 -0800 Message-ID: To: David Schinazi Cc: Tommy Pauly , MASQUE Content-Type: multipart/alternative; boundary="000000000000abc9dc05d04b35b8" Archived-At: Subject: Re: [Masque] Comments on draft-age-masque-connect-ip-01 X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 18:32:15 -0000 --000000000000abc9dc05d04b35b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 8, 2021 at 10:08 AM David Schinazi wrote: > If I may jump in, Tommy I think you misunderstood EKR's point. EKR is > saying that in the common consumer VPN scenario it doesn't make sense for > the CLIENT to send routes to the SERVER. I think we can resolve EKR's > concern by taking this text from draft-cms-masque-connect-ip and copying = it > to draft-age-masque-connect-ip: > Yes, this is what I meant. > In theory, endpoints could use ROUTE_ADVERTISEMENT capsules to divert > traffic from naive endpoints. To avoid this, receivers of > ROUTE_ADVERTISEMENT capsules MUST check their local policy before > acting on such capsules, see Section 5. > > > https://datatracker.ietf.org/doc/html/draft-cms-masque-connect-ip-01#sect= ion-8 > This seems reasonable. -Ekr > > On Mon, Nov 8, 2021 at 10:04 AM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > >> >> >> On Nov 8, 2021, at 8:43 AM, Eric Rescorla wrote: >> >> >> >> On Mon, Nov 8, 2021 at 7:52 AM Tommy Pauly wrote: >> >>> >>> >>> On Nov 7, 2021, at 3:12 PM, Eric Rescorla wrote: >>> >>> This document seems like a reasonable starting point. Good to see >>> the authors converging. Some technical comments below. >>> >>> >>> Thanks for the comments! >>> >>> >>> Overall, I wonder if we should actually forbid the client from >>> using IP addresses in packets when the target is specified. >>> That would avoid goofy situations in which the client does >>> >>> CONNECT 192.0.2.1 >>> >>> And then sends to 192.0.2.2. >>> >>> >>> I think it=E2=80=99s more consistent to define the behavior of what err= or the >>> sender receives when it sends a packet for which it didn=E2=80=99t have= an assigned >>> source address or a valid destination route. Is this cause for dropping= the >>> packet silently, sending an error capsule, or closing the request strea= m >>> with an error? >>> >>> I filed this to discuss: >>> https://github.com/tfpauly/draft-age-masque-connect-ip/issues/43 >>> >> >> I could live with that, though I do like to make it impossible to do bad >> things. >> >> >> Okay, let=E2=80=99s discuss on the issue. >> >> >> >> >>> S 4.1. >>> >>> target: The variable "target" contains a hostname or IP address of = a >>> specific host to which the client wants to proxy packets. If the >>> "target" variable is not specified, the client is requesting to >>> communicate with any allowable host. If the target is an IP >>> address, the request will only support a single IP version. If >>> the target is a hostname, the server is expected to perform DNS >>> resolution to determine which route(s) to advertise to the client= . >>> The server SHOULD send a ROUTE_ADVERTISEMENT capsule that include= s >>> routes for all usable resolved addresses for the requested >>> hostname. >>> >>> This treatment of DNS names seems like it's going to create a lot of >>> additional complexity: for instance, how does the client know which IP >>> to put in the dst field. You don't specify that the >>> ROUTE_ADVERTISEMENT MUST *only* include valid addresses. For instance, >>> suppose that the DNS name resolves to >>> >>> 192.0.2.1 >>> 192.0.2.2 >>> 192.0.2.4 <-- No 192.0.2.3! >>> 192.0.2.5 >>> 192.0.2.6 >>> 192.0.2.7 >>> >>> and the server advertises 192.0.2.1-192.0.2.7. >>> >>> Given that this is an IP layer mechanism, I would simply remove the >>> DNS option; clients can always do DNS over the tunnel. >>> >>> >>> >>> I can see this either way. >>> >>> For cases where I don=E2=80=99t want a full tunnel, but just want to ta= lk to one >>> host, I would need to open an IP flow for a DNS server. I could of cour= se >>> open one, and then open a proxied flow to each target address, and requ= est >>> the same local address I got on the first. >>> >>> This would work, but is more back-and-forth, and also doesn=E2=80=99t g= ive me a >>> way to just ask the proxy to use it=E2=80=99s own DNS cache. For cases = like CONNECT >>> and CONNECT-UDP, we=E2=80=99ve found it very useful for latency to have= the DNS >>> cache run on the proxy, so that we benefit from all clients going throu= gh >>> the proxy sharing the same cache, and not needing a round trip back to = the >>> client. To that end, I=E2=80=99d like to at least *allow* connecting by= a >>> hostname in the protocol (even if some proxies wouldn=E2=80=99t choose = to support >>> that). >>> >> >> I would make several points here. >> >> First, while it's desirable to be able to use the proxy's DNS cache, it'= s >> increasingly insufficient to simply get the A/AAAA records, for reasons >> such as SVCB. For instance, you wouldn't be able to do ECH using the DNS >> version alone because you would need to look up the SVCB. So, while it d= oes >> incur a round trip, it seems like you are going to need to do a DNS >> resolution for this case. >> >> >> Yes, ECH does require doing a DNS lookup, but (a) ECH may not be >> applicable to the type of connection I=E2=80=99m doing with CONNECT-IP a= nd (b) the >> records for A / AAAA / HTTPS / SVCB may have different TTLs and thus hav= e >> different caching benefits. >> >> >> Second, even taken on its own terms, if I understand this mechanism >> correctly, I think it's still broken for the reason I mentioned above. T= he >> problem is that you are using the ROUTE_ADVERTISEMENT as an implicit DNS >> resolution--to tell you what to put in the dst-addr. If that's true, the= n I >> think you need to require that the ROUTE_ADVERTISEMENT to be strict. >> >> >> Yes, I agree that the route advertisement needs to be strict if this is >> allowed. >> >> >> >> >>> >>> >>> S 4.2. >>> Is the server required to send ADDRESS_ASSIGN? If not, what is the >>> client supposed to use as it's source address? Also, what happens >>> if you only get a v6 address but need to talk to a v4 endpoint, >>> or vice versa. >>> >>> >>> https://github.com/tfpauly/draft-age-masque-connect-ip/issues/42 >>> >>> Probably the best thing to say is that any peer that can send packets >>> MUST first have received an ADDRESS_ASSIGN capsule. >>> >>> Regarding v4 and v6, yes, you do need the right family assigned. >>> >>> >>> >>> S 4.2.3. >>> You should probably say something here about how in many cases >>> you shouldn't trust a ROUTE_ADVERTISEMENT. For instance, it's >>> incoherent for an ordinary consumer VPN client to start >>> advertising routes. >>> >>> >>> A full-tunnel VPN server may not have a complex routing table, but it= =E2=80=99s >>> still possible to have some =E2=80=9Cexcluded=E2=80=9D routes that won= =E2=80=99t be allowed >>> (private subnets, etc). Traditionally, most VPN protocols do always inc= lude >>> the route information. The =E2=80=9Ctrust=E2=80=9D here is just about w= hat the endpoint is >>> willing to route/forward. >>> >>> What kind of warning were you imagining? >>> >> >> "Note: peers MUST NOT blindly trust ROUTE_ADVERTISEMENT. They MUST filte= r >> it through local policy" >> >> >> Hm, OK. What would =E2=80=9Clocal policy=E2=80=9D be here? I guess in th= e case of >> personal VPN, my client may expect a full tunnel, but if the server tell= s >> me I can=E2=80=99t route to a specific subnet (maybe it doesn=E2=80=99t = allow 10.0.0/24, >> reasonably), my only recourse would be to fail the connection, not to tr= y >> to send to addresses that are disallowed. >> >> Tommy >> >> >> -Ekr >> >> >>> Best, >>> Tommy >>> >>> >>> >>> >>> >>> -- >>> Masque mailing list >>> Masque@ietf.org >>> https://www.ietf.org/mailman/listinfo/masque >>> >>> >>> -- >> Masque mailing list >> Masque@ietf.org >> https://www.ietf.org/mailman/listinfo/masque >> >> >> -- >> Masque mailing list >> Masque@ietf.org >> https://www.ietf.org/mailman/listinfo/masque >> > --000000000000abc9dc05d04b35b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 8, 2021 at 10:08 AM David= Schinazi <dschinazi.ietf@gmail.com> wrote:
If I may jump in, Tommy I think y= ou misunderstood EKR's=C2=A0point. EKR is saying that in the common con= sumer VPN scenario it doesn't make sense for the CLIENT to send routes = to the SERVER. I think we can resolve EKR's concern by taking this text= from=C2=A0draft-cms-masque-connect-ip and copying it to=C2=A0draft-age-mas= que-connect-ip:

Yes, this is what I m= eant.


=C2=A0 =C2=A0In theory, endpoints could use ROU= TE_ADVERTISEMENT capsules to divert
=C2=A0 =C2=A0traffic from naive endp= oints.=C2=A0 To avoid this, receivers of
=C2=A0 =C2=A0ROUTE_ADVERTISEMEN= T capsules MUST check their local policy before
=C2=A0 =C2=A0acting on s= uch capsules, see Section 5.


This = seems reasonable.

-Ekr


<= /div>

On Mon, Nov 8, 2021 at 10:04 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.= ietf.org> wrote:


On Nov 8, 2021, at= 8:43 AM, Eric Rescorla <ekr@rtfm.com> wrote:



On Mon, Nov 8, 2021 at 7:52 AM Tommy Pauly <tpauly@apple.com> wrote:


On Nov 7, 2021, at 3:12 PM, Eric Rescorla <ekr@rtfm.com> wrote:

=
This document seems like a reasonable starting p= oint. Good to see
the authors converging. Some technical comments= below.

Thanks for the com= ments!

Overall,= I wonder if we should actually forbid the client from
using IP addresse= s in packets when the target is specified.
That would avoid goofy situat= ions in which the client does

=C2=A0 =C2=A0CONNECT 192.0.2.1

= And then sends to 192.0.2.2.

I think it=E2=80=99s more consistent to define the behavior of what= error the sender receives when it sends a packet for which it didn=E2=80= =99t have an assigned source address or a valid destination route. Is this = cause for dropping the packet silently, sending an error capsule, or closin= g the request stream with an error?


=
I could live with that, though I do like to make it impossible to do b= ad things.

Okay, let=E2= =80=99s discuss on the issue.



S 4.1.

=C2=A0 =C2=A0ta= rget: =C2=A0The variable "target" contains a hostname or IP addre= ss of a
=C2=A0 =C2=A0 =C2=A0=C2=A0specific host to which th= e client wants to proxy packets.=C2=A0 If the
=C2=A0 =C2=A0 =C2=A0= =C2=A0"target" variable is not specified, the client is re= questing to
=C2=A0 =C2=A0 =C2=A0=C2=A0communicate with any = allowable host.=C2=A0 If the target is an IP
=C2=A0 =C2=A0 =C2=A0= =C2=A0address, the request will only support a single IP version.=C2= =A0 If
=C2=A0 =C2=A0 =C2=A0=C2=A0the target is a hostname, = the server is expected to perform DNS
=C2=A0 =C2=A0 =C2=A0=C2=A0resolution to determine which route(s) to advertise to the client.
= =C2=A0 =C2=A0 =C2=A0=C2=A0The server SHOULD send a ROUTE_ADVER= TISEMENT capsule that includes
=C2=A0 =C2=A0 =C2=A0=C2=A0ro= utes for all usable resolved addresses for the requested
=C2=A0 =C2=A0 = =C2=A0=C2=A0hostname.

This treatment of DNS names seems= like it's going to create a lot of
additional complexity: for insta= nce, how does the client know which IP
to put in the dst field. You don&= #39;t specify that the
ROUTE_ADVERTISEMENT MUST *only* include valid add= resses. For instance,
suppose that the DNS name resolves to

=C2= =A0=C2=A0192.0.2.1
=C2=A0=C2=A0192.0.2.2
= =C2=A0=C2=A0192.0.2.4 <-- No 192.0.2.3!
=C2=A0=C2= =A0192.0.2.5
=C2=A0=C2=A0192.0.2.6
=C2=A0= =C2=A0192.0.2.7

and the server advertises 192.0.2.1-192.0.2.7= .

Given that this is an IP layer mechanism, I would simply remove th= e
DNS option; clients can always do DNS over the tunnel.
=


I can see this either= way.

For cases where I don=E2=80=99t want a full = tunnel, but just want to talk to one host, I would need to open an IP flow = for a DNS server. I could of course open one, and then open a proxied flow = to each target address, and request the same local address I got on the fir= st.

This would work, but is more back-and-forth, a= nd also doesn=E2=80=99t give me a way to just ask the proxy to use it=E2=80= =99s own DNS cache. For cases like CONNECT and CONNECT-UDP, we=E2=80=99ve f= ound it very useful for latency to have the DNS cache run on the proxy, so = that we benefit from all clients going through the proxy sharing the same c= ache, and not needing a round trip back to the client. To that end, I=E2=80= =99d like to at least=C2=A0allow=C2=A0connecting by a h= ostname in the protocol (even if some proxies wouldn=E2=80=99t choose to su= pport that).

I would make= several points here.

First, while it's desira= ble to be able to use the proxy's DNS cache, it's increasingly insu= fficient to simply get the A/AAAA records, for reasons such as SVCB. For in= stance, you wouldn't be able to do ECH using the DNS version alone beca= use you would need to look up the SVCB. So, while it does incur a round tri= p, it seems like you are going to need to do a DNS resolution for this case= .

Yes, ECH does req= uire doing a DNS lookup, but (a) ECH may not be applicable to the type of c= onnection I=E2=80=99m doing with CONNECT-IP and (b) the records for A / AAA= A / HTTPS / SVCB may have different TTLs and thus have different caching be= nefits.


Second, even taken on = its own terms, if I understand this mechanism correctly, I think it's s= till broken for the reason I mentioned above. The problem is that you are u= sing the ROUTE_ADVERTISEMENT as an implicit DNS resolution--to tell you wha= t to put in the dst-addr. If that's true, then I think you need to requ= ire that the ROUTE_ADVERTISEMENT to be strict.

Yes, I agree that the route advertisement needs to b= e strict if this is allowed.





S 4.2.
Is the serve= r required to send ADDRESS_ASSIGN? If not, what is the
client supposed t= o use as it's source address? Also, what happens
if you only get a v= 6 address but need to talk to a v4 endpoint,
or vice versa.

https://github.com= /tfpauly/draft-age-masque-connect-ip/issues/42

Probably the best thing to say is that any peer that can send packets MUST= first have received an ADDRESS_ASSIGN capsule.

Re= garding v4 and v6, yes, you do need the right family assigned.


S 4.2.3.
= You should probably say something here about how in many cases
you shoul= dn't trust a ROUTE_ADVERTISEMENT. For instance, it's
incoherent = for an ordinary consumer VPN client to start
advertising routes.

A full-tunnel VPN server may= not have a complex routing table, but it=E2=80=99s still possible to have = some =E2=80=9Cexcluded=E2=80=9D routes that won=E2=80=99t be allowed (priva= te subnets, etc). Traditionally, most VPN protocols do always include the r= oute information. The =E2=80=9Ctrust=E2=80=9D here is just about what the e= ndpoint is willing to route/forward.

What kind of = warning were you imagining?

"Note: peers MUST NOT blindly trust ROUTE_ADVERTISEMENT. They MUST = filter it through local policy"

Hm, OK. What would =E2=80=9Clocal policy=E2=80=9D be here= ? I guess in the case of personal VPN, my client may expect a full tunnel, = but if the server tells me I can=E2=80=99t route to a specific subnet (mayb= e it doesn=E2=80=99t allow 10.0.0/24, reasonably), my only recourse would b= e to fail the connection, not to try to send to addresses that are disallow= ed.

Tommy

=

=
-Ekr


Best,
Tommy


--=C2=A0
Masque@ietf.org
https://www.ietf.org= /mailman/listinfo/masque
--
Masque mailing list
Masque@ietf.org https://www.ietf.org/mailman/listinfo/masque
--000000000000abc9dc05d04b35b8-- From nobody Mon Nov 8 10:33:49 2021 Return-Path: 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 907933A0E55 for ; Mon, 8 Nov 2021 10:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.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 kbNKyfZLlM1z for ; Mon, 8 Nov 2021 10:33:41 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 BC97E3A0E2F for ; Mon, 8 Nov 2021 10:33:41 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id c3so6644714iob.6 for ; Mon, 08 Nov 2021 10:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zlIMIMbNkKDKmFBRcxYOKCeBX9nVxi7f6DLkA65ef90=; b=KRzIsUudvttw6J9TmSlDSB2lD/HCWO+4lqUmUoB9UKL7gFszQfqA/pasaXzABXX09f B2cYafX6pjIriS4nNAAsdXjQ+NEkXq238i2dkdYCixfzX6vfKpSUvIu2LLskQcyHlLi6 olhHgWCugIiKUIhjosHIwswTWyzlskx3+QsEIQ1TYzRKCaPo1EUkPQTmujZwvI0pZc9B aSc9C5r1FjG/X+9T6TKxV19alvsSPPkCY6KxHd+7jXrCsWzUk7BVZKDMqukOXAQ/NGnk EkpRejteq588er3kG9u4CteNsdFuulDzJSHrONBOTJTVwMaoJqaP+dGocdycuXyy8JPX hcQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zlIMIMbNkKDKmFBRcxYOKCeBX9nVxi7f6DLkA65ef90=; b=3H47MEobd8/5n52WatLBgEmdcfTqb5/kBlWZJ8hD5HKBbxEArmHNYTNhn+5hk0VByY iwxKbNwp+e8tZMydg+eF/QCkSMo1CX2S1vSQ2F7rr6swJbbgP/XeNffBg8/Vant26SFh 2FXHbMt8Jkl5I82j8+u4oDt9FuskqD76VcoISdNuAA/70rsrHp9PlJjLP98f1dXWXhZW R6iWTZcZayBCrlTArqcsU8fZgl8HhxN2NA2Et+bGe4RvNHy3a5M7qNS77wyLH/CN9zq3 o3XfYlTXjqVaa63yYhrFD50AMXmo0GI3PDSo6+Vb6hpc3JYUMogNdni27LurfySUeTrW OucQ== X-Gm-Message-State: AOAM532lKcVYYzAKcCz/GNHLjGqbN9Brlfb0Mef51NB36I0EvcLy2pOr W1nyxb1wHjJOtJ/k2fdsx8UfKSApDWTcKEU+EHOclQ== X-Google-Smtp-Source: ABdhPJyy0cJ+82UzPOfT/fCmsCSok154zdvZPMAftJvDvIVdl+S2FU0bARAAQZHoH5N5vT/71Pglh9lge9VGRsDvWBI= X-Received: by 2002:a5d:8e07:: with SMTP id e7mr843557iod.148.1636396419315; Mon, 08 Nov 2021 10:33:39 -0800 (PST) MIME-Version: 1.0 References: <7C41DE50-EE9B-4084-8A1D-88471664E23E@apple.com> In-Reply-To: From: Eric Rescorla Date: Mon, 8 Nov 2021 10:33:03 -0800 Message-ID: To: Ben Schwartz Cc: Tommy Pauly , MASQUE Content-Type: multipart/alternative; boundary="00000000000049130e05d04b3bf7" Archived-At: Subject: Re: [Masque] Comments on draft-age-masque-connect-ip-01 X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 18:33:47 -0000 --00000000000049130e05d04b3bf7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 8, 2021 at 10:26 AM Ben Schwartz wrote: > > > On Mon, Nov 8, 2021 at 10:52 AM Tommy Pauly 40apple.com@dmarc.ietf.org> wrote: > >> >> >> On Nov 7, 2021, at 3:12 PM, Eric Rescorla wrote: >> >> ... > >> >> Given that this is an IP layer mechanism, I would simply remove the >> DNS option; clients can always do DNS over the tunnel. >> >> >> >> I can see this either way. >> >> For cases where I don=E2=80=99t want a full tunnel, but just want to tal= k to one >> host, I would need to open an IP flow for a DNS server. I could of cours= e >> open one, and then open a proxied flow to each target address, and reque= st >> the same local address I got on the first. >> >> This would work, but is more back-and-forth, and also doesn=E2=80=99t gi= ve me a >> way to just ask the proxy to use it=E2=80=99s own DNS cache. >> > > I think we need to be clear about what the alternatives are. Suppose we > compare > > A. CONNECT-IP supports DNS names. [current draft] > B. CONNECT-IP doesn't support hostnames but is co-located with a DoH > server. > > Then either way, the client benefits from a DNS cache at the proxy. > > >> For cases like CONNECT and CONNECT-UDP, we=E2=80=99ve found it very usef= ul for >> latency to have the DNS cache run on the proxy, so that we benefit from = all >> clients going through the proxy sharing the same cache, and not needing = a >> round trip back to the client. >> > > That benefit does not apply to CONNECT-IP, because the client must specif= y > an IP address, but it doesn't know what IP address to specify. It > therefore has to wait the same full roundtrip anyway. Compare > > A. > - [C->S] CONNECT-IP > https://proxy.example/ip?target_host=3Dtarget.example.com > - [S->C] 200 OK, ROUTE_ADVERTISEMENT [192.0.2.1] > - [C->S] IP Packet to 192.0.2.1 > > Ironically, because of Issue #43. If you were allowed to have dst_addr=3D0.0.0.0 or something, then this would work. -Ekr --00000000000049130e05d04b3bf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 8, 2021 at 10:26 AM Ben S= chwartz <bemasc@google.com> = wrote:


On Mon, Nov 8, 2021 at 10:52 AM Tommy Pauly &= lt;tpauly=3D40apple.com@dmarc.ietf.org> wrote:


On Nov 7, 2021, at 3:12 PM, Eric Rescorla <ekr@rtfm.com> wrote:
<= /div>
...=C2=A0=C2=A0

Given that this is an IP layer mechanism, I would simply remove = the
DNS option; clients can always do DNS over the tunnel.


I can see this eith= er way.

For cases where I don=E2=80=99t want a ful= l tunnel, but just want to talk to one host, I would need to open an IP flo= w for a DNS server. I could of course open one, and then open a proxied flo= w to each target address, and request the same local address I got on the f= irst.

This would work, but is more back-and-forth,= and also doesn=E2=80=99t give me a way to just ask the proxy to use it=E2= =80=99s own DNS cache.

I = think we need to be clear about what the alternatives are.=C2=A0 Suppose we= compare

A. CONNECT-IP supports DNS names. [curren= t draft]
B. CONNECT-IP doesn't support hostnames but is co-lo= cated with a DoH server.

Then either way, the clie= nt benefits from a DNS cache at the proxy.
=C2=A0
For cases like CONN= ECT and CONNECT-UDP, we=E2=80=99ve found it very useful for latency to have= the DNS cache run on the proxy, so that we benefit from all clients going = through the proxy sharing the same cache, and not needing a round trip back= to the client.

That bene= fit does not apply to CONNECT-IP, because the client must specify an IP add= ress, but it doesn't know what IP address to specify.=C2=A0 It therefor= e has to wait the=C2=A0same full roundtrip anyway.=C2=A0 Compare
=
A.
=C2=A0- = [S->C] 200 OK, ROUTE_ADVERTISEMENT [192.0.2.1]
=C2=A0- [C->= S] IP Packet to 192.0.2.1


Ironically, because of Issue #43. If you were allowed to ha= ve dst_addr=3D0.0.0.0 or something, then this would work.

-Ekr
--00000000000049130e05d04b3bf7-- From nobody Mon Nov 8 12:52:36 2021 Return-Path: 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 4D7CD3A1180; Mon, 8 Nov 2021 12:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fau.de 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 E4cGuOMbNFOV; Mon, 8 Nov 2021 12:52:20 -0800 (PST) Received: from mx-rz-1.rrze.uni-erlangen.de (mx-rz-1.rrze.uni-erlangen.de [IPv6:2001:638:a000:1025::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C7E3A1132; Mon, 8 Nov 2021 12:52:19 -0800 (PST) Received: from mx-rz-smart.rrze.uni-erlangen.de (mx-rz-smart.rrze.uni-erlangen.de [IPv6:2001:638:a000:1025::1e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mx-rz-1.rrze.uni-erlangen.de (Postfix) with ESMTPS id 4Hp3Fp00MZz8vC3; Mon, 8 Nov 2021 21:52:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fau.de; s=fau-2021; t=1636404734; bh=i/Se92m/8Olts15+qD3i1+LgifH3RuesnsT2wZfxRpg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:To:CC: Subject; b=pypds5lvWVtYHCzpdRFkvqOP2p0GAep/TWxreMRYyCiL02oQzfDXhxGLxQBVtUSfO YcyUQvCelDXy83LNCduBUNBL2MDRXMBXW8MIE2FrpX9jXa11C99qMzaDrWu/EnkqTN ldw/bRTWHMZuX4H1iJJwAkzzVypfh1pnLSth6lRkcLeeoU02gzG0thod+NMmN1DLef A6q7Ba+I0aHIXwmC3ldVoFFBJEC8oK/rISQuKr0jUAuxfOk7kFs5EnsMJKKlNVfM0L 93odqjpU+BVNcij/Ll6DxMGpP70C+8TVubBOZzbFaDzFraTUC0vhx+b8rt0hhYzi4J DdW3I4SQl5dTw== X-Virus-Scanned: amavisd-new at boeck4.rrze.uni-erlangen.de (RRZE) X-RRZE-Flag: Not-Spam X-RRZE-Submit-IP: 131.188.37.210 Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) by mailhub.rrze.uni-erlangen.de (Postfix) with ESMTP id 4Hp3Fk4X96z8vFr; Mon, 8 Nov 2021 21:52:10 +0100 (CET) Received: from [192.168.178.35] (dynamic-077-004-104-186.77.4.pool.telefonica.de [77.4.104.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTPSA id 7186240F2449; Mon, 8 Nov 2021 21:52:10 +0100 (CET) To: Marcus Ihlar , "masque@ietf.org" Cc: "etosat@ietf.org" , kramer@tmit.bme.hu, Sebastian Endres References: <66f5e8e0-a57c-2f60-9d82-ee188dc95d9e@fau.de> From: Joerg Deutschmann Message-ID: <01169c23-6b61-974f-7364-ad24e49caaf8@fau.de> Date: Mon, 8 Nov 2021 21:52:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Masque] Path-wise congestion control with MASQUE as replacement for PEPs? X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 20:52:32 -0000 Thanks for your response and also thanks for the ANRW'21 paper and talk [1]. Especially the referenced papers are very interesting for a satellite use-case. As I see it, "multi-domain congestion control" is closely related to our idea of "path-wise congestion control". Are there any updates regarding performance evaluation results and/or publicly available implementations in this context? (sorry in case I missed it on the lists) [1] Cooperative Performance Enhancement Using QUIC Tunneling in 5G Cellular Networks https://dl.acm.org/doi/10.1145/3472305.3472320 https://irtf.org/anrw/2021/program.html Best regards, Joerg On 21.04.20 15:21, Marcus Ihlar wrote: > Hi, > This is an interesting use case that's also relevant in certain 5G deployments. > What you are trying to achieve here could be partially solved by having a client CONNECT via a proxy and the proxy CONNECT to the server or a server frontend proxy. The part that's not in scope for MASQUE, as it is scoped now, is the disabling of congestion control on the end-to-end connection. > Also note that QUIC datagrams are still congestion controlled even though the delivery is unreliable. > > BR > Marcus > > -----Original Message----- > From: Masque On Behalf Of Joerg Deutschmann > Sent: den 21 april 2020 11:07 > To: masque@ietf.org > Cc: etosat@ietf.org > Subject: [Masque] Path-wise congestion control with MASQUE as replacement for PEPs? > > Dear MASQUE list, > > could MASQUE provide path-wise congestion control, something like this (more fancy drawing attached): > > > MASQUE > Server > Client <------##########------##########------> Server > ^ ^ ^ > quic end2end quic > tunnel quic tunnel > sat cc datagrams any cc > > > Other than classical VPNs, the outer tunnels would take care of the flow > and congestion control. Such a setup could replace the Split TCP > Performance Enhancement Proxies used in satellite networks. > > Best regards > Joerg > > -- > Computer Science, Chair for Computer Networks and Communication Systems > Universität Erlangen-Nürnberg > Martensstr. 3, D-91058 Erlangen, Germany > e-mail: joerg.deutschmann@fau.de > phone: +49-9131-8527914 > From nobody Tue Nov 9 04:07:14 2021 Return-Path: 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 E46D93A0FC2; Tue, 9 Nov 2021 04:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 zEXSvD9iVL7B; Tue, 9 Nov 2021 04:07:08 -0800 (PST) Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.rno.apple.com [17.179.253.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DEC83A0FBF; Tue, 9 Nov 2021 04:07:05 -0800 (PST) Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 1A9BwlsE030814; Tue, 9 Nov 2021 04:07:04 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=D8+zhe6dfen6CQVD8qwpg/A1LQafjAxaiX6ugmEeXlE=; b=FWXrIMm+Vi8y0ZBJSr25a5O5btyvILoCQhQ7Z2U4EAkvFZS2/JcLnNBYgfm0R01Eqb8f 25tACy4yr4YZ9r0nnOHccKR1MaHAQQtX4hrzxszC9yVJetX+hNe0BONUh6cAsy4YkmWK mIZcn694WSb3Mmadxz9JYVgQLEifTkoujpYe0KiXc0/hteS+YwFvCHib08wuYDDp4jpx OJ2zVkHEcbEopKKyA/GuzrouSD9cloH2JLtnTatfYhU7VW5qtMu90dG+Q7fG9iH5LDwU gkX4FualNA5nJaakkFDD/LeiOBcV1DAcWv68qXrlv0NLhLBaip1cc9IBzuQQfWrXAI+y 9g== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 3c5n87c13v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 09 Nov 2021 04:07:04 -0800 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R2B008FA0BRGLB0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Tue, 09 Nov 2021 04:07:03 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R2B00K0001SB800@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 09 Nov 2021 04:07:03 -0800 (PST) X-Va-A: X-Va-T-CD: d9ccecb7d9fec9f5a38220676cb304f2 X-Va-E-CD: e751bb68e3c88abfd5fa72fa307cc21f X-Va-R-CD: 1b3cfd29a5716b3254857cda18470d42 X-Va-CD: 0 X-Va-ID: ba961bdb-17e2-4f37-bc73-afcec9a40e1c X-V-A: X-V-T-CD: d9ccecb7d9fec9f5a38220676cb304f2 X-V-E-CD: e751bb68e3c88abfd5fa72fa307cc21f X-V-R-CD: 1b3cfd29a5716b3254857cda18470d42 X-V-CD: 0 X-V-ID: f56d51cc-99a7-4ac8-b3ca-3d11af1fd502 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-09_03:2021-11-08, 2021-11-09 signatures=0 Received: from smtpclient.apple (unknown [17.11.170.54]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R2B00Q4Y0BOQJ00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 09 Nov 2021 04:07:01 -0800 (PST) From: Tommy Pauly Message-id: <4D8340B8-C2A6-4F76-92FF-03724DD8F4F9@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_A878BC5E-9A0C-4124-B9E3-B77ED1E98EED" MIME-version: 1.0 (Mac OS X Mail 15.0 \(3691.0.3\)) Date: Tue, 09 Nov 2021 04:07:00 -0800 In-reply-to: Cc: MASQUE To: Eric Kinnear References: X-Mailer: Apple Mail (2.3691.0.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-09_03:2021-11-08, 2021-11-09 signatures=0 Archived-At: Subject: Re: [Masque] Adoption call for draft-age-masque-connect-ip X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 12:07:13 -0000 --Apple-Mail=_A878BC5E-9A0C-4124-B9E3-B77ED1E98EED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As an author, I support adoption of this work. Best, Tommy > On Nov 8, 2021, at 6:07 AM, Eric Kinnear = wrote: >=20 > Hi all,=20 >=20 > At IETF 112 there was significant support in the room to adopt = draft-age-masque-connect-ip as a starting point for our CONNECT-IP = efforts. >=20 > This email begins an adoption call for draft-age-masque-connect-ip. >=20 > The datatracker page for this document can be found here:=20 > https://datatracker.ietf.org/doc/draft-age-masque-connect-ip/ = >=20 > And the GitHub repository can be found here: > https://github.com/tfpauly/draft-age-masque-connect-ip = >=20 > This call for adoption will conclude on November 22. >=20 > Thanks,=20 > Eric and Chris > --=20 > Masque mailing list > Masque@ietf.org > https://www.ietf.org/mailman/listinfo/masque --Apple-Mail=_A878BC5E-9A0C-4124-B9E3-B77ED1E98EED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii As = an author, I support adoption of this work.

Best,
Tommy

On Nov 8, 2021, at 6:07 AM, Eric Kinnear <ekinnear=3D40apple.com@dmarc.ietf.org> wrote:

Hi = all, 

At = IETF 112 there was significant support in the room to adopt = draft-age-masque-connect-ip as a starting point for our CONNECT-IP = efforts.

This = email begins an adoption call for draft-age-masque-connect-ip.

The datatracker page for = this document can be found here: 
https://datatracker.ietf.org/doc/draft-age-masque-connect-ip/

And the = GitHub repository can be found here:
https://github.com/tfpauly/draft-age-masque-connect-ip

This call for = adoption will conclude on November 22.

Thanks, 
Eric = and Chris
--
Masque mailing list
Masque@ietf.org
https://www.ietf.org/mailman/listinfo/masque

= --Apple-Mail=_A878BC5E-9A0C-4124-B9E3-B77ED1E98EED-- From nobody Fri Nov 12 00:58:12 2021 Return-Path: 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 15C7F3A0486 for ; Fri, 12 Nov 2021 00:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 z6eY7Xw0efDD for ; Fri, 12 Nov 2021 00:58:06 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70077.outbound.protection.outlook.com [40.107.7.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5D03A08F6 for ; Fri, 12 Nov 2021 00:57:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aOB7ZpuQ1ncb8uKNaw9RarxZaaZZ3pU5KmetVV3dQ6sMspExNxvK3rYFuVNehVCbqNwSyOOR7Vr8k0UT+pgTEubg29nd/pYwc31JhnokpjMso/Mkn0eIZ48G5GSLzfZac2FEsHYyOVZv3SZ8F5Nqkl6aW1MyiHCk1rHN2AzsIgWWCFzDgkHbe9IAWZ/68ekxKedAsTeee00SmSyZl4oO771TmDEhA2FHfroIHPL1zMSx53tVVgH/tLZNegJh5blY5CSSGyuNNmdWr6/vOaJnVjkUQu7rWWiUGE7U9hGdTxIDxhtZCBK/6DPpX48DzY4Qy7XQXOcT+Mstu8HRJfsbeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Nmq+LQrefoSajSjHaoNMhyIoCxYeBzqsCoacaCE1qXE=; b=XADJ96xI0fVhMZ/U5JEi4x5nHINBl1EbZI3YhsytQe8VQKvLfL0ofIn5NdbtfgJz6onoFzPw84kkCWewJhQb/GnodMIXPFyXDQtDabXQJsIvcrqo8hg2f9QrzRN6ctr9Ld34jsXLMSYbonMm00SHRXB0JTGxZFsZW0ac0T7FDQMucTNtBXJdE0OzrubXBQrCsBYjcK8plelrgyi3usk4hnOFnq7yujKwphwDqAUp6cUtJxC6/bb2uNf+S41PDzpe2G4+feMwBuR0Ckqn4f2DvUpxg8LTlhM6+O1x/VN71J+LB2k85LCBjsB0IUmrjjkRIadhRJZ/VmtGW43Xh/musQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nmq+LQrefoSajSjHaoNMhyIoCxYeBzqsCoacaCE1qXE=; b=saOlHWTMHaxC2mV9g1Q3KbFehiiRlgfj5gNOWuBn2UZWlvnAifAMfYWtas7CLBIycAs3OvtlWdtttLisDfbnOLMJRbC1lLP1XiiXQayS3DQorJ+f5fcjajzGcZvUDDYh2qVAXsNM8kBZSR0e8l+CftyiKgtqQT84uHpK+LrvPvc= Received: from AM0PR07MB4131.eurprd07.prod.outlook.com (2603:10a6:208:4b::27) by AM0PR07MB4755.eurprd07.prod.outlook.com (2603:10a6:208:7b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.13; Fri, 12 Nov 2021 08:57:24 +0000 Received: from AM0PR07MB4131.eurprd07.prod.outlook.com ([fe80::1061:7da4:23ad:41ee]) by AM0PR07MB4131.eurprd07.prod.outlook.com ([fe80::1061:7da4:23ad:41ee%6]) with mapi id 15.20.4690.025; Fri, 12 Nov 2021 08:57:24 +0000 From: Marcus Ihlar To: "ekinnear=40apple.com@dmarc.ietf.org" , "masque@ietf.org" Thread-Topic: [Masque] Adoption call for draft-age-masque-connect-ip Thread-Index: AQHX1Kn8eHrjtdo8akmSuOqw7wCqWqv/m/GQ Date: Fri, 12 Nov 2021 08:57:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c01710ca-75a9-4df9-731b-08d9a5ba71ef x-ms-traffictypediagnostic: AM0PR07MB4755: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: r47uc4jDWXRm9Q2tUtzNwnpqpiuBu73W8fTYmN5asoV6jRBm2iUDcICGSwRYzGnZsVsp9NUBeJsbycbmX9ol1CHbKGNs1/5dUi/iSmOdAMEyTpiRF/8N3tKgrL3Jb5E/kBAL+wEKtyCEGIqans7tKJ1Jkw0SDnEOLaOR2tMDz+gFd3pAgm0ZooBWDhulnTYjqHeJtYCJtIMcnDmvR4L9wI8/VwSB44QmnmC5JvLrcTwFcXV44mf2CpIUesRL8Kmx9o6MMCf4VdpRKW4nYh2GQFI65s5Tgf6g0oy7G+dDkHLc7LCaydyJgD3679Fw/rl0Ea6snZZP1Su+fRDYKGmYmpdNYJ3yY3PW2lZ1TAcClzHHbLBTyf/0jlFk/psBcJWh7pgsDdbBJz6vr84JCcA4PIchlg3FkFG4ceKDCUnEgXIVGPhrdkQ6STcVDk4vFE6upZp60zwtYlXFX/+zSDTjWRrGgZ8q3SntgjrilBb+tvISRz4HXLKpWUGAee+f4BltgnsKzyeZfimi2V1IYru8lF7/4LxeOLup0nXElhpWSmIDAQDNQBZjggnE/agGjjyGaG6G5XelxIg3hS8lBYBwv3fFEspbChePEf0+ff1LcLTBZNCFYTA1SrPZ9dRsmsJcSQtB1P7R99Q/YqjmYpSqUIVCOq6Ydo8HbC7ZPGBD7ggnvzOSrLoSwJN3DPjd4VoK9T/AMnuWnA0zAKLyuQ8ooF9F7Ikciqeqhy4rGUg9pE3knztwj1g0TxbaFnDwI1kdzpRkybfnNJeW5TD5MJXhyF8dKwPsClYPZwz/jC/dtFNoybSEY6zBNqU+g1nk/D8t3pXTymbEyU/28ubgNxnnwg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4131.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66946007)(33656002)(166002)(966005)(7696005)(66446008)(38070700005)(71200400001)(52536014)(8936002)(66556008)(66476007)(64756008)(4744005)(44832011)(186003)(82960400001)(508600001)(110136005)(53546011)(316002)(76116006)(2906002)(6506007)(8676002)(55016002)(86362001)(5660300002)(38100700002)(122000001)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?+ISkpLhjgIIAm7GuLPHawz6s4meyj1dWjWoLvZ+9gZrTMED7dsC3t0s09KuH?= =?us-ascii?Q?GZuPvCOK8vaiI+1+0/fgCwQuLLkY5aHFMSP/nRW9AKC3GZFsrP2hB0U3GHHR?= =?us-ascii?Q?/iojytdifdrHKNOE+QKrOXWRBj0NzHsaJvSeoM98rAM8+30FPOtNNnwdlE2O?= =?us-ascii?Q?kbuSdXBkueF7BicgYVhABnKMQMrAoUmOVTYTZ+2tZspc6rGHBqUce0Pc6ypR?= =?us-ascii?Q?7WMnv/TgYtiVkq03vzLBIRw9aJD4xR4SOcHw6vpSWxSZ94CahhGwMOmbNI2d?= =?us-ascii?Q?RoXKS7lQoyRQmhCZNjVS+VniOG3YDRg2WJWaxyatwmcDEfwCJcyrOJHanzp+?= =?us-ascii?Q?vpsto7lMey9t1cbyHEGF4ZY9S1MY2azhxVDWfCQPVxgzPOZb1n/HpF6P3rep?= =?us-ascii?Q?e6JP72o9qwyOBqdvQUE5Lm5elaQvuwA4GT/aiXxTEjcPuLXpYGVEmSWTXLh/?= =?us-ascii?Q?SK+Buucp3EUuVzKhdh3f60sXb65ojGEq6/HqW4jaOyv4KRBYydfouUUENZLL?= =?us-ascii?Q?E79zTximjfojwZb/Mw6yb408SSBueWDNzf1Ylvqk4KG5MB8belvPlg/5u/WR?= =?us-ascii?Q?Xxt1Rl9DPOx8HAxIyW9PvlEO6OmS1ABfcVuP08ofc2RWX/YIjcUuq1B6Jd/z?= =?us-ascii?Q?Npa/v/BLGUd/KSX4/rrhUpORHmnc1EQVXv8z7pucrxkbWhSQO4cPRcM3SdcG?= =?us-ascii?Q?faHkQz4DxR69XVyQ/v1Gn9mU4wS+/fPbeAa2mdzs38+4gWOziwgcJBqozwYy?= =?us-ascii?Q?xpAB3lv44f+M6psH5i0FTynMvVuV6yZJICI4n8h6LSqSLLetecHJsK8tqoHC?= =?us-ascii?Q?Xa8fJ3kCRb5Kp8UMyIwYOo+szx5uwjvmkzys3UGJf3fLDwpJOfJyATr1kaOU?= =?us-ascii?Q?w/PQXaxTWOpRkR6RgZuRG43J//LeKlJWf3xRDIEvA+ZpJa6nchefXqK5BkFs?= =?us-ascii?Q?A3Ap9LC8nP1IQhFmyRp0Z2uU+R4f/cwQt/E42w+Ztt/GqbccuisnaAVVpI+j?= =?us-ascii?Q?Rct0v7vBDPV8vCoAv1H23QZ9kD2hrENCOMSSqUELGwWEeRzsGJrqn3mS/YGD?= =?us-ascii?Q?ng0SHqgIgG89ISpOi8VEeHk2PloJsg0LoANl9sTSLcIipbtedS/IATI6IIey?= =?us-ascii?Q?zDdEy2dDjaNk6/TZr0r1jMrXqQLDiTZVNU2auZsmWLsDLeT64hRNsl4VirEI?= =?us-ascii?Q?+sbC/kSjq5yFIuQcp4u2atkU3d0HHjOKIzxSz9RjmbWaK+eZFE1AECetXjFO?= =?us-ascii?Q?s6CIzQF3Z5uLayP6b7XIs6TEeL1zLbqggwNjb6KJIijMSpHuPJKOFcHe2ISH?= =?us-ascii?Q?frq+pj49kH+y0EjWrYj8sIFT07lOYpQ2XQ+p7IA60NgHCoZFwWBpfmzNMHOs?= =?us-ascii?Q?f/gxIQFPjGQV7JFIz7W3zF1UOCrkSYsW40bRFbb3IwBRQq5cF2uQLVDG/h8t?= =?us-ascii?Q?fYtlbplQ8NrClzmq6qvdjmuginQMwRWz5hKkmTqXbR4ihECypFFaQDwhF24Q?= =?us-ascii?Q?XLxRXHpSbbWOvwfzSDxppMNuHuS6mOLJWtFr2L2kLA6EhC0q2U8qb2/zyZOQ?= =?us-ascii?Q?av15CZ6R0Rup128rh1A4xSJG43K+b4ovRzD0t63k8V+BoRyI6PHMTp7I/BE/?= =?us-ascii?Q?VkGfTpVcs5W/gUUWLJmUUvNg0qDB3K1UDmO5AnBVzhnzOw0Qdo+NzvpRq5/r?= =?us-ascii?Q?aKzeAzr8INWsm8M01l8v6DIXcJf0hry//rbGXh22z2fLDz0T9HTTutalB3Ef?= =?us-ascii?Q?RNyTyzVe/A=3D=3D?= Content-Type: multipart/alternative; boundary="_000_AM0PR07MB413108AE5A0459DB7FCD0417E2959AM0PR07MB4131eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB4131.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c01710ca-75a9-4df9-731b-08d9a5ba71ef X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2021 08:57:24.3354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qseppMDFsVWH1AOko5Oi5qzoPRIpedcPVuJKpSDYaqqPcHwgLTTv1qn74NKKzrpMtbGq8yspo0Mh3BT5A1tYs2VhZQj1QGcubYe4+/4Oqwg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4755 Archived-At: Subject: Re: [Masque] Adoption call for draft-age-masque-connect-ip X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2021 08:58:11 -0000 --_000_AM0PR07MB413108AE5A0459DB7FCD0417E2959AM0PR07MB4131eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adoption of this draft From: Masque On Behalf Of Eric Kinnear Sent: den 8 november 2021 15:07 To: MASQUE Subject: [Masque] Adoption call for draft-age-masque-connect-ip Hi all, At IETF 112 there was significant support in the room to adopt draft-age-ma= sque-connect-ip as a starting point for our CONNECT-IP efforts. This email begins an adoption call for draft-age-masque-connect-ip. The datatracker page for this document can be found here: https://datatracker.ietf.org/doc/draft-age-masque-connect-ip/ And the GitHub repository can be found here: https://github.com/tfpauly/draft-age-masque-connect-ip This call for adoption will conclude on November 22. Thanks, Eric and Chris --_000_AM0PR07MB413108AE5A0459DB7FCD0417E2959AM0PR07MB4131eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support adoption of this draft

 

From: Masque <masque-bounces@ietf.org> = On Behalf Of Eric Kinnear
Sent: den 8 november 2021 15:07
To: MASQUE <masque@ietf.org>
Subject: [Masque] Adoption call for draft-age-masque-connect-ip=

 

Hi all, 

 

At IETF 112 there was significant support in the roo= m to adopt draft-age-masque-connect-ip as a starting point for our CONNECT-= IP efforts.

 

This email begins an adoption call for draft-age-mas= que-connect-ip.

 

The datatracker page for this document can be found = here: 

 

And the GitHub repository can be found here:

 

This call for adoption will conclude on November 22.=

 

Thanks, 

Eric and Chris

--_000_AM0PR07MB413108AE5A0459DB7FCD0417E2959AM0PR07MB4131eurp_-- From nobody Sat Nov 20 23:56:07 2021 Return-Path: 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 36E9B3A0899 for ; Sat, 20 Nov 2021 23:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Cf7OYlBe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Cr1MtHjR 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 tujNW8WOjA-3 for ; Sat, 20 Nov 2021 23:55:51 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998033A0897 for ; Sat, 20 Nov 2021 23:55:51 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3A7485C0131 for ; Sun, 21 Nov 2021 02:39:00 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 21 Nov 2021 02:39:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm1; bh=72p40I9CllG WvPnpPJgpqzg+l1hqeaedo028b0wo4Oc=; b=Cf7OYlBewrla4BGMxLfGzKuCTCD zBofwyGeh4I7hlDD1pomm8S1P3x8VfDVoP09t8AXkZFD/kl1r8H0sTpyAiZNOicp jokyBeASOOWcLMkvAZa2xm6g1rkWlGPCz5fg2sXjiyaWtfAX5GJOp40tfqzsBwfq nYw+9/VlUuDmCyuoSDrBJYYLCxgIYcQR1XpuB43EFrZfxluRd28yTHuwimk+BgsZ tducPDts1w4YRmK1zYGHolWiGwKkDPDipdFjMo7NS5Ujv1p/p99VCCZG+/MQduex /tVh3t7WyvAgKfIcjbPUIFhgACESUdva+roLUtC32OGo+Orsd2zDcJJgLDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=72p40I9CllGWvPnpPJgpqzg+l1hqeaedo028b0wo4Oc=; b=Cr1MtHjR ECCv4HqiHGzxYaUpVdjFS9VwLC/Aw3iDlONf7dPMGGpSJBD9IOscofkYAl9qWQ+y u0+Ka5TasnjOIUvLas0MnGT8R33bgPlJrZVhjd8CZTlg0SPS13ApRoAlL6bEff4q nXZDykI2SF19ALIde/zdXLsusRsLFRNAQ5T04/stvBDNF0IzYPlpxudRsWCCIyW/ aqje8em2f8H9Kd0QcdP49JtAqdgt+WrojaiL4HrN6iTTsP9v2ME7OdomC66CYqTj g+a70MwZISfxh4VQfvGv0GtnmGbjmVZFWVgUfReVJW8B/mOWj/LU71xxumR4/9tc d2408n1e49Okgw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrgedugddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 21 Nov 2021 02:39:00 -0500 (EST) Content-Type: multipart/alternative; boundary="===============2995883698742257297==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: masque@ietf.org Message-Id: <20211121075551.998033A0897@ietfa.amsl.com> Date: Sat, 20 Nov 2021 23:55:51 -0800 (PST) Archived-At: Subject: [Masque] Weekly github digest (MASQUE Working Group summary) X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2021 07:55:57 -0000 --===============2995883698742257297== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * ietf-wg-masque/draft-ietf-masque-h3-datagram (+1/-0/=F0=9F=92=AC6) 1 pull requests submitted: - First Proposal for Output of Design Team (by DavidSchinazi) https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/pull/12= 4=20 1 pull requests received 6 new comments: - #124 First Proposal for Output of Design Team (6 by DavidSchinazi, LPar= due, achernya, afrind) https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/pull/12= 4=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp * https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram * https://github.com/ietf-wg-masque/draft-ietf-masque-ip-proxy-reqs --===============2995883698742257297== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MASQUE Working Group summary)

Sunday November 21, 2021

Pull requests

ietf-wg-masque/draft-ietf-masque-h3-datagram (+1/-0/=F0=9F=92=AC6)

1 pull requests submitted:

1 pull requests received 6 new comments:

Repositories tracked by this digest:
--===============2995883698742257297==-- From nobody Sun Nov 28 00:56:05 2021 Return-Path: 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 6A8D43A0163 for ; Sun, 28 Nov 2021 00:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=NSocSvpy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=U4cTHO9Q 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 uFJlhHb0x0Q7 for ; Sun, 28 Nov 2021 00:55:58 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED533A0147 for ; Sun, 28 Nov 2021 00:55:58 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id E7A513200A2A for ; Sun, 28 Nov 2021 02:38:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 28 Nov 2021 02:38:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm1; bh=si08ueYfUlC NoPQCxvJ0VRVyicV708fClLoJN3Rm3QY=; b=NSocSvpyJGuUUfM23itP2r28HFU LGFZUAsVR9zsCXDUmj1UZGVLzNWIRImNjsBqOrOH6Illr1zBSnovf46Bf+G+oYIy aw9TSz6Hz0LrlMnDwobst0AtiwKNcyAY4FM0s+wc6fZbSz+jqYS3GsQ2TFCkHvtp Z1I7tBTsrC2vN5x7JARi7jueJiQ2TpsOOzLN5Vo8/y5LGmfUrYpaEoTa0KtiP/3b 1tDx1kY+lGNxwGJEHf7Z1qRuo+kfw8FiTK+f88NXf/ZCYO0IWwMiVv/OQAopkapj rBnHtHfUWDd0tuXStF3ZfcGyvzcjJmfZb3eJPpzShSIjEd02NHfL/AxuOfw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=si08ueYfUlCNoPQCxvJ0VRVyicV708fClLoJN3Rm3QY=; b=U4cTHO9Q 4N5S6SC9uiG3lKdm7Pm/AI5aEXWOrcoLUkfu1skd89kgz4zDzDMFlxGyXJnlMjrZ flCaLzGwP1IexfUKFXYW0WSHI9HQDuqBObjnsWFm/Qg7mX8zG/VUY8ws47B4o5Bz sQkayXrL/1w3hDrVlyKnC1W6NKr2jFFpVQq3LvSC7DbqB+/W6lp8I8pMiYuuJ2Mb rMD5t2dr5nMlJfkokIjgL8kVGMxlL2oYSaZFznhf2ymfqoafuOODeaQj/Vg2H7d4 Qu/J/LM/Y8TcrSJ7ELK4UIeJX1pxCvAToD5IR+vQwC33OxhOqYg3DKNbwWpH458f DU5GRYfqFiLERQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrheehgdduudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 28 Nov 2021 02:38:55 -0500 (EST) Content-Type: multipart/alternative; boundary="===============5716987197048333471==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: masque@ietf.org Message-Id: <20211128085558.5ED533A0147@ietfa.amsl.com> Date: Sun, 28 Nov 2021 00:55:58 -0800 (PST) Archived-At: Subject: [Masque] Weekly github digest (MASQUE Working Group summary) X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2021 08:56:04 -0000 --===============5716987197048333471== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-wg-masque/draft-ietf-masque-h3-datagram (+1/-0/=F0=9F=92=AC7) 1 issues created: - Zero-Latency Extensibility (by DavidSchinazi) https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues/= 125=20 2 issues received 7 new comments: - #125 Zero-Latency Extensibility (4 by DavidSchinazi, afrind, martinthom= son) https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues/= 125=20 - #111 RELIABLE_DATAGRAM (3 by DavidSchinazi, afrind, martinthomson) https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram/issues/= 111=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp * https://github.com/ietf-wg-masque/draft-ietf-masque-h3-datagram * https://github.com/ietf-wg-masque/draft-ietf-masque-ip-proxy-reqs --===============5716987197048333471== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MASQUE Working Group summary)

Sunday November 28, 2021

Issues

ietf-wg-masque/draft-ietf-masque-h3-datagram (+1/-0/=F0=9F=92=AC7)

1 issues created:

2 issues received 7 new comments:

Repositories tracked by this digest:
--===============5716987197048333471==-- From nobody Tue Nov 30 05:09:41 2021 Return-Path: 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 564113A12AF for ; Tue, 30 Nov 2021 05:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=kiBHhGgH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c+aAx7x3 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 NIKZeIo0CC0D for ; Tue, 30 Nov 2021 05:09:34 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7013A12AC for ; Tue, 30 Nov 2021 05:09:33 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 4044B3202083 for ; Tue, 30 Nov 2021 08:09:32 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute1.internal (MEProxy); Tue, 30 Nov 2021 08:09:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=DskP3gHXHsjKf+uSlgobbzGKTILqDrk 9WXN4YdF7UX8=; b=kiBHhGgHrDQn5BbfPCKGQ0V1atghasnHvkqvYugtMm0GU3R r4wAVX+a1G+QQSEC6WRCFvpo77TbJriNe45HBoZXBDvl7MzlFapAdN712YX5Xztt b2Gx5CkVgDnulI8Q23D0EAFkGJoNQlHowOXtUmuV7u5+sj4Ta0Q6/MuAqSuQwxUz x/u8POjZL+58ylqgGmuviI9MLXyB4ym/ReEMQC3x6Nafe6JBoxvQKbc186qgJNkj vkmS9tulK0Iwd37b38umzZyeYMw811A8A9sAH7ckHYDmz92GbC6wDVqIXfjU116r NmHWqNhXIgOoYFe5bkT3Sf1s1aoRXyZhA36UU/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=DskP3g HXHsjKf+uSlgobbzGKTILqDrk9WXN4YdF7UX8=; b=c+aAx7x3gZO05DhViUU2zT ZP2cmS7DWoUP9pm4ObwCGCaoqmUwZ4Iik9FpiZKEQxH21u7zMNDeGddKl4buDGQG zwk/E1Gg55Apv8J7zlCiBjiPdnCqZ/Px+kOZIRZq95xHAZHfaEfPEAs+obZCEj/W 3Ofcg2Feyf6BEisq3brOiFw8O/6/gDOxDq3tJynaTLNr1V/QHwPS3phxHjVec3sw 1cf3uQ8os9ua1re0c7ESD6Y0J9UfzMqxVDEXVrCdWtub66ioYv71WDu5FnUf4i9L Ml66gfQwvjW23oiw+hJ8VPuRSj7iB8H3MEkXKJ4Sb8FY2KFBloUUH/DfGang5Jhg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddriedugdehtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnheptdffueelveefle ehlefffffgleffjefhkeetudfhueelheetjeehvdffgffhueelnecuffhomhgrihhnpehg ihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7DC873C0F62; Tue, 30 Nov 2021 08:09:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4410-g5528bb82a8-fm-20211130.003-g5528bb82 Mime-Version: 1.0 Message-Id: <5c8d795a-ca61-43c8-ba29-9fd24c91ae7d@www.fastmail.com> In-Reply-To: References: Date: Tue, 30 Nov 2021 05:08:56 -0800 From: "Christopher Wood" To: masque@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Masque] Adoption call for draft-age-masque-connect-ip X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2021 13:09:40 -0000 The adoption call is now complete. Based on support expressed during IETF 112 and here on the list, we think there's consensus to adopt this as a WG draft. Authors, can you please submit draft-ietf-masque-connect-ip-00 at your earliest convenience? Let's also transfer the repository to the WG's GitHub organization (https://github.com/ietf-wg-masque). Thanks, Chris and Eric On Mon, Nov 8, 2021, at 6:07 AM, Eric Kinnear wrote: > Hi all, > > At IETF 112 there was significant support in the room to adopt > draft-age-masque-connect-ip as a starting point for our CONNECT-IP > efforts. > > This email begins an adoption call for draft-age-masque-connect-ip. > > The datatracker page for this document can be found here: > https://datatracker.ietf.org/doc/draft-age-masque-connect-ip/ > > And the GitHub repository can be found here: > https://github.com/tfpauly/draft-age-masque-connect-ip > > This call for adoption will conclude on November 22. > > Thanks, > Eric and Chris > -- > Masque mailing list > Masque@ietf.org > https://www.ietf.org/mailman/listinfo/masque From nobody Tue Nov 30 09:57:04 2021 Return-Path: X-Original-To: masque@ietf.org Delivered-To: masque@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 535F63A145D; Tue, 30 Nov 2021 09:56:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: masque@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: masque@ietf.org Message-ID: <163829501810.21455.14302656558029018247@ietfa.amsl.com> Date: Tue, 30 Nov 2021 09:56:58 -0800 Archived-At: Subject: [Masque] I-D Action: draft-ietf-masque-connect-ip-00.txt X-BeenThere: masque@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multiplexed Application Substrate over QUIC Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2021 17:56:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiplexed Application Substrate over QUIC Encryption WG of the IETF. Title : IP Proxying Support for HTTP Authors : Tommy Pauly David Schinazi Alex Chernyakhovsky Mirja Kuehlewind Magnus Westerlund Filename : draft-ietf-masque-connect-ip-00.txt Pages : 20 Date : 2021-11-30 Abstract: This document describes a method of proxying IP packets over HTTP. This protocol is similar to CONNECT-UDP, but allows transmitting arbitrary IP packets, without being limited to just TCP like CONNECT or UDP like CONNECT-UDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-masque-connect-ip-00.html Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/