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 Transport Area Review Team (tsvart)
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-05-31
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 Kyle Rose
State Completed
Request Early review on draft-ietf-masque-ip-proxy-reqs by Transport Area Review Team Assigned
Posted at
Reviewed revision 02 (document currently at 03)
Result On the Right Track
Completed 2021-05-31
This a response to the early review requested of the Security Directorate.

General query: What are you looking for in an early review of a document you
explicitly state will likely not be published as an RFC? I'm happy to follow up
with greater depth in certain areas if I get more guidance about what you're
looking for.

3.4. IP Assignment

 * From the client's perspective, is this assignment of an IP for the client's
 end of the VPN link or assignment of an IP to be used as the forwarding IP by
 the proxy?

3.7. Transport Security

 * Use of QUIC or TLS does not necessarily imply *mutual* authentication.

3.8. Flow Control

 * You're gonna get flow control with H/2 whether you like it or not. The issue
 is whether that flow control in the lower layer makes the tunnel
 non-performant or completely unusable.

3.9. Indistinguishability

 * It feels like we should have a formal definition of this that doesn't
 involve traffic analysis. My sense is that what is meant is that the adversary
 has access only to the sequence of octets in the encrypted data stream without
 any timing or packet boundary information (which IMO is a very weak adversary,
 but it is what it is).

3.12 Statefulness

 * As a requirement, this is too vague. Maybe I'm being too pedantic about
 this, but any protocol you design can be claimed after the fact to maintain
 limited state. Something stronger like "The protocol must practicably minimize
 the state a MASQUE client or server needs to provide the functions required by
 MASQUE" might be better guidance to architects.

4.2. Reliable Transmission of IP Packets

 * Why is this useful? In general, this document seems like it could benefit
 from more justification of the chosen requirements.

4.4. Data Transport Compression

 * Of course, make sure this doesn't create a side channel vulnerability.

5.3. IP Packet Extraction

 * Does this even need to be mentioned in a document at this layer?