Re: [quicwg/base-drafts] per-CID PN space to avoid PN leak becoming a privacy issue? (#1317)

janaiyengar <notifications@github.com> Mon, 23 April 2018 22:41 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.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 0D1F012DA19 for <quic-issues@ietfa.amsl.com>; Mon, 23 Apr 2018 15:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level:
X-Spam-Status: No, score=-3.01 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 InB-Se8B83W5 for <quic-issues@ietfa.amsl.com>; Mon, 23 Apr 2018 15:41:48 -0700 (PDT)
Received: from o8.sgmail.github.com (o8.sgmail.github.com [167.89.101.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E63124319 for <quic-issues@ietf.org>; Mon, 23 Apr 2018 15:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=Qd8amoa3CvBinnCp98ZLvQv0EEc=; b=qOwxcgB/Ydmyc7B8 kkH5y6xbQLDmCj9wCG5Dbag3e5HefkBt6OUTY81cWxWNC72koY5raVL/DmcXvJRJ lJAhVhuwTOoIY6VH4+nqFdDRRLcR18LM71EKZoOvGXCTs6TStFMxLfURApTAxXyV RdeaygBd5opsIfTBTQ06h89ZB9k=
Received: by filter0443p1mdw1.sendgrid.net with SMTP id filter0443p1mdw1-29417-5ADE612A-1D 2018-04-23 22:41:46.819735752 +0000 UTC
Received: from smtp.github.com (out-9.smtp.github.com [192.30.254.192]) by ismtpd0005p1sjc2.sendgrid.net (SG) with ESMTP id RKFTlCFvTK67Uz1hSA5oZA for <quic-issues@ietf.org>; Mon, 23 Apr 2018 22:41:46.704 +0000 (UTC)
Date: Mon, 23 Apr 2018 22:41:47 +0000
From: janaiyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abd406c2a394d16fc0252d6541a41fd0b02c77c5c892cf0000000116f6232a92a169ce12df98aa@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1317/383745711@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1317@github.com>
References: <quicwg/base-drafts/issues/1317@github.com>
Subject: Re: [quicwg/base-drafts] per-CID PN space to avoid PN leak becoming a privacy issue? (#1317)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ade612a51c84_13912af890bacf58407f6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak13oM9WUfXVg3K9mHTxf20hfkru3O+FxavFJZ +oYppcfS7N+XMP3gszcjtMMpeLy91d6suAk5fb1jXw/WHpR8FWNb69NFK6f4h2KTVy8gVjIx0l7u9H scpXkolXDsJXLg4uBjyfZDvki9gwMwonoHbRpK4tF99TzRiKNQ0GWC0+EE8s8T85sXi1v3vI3Z2Q1f 0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/c06oPIxGyPskPiKuNEz5PDX5dUY>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
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, 23 Apr 2018 22:41:50 -0000

@kazuho : Thank you for writing up this issue. This is exactly the alternative design I had thought of in London. As @ianswett notes, if we were to go here, I suspect this bridges most of the gap from where we are to multipath. I agree that while it's not in scope for v1, if this (i) can be implemented simply for the non-multipath case, and (ii) can be extended by implementations to experiment with multipath, then we're headed in the right direction.

Thinking about this some, I think this is plausible. The current approach of using PNE or whatever, as you note, has exactly the same requirements as this mechanism does, in that a single loss recovery context with exceptions can handle both. If extended however, which we don't need to specify in v1, then multipath is achievable.

-- 
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/1317#issuecomment-383745711