Draft: draft-ietf-masque-connect-ip

Commentary: This adds some additional security considerations , touching on privacy considerations at the same time . Do we want to say anything about IP fragmentation , or at least point to some existing guidance around how to avoid sharp edges there ? Please feel free to reframe or modify the text as you see fit !
Paragraph (version A):
This document describes a protocol for tunnelling IP to an HTTP
server acting as an IP-specific proxy over HTTP.  This can be used
for various use cases such as point-to-network VPN, secure point-to-
point communication, or general-purpose packet tunnelling.
Paragraph (version B):
This document describes a protocol for tunnelling IP through an HTTP
server acting as an IP-specific proxy over HTTP.  This can be used
for various use cases such as point-to-network VPN, secure point-to-
point communication, or general-purpose packet tunnelling.
Paragraph (version A):
This document uses terminology from QUIC.  Where this document
defines protocol types, the definition format uses the notation from
QUIC.  This specification uses the variable-length integer encoding
from QUIC.  Variable-length integer values do not need to be encoded
on the minimum number of bytes necessary.
Paragraph (version B):
This document uses terminology from QUIC.  Where this document
defines protocol types, the definition format uses the notation from
QUIC.  This specification uses the variable-length integer encoding
from QUIC.  Variable-length integer values do not need to be encoded
in the minimum number of bytes necessary.
Paragraph (version A):
There are significant risks in allowing arbitrary clients to
establish a tunnel that permits sending to arbitrary hosts, as that
could allow bad actors to send traffic and have it attributed to the
IP proxy.  IP proxies SHOULD restrict its use to authenticated users.
The HTTP Authorization header HTTP MAY be used to authenticate
clients.  More complex authentication schemes are out of scope for
this document but can be implemented using extensions.
Paragraph (version B):
There are significant risks in allowing arbitrary clients to
establish a tunnel that permits sending to arbitrary hosts,
regardless of whether tunnels are scoped to specific hosts or not.
Bad actors could abuse this capability to send traffic and have it
attributed to the IP proxy.  IP proxies SHOULD restrict its use to
authenticated users.  Depending on the deployment, possible
authentication mechanisms include mutual TLS between clients and
proxies, HTTP-based authentication via the HTTP Authorization header
HTTP, or even bearer tokens.  Proxies can enforce policies for
authenticated users to further constrain client behavior or deal with
possible abuse.  For example, proxies can rate limit individual
clients that send an excessively large amount of traffic through the
proxy.  As another example, proxies can restrict address (prefix)
assignment to clients based on certain client attributes such as
geographic location.
Paragraph (version B):
Address assignment can have privacy implications for endpoints.  For
example, if a proxy partitions its address space by the number of
authenticated clients and then assigns distinct address ranges to
each client, target hosts could use this information to determine
when IP packets correspond to the same client.  Avoiding such
tracking vectors may be important for certain proxy deployments.
Proxies SHOULD avoid persistent per-client address (prefix)
assignment when possible.