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

Those connection ID rules both (1) don't solve the problem and (2) put
unacceptable limits on the virtual target connection ID.

The presented problem is based on two proxies accepting the same virtual
client connection ID -- making them start with the same bit doesn't address
it.

Furthermore, one purpose of virtual target connection IDs is to meet the
requirements of whatever load balancer scheme the QUIC proxy is behind. If
it's QUIC-LB, it is definitely using the first bit for something else, and
I would really rather not have MASQUE levy additional requirements on
QUIC-LB>

On Wed, Nov 15, 2023 at 11:17 AM Ben Schwartz <bemasc@meta.com> wrote:

> 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 <masque-bounces@ietf.org> on behalf of Marc Blanchet <
> marc.blanchet@viagenie.ca>
> *Sent:* Wednesday, November 15, 2023 1:10 PM
> *To:* Martin Duke <martin.h.duke@gmail.com>
> *Cc:* MASQUE <masque@ietf.org>; Ted Hardie <ted.ietf@gmail.com>
> *Subject:* Re: [Masque] TTL and infinite QUIC-proxy loops
>
> !-------------------------------------------------------------------|
>   This Message Is From an External Sender
>
> |-------------------------------------------------------------------!
>
>
>
> > Le 15 nov. 2023 à 11:54, Martin Duke <martin.h.duke@gmail.com> 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
> > Masque@ietf.org
> > https://www.ietf.org/mailman/listinfo/masque
>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>