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

[Antoine FRESSANCOURT <[e-mail]>]

Hello,

For the sake of curiosity, I looked at the prescribed behavior for GENEVE, as this tunneling / encapsulation mechanism also work at the transport layer to convey IP packet or Ethernet frames.

In Section 4.4.2 of RFC 8926, the behavior of the TTL is described as:
“Though either the Uniform or Pipe models could be used for handling TTL (or Hop Limit in case of IPv6) when tunneling IP packets, the Pipe model is more consistent with network virtualization.  [RFC2003] provides guidance on handling TTL between inner IP header and outer IP tunnels; this model is similar to the Pipe model and is RECOMMENDED for use with Geneve for network virtualization applications.”

Now if we look at Section 3.1 in RFC 2003, the behavior of the TTL is described as follows:
“When encapsulating a datagram, the TTL in the inner IP header is decremented by one if the tunneling is being done as part of forwarding the datagram; otherwise, the inner header TTL is not changed during encapsulation.  If the resulting TTL in the inner IP header is 0, the datagram is discarded and an ICMP Time Exceeded message SHOULD be returned to the sender.  An encapsulator MUST NOT encapsulate a datagram with TTL = 0.
The TTL in the inner IP header is not changed when decapsulating. If, after decapsulation, the inner datagram has TTL = 0, the decapsulator MUST discard the datagram.  If, after decapsulation, the decapsulator forwards the datagram to one of its network interfaces, it will decrement the TTL as a result of doing normal IP forwarding.”

From my understanding, in GENEVE, the TTL of the inner IP header is not touched except when the packet is first encapsulated. I think we should adopt the same strategy in MASQUE, and look after using a solution that is specific (while respecting the QUIC invariants etc.)

Best,

Antoine

From: Masque <[e-mail]> On Behalf Of Martin Duke
Sent: mercredi 15 novembre 2023 20:25
To: Ben Schwartz <[e-mail]>
Cc: Marc Blanchet <[e-mail]>; MASQUE <[e-mail]>; Ted Hardie <[e-mail]>
Subject: 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Marc Blanchet <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, November 15, 2023 1:10 PM
To: Martin Duke <[e-mail]<mailto:[e-mail]>>
Cc: MASQUE <[e-mail]<mailto:[e-mail]>>; Ted Hardie <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/masque

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