Skip to main content

Early Review of draft-ietf-masque-ip-proxy-reqs-02

Request Review of draft-ietf-masque-ip-proxy-reqs
Requested revision No specific revision (document currently at 03)
Type Early Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2021-06-11
Requested 2021-05-17
Requested by Christopher A. Wood
Authors Alex Chernyakhovsky , Dallas McCall , David Schinazi
I-D last updated 2021-06-04
Completed reviews Secdir Early review of -02 by Loganaden Velvindron (diff)
Genart Early review of -02 by Robert Sparks (diff)
Intdir Early review of -02 by Bob Hinden (diff)
Rtgdir Early review of -02 by John Drake (diff)
Tsvart Early review of -02 by Kyle Rose (diff)
We're requesting early review of a Working Group Supporting Document to improve quality. This document is not meant to be published as an RFC, but we'd like to ensure as wide of a review as possible.
Assignment Reviewer Robert Sparks
State Completed
Request Early review on draft-ietf-masque-ip-proxy-reqs by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 02 (document currently at 03)
Result On the Right Track
Completed 2021-06-04
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

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

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

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


Provide a reference for TUN.

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