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

[David Schinazi <[e-mail]>]

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 <[e-mail]>
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) <[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/ ?
>>
>>
>>