Re: [Masque] Unifying CONNECT-IP Proposals

[Martin Duke <[e-mail]>]

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 <[e-mail]> wrote:

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