Re: [Masque] [Last-Call] Tsvart last call review of draft-ietf-masque-connect-ip-08

[Ted Hardie <[e-mail]>]

Hi Bob,

Just a quick clarifying question--have you previously reviewed
https://www.rfc-editor.org/rfc/rfc9297 ?

regards,

Ted Hardie

On Wed, Mar 29, 2023 at 9:04 AM Bob Briscoe via Datatracker <
[e-mail]> wrote:

> Reviewer: Bob Briscoe
> Review result: Not Ready
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> [e-mail] if you reply to or forward this review.
>
> -----------------------------------------------------------------------
> ==Overall comments==
>
> How can I say this politely? The HTTP aspects of this document are great
> work
> and near-complete. However, the tunnelling aspects, in particular the
> layering
> interactions need a lot of work - possibly even a partial redesign in
> places.
> Also, the security aspects seem to have been viewed through rose-coloured
> spectacles; sthg like "Most people who like privacy are nice".
>
> Well-written, but not an easy read in a single pass (not clear what the
> point
> is for quite a few pages and lots of forward x-references). Early overview
> of
> the scheme would help. Need to bear in mind that cross-layer work has to be
> addressed at a wider community who don't necessarily all subscribe to the
> same
> mind-share.
>
> -----------------------------------------------------------------------
> ==Document Structure==
>
> I believe §§3-4 are about the tunnel config, and §§5-7 are the per-packet
> aspects of the tunnel. Might be worth explaining that in a doc roadmap.
>
> §6 "Payload Format"
> This section needs to be split and/or re-titled, 'cos in the middle (from
> "Client MAY optimistically start sending...") it switches to operation, not
> format. At "Note that endpoints will decrement..." it switches to TTL
> handling.
> Then at "IPv6 requires that.." it switches to MTU discovery, which is
> another
> aspect of operation.
>
> Just because TTL and packet size are fields of an IP packet, doesn't mean
> these
> aspects fall under the heading of "Payload Format" - these paras are about
> handling these fields, not defining their format.
>
> -----------------------------------------------------------------------
> ==Gaps==
>
> ===A) No discussion of packet ordering ===
>
> Although one of the variants of HTTP (http/3) is over UDP, which is
> unordered,
> QUIC still delivers an ordered stream to the app (which, in this case, is
> the
> inner of the tunnel). So, presumably as packets arrive at the proxy, if
> there
> has been misordering or a loss, QUIC will buffer until the next packet in
> order
> can be delivered, i.e. head-of-line blocking. Hence, it's not really
> advisable
> to forward connectionless packets through a connection-oriented tunnel. The
> privacy benefit might make the poor latency performance worth it. But this
> trade off at least needs to be stated, perhaps in an applicability section.
>
> I don't think an http3 stream is any less granular than an http2 stream or
> an
> http1.1 connection in this proxy arrangement. But if it is, each need to be
> discussed separately.
>
> If there is a vision to use an unordered variant of QUIC, then there could
> be
> problems with Context IDs being processed out of order, which could
> produce all
> sorts of unexpected side-effects, given Context IDs are potentially
> stateful
> (caveat: you will see that I don't really understand what Context IDs
> might be
> used for).
>
> ===B) Conflicting Congestion Controllers (CCs) ===
>
> Needs a section sthg like §12.1 of RFC8229, except:
>
>     That text mostly just listed the problems, but the implication of
>     publishing such a section in a spec is essentially, "We've told you the
>     problems, but now go ahead anyway." This is not just a TCP in TCP
> problem.
>     It's any nesting of two or more CC-controlled protocols (e.g. TCP
> within
>     QUIC, QUIC within QUIC, etc)
>
> As above, if this is a trade off between privacy and performance, that
> needs
> stating.
>
> ===C) Overlapping connection life-cycles ===
>
> If a proxy crashes, powers down, etc. can it be brought back up with all
> the
> connection state restored that it held before it failed? Otherwise, all the
> connections within the tunnel inner depend on the survival of their outer
> connection. There is no reason to believe that all the inner connections
> are
> dispensable.
>
> Would a soft-state design be more resilient than the hard-state design
> described?
>
> [The above points (A-C) are examples of the problems I mentioned when
> using a
> connection-oriented protocol to tunnel a connectionless protocol.]
>
> ===D) Applicable Next Headers (aka IP Protocols) ===
>
> No discussion of whether some IPv6 'Next Headers' (or IPv4 Protocols) are
> not
> applicable / unsafe / poor performing.
>
> The last time that I proposed a generic UDP tunnel to the Intarea as an
> alternative to GUE, the criticism was that it was "too generic". I was told
> that the choice of tunnel protocols is about whether they are sufficiently
> limiting; the aim is not totally generic.
>
> === E) Applicable Address Ranges ===
>
> Are anycast addresses in scope? IP multicast?
> Link-local multicast is mentioned. What about ARP? Service Discovery?
>
> ===F) Propagation of IP headers and header fields between inner and outer.
> ===
>
> Some IPv6 extension headers are copied from inner to outer on
> encapsulation;
> others aren't [RFC2473; §5.1]. The outer IPv6 flow label is often zeroed.
> The
> contents of the DSCP, and ECN fields can be propagated from inner to outer
> and
> the ECN outer is propagated back to the forwarded header [RFC2983],
> [RFC6040].
>
> Because there's a whole stack of headers between the inner and outer IP
> headers
> (e.g. IP, UDP, QUIC, HTTP, IP), the draft needs to make it clear that these
> copying and propagation rules still apply between the two IP headers.
>
> ===G) No explanation of pros & cons relative to other packet tunnelling ===
> Yes, we can tunnel anything over anything, but why this one? AFAIK, it's to
> hide traffic in the HTTP crowd for privacy. But what are the merits
> relative to
> hiding in other crowds? And the drawbacks (e.g. HoL blocking as mentioned
> above). In particular, the pros & cons vs UDP in HTTP.
>
> ===H) Role reversal? ===
>
> It's not made clear whether there's anything intrinsically 'clientish'
> about a
> client. Or 'proxyish' about a proxy. Especially in a bump in the wire
> topology
> (like the site-site VPN example), does it matter which is which? Is it just
> determined by the administrator setting a proxy up in listen mode? Is there
> anything that one or the other cannot do by virtue of its role, other than
> initiate a connection to the other one? Shouldn't the draft speak about
> this if
> it requires correct manual set up? Particularly for tunnels consisting of
> chains (or trees?) of intermediaries.
>
> -----------------------------------------------------------------------
> ==Section by Section==
>
>  1. Introduction (and Abstract)
>
> "...updates RFC9298"
> It's not at all clear to me what aspect of RFC9298 this RFC updates. It
> seems
> unlikely, given IP Proxying is an alternative to UDP Proxying, not an
> update.
> But if it does, the draft needs to say what it updates. And, if RFC9298
> were
> updated by this draft, it would surely be a normative reference, not
> informative.
>
>  3. Configuration of Clients
>
> Reasoning for each each URI template rule?
> I can't really judge whether this set of rules leaves the URI template
> flexible
> enough, without knowing the reason for each constraint. Is this explained
> in
> "Proxying UDP in HTTP"? If so, a ref would be useful.
>
> "IP proxy deployments SHOULD offer service at this location if they need to
> interoperate with such clients." Surely "MUST" to interoperate?
>
>  4. Tunnelling IP over HTTP
>
> "When sending its IP proxying request, the client SHALL perform URI
> template
> expansion..." Surely just "... the client performs..." (just a necessary
> process step, not an interop requirement)
>
> "IP proxying requests [responses] do not carry any message content."
> Is it an error if they do?
>
>  4.1. IP Proxy Handling
>
> "...the IP proxy MUST perform DNS resolution..."
> Surely "... the IP proxy performs..." (just a necessary process step, not
> an
> interop requirement)
>
> "IP proxies MAY choose to tear down the tunnel due to a period of
> inactivity"
> Better? "IP proxies MAY choose to tear down the tunnel, e.g. due to a
> period of
> inactivity" Rationale: there are other possible reasons, e.g responding to
> an
> attack.
>
> "Any response other than a successful response indicates that the request
> has
> failed; thus, the client MUST abort the request." This is repeated at each
> instance in the subsequent sections. Either not needed here as well, or not
> needed in each section as well.
>
>  4.6. Limiting Request Scope
>
> "When the IP proxy knows that a request is scoped to a target prefix or
> protocol, it can leverage this information to optimize its resource
> allocation..." This highlights that the protocol relies on a perverse
> incentive
> for the client to scope its request so that the server can optimize its
> resources. That smells like potentially the opposite of resource
> optimization,
> i.e. a vulnerability; clients can scope their requests to force a server to
> frag its resources. Perhaps consider redesigning the protocol so that the
> server initiates the scoping (or at least it can somehow negotiate the
> outcome)?
>
> "target: ...the IP proxy is expected to perform DNS resolution ..."
> Might this potentially amplify a resource exhaustion vulnerability, esp.
> if the
> client continually gives the proxy DNSSEC work?
>
> "IP proxies MAY perform access control using the scoping information
> provided
> by the client: if the client is not authorized to access any of the
> destinations included in the scope, then the IP proxy can immediately fail
> the
> request." I think the clause after ':' ought to be tagged as an example. I
> think it's intended to be a degenerate/extreme example. Whatever, its
> relation
> with the earlier words is unclear. It's possible this would be better in
> §4.1,
> which is where it would fit into the process steps. However, at that point
> in
> the draft, scope limiting hasn't ben explained. I'm in two minds.
>
>  4.7. Capsules
>
> Are all control messages to the tunnel on one stream, or can each capsule
> arrive in a separate stream, or is it up to the operator? IOW, do capsules
> have
> to be acted on in the order they are sent, or does it depend?
>
>  §4.7.1
> The last para starting "Note that the IP forwarding tunnels described in
> this
> document..." seems more like an architectural point that ought to be stated
> earlier. It's related to ADDRESS_ASSIGN, but is it really appropriate to
> bury
> it here?
>
>  §4.7.2
> IP version:
> Address assignment syntax presumes that two request prefixes will return
> two
> addresses. I think  this means that an endpoint cannot request just one
> address, when it doesn't mind whether it's within a certain IPv4 address
> range
> or a certain IPv6 address range. In the happy eyeballs example, this
> returns
> two addresses. Similarly, I don't think the syntax can express no
> preference
> for a prefix length. Only a specific prefix length is possible. Correct?
> Should
> these limitations of the syntax be pointed out?
>
>  §4.7.3
> "...the most recently received ROUTE_ADVERTISEMENT capsule..."
> I assume this means most recently received after reordering has been
> corrected.
> See my first point under Capsules about control message ordering.
>
>  §5 Context Identifiers
>
> The point below is in a similar vein to the earlier point about whether
> generic
> support of IP Protocols (Next Headers) is a boon or a bane...
>
> This section seems like it's early research. It's vague, with no examples
> and
> no clear purpose (to me). So one cannot reason about what security
> vulnerabilities it might open up (let alone what flexibility it potentially
> affords). There is no citation of [HTTP-DGRAM] in this section, nor
> explanation
> of the purpose of a Context ID.
>
> "The Context ID value of 0 is reserved for IP payloads, "
> This clearly means that non-IP payloads cannot use 0, but does it also mean
> that IP payloads cannot use non-zero values? It's not clear, but none of
> the
> examples (that all use IP) show a non-zero Context ID. A later para (2nd
> para
> under Fig 13 in §6) seems to more unambiguously define a 1:1 mapping
> between IP
> and Context ID=0. If so, I don't understand the point of a Context ID in
> these
> tunnelling cases. What am I missing?
>
> "it is possible for datagrams to be received with Context IDs that have
> not yet
> been registered. For instance, this can be due to reordering of the packet
> containing the datagram and the packet containing the registration message
> during transmission." So..., what happens then?
>
>  6. HTTP Datagram Payload Format
>
> "Context ID:
>     A variable-length integer that contains the value of the Context ID.
> If an
>     HTTP/3 datagram which carries an unknown Context ID is received, the
>     receiver SHALL either drop that datagram silently or buffer it
> temporarily
>     (on the order of a round trip) while awaiting the registration of the
>     corresponding Context ID."
>
> A number of problems here:
>
>   *  undefined what happens if an http/2 or http/1.1 datagram carries an
>   unknown Context ID? *  For TCP, the app layer doesn't know the RTT. *
> Isn't
>   this a resource exhaustion vulnerability? the sender contrives packets
> with
>   Context IDs that cause the receiver to buffer everything, exhausting the
>   memory available for other senders.
>
> "Endpoints MAY implement additional filtering policies on the IP packets
> they
> forward." Eh? This is the first mention of filtering policies.
>
>  7. Error Signalling
>
> For a bump in the wire topology, can an ICMP error be sent back, from one
> IP
> side to the other, through the HTTP tunnel and out the other side? That
> will
> probably work. However, presumably an ICMP error raised by the network
> within
> the extent of the HTTP tunnel will be directed back to the ingress tunnel
> endpoint but no further.
>
>  8.4. Proxied Connection Racing
>
> It might be worth pointing out in a note at the end of this example that,
> as
> well as the proxy deciding to set up parallel tunnels, the approach would
> also
> allow the client to initiate parallel tunnels.
>
>  10. Security Considerations
>
> I find it quite lame/naïve that this section essentially says, "This Proxy
> design gives arbitrary clients great power, both to toast proxies and to
> make
> them appear to be the senders of arbitrary messages to arbitrary
> destinations"
> BUT, "That's not a problem, because a proxy SHOULD restrict its use to
> authorized users."
>
> This massive "get out of jail free" card begs the question, "What
> management
> processes are necessary for this proxy to monitor users to determine
> whether to
> remove their authorization?" It's akin to saying, "We're going to issue
> automatic assault rifles to everyone over the age of 6, but it's not a
> problem,
> because it's illegal to shoot someone without a permit."
>
> -----------------------------------------------------------------------
> ==Nits==
>
> "HTTP provides the CONNECT method (see Section 9.3.6 of [HTTP]) for
> creating a
> TCP [TCP] tunnel..."
>     Citation of IETF core protocols like [TCP] is unnecessary. And
> definitely
>     not normative - this sentence is informatively comparing this draft
> with a
>     TCP-based alternative.
>
> §3
> s/an URI/a URI/
> (unless we're meant to pronounce URI like Cockney "In an 'urry luv?" :)
>
> §4
> Para 1: "To allow negotiation..."
> Para 3: "To initiate an IP tunnel..."
> I think these two paras repeat each other. But para 3 is better: a)
> initiate is
> a better word than negotiate (AFAICT there is no negotiation), and b) it
> explains that it's a /single/ HTTP stream.
>
> "IPv6 scoped addressing zone identifiers..." ref? [RFC6874]?
>
> §4.7.3
> Using 'IP Protocol' rather than 'Next Header' as the keyword within an IP
> Address Range is rather politically incorrect for IPv6 zealots, isn't it?
> :)
>
> Is 'equal than' (2 occurrences) correct in US English? It's certainly not
> in
> British. I can't find any reference to it.
>
> §6
> s/since receiving addresses and routes is/
>  /since receipt of addresses and routes is/
>
> "When an endpoint receives an HTTP Datagram containing an IP packet, it..."
> a tunnel endpoint?
>
> MTU sometimes ought to be PMTU.
>
> "HTTP Datagrams with payloads of at least 1280 bytes"
> Fig 13 potentially labels two things as HTTP Datagram Payload. Which is
> meant
> here? I assume the inner one, but it needs to be clear.
>
> "...the endpoints can pad the QUIC INITIAL packets of the underlying QUIC
> connection that IP proxying is running over. (Assuming QUIC version 1 is in
> use,..." The parenthesis needs to be tagged as an example.
>
> §8.1
> In the format defined in §1.3 of [QUIC] and used in the examples, a value
> after
> '=' is normally numeric. the following format threw me:
>     Payload = Encapsulated IP Packet
> I thought that must imply a field announcing that the type of the payload
> is
> the string "Encapsulated IP Packet". Any chance this could be bracketed off
> somehow, e.g.
>     Payload = <Encapsulated IP Packet>
> Is there any precedent in RFC9000 for an unquoted/unbracketed description
> of a
> binary blob on the RHS of '='?
>
> §8.4
>     "The IP proxy assigns the client both an IPv4 address (192.0.2.3) and
> an
>     IPv6 address (2001:db8:1234::a) to the client."
> Delete first occurrence of 'the client'.
>
> §10
> s/IP proxies SHOULD restrict its use to authenticated users./
>  /IP proxies SHOULD restrict their use to authorized users./
> Reason: as well as the incorrect singular, following the literal rule as
> originally written would give access to authentic criminals.
>
> §11.1
> There's a few places in the IANA section where editor's marks might be
> useful
> to identify text that will need to be updated once approved.
>
> Cheers
>
> Bob
>
>
>
> --
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call
>