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

[David Schinazi <[e-mail]>]

Hi Bob, responses inline.
David

On Fri, Mar 31, 2023 at 7:06 AM Bob Briscoe <[e-mail]> wrote:

> David & Alex, See [BB]
>
> On 30/03/2023 05:47, David Schinazi wrote:
>
> Hi Bob,
>
> Alex and I sat down to go through your thorough review in detail. I'm
> sending our responses below marked with "EDITORS:". Important note: in this
> email, EDITORS refers only to Alex and myself, not all document
> editors/authors. Apologies if the email formatting comes out strange.
>
> Thanks,
> David
>
>
> On Wed, Mar 29, 2023 at 2:48 PM Magnus Westerlund <
> [e-mail]> wrote:
>
>> Hi Bob,
>>
>>
>>
>> Thanks for the review. We authors will have to go though your comments in
>> details. It is unfortunate that you did not review HTTP Datagram
>> specification (RFC 9297) prior as that is allowing sending of datagrams
>> over HTTP/3. In my initial read through of the comments I think most still
>> applies as they are not directly related to if the tunneled IP are in
>> datagrams (unreliable in delivery order) or in streams (reliable in order
>> delivery).  I do know some of the issues you bring up have been discussed
>> but was not documented. We will have to consider if the choice to not
>> document them should be changed or not.
>>
>>
>>
>> Cheers
>>
>>
>>
>> Magnus
>>
>>
>>
>> *From: *Bob Briscoe via Datatracker <[e-mail]>
>> *Date: *Wednesday, 29 March 2023 at 09:04
>> *To: *[e-mail] <[e-mail]>
>> *Cc: *[e-mail] <
>> [e-mail]>, [e-mail] <
>> [e-mail]>, [e-mail] <[e-mail]>
>> *Subject: *Tsvart last call review of draft-ietf-masque-connect-ip-08
>>
>> 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.
>>
>> EDITORS: That's a reasonable editorial ask, we'll look into it as editors
>> and see what we can do.
>>
>> §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.
>>
>> EDITORS - We agree, filed an issue to track adding a new Performance
>> Considerations section:
>> https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/144
>>
>
> [BB] OK, gpod. I'm not convinced the new categorization should be
> 'performance'. See my response to issue #144.
> Whatever, you've grocked the point and I'm sure you'll deal with it.
>

[DS] I agree that performance isn't a perfect section name, but couldn't
come up with a better one. Any suggestions?

-----------------------------------------------------------------------
>> ==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).
>>
>> EDITORS: As discussed, this section is incorrect.
>>
>> ===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.
>>
>> EDITORS: This makes sense, we'll add some text. Tracking in this issue:
>> https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/145
>>
>> ===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?
>>
>> EDITORS: This is true of all tunnels, for example IKEv2/IPsec.
>>
>
> [BB] It's certainly true of /some/ tunnels, where the tunnel provides a
> service that requires flow state (e.g. IPsec holds traffic selectors, as
> you say).
> However, the thinking behind my point is that here /IP/ is the inner, and
> usually tunnel endpoints providing an IP service only hold state about the
> other tunnel endpoint, not about the traffic they carry. So, forwarding
> just continues when it resumes after a failure.
>
> So the Proxied IP service is as generic as IP, but not as resilient.
>

[DS] That's true, but I think this property is inherent to any encrypted
system due to the requirement to keep ephemeral keys and packet numbers.

Luckily here we can use ADDRESS_REQUEST to recreate the same state and
>> avoid connections breaking
>>
>
> [BB] Are you saying that the design as already written would recreate the
> same state, or that it could?
>

[DS] That it could if the endpoints want that feature, but it's not
required to implement.


> [I identified the gaps so far by noting that this tunnel has a nearly
> fully featured transport layer between two IP layers, so I worked through
> the 8 functions of the transport layer to check for conflicts. One is
> connection life-cycle management. That led on to the fate-sharing principle
> [RFC1958], which points out that, if state is not e2e, it will raise
> resilience questions.
>
> Critique is intended to be constructive. I'm trying to distil out the
> trade offs that have been made. Operational issues like this come up after
> an initial design - the usual iterative process.
> It's good to recognize and articulate them. An RFC naturally starts out as
> a sales brochure, then the review process makes it more rounded. See gap
> (G).]
>

[DS] That's fair, but there's no way around this for something akin to
tunnel-mode IPsec like what we're doing here.

