[Masque] Éric Vyncke's Yes on draft-ietf-masque-connect-ip-10: (with COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Fri, 14 April 2023 13:57 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: masque@ietf.org
Delivered-To: masque@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77051C14CEFF; Fri, 14 Apr 2023 06:57:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-masque-connect-ip@ietf.org, masque-chairs@ietf.org, masque@ietf.org, caw@heapingbits.net, caw@heapingbits.net
X-Test-IDTracker: no
X-IETF-IDTracker: 10.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <168148062347.47417.16680293833575368909@ietfa.amsl.com>
Date: Fri, 14 Apr 2023 06:57:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/f9XrTo-mYizGs8ieJMs-cxP0Vhc>
Subject: [Masque] Éric Vyncke's Yes on draft-ietf-masque-connect-ip-10: (with COMMENT)
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Apr 2023 13:57:03 -0000
Éric Vyncke has entered the following ballot position for draft-ietf-masque-connect-ip-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors for the document and for addressing my previous DISCUSS points (see https://mailarchive.ietf.org/arch/msg/masque/pv_wmj3wSaHgtqvEdzWuW9eZdTg/) Hoping that the COMMENTS points below will help to improve the published document (some PR are proposed in the above email thread but not yet merged as far as I can tell -- all of them are non-blocking). Regards -éric # COMMENTS (non blocking) ## Waiting for Last Call PR ? May I suggest, next time, to wait until a revised I-D is submitted based on the IETF Last Call before balloting ? E.g., the PR based on the sec-dir review is not yet merged AFAIK. ## Section 3 `The URI Template MUST NOT contain any non-ASCII unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E inclusive` the fist part of the sentence appears as useless as the second part is more restrictive. ## Section 4.1 In `establishes an IP tunnel` should the other side of the tunnel specified ? ## Section 4.6 Should the text also be clear that the proxy should only proxy packets *from* the target to the client ? ## Section 4.7.1 Should the text specify what are the unused bits of the prefix when the prefix length is not the address length ? I.e., is 2001:db8:cafe:babe:f00d::/32 a valid prefix ? ## Section 4.7.3 In the previous sections, IP protocol could also be an IPv6 extension header. I.e., using "0" as a wildcard value prevents using it to signal Hop-by-hop extension header. Should 59 be used ? (even if no next header is only for IPv6) BTW, I was about to ballot DISCUSS on this issue. The reader (including myself and John Scudder per his ballot) would probably welcome more explanations to understand why the usual CIDR/prefix notation for routes is not used. I.e., some routers only use CIDR/prefix FIB entries and one start-end range could translate in a lot of CIDR/prefix routes in the router FIB. ## Section 7 Thanks for the text about link-local addresses and link-local multicast. But, then it raises the question about which IP address to use when replying to a link-local multicast ? I.e., can a global address be used in the absence of LLA ? ## Section 8 Please also add "hop-limit exceeded" in the non-exhaustive list of errors. Should ICMP echo requests be mentioned ? (they are *not* error signaling but are quite useful). ## Section 9.1 In `Such VPN setups can be either full-tunnel or split-tunnel` please define (or add a reference) to full/split tunnel or simply do not mention those terms now as they are defined later. `using a source address in its assigned prefix` while the client has been assigned a single /32 (i.e., the sentence is correct but could be confusing) The legends of figures 15 and 16 use different templates ("capsule" in one case) is it on purpose ? Should the split-tunnel example have two routes to exclude 192.2.0.42 ? ## Section 12 RFC 5095 is probably not the best RFC about extension header security, there have been many others notably in V6OPS by Fernando Gont et al. Should there be an informative reference to RFC 6169 (Security Concerns with IP Tunneling) ? # NITS (non blocking / cosmetic) ## Section 4.1 s/via A and/or AAAA records/via A and/or AAAA resource records/ ?
- [Masque] Éric Vyncke's Yes on draft-ietf-masque-c… Éric Vyncke via Datatracker
- Re: [Masque] Éric Vyncke's Yes on draft-ietf-masq… David Schinazi