[secdir] Secdir last call review of draft-ietf-masque-connect-ip-09

Nancy Cam-Winget via Datatracker <noreply@ietf.org> Mon, 10 April 2023 20:48 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE02C151554; Mon, 10 Apr 2023 13:48:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Nancy Cam-Winget via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-masque-connect-ip.all@ietf.org, last-call@ietf.org, masque@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.16.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168115968330.32330.4755658830680769791@ietfa.amsl.com>
Reply-To: Nancy Cam-Winget <ncamwing@cisco.com>
Date: Mon, 10 Apr 2023 13:48:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ttxCWPpX8IN86Z84HyfC1K5CVDY>
Subject: [secdir] Secdir last call review of draft-ietf-masque-connect-ip-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Apr 2023 20:48:03 -0000

Reviewer: Nancy Cam-Winget
Review result: Ready

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.


This document specifies how to proxy IP packets using HTTP.
The protocol defined allows for a client to establish a tunnel
with an HTTP server that acts as an IP proxy.

The document is well written and straightforward in its descriptions.
I only have one minor nit.

Nits:
Section 4.5 - It would be good to clarify some error/unsuccessful
codes that speak explicitly to the proxy setup being unsuccessful as well.
I presume codes NOT in 2xx are deemed to be error/unsuccessful like
 305, 407, et al though not sure they either apply or
not apply. Perhaps adding a clause to the first bullet to clarify
That status codes of anything BUT 2xx should be deemed as unsuccessful
And must then abort the request.