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

[Bob Briscoe <[e-mail]>]

David & Ted,

OK, I admit, I was confused. I had gone to various parts of 9297 to read 
parts, but not read the whole, and missed the point.
  But that only invalidates item (A).

There's a load of other problems identified in my review. I can't 
guarantee that I haven't got confused about sthg else. But I don't think 
I have.
Pls don't throw out the baby with the bathwater. Pls read past item (A).

This might slightly tone down the final pick of 'Not Ready'. But (if you 
don't find any other problems with my review), it's still pretty much 
'Not Ready'.

Sry.


Bob



On 29/03/2023 01:21, David Schinazi wrote:
> Hi Bob,
>
> Thanks for the in-depth review. As you can imagine, I won't have time 
> to respond to
> everything in the 15 minutes we have before today's MASQUE session, 
> but I would
> like you to read the references and reconsider your review. You 
> mention the following:
> <<
>     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.
> >>
> and that's fundamentally wrong. Please read RFC 9297 and RFC 9221. If you
> misunderstand the fundamental premise of our work, I don't think we 
> can seriously
> consider your review for a transport perspective.
>
> To echo your "how can I say this politely", Bob I'm sorry but your 
> review needs work.
>
> Thanks,
> David
>
>
> 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
>
>
>
>
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/