[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.
>>
>> EDITORS: This document is about creating an IP tunnel over HTTP so we
>> have a tight scope based on the underlying protocol instead of on the high
>> layer protocols.
>>
>
> [BB] By enabling IP you have created an extremely wide scope. My point was
> that this will open Pandora's box. You might not need to go through all the
> implications in this draft. But I think you need to record that working out
> the security implications will be non-trivial.
>

[DS] I think the Security Considerations section should provide actionable
advice to implementers. I agree that the possibilities are endless, but
saying so isn't actionable.

=== E) Applicable Address Ranges ===
>>
>> Are anycast addresses in scope? IP multicast?
>> Link-local multicast is mentioned. What about ARP? Service Discovery?
>>
>> EDITORS: We've documented the address types that require implementation
>> involvement. Anycast and (non-link-local) unicast are equal to unicast as
>> far as a single link is concerned. ARP operates at L2 so it doesn't apply
>> to an L3 tunnel. Similarly, service discovery protocols don't need any
>> special guidance.
>>
>
> I mentioned ARP and Service Discovery because they are both scoped to a
> subnet. Here, the tunnel creates a disjoint subnet, so the operator needs
> to decide whether and how much it wants the subnet to behave as if it is
> one whole. You might want to say that ops issues like this are out of
> scope. but again record that they will need to be addressed separately.
>

[DS] More specifically, this is a point-to-point link. Do you have specific
guidance in mind that you'd like to see?

===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.
>>
>> EDITORS: This is a tunnel operating at L7, not an L3/L4 encapsulation
>> format. Copying these fields doesn't make sense because it is possible to
>> have multiple IP packets inside a single IP packet.
>>
>
> [BB] Whatever the reason that L7 is in there, you can't escape the fact of
> what you have created, which is a L3 encapsulation. If the packet
> boundaries don't line up, surely it implies a potential problem has been
> created that you have to consider. Not that there aren't any problems.
>
> On thinking about this since having written the review, it wouldn't be
> right to blindly follow the rules. But it would be worth considering the
> intent behind each rule, and whether it still applies in the case of your
> tunnel. For instance, because you have two congestion control loops, the
> proxy does NOT need to propagate ECN from the outer to the inner.
> (Altho' two control loops is not good for performance, I guess this is one
> of the few advantages.)
>

[DS] You're right. Tommy also pointed this out so we've tweaked the PR to
mention this.

===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.
>>
>> EDITORS: There are many motivations for tunneling IP over HTTP, one of
>> them being that it allows traveling through HTTP load balancers. This is
>> discussed in our charter and doesn't need to be added to the document.
>>
>
> [BB] Even if the draft referenced the charter (which it doesn't) it would
> not be sufficient, 'cos the masque charter doesn't answer the question of
> what the drawbacks are and why this specific choice of technology is a
> useful tradeoff between the benefits and those drawbacks. That comes from
> the experience of have designed and implemented.
>
> If you had an RFC that motivated this specific solution (not just the WG
> in general), you could certainly refer to it to save keep including it in
> each RFC. But someone does actually have to explain and motivate what's
> been done, and draw conclusions about tradeoffs. Just mandating how to
> build something is not enough. That is the reason that RFCs go through
> wider IETF review - not least to weed out group-think.
>

[DS] We went through this exercise in draft-ietf-masque-ip-proxy-reqs. The
tradeoffs between various solutions sounds like a good topic for a future
document.

===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.
>>
>> EDITORS: The terms "client" and "proxy" are HTTP terminology. The client
>> sends the request, the proxy responds. Once the tunnel is up, the draft
>> talks about endpoints and peers because then it's symmetric.
>>
>
> [BB] I know it's HTTP terminology. I've caught up now. I was labouring
> under the misconception (not the fault of the draft, just my earlier faulty
> assumptions) that the decap function was somehow intrinsic to a proxy. But
> it's not, it's created by the particular ADDRESS_REQUEST and ADDRESS_ASSIGN
> messages used. I had (wrongly) thought that each tunnel endpoint in the
> symmetric site-to-site VPN example was both a client and a proxy. I've now
> caught up and grocked that still only one end of such a tunnel would be a
> proxy (as correctly labelled in Fig 17).
>
>
>> -----------------------------------------------------------------------
>> ==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.
>>
>> EDITORS: Fair enough, we'll add text. Tracked in this issue:
>> https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/146
>>
>>  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.
>>
>
> [BB] I think this point got missed (probably the way the review tool wraps
> lines together).
>

[DS] Sorry for missing this. We came up with a pragmatic list to simplify
implementations for 9298, and we just reused it here. We mention the reuse
in the acknowledgements.

 "IP proxy deployments SHOULD offer service at this location if they need
>> to interoperate with such clients." Surely "MUST" to interoperate?
>>
>> EDITORS: That's right, the MUST was to simplify interoperating. We made
>> these decisions for CONNECT-UDP as a WG and then decided to keep the same
>> ones for CONNECT-IP.
>>
>
> [BB] But the draft doesn't say MUST. It says SHOULD, which is my point.
> (And similarly the CONNECT-UDP draft says SHOULD in the equivalent
> sentence.)
>

[DS] Oh sorry I think I had misread your initial comment here - we landed
on SHOULD to allow servers to make the decision that is best for their
deployment.

 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)
