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

["Eric Vyncke (evyncke)" <[e-mail]>]

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]<mailto:[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.

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.

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.

## 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.

----------------------------------------------------------------------
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/ ?