Re: [Masque] Unifying CONNECT-IP Proposals

[Martin Duke <[e-mail]>]

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

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