Early Review of draft-ietf-masque-ip-proxy-reqs-02
review-ietf-masque-ip-proxy-reqs-02-genart-early-sparks-2021-06-04-00

This is an early genart review of draft-ietf-masque-ip-proxy-reqs-02.
Comments here should be processed the same as any other feedback given for the
document.

I think I see some conflicts in the requirements that I think would be good to
resolve more clearly to help inform actual mechanism discussions.

There is pressure to limit MASQUE-related state, but the document already
proposes quite a bit of state - in particular keeping routes. More discussion
of whether that's necessary state would probably help find spots of
disagreement.

If it's the intent to limit MASQUE to support only VPN-like traffic, say so
more explicitly. As written, it looks like there might be intent for MASQUE to
provide an arbitrary IP transport layer, over which other routing protocols
could be run (as opposed to only allowing the posited configured routing the
document currently discusses). It would help to more clearly discuss if there
are limits on what can be built on top of MASQUE and if there are none,
reconsider configuring routes as a requirement on the base protocol in favor of
that being something that uses this protocol does once it's in place.

At 2.1, you note that in consumer VPN environments, "hidden information" is
available to the VPN service provider. While true, why is that important for
this document/group? Is there an intent to build something that could replace a
consumer-VPN service that treats such hidden information differently? If so,
there are some requirements that would be worth explicitly exploring.

At 3.6, you require carrying an identity, but punt on authenticating it. It
would help more to discuss why. The security considerations section could talk
about the tradeoff, and discuss what properties the identifier might need to
have beyond possibly being authenticatable. Do you anticipate, for example,
that they need to be hard to guess? Are there collision concerns? Or are such
things all up to whatever application might get built on top of this protocol?
Should the requirements for realizing VPN-like applications be pulled up a
layer?

Please look more closely at whether you can/should discuss _requirements_ on
the mechanism's security in this document's security consideration section.

Nits:

Provide a reference for TUN.

3.5 is titled "Route Negotiation", but there is no negotiation proposed, only
configuration.