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

[David Schinazi <[e-mail]>]

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.
We mention translation in the "Non-requirements" section, we should
probably add TTL decreasing to that section as well.


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

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.


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


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


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


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