[Tsv-art] Tsvart early review of draft-ietf-masque-ip-proxy-reqs-02

Kyle Rose via Datatracker <noreply@ietf.org> Tue, 01 June 2021 00:42 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsv-art@ietf.org
Delivered-To: tsv-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 285153A0DB7; Mon, 31 May 2021 17:42:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kyle Rose via Datatracker <noreply@ietf.org>
To: <tsv-art@ietf.org>
Cc: draft-ietf-masque-ip-proxy-reqs.all@ietf.org, masque@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162250814901.30330.16465163411148155262@ietfa.amsl.com>
Reply-To: Kyle Rose <krose@krose.org>
Date: Mon, 31 May 2021 17:42:29 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/5yJDiphNml6fg3oIuDreux2Aua4>
Subject: [Tsv-art] Tsvart early review of draft-ietf-masque-ip-proxy-reqs-02
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2021 00:42:30 -0000

Reviewer: Kyle Rose
Review result: On the Right Track

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?