Re: [Masque] Unifying CONNECT-IP Proposals

[David Schinazi <[e-mail]>]

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