Re: [Masque] Initial look at draft-cms-masque-ip-proxy-reqs-00.txt

[Eric Rescorla <[e-mail]>]

On Mon, Jul 27, 2020 at 6:42 PM David Schinazi <[e-mail]>
wrote:

> Thanks for the feedback, EKR! Responses inline.
>
> David
>
>
> On Mon, Jul 27, 2020 at 5:58 PM Eric Rescorla <[e-mail]> wrote:
>
>> I took an initial look at this document. Comments below.
>>
>> S 2.
>> I'm surprised to not see the common consumer use case where
>> someone VPNs onto the Internet. I suppose you could argue
>> that this is "Point to Network" but the way you phrase
>> this in 2.2 suggests otherwise.
>>
>
> Good point, I think we should add that as a separate use-case to
> make it clearer that this is something that we want to support.
>
> S 3.2.
>>    The protocol will establish Data Transports, which will be able to
>>    forward IP packets, in their unmodified entirety.  The protocol will
>>    support both IPv6 [IPV6] and IPv4 [IPV4].
>>
>> This doesn't seem correct. At minimum you should be decrementing the
>> TTL and you might also be doing IP translation.
>>
>
> It depends on how you look at it. My thinking is that MASQUE itself does
> not modify IP packets at all. However, once your MASQUE server has
> decapsulated an IP packet, it'll pass it to its kernel which will then
> route
> the packet and decrement the TTL. I think that decrementing the TTL
> (and any kind of IP translation) should be out of scope for MASQUE
> IP proxying, and handled by other components separate from MASQUE.
>

I'm fine with that, but  it seems like it would be useful to clarify the
text to make
this point, because "forward" seems to me to imply that the packets that
go out the egress have the same TTL as those that come in.



> S 3.3.
>>
>>    The protocol will allow endpoints to negotiate the Maximum
>>    Transmission Unit (MTU) in use over a given Data Transport.  This
>>    will allow avoiding IP fragmentation, especially as IPv6 does not
>>    allow IP fragmentation by nodes along the path.
>>
>> This is an unusual use of the term "negotiate" because as a general
>> matter, the egress point will have a fixed external MTU and thus
>> the MTU becomes that minus overhead.
>>
>
> Perhaps "negotiate" isn't the right term. I think what we meant to say
> was that MASQUE endpoints should have the ability to inform their peer
> what MTU it has on egress. Do you have a suggestion for a better word?
>

Perhaps
"The protocol will allow endpoints to inform each other of their sending
MTU".

>
> S 3.4/3.5.
>>
>>    Both the client or server may request to be assigned an IP address
>>    range.  In response to the request, the peer will respond with an IP
>>    address range of its choosing.
>>
>> This seems like a feature that is intended for Network to Network
>> VPNs that doesn't make sense for a consumer-type VPN in which the
>> assumption is that the VPN server is the default router.
>>
>
> Not necessarily. In the consumer VPN protocols today, the server
> often tells the client what IP to use, and often the client has the ability
> to suggest an IP it would prefer if available, similar to DHCP. That's
> what we're trying to replicate here.
>

I am finding this text a bit hard to understand, so perhaps we can just talk
about what we are trying to achieve.

Consider the case where the server has external addresses in two ranges
A and B. The client might wish to have its outgoing packets come from
somewhere in either range. Is that what you have in mind?

However, the packets that the *server* sends to the client represent the
addresses of the endpoints the client is talking to. My point is that this
is not a symmetrical situation for this calss of VPN: from the client's
perspective
the server has all addresses (except for the narrow exceptions for which
the client is locally routing).


   At any point in an IP Session (not limited to its initial
>>    negotiation), the protocol will allow both client and server to
>>    request routes to specific IP address ranges.  In response to this
>>    request, the peer will have the ability to respond with a subset of
>>    routes that it is willing to accept, or deny the request.
>>
>> I don't understand what "request routes" means. Does it mean that
>> I am asking the peer to be willing to route to those domains?
>> Something else?
>>
>
> Yes, for example the client could say "I would like a route
> to 2001:DB8/32",
> and the server could respond "I'm willing to route you to 2001:DB8:42/48".
>

Hmm... Three points here:

1. It seems like it would work better for the peer to announce its routes
2. We should consider using some existing routing protocol here.
3. These routes seem like they need to be authenticated in some way.


>
>> S 3.6.
>>    When negotiating the creation of an IP Session, the protocol will
>>    allow both endpoints to exchange an identifier.  For example, both
>>    endpoints will be able to identify themselves by sending a fully-
>>    qualified domain name.
>>
>> Is this identifier secure authenticated?
>>
>
> Yes, though the way I've been thinking about it would be to have a
> mechanism for each endpoint to announce its identity, and then a separate
> mechanism for endpoints to authenticate themselves. The server could
> potentially use the client's identity when picking which key to use when
> verifying the client's signature, for example.
>

How would you compare this to the way that TLS/QUIC currently do
authentication?


S 3.8.
>>
>>    Additionally to the authentication provided by the transport, the
>>    protocol will have the ability to authenticate both client and server
>>    during the establishment of the IP Session.  In particular, it will
>>    be possible for the client to offer an OAuth Access Token [OAUTH] to
>>    the server when requesting IP proxying, potentially through an
>>    extension of the protocol.  The protocol will also have the ability
>>    to support vendor-specific authentication mechanisms as extensions.
>>
>> This seems incomplete. First, the OAUTH access token doesn't authenticate
>> the *server*.
>>
>
> I would expect most deployments to use the WebPKI to authenticate the
> server,
> and then MASQUE is required to allow other custom mechanisms to
> authenticate
> endpoints, such as authenticating the client via OAUTH for example.
>

That seems sensible for the asymmetric cases (e.g., Client -> Internet) but
not for
Network to Network.


>
>> S 3.9.
>>
>>    While it is desirable to transmit IP packets unreliably in most
>>    cases, the protocol will provide a mechanism to allow forwarding some
>>    packets reliably.  For example, when using HTTP/3, this can be
>>    accomplished by allowing Data Transports to run over both DATAGRAM
>>    and STREAM frames.
>>
>> This seems like an odd feature to add in a VPN protocol. What's the
>> rationale for this.
>>
>
> It's uncommon for VPN protocols today, but we've seen noticeable
> performance benefits when sending some specific packets reliably.
> Using this would be solely at the discretion of MASQUE endpoints.
> Given that MASQUE is built over QUIC, I suspect any solution we
> build will involve a stream of some kind, so having the ability to use
> the stream to route packets won't be significant extra work, especially
> considering the fact that we'll need this for MASQUE over HTTP/2.
>

>From my perspective, it might or might not be a good idea to build this, but
I'm not persuaded it rises to the level of a requirement.

-Ekr