[quicwg/base-drafts] Clarify response to a non-probing migration when no CIDs are available (#4788)

ianswett <notifications@github.com> Wed, 20 January 2021 22:13 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 BA4743A157F for <quic-issues@ietfa.amsl.com>; Wed, 20 Jan 2021 14:13:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.945
X-Spam-Level:
X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 y6zKFuYA94tb for <quic-issues@ietfa.amsl.com>; Wed, 20 Jan 2021 14:13:08 -0800 (PST)
Received: from smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3EA83A157C for <quic-issues@ietf.org>; Wed, 20 Jan 2021 14:13:07 -0800 (PST)
Received: from github.com (hubbernetes-node-c0cb15c.ac4-iad.github.net [10.52.102.51]) by smtp.github.com (Postfix) with ESMTPA id 0FCF1520428 for <quic-issues@ietf.org>; Wed, 20 Jan 2021 14:13:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1611180787; bh=Ua8U+88WJ+wjGplB9pLo+QhUQVDEWGTTtrYKvWOaPmM=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=1+6mCc2WagHTptALBoxZOKuXxgACGgW+wVTK3nMFHuqaPqULJBPaypdWEFJG6au1V yqQL4DLMG+vqkBEFZIMLo5qHA3iOhSPm49WkhwVXh8E4pm15pbFfzs2KHL6YYhECKW 1FrheuRypFSW4zck3nJdQfn19gPwnbZea5JHYvPA=
Date: Wed, 20 Jan 2021 14:13:07 -0800
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK62YVQBIATRMH3Z3HF6CSF7HEVBNHHC6HBMWU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4788@github.com>
Subject: [quicwg/base-drafts] Clarify response to a non-probing migration when no CIDs are available (#4788)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_6008aaf3cd79_4f1a0414208"; 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/6CIklpHb4fxOylOpnvdBAXuOXE8>
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: Wed, 20 Jan 2021 22:13:10 -0000

Section 9.3 of Transport(https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-9.3) says:

"If the recipient permits the migration, it MUST send subsequent
   packets to the new peer address and MUST initiate path validation
   (Section 8.2) to verify the peer's ownership of the address if
   validation is not already underway."

In section 9.5(https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-9.5)

"Similarly, an endpoint MUST NOT reuse a connection ID when sending to
   more than one destination address.  Due to network changes outside
   the control of its peer, an endpoint might receive packets from a new
   source address with the same destination connection ID, in which case
   it MAY continue to use the current connection ID with the new remote
   address while still sending from the same local address."

So as long as it's an unintentional change, everything is clear.  But if the destination address changes and the incoming CID changes, but the sender(ie: server) doesn't have any more CIDs, it's not clear what should be done, as the two MUSTs seem to contradict one another.  Or maybe they imply the server can't send anything?

-- 
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/4788