Re: [Masque] TTL and infinite QUIC-proxy loops

[Ben Schwartz <[e-mail]>]

I would still like to see if we can come up with a non-TTL solution, to avoid large amplification factors and avoid adding complexity to the forwarding plane.

For example, we could add the following Connection ID rules:

  *   Virtual Connection IDs are always longer than the corresponding real Connection ID.
  *   Virtual Target Connection IDs always start with "1".
  *   Virtual Client Connection IDs always start with "0".

The first rule ensures that an infinite cycle must traverse both upstream (shortening) and downstream (lengthening) forwarding steps.  The other rules ensure that a downstream forwarded packet can never be misread as an upstream packet to forward.

These rules don't make any assumptions about who chooses the IDs, or which paths are allowed by QUIC path validation.  We might be able to come up with even better loop-prevention by incorporating those aspects.

--Ben
________________________________
From: Masque <[e-mail]> on behalf of Marc Blanchet <[e-mail]>
Sent: Wednesday, November 15, 2023 1:10 PM
To: Martin Duke <[e-mail]>
Cc: MASQUE <[e-mail]>; Ted Hardie <[e-mail]>
Subject: Re: [Masque] TTL and infinite QUIC-proxy loops

!-------------------------------------------------------------------|
  This Message Is From an External Sender

|-------------------------------------------------------------------!



> Le 15 nov. 2023 à 11:54, Martin Duke <[e-mail]> a écrit :
>
> (Looking forward to not having to say "with no hats" in 4 months).
>
> In my presentation in Prague on infinite quic-proxy loops, I dismissed the idea that simply decrementing the TTL was a sufficient mitigation for infinite loops caused by a misbehaving client, because 256 hops is still a lot. In response, Ted suggested that we could use a lower limit.
>
> Thankfully, we did not try to further design this at the mic.
>
> But, thinking about it some more, Ted's suggestion could mean two things:
>
> (1) Use the IP TTL field: "When receiving a packet from the target, a proxy MUST set the TTL on the forwarded packet's IP header to a value lower than the TTL value of the incoming IP header. Furthermore, the TTL value MUST be no larger than N".

My understanding of most implementations is that they use 64 by default, not 256. 64 as an Internet hop count radius is already pretty large. Would that value (64) make the issue less problematic?

Marc.


>
> Clearly, for some value of N the mitigation would be sufficient. I have not checked if this in some way violates the rules about IP TTL. I also wonder if a hard limit is sufficiently permissive for legitimate but long paths.
>
> (2) There is some sort of MASQUE field that counts down the number of proxy hops. I cannot see how this can work, as (a) these are packets from the target, which is not going to add MASQUE-specific stuff; (b) by design, proxies do not know if targets are also MASQUE proxies; and (c) by design, proxies to do not know if clients are MASQUE proxies.
>
> *****
>
> I do not object to decrementing the IP TTL field by one in forwarded mode, though I think that is an insufficient mitigation for this attack. If anyone has a better-thought out design to enforce a limit, or thinks that 256 hops is just fine, I would appreciate their input.
>
> Martin
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque

--
Masque mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/masque