Subject: [Masque] Unifying CONNECT-IP Proposals

From: David Schinazi <[email-masked]>
Date: Fri, 27 Aug 2021 11:04:16 -0400

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
[2] 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
[4]
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

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 27 Aug 2021 12:52:51 -0700

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 <[email-masked]> 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.
> 
> with Tommy Pauly on this topic and would love for him to join us as editor on
> Additionally, the discussion at IETF 111 showed that folks were also interested
> negotiating routing and some are interested in flow forwarding. We believe that
> draft-cms-masque-connect-ip-ext-routes [3]. This enables split-tunnel VPN and
> We also made sure that flow forwarding mode would work as an extension, and as
> group: it would allow us to unify multiple proposals around a common extensible
> against it because it would unnecessarily delay the publication of CONNECT-IP.
> 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.
> 
> [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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque

---

From: Eric Kinnear <[email-masked]>
Date: Fri, 27 Aug 2021 14:29:13 -0700

> On Aug 27, 2021, at 12:52 PM, Tommy Pauly <[email-masked]> wrote:
> 
> Hi David,
> 

Thanks, Tommy! We’re working on enumerating the possible paths forward for the WG’s consideration. Stay tuned for an update.

Thanks,
Eric

> 
> Best,
> Tommy
> 
>> On Aug 27, 2021, at 8:04 AM, David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi MASQUE Enthusiasts,
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Martin Duke <[email-masked]>
Date: Fri, 27 Aug 2021 17:22:25 -0700

Hi David,

First, thanks for making an effort (and some concessions) to move things
along!

As an AD, I have no objection to splitting up the CONNECT-IP deliverable
into multiple drafts. I would consider all of these child drafts to be in
scope of the current charter.

As an individual, I'm fine with the split at a high level, but this
architecture needs some deeper thinking about failure cases - servers that
don't support the extension, or intermediaries that forward CONNECT-UDP but
eat CAPSULE. In particular, I can see immediately that making flow
forwarding mode an extension creates a 1 RTT penalty -- IIUC I can't send a
datagram until the server confirms it processed the flow forwarding header.

That's not a deal breaker for me, but I'm curious what other failure cases
are lurking in the design.

AFAICT the network-to-network design is robust to these issues, so that's
safe to split out.

Hope that helps.

Martin

On Fri, Aug 27, 2021 at 8:05 AM David Schinazi <[email-masked]>
wrote:

> [1]
> https://datatracker.ietf.org/doc/html/draft-ietf-masque-ip-proxy-reqs-03

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Aug 2021 17:37:13 -0700

On Fri, Aug 27, 2021 at 5:22 PM Martin Duke <[email-masked]> wrote:

> eat CAPSULE.

FWIW, I'm generally not really sympathetic to these cases. Clients don't
magically connect to services, they are configured with them by services.
If you need CAPSULE, then you shouldn't be configured with the address of a
server which doesn't support it.

-Ekr

In particular, I can see immediately that making flow forwarding mode an
> extension creates a 1 RTT penalty -- IIUC I can't send a datagram until the
> server confirms it processed the flow forwarding header.
>

---

From: Martin Duke <[email-masked]>
Date: Fri, 27 Aug 2021 21:02:03 -0700

There are certainly cases where that approach is totally satisfactory. But
the CAPSULE case is mostly about intermediaries; in the flow forwarding
case, we are always stuck with the 1RTT delay unless we run the risk of the
server spewing out malformed packets.

To be clear, I like David's proposal at first glance; I also want to fully
think through these sorts of implications.

On Fri, Aug 27, 2021 at 5:37 PM Eric Rescorla <[email-masked]> wrote:

>> That's not a deal breaker for me, but I'm curious what other failure
>> cases are lurking in the design.
>>

---

From: David Schinazi <[email-masked]>
Date: Sat, 28 Aug 2021 12:23:44 -0400

Hi Martin,

This design does not require an extra round trip to use flow forwarding
mode.
That was actually one of the important design requirements of the straw man
to see if the design worked. The key design choice that enables this feature
is the fact that flow forwarding mode uses a different capsule type to
register
its datagram context IDs. The client can immediately send its
REGISTER_DATAGRAM_CONTEXT_IP_PAYLOAD capsule [1] right after
it sent its CONNECT-IP request, and it can start using IP Payload datagrams
right away. If the server does not support the extension, the server will
silently
drop the REGISTER_DATAGRAM_CONTEXT_IP_PAYLOAD capsule and not
consider that datagram context ID as registered, so when it sees subsequent
datagrams with an unknown context ID, those will also be dropped. This
removes
any risk that an endpoint tries to parse an IP Payload as if it were an IP
header
or vice versa.

To be clear, this is a very early proof of concept - if we decide to go
this route
we'll need to improve and iterate - there are bound to be many minor bugs,
but the overall design should work and provide the properties we've
discussed
at past meetings.

Thanks,
David

[1]
https://datatracker.ietf.org/doc/html/draft-tbd-masque-connect-ip-ext-flow-00#section-3.1.1

On Sat, Aug 28, 2021 at 12:02 AM Martin Duke <[email-masked]>
wrote:

>>> AFAICT the network-to-network design is robust to these issues, so
>>> that's safe to split out.
>>>
>>> Hope that helps.
>>>
>>> Martin
>>>
>>>
>>>> [2]
>>>> https://datatracker.ietf.org/doc/html/draft-cms-masque-connect-ip-02
>>>> [3]

---

From: Martin Duke <[email-masked]>
Date: Mon, 30 Aug 2021 10:37:24 -0700

Ah, I noew see that now that there's no issue here.

Thanks for making me smarter!
Martin

On Sat, Aug 28, 2021 at 9:23 AM David Schinazi <[email-masked]>
wrote:

>> There are certainly cases where that approach is totally satisfactory.
>> But the CAPSULE case is mostly about intermediaries; in the flow forwarding
>> To be clear, I like David's proposal at first glance; I also want to
>> fully think through these sorts of implications.
>>
>>>> First, thanks for making an effort (and some concessions) to move
>>>> things along!
>>>>
>>>> As an AD, I have no objection to splitting up the CONNECT-IP
>>>> deliverable into multiple drafts. I would consider all of these child
>>>> drafts to be in scope of the current charter.
>>>>
>>>> On Fri, Aug 27, 2021 at 8:05 AM David Schinazi <
>>>> [email-masked]> wrote:
>>>>
>>>>> Hi MASQUE Enthusiasts,
>>>>>