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

[Eric Rescorla <[e-mail]>]

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.




-+