Re: [Masque] Unifying CONNECT-IP Proposals

Tommy Pauly <tpauly@apple.com> Fri, 27 August 2021 19:53 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA463A130E for <masque@ietfa.amsl.com>; Fri, 27 Aug 2021 12:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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 lOOyEgdVZBTH for <masque@ietfa.amsl.com>; Fri, 27 Aug 2021 12:52:55 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp15.apple.com (rn-mailsvcp-ppex-lapp15.rno.apple.com [17.179.253.34]) (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 DD6433A1304 for <masque@ietf.org>; Fri, 27 Aug 2021 12:52:55 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp15.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp15.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 17RJqnwm021262; Fri, 27 Aug 2021 12:52:52 -0700
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=crOfwo8TDv6FWScShBm6td/CKANFlJpz5HeGNqKFT4E=; b=eL8oK1FAQgXKj9TSEflQyFFCR0KZYv0NrCh/HuQoV6lSIHP09CE10lNrRtNRVZhwBGJR EyjumNOUGwiOgaF3/+20SntDM9PjogDbbJvQOou3/gXpxdTNeoipUMY312xRCHmrLmqu rYQlXvncJOrxGkgHi4eRXfRAg9NbGw67iPrrMdIpf1mjBq7KrrogUzQ6rXK9+7O0QKc6 dcWu+JSIqd3ycYtBM6bUA3KjnSv+KVHkZIhwRX6BshdC3RQwLvSUhALjKbQyujvXITPN 1knNEOg9C3OqjAwXHEIN+Obz7RR/y1zxzdLVVnbFi9Egb8Ylxgxtazw982C4VoNsrgpX vQ==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp15.rno.apple.com with ESMTP id 3ajy2bysh4-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 27 Aug 2021 12:52:52 -0700
Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QYI00KBFKK4GRF0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Fri, 27 Aug 2021 12:52:52 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QYI01100K4W2O00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Fri, 27 Aug 2021 12:52:52 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 86a101bb85ebb52d38b4b0b10a68ff9e
X-Va-E-CD: 6958aaad2eccdca6d875c1f0dbcca7b3
X-Va-R-CD: 594eb84eb2bad94341062af861bc90ed
X-Va-CD: 0
X-Va-ID: 09102aec-5a01-45c2-8b29-102bc8fd50ef
X-V-A:
X-V-T-CD: 86a101bb85ebb52d38b4b0b10a68ff9e
X-V-E-CD: 6958aaad2eccdca6d875c1f0dbcca7b3
X-V-R-CD: 594eb84eb2bad94341062af861bc90ed
X-V-CD: 0
X-V-ID: 970e365a-8711-47b6-b380-ba8adec05043
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-27_05:2021-08-27, 2021-08-27 signatures=0
Received: from smtpclient.apple (unknown [17.234.97.71]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QYI00B6YKK30600@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Fri, 27 Aug 2021 12:52:51 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <7C135A13-4E2E-4619-9620-73D6540329C6@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_C51EC10D-5688-46CC-9E0A-B1C5B37D2350"
MIME-version: 1.0 (Mac OS X Mail 15.0 \(3691.0.3\))
Date: Fri, 27 Aug 2021 12:52:51 -0700
In-reply-to: <CAPDSy+5R68Kn8uD_ig1vVbxO+Z=vEBJBy+veBCXN-GU1xmGGzw@mail.gmail.com>
Cc: MASQUE <masque@ietf.org>
To: David Schinazi <dschinazi.ietf@gmail.com>, Christopher Wood <caw@heapingbits.net>, Eric Kinnear <ekinnear@apple.com>
References: <CAPDSy+5R68Kn8uD_ig1vVbxO+Z=vEBJBy+veBCXN-GU1xmGGzw@mail.gmail.com>
X-Mailer: Apple Mail (2.3691.0.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-27_06:2021-08-27, 2021-08-27 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/Qc-fACS-fPtmsQ5NdY7veU62-b0>
Subject: Re: [Masque] Unifying CONNECT-IP Proposals
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Aug 2021 19:53:03 -0000

Hi David,

While I appreciate the effort to show extensibility, I don’t think this is quite the right approach for what the core of CONNECT-IP would be, and how to frame collaboration on the different use cases.

Specifically, the proposed core document is still lacking a description of when the various capsules are needed, and I think it would be far simpler to say that the address assignment mode is something that is optional, rather than making extensions try to work around it. I’m also not convinced that these various use cases need to split up rather than having a more elegant and unified set of solutions.

As you mention, I’ve spoken a bit about this with the various authors and would be happy to help act as an editor to resolve these various directions. This needs to be a collaborative effort, and I think the protocol will be stronger for it.

Chairs, would you help set up a working interim call to work on how CONNECT-IP should be structured?

Best,
Tommy

> On Aug 27, 2021, at 8:04 AM, David Schinazi <dschinazi.ietf@gmail.com> wrote:
> 
> Hi MASQUE Enthusiasts,
> 
> As you know, we've had two distinct proposals for CONNECT-IP for a while. While
> both of them have interesting features, we need to unify on a joint effort if
> we want to make progress. In order to further that goal, we've made some edits
> to the existing documents in order to create a unified coherent path forward.
> 
> First, we updated draft-ietf-masque-ip-proxy-reqs to reflect working group
> consensus: since the WGLC showed consensus on everything except the
> network-to-network use-case and the route negotiation requirement, both of
> those were removed from the document. draft-ietf-masque-ip-proxy-reqs-03 [1]
> now better reflects the working group's choice.
> 
> Based on these requirements, and on the WG consensus at IETF 110 to focus on
> Proxying IP Packets, we also updated draft-cms-masque-connect-ip. We removed
> all routing-related features and now draft-cms-masque-connect-ip-02 [2]
> contains solely what is needed to satisfy the WG's requirements from
> draft-ietf-masque-ip-proxy-reqs-03. We've had some interesting conversations
> with Tommy Pauly on this topic and would love for him to join us as editor on
> draft-cms-masque-connect-ip.
> 
> Additionally, the discussion at IETF 111 showed that folks were also interested
> in various features that didn't have WG consensus: some are interested in
> negotiating routing and some are interested in flow forwarding. We believe that
> both of those are interesting features worth pursuing. The best way to
> accomplish this is through extensions. Luckily CONNECT-IP is extensible.
> 
> We wrote up the routing negotiation as an extension in
> draft-cms-masque-connect-ip-ext-routes [3]. This enables split-tunnel VPN and
> the network-to-network use-case.
> 
> We also made sure that flow forwarding mode would work as an extension, and as
> proof-of-concept wrote it up as draft-tbd-masque-connect-ip-ext-flow [4]. As
> mentioned in that document, this is mostly copied from
> draft-kuehlewind-masque-connect-ip-01 [5] with some minor modifications. We
> would like to have the authors of draft-kuehlewind-masque-connect-ip author
> this extension, given that they produced the interesting ideas in it.
> 
> We think this refactor would be a great path forward for the MASQUE working
> group: it would allow us to unify multiple proposals around a common extensible
> protocol. We did discuss merging these three documents into one, but decided
> against it because it would unnecessarily delay the publication of CONNECT-IP.
> We would love for the working group to adopt both extensions as they will
> influence the design of CONNECT-IP, but both need to solve some specific hard
> problems that don't need to delay CONNECT-IP, so they deserve their own drafts.
> 
> As usual, comments and thoughts are most welcome!
> 
> Thanks,
> David
> 
> [1] https://datatracker.ietf.org/doc/html/draft-ietf-masque-ip-proxy-reqs-03 <https://datatracker.ietf.org/doc/html/draft-ietf-masque-ip-proxy-reqs-03>
> [2] https://datatracker.ietf.org/doc/html/draft-cms-masque-connect-ip-02 <https://datatracker.ietf.org/doc/html/draft-cms-masque-connect-ip-02>
> [3] https://datatracker.ietf.org/doc/html/draft-cms-masque-connect-ip-ext-routes-00 <https://datatracker.ietf.org/doc/html/draft-cms-masque-connect-ip-ext-routes-00>
> [4] https://datatracker.ietf.org/doc/html/draft-tbd-masque-connect-ip-ext-flow-00 <https://datatracker.ietf.org/doc/html/draft-tbd-masque-connect-ip-ext-flow-00>
> [5] https://datatracker.ietf.org/doc/html/draft-kuehlewind-masque-connect-ip-01 <https://datatracker.ietf.org/doc/html/draft-kuehlewind-masque-connect-ip-01>
> -- 
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque