[Gen-art] Genart early review of draft-ietf-masque-ip-proxy-reqs-02
Robert Sparks via Datatracker <firstname.lastname@example.org> Fri, 04 June 2021 16:22 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D60333A181F; Fri, 4 Jun 2021 09:22:31 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Robert Sparks via Datatracker <email@example.com>
Cc: firstname.lastname@example.org, email@example.com
Reply-To: Robert Sparks <firstname.lastname@example.org>
Date: Fri, 04 Jun 2021 09:22:31 -0700
Subject: [Gen-art] Genart early review of draft-ietf-masque-ip-proxy-reqs-02
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jun 2021 16:22:32 -0000
Reviewer: Robert Sparks Review result: On the Right Track 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.
- [Gen-art] Genart early review of draft-ietf-masqu… Robert Sparks via Datatracker