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

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Jul 2020 17:57:17 -0700

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.

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.

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.

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.

   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?

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?

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

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.

-+

---

From: David Schinazi <[email-masked]>
Date: Mon, 27 Jul 2020 18:42:47 -0700

Thanks for the feedback, EKR! Responses inline.

David

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

> 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.
> 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 asking the peer to be willing to route to those domains?

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

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

> This seems incomplete. First, the OAUTH access token doesn't authenticate

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.

> This seems like an odd feature to add in a VPN protocol. What's the

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: Eric Rescorla <[email-masked]>
Date: Mon, 27 Jul 2020 19:00:46 -0700

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

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

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

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

> verifying the client's signature, for example.

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

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

>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