Re: [Masque] Unifying CONNECT-IP Proposals

[Eric Rescorla <[e-mail]>]

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

> 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.
>

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.
>
> 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 <[e-mail]>
> 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
>> [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
>> --
>> Masque mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/masque
>>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>