Re: [quicwg/base-drafts] 5tuple routing (#3536)

Kazuho Oku <notifications@github.com> Sat, 21 March 2020 00:24 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F2E3A0FD3 for <quic-issues@ietfa.amsl.com>; Fri, 20 Mar 2020 17:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hZ87_YsUCG3 for <quic-issues@ietfa.amsl.com>; Fri, 20 Mar 2020 17:24:26 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B941B3A0FD1 for <quic-issues@ietf.org>; Fri, 20 Mar 2020 17:24:26 -0700 (PDT)
Received: from github-lowworker-fa7043e.ash1-iad.github.net (github-lowworker-fa7043e.ash1-iad.github.net [10.56.109.45]) by smtp.github.com (Postfix) with ESMTP id 684B6660DFA for <quic-issues@ietf.org>; Fri, 20 Mar 2020 17:24:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584750265; bh=koYXKlwRXJf4DmTeC6y4teM4gKSOEqstK1UCg2pxMAQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=QY6yo/gUxm1rQixw89u6AoQVeQPoaJpPAz6mIJ6IOY2Vq3MclK9008msMj6csuxrl E2pTq41N05vIXG9kRsGKiucTp+6hkixyJuzRLJ2rjeCcnHifd3J2KD17nOqqZ3Z7LK OSO+ReL5NBVLpkEIeEr1GbkFtntIaol5BBUi6SFA=
Date: Fri, 20 Mar 2020 17:24:25 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5SAAX6UNE4AWFYM6V4QE73TEVBNHHCFYX2PM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3536/review/378872391@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3536@github.com>
References: <quicwg/base-drafts/pull/3536@github.com>
Subject: Re: [quicwg/base-drafts] 5tuple routing (#3536)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e755eb95786f_120d3fe3002cd968529e6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/4jUjm70X8N2yW-r6iTXxTPxV9_Q>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Mar 2020 00:24:29 -0000

kazuho commented on this pull request.

Generally looks good, though I think there is one issue.

> +
+* Servers can use an out-of-band mechanism to deliver packets to the correct
+destination or transfer state from the original destination. Properly designed,
+this completely solves the problem and no further measures are necessary.
+
+* Sending the disable_active_migration transport parameter informs the client
+that any address change is likely to terminate the connection, which can lead it
+to use more aggressive timeouts or terminate connections when its IP address
+changes.
+
+* The preferred_address transport parameter can provide a path that does not use
+the 5-tuple based routers.
+
+* Servers MUST either use different Stateless Reset Token keys, or encode the
+client IP address and port in the Stateless Reset token. Doing neither will
+create a Reset Oracle (see {{reset-oracle}}).

The last two advices contradict against each other (or are incomplete).

The discussion about the use of preferred_address TP suggests that there is a direct path to any of the servers behind the server cluster, that are reachable from any client address. An attacker might try to use that path to let one of the servers generate a valid stateless token, and send it to the client.

As an example, consider the case of a server cluster consisting of two servers A and B. Server A is handling a connection QUIC connection that goes to client address X. If an attacker might send a packet directly to server B with source address of X, server B would send a valid stateless reset token to X, causing the connection to be reset.

Regarding specification, I think it might be better to simply refer to {{reset-oracle}} regarding the discussion of Stateless Resets, rather than trying to provide an exhaustive list of how to prevent attacks.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3536#pullrequestreview-378872391