Re: [Masque] Éric Vyncke's Discuss on draft-ietf-masque-connect-ip-09: (with DISCUSS and COMMENT)
David Schinazi <dschinazi.ietf@gmail.com> Thu, 13 April 2023 16:50 UTC
Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEEDC151520; Thu, 13 Apr 2023 09:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvgdvAfDULBv; Thu, 13 Apr 2023 09:50:55 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E6BC14CE4B; Thu, 13 Apr 2023 09:50:55 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-505035e3368so1731679a12.0; Thu, 13 Apr 2023 09:50:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681404653; x=1683996653; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6FKKlUwF6XW3ZakvcChzdgzGVWmo/iTDrkcK0sY+pn4=; b=MEVZTASuuGqNoMuoFlZFxL4lc+MMJH9dbav2Ny0ZveJjx+HP5QnBZ8VVBq6K74hu1w rGLmO64exjM3YvTFp8c3SDkTewlSJ4zqPaKsbBUGmfVMRIrbLE6ilEprd9R8V5c/s/DD TIt1ucDiW/MD5S+QzrdozoZ8nGwB4fwMRVIlgASjdF+D5wImZKwTLibvqTyiQh87j+Cj eaWmO3Bh6vLkEXlO19DW7minNNETZdO17um/A9sqUxIrItjxsnBujjObt2ND2FaPQTJR 0DfQOSkY7rxskZ1qDOV4Oxoje87sgvzaMsR/ulnyYLfapusCxL51+JC+W+oasIPeO37v kMvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681404653; x=1683996653; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6FKKlUwF6XW3ZakvcChzdgzGVWmo/iTDrkcK0sY+pn4=; b=bR+uawBuKwtUwyFyqkrOm3xGac3pZA/Hcl6tqyvyuqxl47ZEd9m/SEdEuN5T6lDf+X AcJXcuEvSSfpW70mz6PMgy1Rkgm88pYXyVp5cyOf9nyz7p7J9175ceCRhHkPtPlf9QQ6 fiW1VjvgfjslCWoxR1ztYuHQMb4XMLz4fwo1Zs8riYqJ5gVvw9NehKnprRY8v00HMAGn 1X3vPgsp4d5JYZ+pw2zvwm0RMEYhzFUCkXZn8TMecpt6lH8NShrfvvz4VspFOO1d9zfr hQU+z9slM+5FYTlIBOCq9IObYaGgMltSm+JChnsK1tkv4OnT2w4GQmGf1oLwL0e7EOhZ UALA==
X-Gm-Message-State: AAQBX9fzBUMUF5hhI2wbrniXhxGEkQLPknQ1mERTaJ84x31awTE6H+gm PsaYD51WhKcX+fYRNd0gLclrUn7lJhWIC9wPTBPvD/mHSWA=
X-Google-Smtp-Source: AKy350aHqoPGO4N0eJaRdQ/ZsGzdiwdka+pFjEWSZW5yssPOOqYCASKJBsphLC1bwzmC/AdO4A5Xot9wgbMIz0vO1/U=
X-Received: by 2002:a50:8d43:0:b0:4fc:fc86:5f76 with SMTP id t3-20020a508d43000000b004fcfc865f76mr1605942edt.6.1681404652859; Thu, 13 Apr 2023 09:50:52 -0700 (PDT)
MIME-Version: 1.0
References: <168121253516.32736.10754673770332939967@ietfa.amsl.com> <CAPDSy+5joAN3X15PNYv5p9X5vde4mz6rXSf3dFXG1b0D4ZVpSg@mail.gmail.com> <09D789D4-1B4F-4292-837B-2BF0D92EBF4C@cisco.com> <CAPDSy+4tNnAxwm0T9HzPk5HyqwHTk86rYwKDk0VaSqYc=1Gw8w@mail.gmail.com> <CAPDSy+4qwbBHmtUm4rTtHaSq3hzfzk2ikAr4drZCysygyfSqgA@mail.gmail.com> <4A439244-F4F7-4E76-B4A7-6860C2B4C299@cisco.com>
In-Reply-To: <4A439244-F4F7-4E76-B4A7-6860C2B4C299@cisco.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Thu, 13 Apr 2023 09:50:41 -0700
Message-ID: <CAPDSy+59WuLw73tcbA_Dx=pXtBYEg+b3EutNitSrzXTY9vGJ2A@mail.gmail.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-masque-connect-ip@ietf.org" <draft-ietf-masque-connect-ip@ietf.org>, "masque-chairs@ietf.org" <masque-chairs@ietf.org>, "masque@ietf.org" <masque@ietf.org>, "caw@heapingbits.net" <caw@heapingbits.net>
Content-Type: multipart/alternative; boundary="0000000000000eb65305f93a873b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/7kqXpsdD87qN7DDMRgdr9rY8SA4>
Subject: Re: [Masque] Éric Vyncke's Discuss on draft-ietf-masque-connect-ip-09: (with DISCUSS and COMMENT)
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Thu, 13 Apr 2023 16:50:58 -0000
Thank you, Eric! As requested, we've merged the PRs and submitted draft-ietf-masque-connect-ip-10 - so we should be good to go to switch your DISCUSS to a COMMENT. Let's keep chatting about PR 156 and the rest of your comments, I'll have a reply for you later today (or at the latest tomorrow). David On Thu, Apr 13, 2023 at 4:24 AM Eric Vyncke (evyncke) <evyncke@cisco.com> wrote: > Hello David, > > > > About PR #156, unsure what it is the added value (I am even afraid that it > brings confusion): ` When IP proxying endpoints forward IP packets > between different links,... This does not apply to IP packets generated by > the IP proxying endpoint itself.` > > > > But, PR #157 and PR #158 are indeed addressing my DISCUSS concerns. I.e., > I am clearing my DISCUSS ballot as soon as those 2 PRs are merged into a > revised I-D. > > > > NOTE: I still wonder whether the example in 9.2 is a kludge or just a > token of something wrong in the design... at least the text with the PR is > clear about the issue. > > > > While the COMMENT points can be ignored, I would suggest that the authors > review them. > > > > Regards, > > > > -éric > > > > > > *From: *David Schinazi <dschinazi.ietf@gmail.com> > *Date: *Thursday, 13 April 2023 at 00:58 > *To: *Eric Vyncke <evyncke@cisco.com> > *Cc: *The IESG <iesg@ietf.org>, "draft-ietf-masque-connect-ip@ietf.org" < > draft-ietf-masque-connect-ip@ietf.org>, "masque-chairs@ietf.org" < > masque-chairs@ietf.org>, "masque@ietf.org" <masque@ietf.org>, " > caw@heapingbits.net" <caw@heapingbits.net> > *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-masque-connect-ip-09: > (with DISCUSS and COMMENT) > > > > Hi Eric, > > > > To clarify the proposals in my previous email, I've written them up as PRs: > > (1) > https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/pull/157 > > (2) > https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/pull/156 > > (3) > https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/pull/158 > > > > Thanks, > > David > > > > On Wed, Apr 12, 2023 at 9:45 AM David Schinazi <dschinazi.ietf@gmail.com> > wrote: > > Thanks Eric! Below I propose making three changes to the document to > address your DISCUSS points, let me know if they'd work for you, see "DS>". > > David > > > > On Wed, Apr 12, 2023 at 3:54 AM Eric Vyncke (evyncke) <evyncke@cisco.com> > wrote: > > Hello David, > > > > Thank you for your prompt reply. > > > > As you know, authors may completely ignore the COMMENT points as they are > not blocking. > > > > Please look below for EV> for my replies. And, to be clear, I intend to > ballot a YES once the DICUSS points are discussed/addressed as I really > like the technique. > > > > Regards > > > > -éric > > > > *From: *David Schinazi <dschinazi.ietf@gmail.com> > *Date: *Wednesday, 12 April 2023 at 02:12 > *To: *Eric Vyncke <evyncke@cisco.com> > *Cc: *The IESG <iesg@ietf.org>, "draft-ietf-masque-connect-ip@ietf.org" < > draft-ietf-masque-connect-ip@ietf.org>, "masque-chairs@ietf.org" < > masque-chairs@ietf.org>, "masque@ietf.org" <masque@ietf.org>, " > caw@heapingbits.net" <caw@heapingbits.net> > *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-masque-connect-ip-09: > (with DISCUSS and COMMENT) > > > > Hi Éric, and thank you for your review. > > In this email, I'll address your DISCUSS points. We'll dive into your > COMMENTs once we've cleared your DISCUSS. > > Please see responses inline. > > David > > > > On Tue, Apr 11, 2023 at 4:28 AM Éric Vyncke via Datatracker < > noreply@ietf.org> wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-masque-connect-ip-09: Discuss > > 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/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. I *really* find the idea > and the > protocol interesting and useful. The text is also easy to read and to > understand (albeit underspecified in some cases -- hence my DISCUSS). > > Please find below some blocking DISCUSS points (easy to address by adding > some > text), some non-blocking COMMENT points (but replies would be appreciated > even > if only for my own education), and some nits. > > Special thanks to Chris Wood for the shepherd's detailed write-up > including the > WG consensus *but* it lacks the justification of the intended status. > > Other thanks to Tim Winters, the Internet directorate reviewer (at my > request): > > https://datatracker.ietf.org/doc/review-ietf-masque-connect-ip-09-intdir-telechat-winters-2023-04-07/ > (and I have read the email exchange, thanks to all) > > I hope that this review helps to improve the document, > > Regards, > > -éric > > # DISCUSS (blocking) > > As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a > DISCUSS ballot is a request to have a discussion on the following topics: > > ## Section 8 > > Several parts of this section are unspecified, see below. > > `Note that ICMP messages can originate from a source address different from > that of the IP proxying peer.` is of course obvious, but I think that this > case > (ICMP originating from the global Internet to the proxy client) deserves a > section on its own. Notably whether this source must be within the target ? > > > > This is discussed in the following paragraph of our Security > Considerations: > > > https://www.ietf.org/archive/id/draft-ietf-masque-connect-ip-09.html#section-12-4 > > Does that answer your question? > > > > EV> Not really, the point in the security section is valid and should be > kept of course. > > EV> But, the sentence in section 8 is really terse and would benefit from > a paragraph on its own. > > EV> Would the authors object adding a sentence like "Client SHOULD expect > receiving ICMP messages sourced outside of the target." ? > > EV> If authors object, then I am clearing this DISCUSS point as it would > have been discussed. > > > > DS> I think mentioning that it can come from outside is a good idea, but I > prefer it as a statement of fact instead of a SHOULD. How about the > following change: > > DS> (1) <<Note that ICMP messages can originate from a source address > different from that of the IP proxying peer, and also from outside the > target if scoping is in use.>>? > > > > The source address to be used by the proxy when originating an ICMP should > also > be specified, even if just a reference to RFC 6724 for IPv6. > > > > We already reference RFC 4443 which discusses this in section 2.2. I'm not > sure > > adding a reference to RFC 6724 is required. Either way, may I propose we > move > > this editorial topic out of your DISCUSS block and into a COMMENT please? > > > > EV> the reference to RFC 4443 in section 8 is correct even if I would > prefer to have a clearer text rather than " IP proxying endpoints SHOULD > use ICMP" (the use being rather vague, what about "IP proxying endpoints > SHOULD generate an ICMP by implementing ICMP/ICMPv6" ?). It is about > clarification. > > > > DS> I tried reworking the sentence a few times, and it ended up being less > clear than the current text <<In such scenarios, IP proxying endpoints > SHOULD use ICMP {{!ICMP=RFC0792}} {{!ICMPv6=RFC4443}} to signal the > forwarding error to its peer by generating ICMP packets and sending them > using HTTP Datagrams.>> because if I remove the use ICMP then it becomes > quite a mouthful with the discussion of putting it in HTTP Datagrams. Can > you propose a rephrasing? > > > > EV> BTW, I forgot to add a non-blocking COMMENT on this section about ICMP > generation about packets received from the Internet to the proxy client. > Feel free to ignore of course. > > > > DS> Can you elaborate? Is this about the proxy sending ICMP to an Internet > machine? That might be outside the scope of this document, or am I > misunderstanding what you mean? > > > > ## Section 9.2 > > In the example where the IP proxy has an IP address in the same prefix as > the > legacy client (there is no on-link / off-link state for IPv4 as opposed to > IPv6), the encapsulation behavior of section 7 requires the TTL to be > decremented before entering the tunnel, which is really wrong as it this > case > it is not formally a routing to a different prefix and some protocols may > expect TTL=255, which won't be the case. > > Request to add some text about this "issue". > > > Can you elaborate on what protocols do this? As far as I know, all modern > OSes > > set a default TTL of 64 so you'd never see a TTL or Hop Limit of 255. We > use > > something very similar to this example in production and haven't had any > TTL > > problems. > > > > EV> Erik Kline has also noticed this issue. As you asked for examples, > from the top of my head: > > EV> The generalized TTL security mechanism, RFC 5082, is often used > outside of BGP/LDP (and BTW I would love to support BGP on a MASQUE IP > proxy) > > EV> RFC 4891, NDP, also relies on HL=255 > > EV> See also section 11 of RFC 6762 (mDNS) > > > > > > EV> In short, there is either a shortcoming in the route/address > negotiation in connect-ip as it allows such deployement > EV> or this example should be annotated by some text about the TTL/HL > being decremented in what appears a link operation. > > > > DS> That makes sense. I propose we make two changes: > > DS> (2) in the normative text about decrementing TTL/HL, we mention that > this decrement is not applied for traffic generated by the IP proxying > endpoint itself > > DS> (3) in the "Site-to-Site VPN" example, we mention that since this goes > across a router, the TTL/HL will be decremented so protocols that require > TTL/HL=255 won't work > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > # 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 Discuss on draft-ietf-masq… Éric Vyncke via Datatracker
- Re: [Masque] Éric Vyncke's Discuss on draft-ietf-… David Schinazi
- Re: [Masque] Éric Vyncke's Discuss on draft-ietf-… Eric Vyncke (evyncke)
- Re: [Masque] Éric Vyncke's Discuss on draft-ietf-… David Schinazi
- Re: [Masque] Éric Vyncke's Discuss on draft-ietf-… David Schinazi
- Re: [Masque] Éric Vyncke's Discuss on draft-ietf-… Eric Vyncke (evyncke)
- Re: [Masque] Éric Vyncke's Discuss on draft-ietf-… David Schinazi
- Re: [Masque] Éric Vyncke's Discuss on draft-ietf-… David Schinazi