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

Martin Thomson <notifications@github.com> Fri, 27 March 2020 05:14 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 6E94B3A0D13 for <quic-issues@ietfa.amsl.com>; Thu, 26 Mar 2020 22:14:31 -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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 VrIb_OH_Kr2K for <quic-issues@ietfa.amsl.com>; Thu, 26 Mar 2020 22:14:25 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA7F3A0D17 for <quic-issues@ietf.org>; Thu, 26 Mar 2020 22:14:25 -0700 (PDT)
Received: from github-lowworker-56fcc46.va3-iad.github.net (github-lowworker-56fcc46.va3-iad.github.net [10.48.102.32]) by smtp.github.com (Postfix) with ESMTP id 9EC016A002D for <quic-issues@ietf.org>; Thu, 26 Mar 2020 22:14:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585286063; bh=ccd8PhSbUn6dsOOmOYfCMB2Jm+k8TIM9hv/hfBPmua8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=U/7Xo2xvBgK2nZovhV9conxXXp3trPkCmp9eZMCXd3qYWGzvDxWlrQpGbM6h9/3Zr yh+ww1jN3LOlssa7ZwMOwadKtUxbwGzLsp0BtfvGDXVfEkDMsuxr8uw/pLT8tbmbzV pSRyg8dd9Q1cBo3qqOq/TSwGjtsZzRh4BBXeodlA=
Date: Thu, 26 Mar 2020 22:14:23 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3P6BW5ZZLJCSG23VF4RFWK7EVBNHHCFYX2PM@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/379082220@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_5e7d8baf8ea3c_436d3fde2f4cd9641692f3"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/KHEefRwbY2Kd7hgeHV-rTAuHQ9k>
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: Fri, 27 Mar 2020 05:14:32 -0000

@martinthomson commented on this pull request.

GitHub believes that I have unposted comments.  They might be worth something.

> +QUIC servers can be deployed behind a 5-tuple based routing architecture that
+delivers packets based on both the source and destination IP addresses and
+ports. In such an architecture, clients that change IP address or port are
+likely to be routed to a different server. There are several actions that can
+mitigate or resolve operational and security issues in this case.

I think that the point here is that some endpoints might choose to use address details they don't control in their routing decisions.  It's not just servers, but this spec doesn't allow for server addresses to change.  In any case, if the peer address does change, packets might not arrive at the correct endpoint instance.

> +## Considerations for 5-tuple routing architectures
+
+QUIC servers can be deployed behind a 5-tuple based routing architecture that
+delivers packets based on both the source and destination IP addresses and
+ports. In such an architecture, clients that change IP address or port are
+likely to be routed to a different server. There are several actions that can
+mitigate or resolve operational and security issues in this case.
+
+* 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.

I agree with Ian.  If this is the concrete recommendation, then advise that the idle timeout is set accordingly.

I don't think that this should be on the client to recognize.

The problem with a recommendation like this is that it could lead to terrible battery performance on devices.  Client's now need to recognize that.

> +delivers packets based on both the source and destination IP addresses and
+ports. In such an architecture, clients that change IP address or port are
+likely to be routed to a different server. There are several actions that can
+mitigate or resolve operational and security issues in this case.
+
+* 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.

This is a really interesting idea.  The server uses anycast for load balancing, but offloads to unicast as soon as possible to an address that is unique to the connection.

As Ian says, this probably needs more explanation.

> +likely to be routed to a different server. There are several actions that can
+mitigate or resolve operational and security issues in this case.
+
+* 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

It's probably enough to cite the other section, as Kazuho points out.

> @@ -6387,6 +6387,29 @@ following properties:
 Note that these guarantees are the same guarantees provided for any NAT, for the
 same reasons.
 
+## Considerations for 5-tuple routing architectures

Is the security considerations section the right place for text like this?  Maybe this can be a new Section 5.2.3, after [Server Packet Handling](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-server-packet-handling).

-- 
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-379082220