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

Marc Blanchet <marc.blanchet@viagenie.ca> Wed, 15 November 2023 18:10 UTC

Return-Path: <marc.blanchet@viagenie.ca>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C348FC14CE2B for <masque@ietfa.amsl.com>; Wed, 15 Nov 2023 10:10:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viagenie-ca.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFtRDC_bYYyo for <masque@ietfa.amsl.com>; Wed, 15 Nov 2023 10:10:59 -0800 (PST)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D87C14CE3B for <masque@ietf.org>; Wed, 15 Nov 2023 10:10:58 -0800 (PST)
Received: by mail-ot1-x335.google.com with SMTP id 46e09a7af769-6d33298f8fdso4101008a34.1 for <masque@ietf.org>; Wed, 15 Nov 2023 10:10:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20230601.gappssmtp.com; s=20230601; t=1700071858; x=1700676658; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rWGSNI4yYKchaq8YEDNObr1HtDdMgr1/wST2R/TFCaQ=; b=SWW7rZVE3XQUFwnSAlU5PTwrhDVM4DV7+z6xYMBKKmXSs63eotpsBAlJrKNh67SXEj WPL9SG8U7V407jGo4kAzbeFAI/YEnBOWKj3GvXtWdp94xnWiUGK13RU8KHHoYPi2Hond uFneFTNt49ZeCWLVl9A8VFNOwyZc+x06hrtd4IL24pYvWftQzRB6x4yjzjVg+aEc9zXs 7KyZasxaIp6CwFc0/GNMk3waCDufQWY3y5Fe/uZ5L+iFoyHOz9S5OXHnfhx9MtKUczqH +gMSl5G/VAaA+ifk5m49kRcfoXesqLqVfuhms+eZTohV36WkkPGU4yGxr2RaqqVCC4d0 yY+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700071858; x=1700676658; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rWGSNI4yYKchaq8YEDNObr1HtDdMgr1/wST2R/TFCaQ=; b=WyiCjoP1PecPVFZ1Vy96/Dj6n5w5HeJiilbQd6TLJDK8/diuvah8yBmimhR9xvrb+c aBGQaJzrdxcVZdmCoK5Gb6o9zUfqyfEolYCyVnzV3GMqZE3o0LrwRXJkOm/Lih9TV3xr udSNWKVYg//W2IkjiDWQp4k35FL8Xdfva3doecfGDzvJ/wKGt0qHL/HFkp8j9W2VoJwq Z6GS3W8V4TJpObg+ve3Md6gUP9G2560F27wlPnULv8ij3ueIqAgxNKFAbe5RgA5Gi+Vo sIOnbwBe1Ce2w12Bj927F30mgjwfv7u2JNXh/awkyIlxGk8ZHmii3X41OXmUiinUsut1 K5QA==
X-Gm-Message-State: AOJu0Ywrq+mObdNbHIF14aU9wEO5mOcLEPO8nowuDfX6RotTnrpMJCL7 DbDScz5rqg5fX6kqgDjU+UFTWYorcWS6bpLr3N1tYg==
X-Google-Smtp-Source: AGHT+IGosIdtMS+W1CInpaj8uqlXnw+4T+a3XzcsOZn7wXWZRyh8m7utqV51dmtJCzZaniZgKcaRLg==
X-Received: by 2002:a9d:7c81:0:b0:6d6:552e:13db with SMTP id q1-20020a9d7c81000000b006d6552e13dbmr6939832otn.23.1700071858053; Wed, 15 Nov 2023 10:10:58 -0800 (PST)
Received: from smtpclient.apple (modemcable161.124-162-184.mc.videotron.ca. [184.162.124.161]) by smtp.gmail.com with ESMTPSA id l19-20020a056214029300b0066db33eeeb7sm711985qvv.131.2023.11.15.10.10.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2023 10:10:56 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
From: Marc Blanchet <marc.blanchet@viagenie.ca>
In-Reply-To: <CAM4esxRt5nua=ftxaDn4N_L3jQigJpkOH6LCqDrK1h1qwhVHwA@mail.gmail.com>
Date: Wed, 15 Nov 2023 13:10:45 -0500
Cc: MASQUE <masque@ietf.org>, Ted Hardie <ted.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC36FA2E-F9ED-485C-B85C-61E063F429DC@viagenie.ca>
References: <CAM4esxRt5nua=ftxaDn4N_L3jQigJpkOH6LCqDrK1h1qwhVHwA@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/CeIlDnoMC2mh-EYsq69cvrl6rVw>
Subject: Re: [Masque] TTL and infinite QUIC-proxy loops
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2023 18:10:59 -0000


> 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