Re: [Masque] Éric Vyncke's Discuss on draft-ietf-masque-connect-ip-09: (with DISCUSS and COMMENT)

[David Schinazi <[e-mail]>]

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) <[e-mail]>
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 <[e-mail]>
> *Date: *Wednesday, 12 April 2023 at 02:12
> *To: *Eric Vyncke <[e-mail]>
> *Cc: *The IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *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 <
> [e-mail]> 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/ ?
>
>
>