Re: [quicwg/base-drafts] Specify DCID of 0-RTT packets (#2398)

Martin Thomson <notifications@github.com> Mon, 11 February 2019 00:01 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 DA57F12958B for <quic-issues@ietfa.amsl.com>; Sun, 10 Feb 2019 16:01:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
X-Spam-Status: No, score=-8.001 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 xzuyyGz30BNp for <quic-issues@ietfa.amsl.com>; Sun, 10 Feb 2019 16:01:25 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D682C129284 for <quic-issues@ietf.org>; Sun, 10 Feb 2019 16:01:24 -0800 (PST)
Date: Sun, 10 Feb 2019 16:01:24 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549843284; bh=FSW/tEg1WMbqY65jubPmc2PDsKYZLwI7k5O4ifGxGig=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=WldY0F3UZqyjM2UmsMXhvSZTvzIuZzxKtz0KWwUe+GtTB4quECxlrpxCN27iP8lsY bsIJZa52aN9yGPUnWqOc3ugQVgagMK+uF4kF2xGxCXbXlBeADjl6YxfCS5ZWpCnQ+C lzrNwfT3+KrSHFlZWSKkwWGtB/EsmT2OBcFSi1lk=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab559857f2bd6fdb907c3a092e543a3c6ac3a6e17292cf0000000118787d5392a169ce182664e3@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2398/462194127@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2398@github.com>
References: <quicwg/base-drafts/issues/2398@github.com>
Subject: Re: [quicwg/base-drafts] Specify DCID of 0-RTT packets (#2398)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c60bb53f3d5d_57bf3fa8818d45b4863235"; 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/msYNfbE2HKASfLA8FjvbDNAbJYQ>
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: Mon, 11 Feb 2019 00:01:27 -0000

The point that keeps coming up in this context (I'm sure I've typed the same response elsewhere...) is that the timescales over which connection IDs are stable is likely far less than the timescale over which attempting 0-RTT is possible.  That is, you might attempt 0-RTT up to a week later, but the server cluster you hit might be in a configuration so different that the connection ID you got 5 or 6 days ago doesn't route to the same node.

That said, for those server configurations that are more stable, this isn't a terrible idea.  If this were discretionary, say as an extension, then it might be useful for ensuring that 0-RTT attempts are routed to the right destination.

But anything that does this sort of targeting could also create a nice targeted DoS vector.  Connect to the same server multiple times over the course of a week.  Then, when it's go time, send that server 0-RTT using all the collected connection IDs that route directly to it.

Marking v2, not editorial.

-- 
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/issues/2398#issuecomment-462194127