IETF Logo Mail Archive

Re: [quicwg/base-drafts] Connection migration should be indistinguishable from a new connection (#203)

Christian Huitema <notifications@github.com> Mon, 05 February 2018 02:32 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 DA7FF124319 for <quic-issues@ietfa.amsl.com>; Sun, 4 Feb 2018 18:32:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, 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 YlEFTfICYqM5 for <quic-issues@ietfa.amsl.com>; Sun, 4 Feb 2018 18:32:01 -0800 (PST)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext1.iad.github.net [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55047120227 for <quic-issues@ietf.org>; Sun, 4 Feb 2018 18:32:01 -0800 (PST)
Date: Sun, 04 Feb 2018 18:32:00 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1517797920; bh=I5eeF7DwwHfziV5lDrq6+hHIt4OOVCxR4kgDbviJjd4=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=s4nF9y/AF+CyuFcFRL99S8mGfXXYVhM3mpLrPOujPA+inWghkABEziX6TTWIPv6wz y2XAOq11YTHXu/VpqAp36XqXkHHIgCSzcpQcS3lZJxXYnXZsnImorN6rh2j0DpaTKc A6np9mJvSjV9s5xHDxvJh81SKnMWfsvGHPkgyUIc=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab98d4f7dae4c71f9265a1ba235e873ae7a5ef9eff92cf00000001168f842092a169ce0c118d76@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/203/362965678@github.com>
In-Reply-To: <quicwg/base-drafts/issues/203@github.com>
References: <quicwg/base-drafts/issues/203@github.com>
Subject: Re: [quicwg/base-drafts] Connection migration should be indistinguishable from a new connection (#203)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5a77c2208e591_55182ac8d2a74ed0526853"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/OuZz0WR6CuBq8J7rEBVkQlHBj0k>
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, 05 Feb 2018 02:32:03 -0000

Who says that we have to send fake packets?

The plausible solution is to treat the connection migration as a special form of session resume. The resume ticket would need to encode that this really is a continuation of the existing QUIC session, but that seems reasonably OK to engineer. These would have to be passed to the client somehow, maybe as "MIGRATION RESUME TOKEN" frames, replacing the "NEW CONNECTION ID" mechanism. The connection setup would provide an implicit path validation, removing the need for the PATH CHALLENGE and RESPONSE frames. Not sure whether the result would be more or less complex than the present mechanism, probably similar in complexity.

-- 
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/203#issuecomment-362965678

v2.37.1 | Report a Bug | By Email | System Status