Re: Asymmetric CIDs

Mikkel Fahnøe Jørgensen <> Sat, 17 February 2018 00:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63836124234 for <>; Fri, 16 Feb 2018 16:22:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oEL8NXycfosJ for <>; Fri, 16 Feb 2018 16:22:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E08F91200C1 for <>; Fri, 16 Feb 2018 16:22:47 -0800 (PST)
Received: by with SMTP id z6so5875584iob.11 for <>; Fri, 16 Feb 2018 16:22:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=H5SJnDGxpJt98O1ztRdqJAX209uF8gQ4vdJM7tckrZA=; b=Ki2/T6fETpvRFlB20PonsfJ037vNrTVsvOXhiTrTNU/AFsOZ98/vTmz6+8mXEkcZNw 6/cKwMGCqpAQHg48ZEz3T00oAbnhfYHxBkh8234BLcA8uKpa0gFfpwITE5K13PB4cJTn i6Y4A7DJu1vDK2Ok4RQjFi6ht1T/4pjheaJ/6DDUR1uGhV6HaD7IwbOQV/P4TCekqIOO LT/L68+pi6ddHvZ1wZFn725VmdVSI+uLjtQiQDeZkYunofgmeHGxxx08FTuYmm9ruV8v mq8fpZulnj+gGYj+52SWkPWsSjVf9b+UyqsgG9sfJXCWSKN5W87rqVBiDTHxNUZe8EON rEcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=H5SJnDGxpJt98O1ztRdqJAX209uF8gQ4vdJM7tckrZA=; b=MD5LHG40oUilYJEVl2Ox0N/3EVC+v4Ba6Sr7hkeDraxSiOf8Bj1EG9pNCJXjhb4b9z c8q9ygVj/7k3b1vGn9loOv1i39HvRhCMlgGA+1oKimIOQwFd70fo6RV01KDgDnVSl2M/ tzyuv9ROD9o5br4geQWd71QTQVOYEi8eLfHMW4+rqM1QsjxbXovuVRrCzjJOTlhY81vl zVy+0SuftVBhcvGznZtOh+YwTnXDFAbvIxAOzoQ+DtrXQfJ4P4Si5PQ9dHjcZbEW4tFS TfDXJ7O5UpPWhnxf5xobHWKmfDg22gRo8F2XoEh2W8YCI55qcfuUVEFCHpSmBgXlof/O tvwg==
X-Gm-Message-State: APf1xPCkdvRobTTsKurq3HZ+fYY/6FP3sT0P4uiALb4XC+v1v7IaMYLN PeJbTcVX+wXjb+NnkOzwQP8lQACrCOqb/BUqDHw=
X-Google-Smtp-Source: AH8x2256FzF4jyfeiMxIDDLuAPFy6x8t4bid8NBhqhlUQ7mXFNYJLNQ1TIiw3eVeIb581ysXU9OQBW2Q40IURo8usO0=
X-Received: by with SMTP id u206mr9662246iod.96.1518826967291; Fri, 16 Feb 2018 16:22:47 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 16 Feb 2018 16:22:46 -0800
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 16 Feb 2018 16:22:46 -0800
Message-ID: <>
Subject: Re: Asymmetric CIDs
To: Nick Banks <>, Roberto Peon <>, Ian Swett <>
Cc: Eric Rescorla <>, IETF QUIC WG <>, Martin Duke <>, huitema <>
Content-Type: multipart/alternative; boundary="001a114f7e84dc6e6e05655d7555"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Feb 2018 00:22:50 -0000

This looks good to me.

Path migration might involve CID validation so a connection shuts down if a
single endpoint messes up linkage.

The stateless reset has been discussed - problem with routing to peer (I
don’t recall if reset can go both ways, but I think is is currently only
server to client ATM) with ACID it would be more relevant to also discuss
opposite reset because the use case would/could be p2p servers.

I think perhaps getting rid of reset would be good. As an alternative a
PATH_CHALLENGE or a PING could be used if one endpoint thinks the other end
is a tad silent. The sub protocol for updating router CID could also be
extended to filter out noisy clients by cancelling a CID that is not in use.

The stateless retry concern has not been discussed in this thread, I
suppose. It is mentioned in the ACID issue:

Kind Regards,
Mikkel Fahnøe Jørgensen

On 16 February 2018 at 23.56.35, Roberto Peon ( wrote:

That would make multipath hard/interesting.

I expect non-zero length (-> client) CIDs when multipath is not theoretical.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Ian Swett <>
Date: 2/16/18 2:45 PM (GMT-08:00)
To: Nick Banks <>
Cc: huitema <>et>, Roberto Peon <>om>, Martin Duke
<>om>, IETF QUIC WG <>rg>, Eric Rescorla <>
Subject: Re: Asymmetric CIDs

I agree that could be a concern, but I think it's no more difficult to
solve than the status quo.  It just means both sides need to have more
connection IDs, not just one side.

Nick's solution is a good suggestion, but one can also imagine cases when
other connection IDs have previously been made available.

In practice, for most of the cases we're discussing, I'm expecting the
connection ID from server to client will be 0 bytes in length, making this
a non-issue.