IETF Logo Mail Archive

Re: [quicwg/base-drafts] Looping with multiple Retry packets (#1451)

Kazuho Oku <notifications@github.com> Thu, 21 June 2018 05:40 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 A46811311FC for <quic-issues@ietfa.amsl.com>; Wed, 20 Jun 2018 22:40:32 -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 uSu7n-VUtCHq for <quic-issues@ietfa.amsl.com>; Wed, 20 Jun 2018 22:40:30 -0700 (PDT)
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 B7001131229 for <quic-issues@ietf.org>; Wed, 20 Jun 2018 22:40:30 -0700 (PDT)
Date: Wed, 20 Jun 2018 22:40:29 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1529559629; bh=COoLRi2BS2N59b2Q9Foe+9o1A2DDkruvzMcem40atLk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=C0SebeBh62ujhMQgRa7Ov2yPv19L6Bojbkqzf1IaSuNXLdcXgtFaCy+lCRtJb1l1l 7jbNH+li44wcqAwGyXVzb/1NDQ6JjWJ9YTSPwTYVqk8jRoCknfyPVnEiD67FvPk536 pKZoflZXDvpt2yjrwrCibFJMatcHcXfQ2SKZ4rIQ=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab91d6c243ac8285bb7889ba976160996e777c76fa92cf000000011742fc4d92a169ce13d69366@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1451/398982420@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1451@github.com>
References: <quicwg/base-drafts/issues/1451@github.com>
Subject: Re: [quicwg/base-drafts] Looping with multiple Retry packets (#1451)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b2b3a4d82cc6_1fc83fc0b9696f7c2094f3"; 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/k8OK1PjKP3MwSk_BMc1dVuAZh3s>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 21 Jun 2018 05:40:35 -0000

> It is our (Microsoft's) goal to use Retry for DDoS mitigation and possibly load balancing.

That's understandable. I'd anticipate that others will do the same thing.

> In both cases the middle box operating on behalf of the QUIC server would likely have little or no shared state with the QUIC server.

May I ask why you think that it is not a good idea to require every one of us to share some small amount of secret (e.g. encryption key) between the middleboxes and the servers than we would be running?

As stated in my previous comment, not sharing opens an attack vector. There could be other attack vectors since lack of shared state allows anyone to run the middlebox. Considering that, I think it makes sense to *require* sharing state, under the assumption that doing so is not hard.

-- 
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/1451#issuecomment-398982420

v2.23.0 | Report a Bug | By Email