Early Review of draft-ietf-masque-ip-proxy-reqs-02
review-ietf-masque-ip-proxy-reqs-02-tsvart-early-rose-2021-05-31-00
| 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) |
|
| Comments |
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 | https://mailarchive.ietf.org/arch/msg/tsv-art/5yJDiphNml6fg3oIuDreux2Aua4 | |
| Reviewed revision | 02 (document currently at 03) | |
| Result | On the Right Track | |
| Completed | 2021-05-31 |
review-ietf-masque-ip-proxy-reqs-02-tsvart-early-rose-2021-05-31-00
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?