Re: [quicwg/base-drafts] Most the Retry-related fixes (#1788)

ianswett <notifications@github.com> Sun, 23 September 2018 13:16 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 C9271130DEF for <quic-issues@ietfa.amsl.com>; Sun, 23 Sep 2018 06:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Level:
X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01, 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 k-FTy1bVKhDN for <quic-issues@ietfa.amsl.com>; Sun, 23 Sep 2018 06:16:09 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F282D1292AD for <quic-issues@ietf.org>; Sun, 23 Sep 2018 06:16:08 -0700 (PDT)
Date: Sun, 23 Sep 2018 06:16:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1537708567; bh=Oidjz8BRif5NGtI0a2Mr8FquxMCQQ6AiGJqHRbW/3Fg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=r1z0T5kkK0P2BZJB6I7s6JF7+mJ+K7Hx/FgT8NuaL8XSeIP590H7LMXOIDVeBdaCK jPdyFCVIQyYUOmsaMmZMZNtxwrBHkBynWQXFURczNEppsoptYCQgvcVMQnmyycOaxp qmqWPAinoccbNRJ8TVJsgla7k1xMbC7n85ObTfFo=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab4ad15e5b94b728bfafcc224fc05e56d0da5d8a0092cf0000000117bf541792a169ce159ffad0@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1788/review/157937587@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1788@github.com>
References: <quicwg/base-drafts/pull/1788@github.com>
Subject: Re: [quicwg/base-drafts] Most the Retry-related fixes (#1788)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ba79217912c3_25583f80326d45c4113852e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/rT5uEHQoWP-OV9gmSjfADpl8GYI>
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: Sun, 23 Sep 2018 13:16:12 -0000

ianswett commented on this pull request.

Thanks Martin, looks good.

> @@ -593,37 +593,40 @@ The server populates the Destination Connection ID with the connection ID that
 the client included in the Source Connection ID of the Initial packet.
 
 The server includes a connection ID of its choice in the Source Connection ID
-field.  The client MUST use this connection ID in the Destination Connection ID
-of subsequent packets that it sends.
+field.  This value MUST not be equal to the Destination Connection ID field of

So the server HAS to change connection ID with a Retry?  I have no problem with that, but I wasn't sure where that ended up previously.

>  
-A Retry packet does not include a packet number and cannot be explicitly
-acknowledged by a client.
+A server MAY send Retry packets in response to Initial and 0-RTT packets.  A
+server can either discard or buffer 0-RTT packets that it receives.  A server

Below, you're advising that the client changes crypto context in response to Retry, so buffering 0RTT packets is likely to be useless, correct?

Retry is really meant for cheap DDoS, so if we want this to work well, I think we should spend more time thinking about how to make it work well.  I suspect we don't care and should just advise dropping 0RTT packets if you're sending a Retry?

>  
-A server MUST NOT send a Retry in response to packets other than Initial
-or 0-RTT packets.  A server MAY choose to only send Retry in response to Initial
-packets and discard or buffer 0-RTT packets corresponding to unvalidated client
-addresses.
+A client MUST accept and process at most one Retry packet for each connection

This MUST is a bit strong for me when thinking of man-on-the-side, especially since you don't respond to cases when the original dcid doesn't match, but it's Ok for now since mots is out of scope for v1.

-- 
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/1788#pullrequestreview-157937587