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

[David Schinazi <[e-mail]>]

Hi Eric, as promised: please find responses to your COMMENTs below. See
"DS2>".
David

On Thu, Apr 13, 2023 at 9:50 AM David Schinazi <[e-mail]>
wrote:

> 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) <[e-mail]>
> 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.`
>>
>
DS2> The clarification here is that conceptually routers decrement the TTL,
not links. So it applies during forwarding, not for all packets. Can you
elaborate on what is unclear to you?

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 <[e-mail]>
>> *Date: *Thursday, 13 April 2023 at 00:58
>> *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 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.
>>
>>
DS2> We submitted a revised ID at the end of IETF LC with responses to all
the reviews. This particular review arrived late past the deadline.

## 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.
>>
>>
DS2> I see what you mean, but I'd rather this be crystal clear. Removing
the first part could be misinterpreted as "unicode is allowed but when
using ASCII this requirement applies".

## Section 4.1
>>
>> In `establishes an IP tunnel` should the other side of the tunnel
>> specified ?
>>
>>
DS2> "tunnel" here is HTTP parlance for turning this request/response into
a full-duplex communication channel, it's not about the IP interface. I
think we go into sufficient detail about where the tunnel goes later in the
doc.

## Section 4.6
>>
>> Should the text also be clear that the proxy should only proxy packets
>> *from*
>> the target to the client ?
>>
>>
DS2> That's not a requirement. As part of your DISCUSS point we added text
about how the client should expect ICMP from outside the target.

## 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 ?
>>
>>
DS2> Good catch, this PR requires them to be 0:
https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/pull/155

## 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.
>>
>>
DS2> That's a good point. We cover IPv6 extension headers with regards to
scoping but
we forgot to also do so for ROUTE_ADVERTISEMENT capsules. Fixing via this
PR:
https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/pull/161
0 is allowed since the scoping walks the list of extension headers.

> 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.
>>
>>
DS2> Explanations as to why a design choice was made are useful during IETF
review of a document,
but not to implementers. See discussion in response to John for details,
but I don't think those belong
in the doc.

## 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
>> ?
>>
>>
DS2> Yes, but that's true of any IPv6 host, and is not specific to this
document.
I don't think we need to specify that here.

## Section 8
>>
>> Please also add "hop-limit exceeded" in the non-exhaustive list of errors.
>>
>> DS2> I don't think that one is notable, because we never see it in
practice. The list is non-exhaustive.

Should ICMP echo requests be mentioned ? (they are *not* error signaling but
>> are quite useful).
>>
>>
DS2> Those are discussed in the section about MTU.

## 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.
>>
>>
DS2> I think this is fine because the terms are defined in the next two
paragraphs in the same section.

`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 ?
>>
>>
DS2> Agreed on all three of these points. Fixed in this commit:
https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/commit/07423a9b882d59739d9ee6aefb34354f5f525210


>
>> ## 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.
>>
>> DS2> Do you have another RFC you want to propose we use instead?

>
>> Should there be an informative reference to RFC 6169 (Security Concerns
>> with IP
>> Tunneling) ?
>>
>>
DS2> Indeed, added.

# NITS (non blocking / cosmetic)
>>
>> ## Section 4.1
>>
>> s/via A and/or AAAA records/via A and/or AAAA resource records/ ?
>>
>> DS2> I think just "records" is clearer and non-ambiguous