Return-Path: 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 C30A2127137 for ; Fri, 20 Apr 2018 10:48:57 -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 u3gLSS3RpZXv for ; Fri, 20 Apr 2018 10:48:55 -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 818C5124BAC for ; Fri, 20 Apr 2018 10:48:55 -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=JvTr5DuMw+94+cBBCvIurAnYB44=; b=tLYbp2L+frPunEfg XUgGcvBjIe6bXyOXjKoTLj7IOA4jWOPlQ+/He1VAtq1jghBl8GIL8oAf0d6uw+Ny ZdV1Lkc9zq459N+mo0j7qhP/OrxXTIix6iA5HephHH205PB2i+8FXsLTL8ZxozkG 4HvAoZsce88vX4FEUPBbJezxDEg= Received: by filter0937p1mdw1.sendgrid.net with SMTP id filter0937p1mdw1-7498-5ADA2806-20 2018-04-20 17:48:54.683992969 +0000 UTC Received: from smtp.github.com (out-3.smtp.github.com [192.30.252.194]) by ismtpd0010p1iad2.sendgrid.net (SG) with ESMTP id hQZs2C2wQomUM6d1wtAzrQ for ; Fri, 20 Apr 2018 17:48:54.718 +0000 (UTC) Date: Fri, 20 Apr 2018 17:48:54 +0000 (UTC) From: Mike Bishop Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Change Packet Number Gap to Packet Number Offset (#1307) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5ada28067878a_78013fb188d04f841286dd"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: MikeBishop X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org X-CSA-Complaints: whitelist-complaints@eco.de X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1uObVIF5VIHwWd6OJgxEL3TA6Xw2RgwmNbi7 9cfl7CB89LuNuhTVznEHYQ4NkEItqrGc/SyqyFr2zY/0kD60sRBbfJTBpmDrPN3iYC++nN7YuftONF Z8Cly6+FspE3IlrTR9QvgiKT7NriaZWRapi+YT6rdfGUT4BycKsf06D/8erkQc8Z4SUhGOQOy28XKg I= Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.22 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 17:48:58 -0000 ----==_mimepart_5ada28067878a_78013fb188d04f841286dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit MikeBishop requested changes on this pull request. I think @marten-seemann is correct -- this solution only makes sense as a transform on every packet, not just as something to do on particular packets with a new CID. That's my key feedback on fixing the PR. On the proposal itself, however, I share @huitema's concerns that correlation of gaps between flows is still possible. A future PR for a shuffle can make that harder for an observer, but only so much (observing over the shuffle window, you can perform the same analysis). > @@ -832,6 +832,27 @@ Use of a secure random number generator {{?RFC4086}} is not necessary for generating the initial packet number, nor is it necessary that the value be uniformly distributed. +### New Connection ID Packet Numbers + +Packets with with new connection IDs have special rules for encoding the packet +number in the headers. They use an offset (see {{packet-number-offset}}) to +transform the packet number via the following: The gap in the actual packet number was introduced at the point you sent the first packet with a new CID. This proposal is a transformation of the actual packet number for wire presentation, so it needs to occur every time. > @@ -832,6 +832,27 @@ Use of a secure random number generator {{?RFC4086}} is not necessary for generating the initial packet number, nor is it necessary that the value be uniformly distributed. +### New Connection ID Packet Numbers + +Packets with with new connection IDs have special rules for encoding the packet +number in the headers. They use an offset (see {{packet-number-offset}}) to +transform the packet number via the following: + +~~~ +transformed_packet_number = (packet_number + offset) % 2^62 This might actually be okay, but the possibility that the transformed packet number might wrap around to zero before being truncated feels a little odd. > @@ -832,6 +832,27 @@ Use of a secure random number generator {{?RFC4086}} is not necessary for generating the initial packet number, nor is it necessary that the value be uniformly distributed. +### New Connection ID Packet Numbers + +Packets with with new connection IDs have special rules for encoding the packet +number in the headers. They use an offset (see {{packet-number-offset}}) to +transform the packet number via the following: + +~~~ +transformed_packet_number = (packet_number + offset) % 2^62 +~~~ + +Once transformed, the normal rules of packet number encoding are followed, only +encoding the least number of bits required. "only" and "the least" feels duplicative. Maybe just replace the part with the comma with a reference to the section where the truncation is defined? Better yet, since this is effectively a transform on every packet number, put this in the section about truncation (it becomes a description of how the 64-bit number is encoded on the wire) and make this section purely about determining what the offset will be. -- 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/pull/1307#pullrequestreview-114065522 ----==_mimepart_5ada28067878a_78013fb188d04f841286dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@MikeBishop requested changes on this pull request.

I think @marten-seemann is correct -- this solution only makes sense as a transform on every packet, not just as something to do on particular packets with a new CID. That's my key feedback on fixing the PR.

On the proposal itself, however, I share @huitema's concerns that correlation of gaps between flows is still possible. A future PR for a shuffle can make that harder for an observer, but only so much (observing over the shuffle window, you can perform the same analysis).

In draft-ietf-quic-transport.md:

> @@ -832,6 +832,27 @@ Use of a secure random number generator {{?RFC4086}} is not necessary for
 generating the initial packet number, nor is it necessary that the value be
 uniformly distributed.
 
+### New Connection ID Packet Numbers
+
+Packets with with new connection IDs have special rules for encoding the packet
+number in the headers.  They use an offset (see {{packet-number-offset}}) to
+transform the packet number via the following:

The gap in the actual packet number was introduced at the point you sent the first packet with a new CID. This proposal is a transformation of the actual packet number for wire presentation, so it needs to occur every time.

In draft-ietf-quic-transport.md:

> @@ -832,6 +832,27 @@ Use of a secure random number generator {{?RFC4086}} is not necessary for
 generating the initial packet number, nor is it necessary that the value be
 uniformly distributed.
 
+### New Connection ID Packet Numbers
+
+Packets with with new connection IDs have special rules for encoding the packet
+number in the headers.  They use an offset (see {{packet-number-offset}}) to
+transform the packet number via the following:
+
+~~~
+transformed_packet_number = (packet_number + offset) % 2^62

This might actually be okay, but the possibility that the transformed packet number might wrap around to zero before being truncated feels a little odd.

In draft-ietf-quic-transport.md:

> @@ -832,6 +832,27 @@ Use of a secure random number generator {{?RFC4086}} is not necessary for
 generating the initial packet number, nor is it necessary that the value be
 uniformly distributed.
 
+### New Connection ID Packet Numbers
+
+Packets with with new connection IDs have special rules for encoding the packet
+number in the headers.  They use an offset (see {{packet-number-offset}}) to
+transform the packet number via the following:
+
+~~~
+transformed_packet_number = (packet_number + offset) % 2^62
+~~~
+
+Once transformed, the normal rules of packet number encoding are followed, only
+encoding the least number of bits required.

"only" and "the least" feels duplicative. Maybe just replace the part with the comma with a reference to the section where the truncation is defined?

Better yet, since this is effectively a transform on every packet number, put this in the section about truncation (it becomes a description of how the 64-bit number is encoded on the wire) and make this section purely about determining what the offset will be.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_5ada28067878a_78013fb188d04f841286dd--