>>
>> EDITORS: We disagree, making this normative is clearer. This matches our
>> editorial style in 9298.
>>
>
> [BB] Doesn't make either of them right. But I won't fight, 'cos too many
> words in caps is on the safe side of interop.
>
>
>> "IP proxying requests [responses] do not carry any message content." Is
>> it an error if they do?
>>
>> EDITORS: The stream is taken over by the capsule protocol. Data on the
>> stream is not message content as the data stream has been taken over. See
>> 9297 for details.
>>
>
> [BB] So this becomes an editorial point, i.e. shouldn't this say "IP
> proxying requests [responses] *cannot* carry any message content."
>
>
>>  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)
>>
>> EDITORS: We disagree, making this normative is clearer. This matches our
>> editorial style in 9298.
>>
>> "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.
>>
>> EDITORS: It's already clear that the proxy can tear down the tunnel, this
>> bit is about lifetime
>>
>
> [BB] OK. Then it becomes editorial, i.e. a slightly more obvious flow of
> word order would be "After a period of inactivity IP proxies MAY choose to
> tear down the tunnel".
>
>
>> "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.
>>
>> EDITORS: This isn't repeated, they're separate requirements.
>>
>
> [BB] Not important, but my point was that there are two separate
> requirements in the two Response subsections after §4.1 (§4.3 & §4.5), but
> also the same requirement in §4.1 covering all cases in general 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)?
>>
>> EDITORS: The server is always able to abort the tunnel if it doesn't want
>> to spend resources. The protocol as currently designed is what we need in
>> practice, your proposed redesign is not.
>>
>
> [BB] My point wasn't to push my proposed redesign, it was to point out the
> potential vulnerability.
>

[DS] The "vulnerability" here is the fact that the client can request the
server spend resources. That's true of pretty much any protocol in this
space.


>
>
> "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?
>>
>
> [BB] This point seems to have been missed.
>

[DS] My personal solution to that is "don't do DNSSEC" but that's not
something we can put in an RFC :-)

"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 been
>> explained. I'm in two minds.
>>
>> EDITORS: I agree with you that this change doesn't really improve things,
>> so we'll keep them as-is.
>>
>
> [BB] I think this is an editorial point then. I think the problem is the
> colon, which would be better as just a full stop. A colon implies that the
> clause after it is just another way of saying the clause before it. But the
> clause before is the general point, and the clause after is just one case
> where it's easy to decide that it's a fail.
>
>
>>  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?
>>
>> EDITORS: Please read RFC 9297 § 3. Capsules are sent on the one (only)
>> stream, and are sent in order. Capsule protocol does not require they be
>> processed in order, but in almost all cases should be.
>>
>
> [BB] I was thinking of a case where it would be useful to have >1 control
> stream. As I explained before, I did read the relevant parts of 9297 each
> time I needed to find the answer to a question like this one.
>
> Actually, this morning I read the whole of 9297 twice. And I've just read
> the capsule section again. I can't find anywhere where it precludes more
> than one stream. However, I admit I don't have a strong grasp of large
> swathes of the recent additions to HTTP. Is there a good tutorial anywhere?
>

[DS] HTTP requests are associated with a single stream. The reference for
this is RFC9114s6.1 but I don't know if there's a nice tutorial somewhere
https://www.rfc-editor.org/rfc/rfc9114#section-6.1

 §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?
>>
>> EDITORS: Agreed, tracked in this issue:
>> https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/144
>>
>>  §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?
>>
>> EDITORS: If a client wants exactly one address, but doesn't care which
>> address family, it should send an ADDRESS_REQUEST for v4 as 0.0.0.0/32,
>> and if it does not get one assigned, then send a request for v6 as ::/128
>> (or other mask). (This algorithm can be run in the reverse order as well)
>>  If it wants _at least_ one address of either address family, it should
>> send a single ADDRESS_REQUEST asking for both, and simply not use the
>> assigned address of the address family it is uninterested in.
>>
>
> [BB] So, in the case where the client supports both v4 & v6 and doesn't
> care which it gets, but the proxy only supports (say) v6, the allocation
> can require two rounds. That was my concern.
>

[DS] The client can send both address requests in parallel if it's worried
about the latency hit.

 §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.
>>
>> EDITORS: Please read 9297. These capsules are on the reliable stream and
>> are delivered in order.
>>
>
> [BB] My premise for this question was also a single ordered stream. As I
> said, you must mean the most recently received after reordering has been
> corrected.
> Example: Client sends A then B, which get reordered. So A is "the most
> recently received".
> It's just a picky point. Probably best to say "the latest
> ROUTE_ADVERTISEMENT capsule in sequence".
>
>
>>  §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.
>>
>> EDITORS: The first paragraph explains the rationale. This feature was
>> discussed at length in the WG and we decided to add context IDs to both
>> CONNECT-UDP and CONNECT-IP.
>>
>
> [BB] Sounds experimental. This is a PS.
> One purpose of an area review is to highlight this sort of thing to the
> members of the IESG. No need to convince me - I don't make the judgements.
>
>
>> "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?
>>
>> EDITORS: Context IDs are registered and can be for any purpose. Context
>> ID 0 is pre-registered for full IP payloads. Future extensions can perform
>> registration to create new context IDs with different payload types
>>
>> "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?
>>
>> EDITORS: Datagrams referring to context ids that are not yet registered
>> can either be buffered or dropped by the receiver, at their discretion. We
>> don't provide specific guidance because this behavior will be specified by
>> extensions that use the context ID and that guidance might vary between
>> extensions.
>>
>
> [BB] Then pls say this. 'Cos as it stands, it just sounds like an open
> issue that tails off into "um, er, y' know".
>
>
>>  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.
>>
>> EDITORS: This won't happen in HTTP/2 or HTTP/1.1, because everything is
>> delivered in order by TCP.
>>
>> *  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.
>>
>> EDITORS: We're still bound by TCP flow control. Additionally, the
>> receiver is allowed to drop so it'll do that.
>>
>> "Endpoints MAY implement additional filtering policies on the IP packets
>> they forward." Eh? This is the first mention of filtering policies.
>>
>> EDITORS: Agreed, this is the first mention. Implementers of IP tunnels
>> are familiar with the concept.
>>
>
> [BB] My point was the word 'additional' implies you've just been talking
> about other filtering policies. But you've just been talking about aborting
> a whole stream and sending echo requests etc, none of which is packet
> filtering. It felt like this sentence had got left over after something
> before it had been deleted.
>
>
>>
>>  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.
>>
>> EDITORS: CONNECT-IP conveys ICMP inside the tunnel only and is not
>> responsible for any ICMP messages on the outer connection. Existing
>> handling rules apply and are out of scope of this document.
>>
>
> [BB] OK, as I thought.
>
> [Actually, the tunnel /is/ responsible for any ICMP messages on the outer
> connection, it just can't do anything about them, and it's well-known that
> the Internet architecture doesn't give it a way to forward the error to
> their original source either. But that's not exclusively your problem.]
>
>
>>  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.
>>
>> EDITORS: We don't see value in adding this note to this example. The
>> proposed note is a completely different example. The proxy cannot set up
>> parallel tunnels; only the client issuing CONNECT-IP can set up a tunnel.
>> The right-hand side are not tunnels in this example.
>>
>
> [BB] Sorry, I worded my comment badly/wrongly. Retrying...
>
> Same comment, but s/parallel tunnels/parallel addresses/
>

[DS] Isn't that obvious from the fact that ADDRESS_REQUEST carries a list
of one or more requested addresses?

 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."
>>
>> EDITORS: Your comment is both ableist and violent. Please rephrase this
>> to be professional and actionable and then we'll discuss more.
>>
>
> [BB] One can only rely on authorization for security if the system can
> provide a mechanism for determining  what/who to authorize.
>
> For instance, any attacks that rely on the proxy appearing to send a
> message on behalf of the client are undetectable by the proxy unless the
> attack is detected (e.g. by the victim) and leads to an investigation. The
> proxy will never know about successful attacks that are not detected, and
> therefore cannot deny authorization to the attackers that launch them.
> Authorization is therefore not a sufficient security mechanism.
>
> Hence, the draft needs to address the question of "What management
> processes are necessary for this proxy to monitor users to determine
> whether to remove their authorization?"
>

[DS] Thank you for rephrasing. I think that topic is way too broad to
address in this document. Detecting and attributing abuse on the Internet
is not a solved problem, and an encapsulation format isn't the right place
to figure this out. As an example, the IPsec specs didn't tackle this.


> Cheers
>
>
>
> Bob
>
>
>
>
>> -----------------------------------------------------------------------
>> ==Nits==
>>
>> EDITORS: We've looked through these nits and made minor changes to the
>> document for the ones we agree with.
>>
>> "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
>>
>>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>