Subject: [quicwg/base-drafts] Symmetric connection IDs (#1151)

From: Martin Thomson <[email-masked]>
Date: Fri, 02 Mar 2018 07:38:08 +0000 (UTC)

Lots of changes here.

Obviously people will feel inclined to nitpick at the length encoding.  Feel
free, but I think that I have good reasons for my choices there.

The NEW_CONNECTION_ID thing is tricky.  As was the analysis around the
handshake packet keys.  Also, note the trick in Version Negotiation packets
about swapping the connection IDs.  That makes client packet handling much
simpler.

The big loss is in stateless reset, which I think that I've covered well
enough.

Closes #1101.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1151

-- Commit Summary --

  * wip
  * Symmetric connection IDs

-- File Changes --

    M draft-ietf-quic-invariants.md (78)
    M draft-ietf-quic-tls.md (25)
    M draft-ietf-quic-transport.md (409)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1151.patch
https://github.com/quicwg/base-drafts/pull/1151.diff

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 02 Mar 2018 10:17:13 +0000 (UTC)

mikkelfj commented on this pull request.

> @@ -257,9 +271,9 @@ Version Negotiation packets do not use integrity or confidentiality protection.
 A specific QUIC version might authenticate the packet as part of its connection
 establishment process.
 
-The Connection ID field in a Version Negotiation packet contains the Connection
-ID from the packet that was received.  This provides some protection against
-injection of Version Negotiation packets by off-path attackers.
+The Connection ID fields in a Version Negotiation packet contain the Connection
+ID values from the packet that was received.  This can provide some protection
+against injection of Version Negotiation packets by off-path attackers.

ID values in reversed order.

-- 
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/1151#pullrequestreview-100728822

---

From: MikkelFJ <[email-masked]>
Date: Fri, 02 Mar 2018 10:44:15 +0000 (UTC)

Nonce use conflicts with routing use of ID

> +Note(1):
+
+: The Destination Connection ID is of arbitrary length, and it could be zero
+  length if the server sends a Retry packet with a zero-length Source Connection
+  ID field.  In this case, the handshake keys provide no assurance to the client
+  that the server received its packet; the client has to rely on the exchange
+  that included the Retry packet for that property.
+
+Note(2):
+
+: HKDF-Extract uses HMAC {{?RFC2104}}, which produces the same output for values
+  ending in zero octets and values that omit those octets.  Thus,
+  0x12345678900000 and 0x1234567890 produce the same result.  A client is
+  required to randomize the value of Destination Connection ID, which avoids
+  this problem.
+

Can we avoid requiring it to be random, or allow it to be only partially random? If a client has intimate knowledge of the server infrastructure, it might want to route the packet, or add some guidance in the initial destination ID.

> -The value in the Unused field is selected randomly by the server. The Connection
-ID field echoes the corresponding value from the triggering client packet.  This
-allows clients some assurance that the server received the packet and that the
-Version Negotiation packet is in fact from the server.  The Version field MUST
-be set to 0x00000000.  The remainder of the Version Negotiation packet is a list
-of 32-bit versions which the server supports.
+The value in the Unused field is selected randomly by the server.
+
+The server MUST include the value from the Source Connection ID field of the
+packet it receives in the Destination Connection ID field; similarly, the value
+of the Source Connection ID field is set to the Destination Connection ID from
+the received packet.  The value for Source Connection ID is randomly selected by
+a client and so gives clients some assurance that the server received the packet
+and that the Version Negotiation packet was not generated by an off-path
+attacker.
+

The the client sends a random source ID, it cannot be used to route the vneg packet back to the client. It could be partially a random. Even if encrypted, it wouldn't really be random. It seems that the need for nonces somewhat conflicts with the idea of using the ID for routing. It could also make the connection ID longer than necessary just to ensure initial entropy that isn't needed subsequently.

vneg routing issue: https://github.com/quicwg/base-drafts/issues/1146

> @@ -594,10 +607,14 @@ off-path attackers.
 The Initial packet uses long headers with a type value of 0x7F.  It carries the
 first cryptographic handshake message sent by the client.
 
-The client populates the connection ID field with randomly selected values,
-unless it has received a packet from the server.  If the client has received a
-packet from the server, the connection ID field uses the value provided by the
-server.
+If the client has not previously received a Retry packet from the server, it
+populates the Destination Connection ID field with a randomly selected value.
+This MUST NOT be zero length, but can be any other length.  If the client
+received a Retry packet and is sending a second Initial packet, then it uses the
+value from the Source Connection ID in the Retry packet.
+
+The client populates the Source Connection ID field with a value of its choosing
+and sets the low bits of the ConnID Len field to match.

Again same issue with randomness as for vneg.

-- 
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/1151#pullrequestreview-100730905

---

From: MikkelFJ <[email-masked]>
Date: Fri, 02 Mar 2018 10:46:18 +0000 (UTC)

Although it adds even more bulk, it might make sense to include a separate 32 bit nonce value in long headers. It would allow ID's to be routable and ensure entropy even when ID's are not in use.

-- 
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/1151#issuecomment-369888390

---

From: Nick Banks <[email-masked]>
Date: Fri, 02 Mar 2018 06:50:41 -0800

nibanks commented on this pull request.

 ## Connection ID
 
-A connection ID is an opaque 64-bit field.
+A connection ID is an opaque field.  A connection ID can be 0 octets in length,
+or between 8 and 22 octets (inclusive).

Why limit the allowable range to 8 and 22 (inclusively)? Practically, the size just needs to be large enough for the number of connections on a given tuple, right? So if a client only needs to share with a couple of connections, 1 byte might be sufficient.

> @@ -435,10 +450,11 @@ The following packet types are defined:
 | 0x7C | 0-RTT Protected               | {{packet-protected}}        |
 {: #long-packet-types title="Long Header Packet Types"}
 
-The header form, packet type, connection ID, packet number and version fields of
-a long header packet are version-independent. The types of packets defined in
-{{long-packet-types}} are version-specific.  See {{QUIC-INVARIANTS}} for
-details on how packets from different versions of QUIC are interpreted.
+the header form, type, connection ID lengths octet, destination and source

Should `the` be capitalized?

-If there is no connection ID, but the packet matches the address/port tuple
-of a connection where the host did not require connection IDs, QUIC processes
-the packet as part of that connection. Endpoints MUST drop packets that omit
-connection IDs if they do not meet both of these criteria.
+If the Destination Connection ID is zero length, but the packet matches the
+address/port tuple of a connection where the host did not require connection
+IDs, QUIC processes the packet as part of that connection. Endpoints MUST drop
+packets with zero-length Destination Connection ID fields if they do not meet
+both of these criteria.

This adds a bit of complexity that I'm not sure is worth it. As I understand it, it would require a look up table of all remote address/port tuples in use, that would have to be checked for every new connection attempt. If we don't do this, and leave it up to the peer to make the smart choice, one of two things happen:

1) The do things correctly and everything works.
2) They have two connections on the same tuple, 1 with a CID and one without. The one without breaks down because it cannot distinguish its short header packets from the other one.

If the peer does 2) above, then it's their own fault and they suffer the consequences.

-- 
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/1151#pullrequestreview-100791377

---

From: Mike Bishop <[email-masked]>
Date: Fri, 02 Mar 2018 10:47:00 -0800

MikeBishop approved this pull request.

I like the approach.

Minor nit:  "zero-length" is definitely hyphenated when used as an adjective preceding a noun.  It might also be hyphenated when used as an adjective with "is", but I'm less certain on that.

> @@ -135,12 +135,12 @@ version-specific semantics are marked with an X.
 ~~~
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+
-|1|X X X X X X X|
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|1|X X X X X X X| ConnID Len(8) |

Given the description below, it might be clearer to show this as two four-bit fields.

+

Tempting to simply require that the final octet not be zero.  If the client has knowledge of how to generate a Connection ID, it can respin in the 1/16 chance it generates one that ends in zeros.

Or alternatively, append a fixed non-zero octet to the Connection ID to side-step this problem.

> @@ -288,16 +289,12 @@ processing.
 
 ## Connection Migration and Resilience to NAT Rebinding
 
-QUIC connections are identified by a Connection ID, a 64-bit unsigned number
-randomly generated by the server.  QUIC's consistent connection ID allows
-connections to survive changes to the client's IP and port, such as those caused
-by NAT rebindings or by the client changing network connectivity to a new
-address. QUIC provides automatic cryptographic verification of a rebound client,
-since the client continues to use the same session key for encrypting and
-decrypting packets. The consistent connection ID can be used to allow migration
-of the connection to a new server IP address as well, since the Connection ID
-remains consistent across changes in the client's and the server's network
-addresses.
+QUIC connections carry a connection ID, an opaque value assigned by the intended
+recipient of the packet.  Using a consistent connection ID allows connections to
+survive changes to the sender's IP and port, such as those caused by NAT
+rebindings or by changes in network connectivity.  QUIC provides mechanisms that

"mechanisms to," I'd say.  The verification doesn't happen by itself.

> -QUIC connections are identified by a Connection ID, a 64-bit unsigned number
-randomly generated by the server.  QUIC's consistent connection ID allows
-connections to survive changes to the client's IP and port, such as those caused
-by NAT rebindings or by the client changing network connectivity to a new
-address. QUIC provides automatic cryptographic verification of a rebound client,
-since the client continues to use the same session key for encrypting and
-decrypting packets. The consistent connection ID can be used to allow migration
-of the connection to a new server IP address as well, since the Connection ID
-remains consistent across changes in the client's and the server's network
-addresses.
+QUIC connections carry a connection ID, an opaque value assigned by the intended
+recipient of the packet.  Using a consistent connection ID allows connections to
+survive changes to the sender's IP and port, such as those caused by NAT
+rebindings or by changes in network connectivity.  QUIC provides mechanisms that
+verify addresses of endpoints that change network connectivity, while
+maintaining session continuity.

This phrase doesn't feel right with a comma, but without the comma it's ambiguous which idea it's referring to.  Maybe reword?

> @@ -370,12 +367,12 @@ keys are established.
 ~~~~~
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+
-|1|   Type (7)  |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|1|   Type (7)  | ConnID Len(8) |

Same here.

Yes, it should.

This also conflicts with a paragraph or so lower, which says that the Source CID is "of [the client's] choosing" and later says "this might be a zero length value."

> @@ -623,8 +640,13 @@ A Retry packet uses long headers with a type value of 0x7E.  It carries
 cryptographic handshake messages and acknowledgments.  It is used by a server
 that wishes to perform a stateless retry (see {{stateless-retry}}).
 
-The server includes a connection ID of its choice in the connection ID field.
-The client MUST use this connection ID for any subsequent packets that it sends.
+The server populates the Destination Connection ID with the connection ID that
+the client included in the Source Connection ID of the Initial packet.  This
+might be a zero length value.

Adjective preceding a noun, so zero-length.

-The client MUST choose a random connection ID and use it in Initial packets
-({{packet-initial}}) and 0-RTT packets ({{packet-protected}}).
+During the handshake, packets with the long header are used to establish the
+Destination Connection ID that each endpoint uses.  Each endpoint sends the
+value that they wish their peer to use in the Source Connection ID field.  Upon

It should be clear from context, but the sentence by itself is slightly ambiguous.  Perhaps "Each endpoint uses the Source Connection ID field to communicate the CID which should be used in the Destination CID field of packets being sent to them."?

-The client MUST choose a random connection ID and use it in Initial packets
-({{packet-initial}}) and 0-RTT packets ({{packet-protected}}).
+During the handshake, packets with the long header are used to establish the
+Destination Connection ID that each endpoint uses.  Each endpoint sends the
+value that they wish their peer to use in the Source Connection ID field.  Upon
+receiving a packet, each endpoint sets the Destination Connection ID to match
+the value of the Source Connection ID that they receive.

Discussion of receiving multiple packets with differing Source CID fields might be warranted.  Do I set this value every time I receive a packet?  First time I see a change?  What if the change isn't until later?

-Once the client receives the connection ID that the server has chosen, it MUST
-use it for all subsequent Handshake ({{packet-handshake}}) and 1-RTT
-({{packet-protected}}) packets but not for 0-RTT packets ({{packet-protected}}).
+The very first packet sent by a client client includes a random value for
+Destination Connection ID.  The same value MUST be used for all 0-RTT packets
+sent on that connection ({{packet-protected}}).  This randomized value is used
+to determine the handshake packet protection keys (see Section 5.2.2 of
+{{QUIC-TLS}}).
 
 Server's Version Negotiation ({{packet-version}}) and Retry ({{packet-retry}})
 packets MUST use connection ID selected by the client.

I know you didn't touch this, but it's missing a "the."  Also, should this say "both Source and Destination CIDs"?

With the `omit` setting removed, I think there is no more "did not require Connection IDs," only connections where the Connection ID is zero-length.  At that point, this is a duplicate of CID collision.

In that case, the language can be something like "If the Destination Connection ID matches multiple connections (such as because they all have zero-length connection IDs), the address/port tuple is used to identify the correct connection.  Endpoints MUST drop packets with zero-length connection IDs if they cannot be matched to a connection."

> +{{packet-number-gap}}. Packet number gaps are cumulative.  An endpoint might
+skip connection IDs, but it MUST ensure that it applies the associated packet
+number gaps for connection IDs that it skips in addition to the packet number
+gap associated with the connection ID that it does use.
+
+An endpoint that receives a packet that is marked with a new connection ID
+recovers the packet number by adding the cumulative packet number gap to its
+expected packet number.  An endpoint MUST discard packets that contain a smaller
+gap than it advertised.
+
+An endpoint that receives a packet from a new address with either a previously
+unused connection ID or an empty connection ID MUST use the next available
+connection ID for any packets it sends to that address.  Failing to do this
+would allow for use of that connection ID to link activity on new paths.  An
+endpoint SHOULD use a new connection ID if it observes a change in address
+without a change in connection ID.

To avoid linkability, we also should say that if you observe a change in the peer's connection ID, you should also change CIDs yourself.  Otherwise, the connection IDs in the reverse direction provide correlation.

> @@ -2320,15 +2352,28 @@ Sequence:
   the value selected during the handshake comes immediately before the first
   value that a server can send.
 
+Length:
+
+: An 8-bit unsigned integer containing the length of the connection ID.  Values
+  less than 8 and greater than 22 are invalid and MUST be treated as a
+  connection error of type PROTOCOL_VIOLATION.

You have the room here to spell it out, but there's something to be said for using the same encoding other places the length is written.  Maybe just use four bits and zero/ignore the upper four?

-- 
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/1151#pullrequestreview-100859608

---

From: Mike Bishop <[email-masked]>
Date: Fri, 02 Mar 2018 10:59:10 -0800

MikeBishop commented on this pull request.

For short headers, an endpoint can simplify its job by always using the same length CID, but if it doesn't then it probably needs to keep the connections in a tree by CID.  Check the first byte, see if there are any CIDs that begin with that byte, and so on, until it either finds a complete match or a lookup failure.

Then, if there's a lookup failure, it might have been zero-length and you were accidentally reading the packet number and encrypted payload as a CID.  So now you look into your separate bag of connections where the CID is zero-length and try to match by tuple.

But wait!  You also might have had a collision between the packet number and a CID, so packets which can't be validated by the selected connection *also* need to be checked against the zero-length set.  And we pray that doesn't happen very often, because this seems like the worst-case path through the code.

Ick.

-- 
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/1151#discussion_r171933242

---

From: ianswett <[email-masked]>
Date: Fri, 02 Mar 2018 11:02:11 -0800

ianswett commented on this pull request.

Thanks for writing this up, only one substantive comment(same as Nick's) about short conn IDs

> @@ -150,10 +150,25 @@ version-specific semantics are marked with an X.
 {: #fig-long title="QUIC Long Header"}
 
 A QUIC packet with a long header has the high bit of the first octet set to 1.
+All other bits in that octet are version specific.
+
+The next octet contains the length in octets of the two Connection IDs (see
+{{connection-id}}) that follow.  Each length is encoded as a 4 bit unsigned
+integer.  The length of the Destination Connection ID occupies the high bits of
+the octet and the length of the Source Connection ID occupying the low bits of
+the octet.  An encoded length of 0 indicates that the connection ID is also 0

I think there are valid use cases for shorter connection IDs(ie: 4 bytes in particular), so I'd be biased towards using 5 bits for each length.  I'm not sure if I'd want to overlap this with the first byte to reduce the number of bits we'd want to grease or just deal with randomizing 3 bits in each byte.

-A QUIC packet with a long header has two fixed fields immediately following the
-first octet: a 64-bit Connection ID (see {{connection-id}}) and a 32-bit Version
-(see {{version}}).
+The connection ID lengths are followed by connection IDs.  The connection ID
+selected by the recipient of the packet (the Destination Connection ID) is
+followed by the connection ID selected by the sender of the packet (the Source
+Connection ID).
+
+After both Connection IDs, a 32-bit Version (see {{version}}) is followed by a
+version-specific payload.

Not in this PR, but I think moving to varlen connection IDs motivates moving the version in front of the connection IDs, because then it's in a fixed spot, which is nice.

Previously the connection ID was always in a fixed spot, but now it's offset changes by 1 byte based on long/short header anyway, so we might as well have it move by 5 bytes instead of 1.  Conveniently, an 8 byte connection ID fits into a typical 16 byte cacheline in either location.

This isn't to say that the connection ID format in long headers should be removed from the invariants, because I think that turns out to be impractical.

nit: I think it reads more cleanly to say "This MUST be at least 8 bytes."

-- 
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/1151#pullrequestreview-100871459

---

From: ekr <[email-masked]>
Date: Fri, 02 Mar 2018 15:24:49 -0800

ekr commented on this pull request.

perhaps "by the connection IDs"

+1 to Ian here.

This isn't quite correct for the initial Initial packet. Maybe "associated with the recipient"

> @@ -552,7 +552,8 @@ older than 1.3 is negotiated.
 
 QUIC requires that the initial handshake packet from a client fit within the
 payload of a single packet.  The size limits on QUIC packets mean that a record
-containing a ClientHello needs to fit within 1171 octets.
+containing a ClientHello needs to fit within 1131 octets, though endpoints can
+reduce the size of their connection ID to increase by up to 22 octets.

You'll of course need to change this if you ahnge the length encoding.

> @@ -679,13 +680,13 @@ client packet protection key would use HKDF-Expand with an `info` parameter of
 ### Handshake Secrets {#handshake-secrets}
 
 Packets that carry the TLS handshake (Initial, Retry, and Handshake) are
-protected with a secret derived from the connection ID used in the client's
-Initial packet.  Specifically:
+protected with a secret derived from the Destination Connection ID field from
+the client's Initial packet.  Specifically:

Good catch.

> @@ -703,6 +704,22 @@ ensuring that the keys are different for each version of QUIC. This prevents a
 middlebox that only recognizes one version of QUIC from seeing or modifying the
 contents of handshake packets from future versions.
 
+Note(1):
+

I believe this is incorrect.

HKDF-Extract is:

```
PRK = HMAC-Hash(salt, IKM)
```

In this case, salt is the handshake_salt (used as the HMAC key) and the CID is the IKM (used as the message. HMAC does right-pad the key with 0s (before XORing in the pad) but it does not handle the message that way.

 

Technically, QUIC packets carry a connection ID.

-- 
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/1151#pullrequestreview-100940428

---

From: ekr <[email-masked]>
Date: Fri, 02 Mar 2018 23:59:51 +0000 (UTC)

> @@ -3987,6 +4031,9 @@ Issue and pull request numbers are listed with a leading octothorp.
 - Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with Data and
   PONG frame. Changed ACK frame type from 0x0e to 0x0d. (#1091, #1086)
 
+- Made connection IDs symmetrical and variable length.  Removed

The fact that I called this "asymmetric" and you called it "symmetrical" suggests that both names are bad. Maybe "unidirectional" is the term we want?

-- 
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/1151#pullrequestreview-100949104

---

From: Martin Thomson <[email-masked]>
Date: Mon, 05 Mar 2018 06:55:04 +0000 (UTC)

martinthomson commented on this pull request.

 ~~~
  0                   1                   2                   3

I guess so.  This seemed a little easier to understand without having to read the text that follows.

I actually think that shorter connection IDs is harmful.  If we are to encourage the use of NEW_CONNECTION_ID, the space needs to be large enough to make the use of a new identifier meaningful.

Yep, I think that's a good idea.  We should make that move sooner rather than later if we do.

 ## Connection ID

I thought carefully about this.

Shorter values make it much harder to come up with a scheme for preserving unlinkability if you use NEW_CONNECTION_ID.  Thus, I want to prohibit 1 octet connection IDs.  2 seems similarly challenged.

Yeah, I'm close to killing this sentence, but it's somewhat useful to know where the limits are.

+Note(1):
+

Ahh, yes, the key is a problem, not the IKM.  I've never understood the ordering choice in the design of HKDF.

Difficult.  A complete redo maybe.

An understandable misinterpretation.

Client sets destination to random, source to whatever it needs.
In VN, server sets destination to client's source and source to client's destination.

Thus, it's very hard to explain.  And clearly I failed.

Good catch.  I've put in a rule for this.  I think that it's a sensible rule, but you can judge that for yourself.

"don't do that"

+Length:
+

There's a good reason to make the headers we expose to the cesspit use a crappy encoding, but less so here.

I did that intentionally :)  But the changelog can be better.  I might avoid all those words and say what they are instead.

-- 
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/1151#discussion_r172098496

---

From: Martin Thomson <[email-masked]>
Date: Sun, 04 Mar 2018 22:56:08 -0800

@martinthomson pushed 1 commit.

ce697aa  Address review comments, closes #1052

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/e2ead3c32008e026a77712a0fcfb4a3db7eb4da2..ce697aac38adf16144c3e4ac796452bc590ed3bf

---

From: mirjak <[email-masked]>
Date: Mon, 05 Mar 2018 09:34:55 +0000 (UTC)

mirjak commented on this pull request.

> +An endpoint which wishes to break linkability upon changing networks MUST use
+the connection ID provided by its peer as well as incrementing the packet
+sequence number by an externally unpredictable value computed as described in
+{{packet-number-gap}}. Packet number gaps are cumulative.  An endpoint might
+skip connection IDs, but it MUST ensure that it applies the associated packet
+number gaps for connection IDs that it skips in addition to the packet number
+gap associated with the connection ID that it does use.
+
+An endpoint that receives a packet that is marked with a new connection ID
+recovers the packet number by adding the cumulative packet number gap to its
+expected packet number.  An endpoint MUST discard packets that contain a smaller
+gap than it advertised.
+
+An endpoint that receives a packet either with a previously unused connection ID
+or with an empty connection ID and from a new remote address MUST use the next
+available connection ID for any packets it sends to that address.  Failing to do

What happens if there is no new connection ID available (anymore)?

-- 
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/1151#pullrequestreview-101093803

---

From: mirjak <[email-masked]>
Date: Mon, 05 Mar 2018 01:39:09 -0800

> @@ -178,16 +191,17 @@ version-specific semantics are marked with an X.
 
 A QUIC packet with a short header has the high bit of the first octet set to 0.
 
-A QUIC packet with a short header includes an optional connection ID and no
-version field.  The second bit of that octet (that is, 0x40) determines whether
-the connection ID is present.  If the second bit is cleared, a 64-bit connection
-ID immediately follows the first octet.  If the second bit is set, the remainder
-of the packet has version-specific semantics.
+A QUIC packet with a short header includes a Destination Connection ID.  The

Just double checking: The short header does actually not include a connection ID if the length was zero in the long header, right?

-- 
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/1151#pullrequestreview-101095069

---

From: mirjak <[email-masked]>
Date: Mon, 05 Mar 2018 09:40:44 +0000 (UTC)

> @@ -2320,15 +2362,28 @@ Sequence:
 
+Length:
+

What is actually the use case for changing the connection ID length during a connection? Is that really needed?

-- 
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/1151#pullrequestreview-101095553

---

From: Mike Bishop <[email-masked]>
Date: Mon, 05 Mar 2018 19:21:31 +0000 (UTC)

>  Connection ID.
 
-The connection ID lengths are followed by connection IDs.  The connection ID
-selected by the recipient of the packet (the Destination Connection ID) is
-followed by the connection ID selected by the sender of the packet (the Source
-Connection ID).
+The connection ID lengths are followed by a two connection IDs.  The connection

by ~a~ two

"When an endpoint changes network connectivity, QUIC provides mechanisms to verify new addresses while maintaining session continuity.", maybe?

-- 
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/1151#pullrequestreview-101288022

---

From: Mike Bishop <[email-masked]>
Date: Mon, 05 Mar 2018 19:37:03 +0000 (UTC)

Another pass.

> -
-Once the client receives the connection ID that the server has chosen, it MUST
-use it for all subsequent Handshake ({{packet-handshake}}) and 1-RTT
-({{packet-protected}}) packets but not for 0-RTT packets ({{packet-protected}}).
-
-Server's Version Negotiation ({{packet-version}}) and Retry ({{packet-retry}})
-packets MUST use connection ID selected by the client.
+A connection ID is used to ensure consistent routing of packets.  The long
+header contains two connection IDs: the Destination Connection ID is chosen by
+the recipient of the packet and is used to provide consistent routing; the
+Source Connection ID is used to set the Destination Connection ID used by a
+peer.
+
+During the handshake, packets with the long header are used to establish the
+Destination Connection ID that each endpoint uses.  Each endpoint uses the
+Source Connection ID field to communicate the connection that is used in the

"communicate the connection that is used" doesn't read properly to me.  Should this be "connection ID"?

> -connection IDs, but it MUST ensure that it applies the associated packet number
-gaps for connection IDs that it skips in addition to the packet number gap
-associated with the connection ID that it does use.
-
-A server that receives a packet that is marked with a new connection ID recovers
-the packet number by adding the cumulative packet number gap to its expected
-packet number.  A server SHOULD discard packets that contain a smaller gap than
-it advertised.
+to correlate activity between those paths.  An endpoint that moves between
+networks might not wish to have their activity correlated by any entity other
+than a server. The NEW_CONNECTION_ID message can be sent by both endpoints to
+provide an unlinkable connection ID for use in case a peer wishes to explicitly
+break linkability between two points of network attachment.
+
+An endpoint might need to send packets on multiple networks without receiving
+any response from the server.  To ensure that the endpoint is not linkable

You're mixing "endpoint/peer" and "client/server" language here.  While it's (currently) correct that the endpoint on the previous line must be a client, you might want to pick one or the other for clarity.

If it's an empty connection ID and a new remote address, how would the packet even be associated with the connection?  I think this is a normative requirement for a situation which can't occur.

A few reasonable choices would be to continue with the current CID (it's the peer's fault for letting you run out, so they've lost their linkability), or to prohibit sending until you get a NEW_CONNECTION_ID frame.  The latter has the nasty corner case that, if you're prohibited from sending ACKs and the packet containing your new CID gets dropped, you can't make forward progress until you RTO.

> @@ -3987,6 +4041,10 @@ Issue and pull request numbers are listed with a leading octothorp.
 
+- Endpoint now set the connection ID that their peer uses.  Connection IDs are

Endpoint**s**.

-- 
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/1151#pullrequestreview-101293491

---

From: ekr <[email-masked]>
Date: Mon, 05 Mar 2018 12:27:03 -0800

+Note(1):
+

AIUI, the idea is that HMAC is a PRF, with the IKM being the message,  so this whitens the IKM.

+

@MikeBishop: as noted above, I don't think this is necessary.

-- 
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/1151#discussion_r172317506

---

From: Martin Thomson <[email-masked]>
Date: Mon, 05 Mar 2018 22:35:59 +0000 (UTC)

c9f1823  Review-based tweakin'

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/ce697aac38adf16144c3e4ac796452bc590ed3bf..c9f1823f77e1bc39323531e47ea8869fe474a892

---

From: Martin Thomson <[email-masked]>
Date: Mon, 05 Mar 2018 22:36:07 +0000 (UTC)

Yep, either that or it includes a zero-length connection ID :)

Hmm, only if it does trial decryption for all connections.  Probably unrealistic.  Trimming "with an empty connection ID and" out.

Opened #1163

+Length:
+

Well, if you are migrating to new load balancing infrastructure, it might help.  Note that you probably need an indicator of length in the connection ID itself to make this work, or a period where the common prefix is distinct.

Basically, I couldn't see any reason not to allow this, given that it's the endpoint that sends NEW_CONNECTION_ID that absorbs the complexity cost.

-- 
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/1151#discussion_r172349116

---

From: Martin Thomson <[email-masked]>
Date: Mon, 05 Mar 2018 14:41:36 -0800

a2ea973  Closes #1146 too

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/c9f1823f77e1bc39323531e47ea8869fe474a892..a2ea973b99cd7eaf2291e23c073bf3189a779927

---

From: Martin Thomson <[email-masked]>
Date: Mon, 05 Mar 2018 17:14:04 -0800

ae8a475  Closes #821 too

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/a2ea973b99cd7eaf2291e23c073bf3189a779927..ae8a475f1c83180932a7c3d2b8c0b8dc06f07361

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 06 Mar 2018 01:56:58 +0000 (UTC)

igorlord commented on this pull request.

Please, drop: "or from a new remote address".  No "either" there.  Otherwise, you are setting yourself up for an attack, where the attacker just replays the same packet from many different addresses toward a peer, draining the list of connection IDs that peer has.  Then, when there is a genuine connection migration, the peer has no connection IDs left.

-- 
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/1151#discussion_r172388926

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 05 Mar 2018 18:01:07 -0800

+this would allow for use of that connection ID to link activity on new paths.
+An endpoint SHOULD use a new connection ID if it observes a change in address

See above why SHOULD should be SHOULD NOT.  I.e. you do not want an attacker resend the same packet from many src IPs.  In any case, the linkability cause is probably lost, if even one packet has made it from one peer to another with an old connection ID over the new path (even in one direction).

-- 
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/1151#pullrequestreview-101397279

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Mar 2018 02:29:16 +0000 (UTC)

387911d  Let's not flip around too often unnecessarily

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/ae8a475f1c83180932a7c3d2b8c0b8dc06f07361..387911ddd8b0759edf741f8f61a7a0b67c9abcdf

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Mar 2018 05:25:43 +0000 (UTC)

Would it be enough to insist that the packet be authenticated?  The current rules for migration require that the packet be both authenticated and have the largest packet number seen thus far.  That isn't perfect, but the fact here is that an attacker with that level of control can cause new connection IDs to be used.

That's fair, but I'm going to remove 2119 language there.

-- 
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/1151#discussion_r172392290

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 06 Mar 2018 05:54:15 +0000 (UTC)

Thanks for updating. The level of control required is not much, really, especially if the connection is over ipv6 (ie. the number of unique ip addresses under attacker's control is enormous).

The ability to collect and correlate data from multiple independent networks to follow nodes across migrations assumes a rather awesome level of control and resources already.

-- 
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/1151#discussion_r172416148

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Mar 2018 00:19:04 -0800

+gap associated with the connection ID that it does use.
+
+An endpoint that receives a packet that is marked with a new connection ID
+recovers the packet number by adding the cumulative packet number gap to its
+expected packet number.  An endpoint MUST discard packets that contain a smaller
+gap than it advertised.
+
+An endpoint that receives a successfully authenticated packet with a previously
+unused connection ID MUST use the next available connection ID for any packets
+it sends to that address.  To avoid changing connection IDs multiple times when
+packets arrive out of order, endpoints MUST change only in response to a packet
+that increases the largest received packet number.  Failing to do this could
+allow for use of that connection ID to link activity on new paths.  There is no
+need to move to a new connection ID if the address of a peer changes without
+also changing the connection ID.

I'm not fully up to speed on connection migration, so bear with me, but...

What if both endpoints migrate? For example B has sent two NEW_ID_B(1,2) to A, and A sends two NEW_ID_A(1,2) to B. A migrates and consumes the first NEW_ID_B(1). Then B migrates and consumes NEW_ID_A(1). But because either end has migrated, they are now on new infrastructure and the load balancers no longer understand NEW_ID_A(2) or NEW_ID_B(2).

It seems to me that you cannot have a sequential NEW_ID - assuming an endpoint only migrates to one location at a time (no multipath) there must a be a latest NEW_ID that will work, but the older might not. It is just trial an error until something works?

-- 
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/1151#pullrequestreview-101451216

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Mar 2018 08:26:55 +0000 (UTC)

Maybe I'm just not reading careful enough, but could we perhaps change the language slightly - despite that I have been thinking about this problem for a long time, I still got confused. There are 3 different connection ID's. The initial connection ID chosen randomly by client, and the client chosen ID, and the server chosen ID. Each of these are sometimes a Destination ID or a Source ID depending on direction.

In some place there is a wording along "Even if the server changes the ID, the same ID must be used". It would be helpful to clarify which kind of ID and exactly for how long.

-- 
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/1151#issuecomment-370701851

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Mar 2018 00:47:38 -0800

Migration happens with short headers, so there is usually one connection ID in each direction.

For instance, the client might be sending SCID3 and the server might send CCID2.  If the client moves, then it sends SCID4.  The server sees the new connection ID from the client and moves to sending CCID3.

Note that connection IDs are currently strictly sequential, but that is not a property we need to preserve if we encrypt packet numbers.  Any connection ID should work (with some caveats that I can go into more).

-- 
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/1151#discussion_r172444802

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Mar 2018 08:50:44 +0000 (UTC)

Not following you there.  There are actually 4 discrete values for connection ID that might be in use during the handshake (the server can update its choice if it sends Retry).

I added this recently, does it help?

> During the handshake, an endpoint might receive multiple packets with the long
header, and thus be given multiple opportunities to update the Destination
Connection ID it sends.  An client MUST only change the value it sends in the
Destination Connection ID field in response to the first packet of each type
(Retry, or Handshake) that it receives; a server MUST only change its value
based on an Initial packet.  This avoids problems that might arise from
stateless processing of multiple Initial packets producing different connection
IDs.

-- 
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/1151#issuecomment-370707895

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Mar 2018 00:50:53 -0800

OK, thanks for explaining - as long as this has been given some consideration, I'm happy.

-- 
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/1151#discussion_r172445552

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Mar 2018 08:51:59 +0000 (UTC)

febac4d  Fix length labels

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/acf8bfe99785a6617962d7a4786cc389f0d7b84b..febac4d3d619821f8e1f3d3a2c61326f7644f154

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Mar 2018 01:21:23 -0800

Yes this clarifies the last part. I still wonder if might help to provide a name to the initial Destination ID, such as Client Probe ID, or whatever. Note typo "An client MUST".

-- 
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/1151#issuecomment-370716348

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Mar 2018 09:28:40 +0000 (UTC)

436786f  -n

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/febac4d3d619821f8e1f3d3a2c61326f7644f154..436786f8f116c40e0236bed97d429bff67c56b8d

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Mar 2018 09:41:20 +0000 (UTC)

Hmm - in the above example: If the server later moves, it uses CCID4 and the client sees this and sends SCID5. But SCID5 was send in a NEW_ID message before the server moved to use CCID4 and the server is now behind infrastructure that does not understand SCID5.

If the migration where the server sends CCID4 also marks the smallest valid SCID, there should be no issue - perhaps this is already the case.

-- 
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/1151#discussion_r172458591

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Mar 2018 02:00:44 -0800

It is the responsibility of the endpoint to ensure that any connection ID it provides to its peer is capable of reaching it, no matter where it moves to.  The only stipulation being that packets arrive at an address that the endpoint control.  Either the endpoint or intermediaries over which it has influence, like a load balancer.

-- 
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/1151#discussion_r172464388

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Mar 2018 22:56:19 +0000 (UTC)

2764c5c  Reducing minimum connection ID length to 4 octets

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/436786f8f116c40e0236bed97d429bff67c56b8d..2764c5c388f858f1cb18c6297a66af043676b14b

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Mar 2018 23:18:57 +0000 (UTC)

7bfa8ab  Sums iz haard

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/2764c5c388f858f1cb18c6297a66af043676b14b..7bfa8ab3ae3db5a9ccacc51dc06f614bc3706374

---

From: ianswett <[email-masked]>
Date: Wed, 07 Mar 2018 14:52:48 +0000 (UTC)

A few more small suggestions.

> @@ -1502,13 +1534,13 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code.
 
 ## Connection Migration {#migration}
 
-QUIC connections are identified by their 64-bit Connection ID.  QUIC's
-consistent connection ID allows connections to survive changes to the client's
-IP and/or port, such as those caused by client or server migrating to a new
-network.  Connection migration allows a client to retain any shared state with a
-connection when they move networks.  This includes state that can be hard to
-recover such as outstanding requests, which might otherwise be lost with no easy
-way to retry them.
+A QUIC connection can be identified using the Destination Connection ID included
+in packets.  QUIC's consistent connection ID allows connections to survive
+changes to the client's IP and/or port, such as those caused by client or server

I realize this is text Jana added, but shouldn't asymmetric connection IDs allow a change to either a client or server's IP and/or port?

-: Octets 1 through 8 contain the connection ID. {{connection-id}} describes the
-  use of this field in more detail.
+Destination Connection ID:
+
+: The Destination Connection ID field starts at octet 2 and is either 0 octets
+  in length or between 4 and 18 octets. {{connection-id}} describes the use of
+  this field in more detail.
+
+Source Connection ID:
+
+: The Source Connection ID field starts at octet 2 and is either 0 octets in

They can't both start at octet 2, unless the destination Connection ID is 0 length.

+Source Connection ID is used to set the Destination Connection ID used by a
+peer.
+
+During the handshake, packets with the long header are used to establish the
+Destination Connection ID that each endpoint uses.  Each endpoint uses the
+Source Connection ID field to specify the connection ID that is used in the
+Destination Connection ID field of packets being sent to them.  Upon receiving a
+packet, each endpoint sets the Destination Connection ID it sends to match the
+value of the Source Connection ID that they receive.
+
+During the handshake, an endpoint might receive multiple packets with the long
+header, and thus be given multiple opportunities to update the Destination
+Connection ID it sends.  A client MUST only change the value it sends in the
+Destination Connection ID field in response to the first packet of each type
+(Retry, or Handshake) that it receives; a server MUST only change its value

I think an algorithm based on packet number might be more robust than specifying the first packet of each type?  Largest packet number wins?

Also, I would say the server MUST set it's value based on an Initial packet.  Given there was no connection before, I wouldn't call it a change of connection ID.

-- 
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/1151#pullrequestreview-101506040

---

From: Mike Bishop <[email-masked]>
Date: Wed, 07 Mar 2018 16:45:37 +0000 (UTC)

It might in the future, but server connection migration isn't defined.  Certainly they pave the way, though.

-- 
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/1151#discussion_r172907010

---

From: ianswett <[email-masked]>
Date: Wed, 07 Mar 2018 09:25:47 -0800

SGTM, ignore this comment for now.

-- 
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/1151#discussion_r172920252

---

From: janaiyengar <[email-masked]>
Date: Wed, 07 Mar 2018 21:46:14 +0000 (UTC)

janaiyengar commented on this pull request.

Looking great! Some comments.

> @@ -150,10 +150,26 @@ version-specific semantics are marked with an X.

4-bit

remove "a"

-A QUIC packet with a long header has two fixed fields immediately following the
-first octet: a 64-bit Connection ID (see {{connection-id}}) and a 32-bit Version
-(see {{version}}).
+The connection ID lengths are followed by a two connection IDs.  The connection
+ID associated with the recipient of the packet (the Destination Connection ID)
+is followed by the connection ID associated with the sender of the packet (the
+Source Connection ID).

maybe s/"associated with"/"chosen by"/

-A QUIC packet with a long header has two fixed fields immediately following the
-first octet: a 64-bit Connection ID (see {{connection-id}}) and a 32-bit Version
-(see {{version}}).
+The connection ID lengths are followed by a two connection IDs.  The connection
+ID associated with the recipient of the packet (the Destination Connection ID)
+is followed by the connection ID associated with the sender of the packet (the
+Source Connection ID).
+
+After both Connection IDs, a 32-bit Version (see {{version}}) is followed by a

"After" seems a bit odd. How about "The Connection IDs are followed by a 32-bit Version (see {{version}}) and a version-specific payload."

 

I would call that out explicitly. "an optional Destination Connection ID" should do the job.

> @@ -257,9 +272,12 @@ Version Negotiation packets do not use integrity or confidentiality protection.
 
-The Connection ID field in a Version Negotiation packet contains the Connection
-ID from the packet that was received.  This provides some protection against
-injection of Version Negotiation packets by off-path attackers.
+The Connection ID fields in a Version Negotiation packet contain the Connection
+ID values from the packet that was received by the server, inverted to ensure
+correct routing of the packet toward the client based on the Destination
+Connection ID.  Echoing the value of the client's Destination Connection ID in

I would remove "based on the Destination Connection ID", since it's not clear which packet's Destination ID is being mentioned (and it is unnecessary).

> @@ -257,9 +272,12 @@ Version Negotiation packets do not use integrity or confidentiality protection.
 
-The Connection ID field in a Version Negotiation packet contains the Connection
-ID from the packet that was received.  This provides some protection against
-injection of Version Negotiation packets by off-path attackers.
+The Connection ID fields in a Version Negotiation packet contain the Connection
+ID values from the packet that was received by the server, inverted to ensure
+correct routing of the packet toward the client based on the Destination
+Connection ID.  Echoing the value of the client's Destination Connection ID in
+the Source Connection ID field can provide some protection against injection of
+Version Negotiation packets by off-path attackers.

Doesn't echoing the client's Source Connection ID provide this protection? Echoing either field provides this protection, doesn't it?

> @@ -163,7 +163,8 @@ Connection:
 
 Connection ID:

s/Connection ID/Destination Connection ID/

> @@ -163,7 +163,8 @@ Connection:
 
 Connection ID:
 
-: The 64-bit unsigned number used as an identifier for a QUIC connection.
+: An opaque identifier that is used to identify a QUIC connection.  Each

This sentence sounds incomplete now. How about "to identify a QUIC connection at an endpoint"?

> @@ -404,26 +401,44 @@ Long Packet Type:
   indicate one of 128 packet types.  The types specified for this version are
   listed in {{long-packet-types}}.
 
-Connection ID:
+DCIL and SCIL:
+
+: Octet 1 contains the lengths of the two connection ID fields that follow it.
+  These lengths are encoded as two 4-bit unsigned integers. The Destination
+  Connection ID Length (DCIL) field occupies the 4 high bits of the octet and
+  the Source Connection ID Length (SCIL) field occupies the 4 low bits of the
+  octet.  An encoded length of 0 indicates that the connection ID is also 0
+  octets in length.  Non-zero encoded lengths are increased by 3 to get the full
+  length of the connection ID, producing a length between 4 and 18 octets
+  inclusive.  For example, an octet with the value 0x50 describes an 8 octet

8-octet

> @@ -404,26 +401,44 @@ Long Packet Type:
   indicate one of 128 packet types.  The types specified for this version are
   listed in {{long-packet-types}}.
 
-Connection ID:
+DCIL and SCIL:
+
+: Octet 1 contains the lengths of the two connection ID fields that follow it.
+  These lengths are encoded as two 4-bit unsigned integers. The Destination
+  Connection ID Length (DCIL) field occupies the 4 high bits of the octet and
+  the Source Connection ID Length (SCIL) field occupies the 4 low bits of the
+  octet.  An encoded length of 0 indicates that the connection ID is also 0
+  octets in length.  Non-zero encoded lengths are increased by 3 to get the full
+  length of the connection ID, producing a length between 4 and 18 octets
+  inclusive.  For example, an octet with the value 0x50 describes an 8 octet
+  Destination Connection ID and a zero octet Source Connection ID.

zero-octet

+1. I would remove the starting position.

> @@ -577,12 +589,20 @@ The layout of a Version Negotiation packet is:
 ~~~
 {: #version-negotiation-format title="Version Negotiation Packet"}
 
-The value in the Unused field is selected randomly by the server. The Connection
-ID field echoes the corresponding value from the triggering client packet.  This
-allows clients some assurance that the server received the packet and that the
-Version Negotiation packet is in fact from the server.  The Version field MUST
-be set to 0x00000000.  The remainder of the Version Negotiation packet is a list
-of 32-bit versions which the server supports.
+The value in the Unused field is selected randomly by the server.
+
+The server MUST include the value from the Source Connection ID field of the
+packet it receives in the Destination Connection ID field.  The value for Source
+Connection ID MUST be copied from the Destination Connection ID of the received
+packet, which is initially randomly selected by a client.  Echoing both
+connection IDs gives clients some assurance that the server received the packet
+and that the Version Negotiation packet was not generated by an off-path
+attacker.

This text is great. Can you use this text above in the VN section of the invariants draft?

> @@ -257,9 +272,12 @@ Version Negotiation packets do not use integrity or confidentiality protection.
 
-The Connection ID field in a Version Negotiation packet contains the Connection
-ID from the packet that was received.  This provides some protection against
-injection of Version Negotiation packets by off-path attackers.
+The Connection ID fields in a Version Negotiation packet contain the Connection
+ID values from the packet that was received by the server, inverted to ensure
+correct routing of the packet toward the client based on the Destination
+Connection ID.  Echoing the value of the client's Destination Connection ID in
+the Source Connection ID field can provide some protection against injection of
+Version Negotiation packets by off-path attackers.

The text in the VN Packet section of the transport draft is great. I would simply use that same text here.

> @@ -614,10 +634,14 @@ off-path attackers.

Is this a single random value for all packets until one is received from teh server? Or is it ok for the client to send a new random in each packet?

> @@ -678,8 +707,10 @@ A Handshake packet uses long headers with a type value of 0x7D.  It is
 used to carry acknowledgments and cryptographic handshake messages from the
 server and client.
 
-The connection ID field in a Handshake packet contains a connection ID
-that is chosen by the server (see {{connection-id}}).
+The Destination Connection ID field in a Handshake packet contains a connection
+ID that is chosen by the recipient of the packet; the Source Connection ID

The server's Initial packet also carries a dest connection ID chosen by the client, right?

 The client can send 0-RTT packets after receiving a Handshake packet
 ({{packet-handshake}}), if that packet does not complete the handshake.  Even if
 the client receives a different connection ID in the Handshake packet, it MUST
-continue to use the connection ID selected by the client for 0-RTT packets, see
+continue to use the same Destination Connection ID for 0-RTT packets, see

What should a receiver do if a subsequent packet is received with a different source connection ID?

remove "field"

remove "field"

+value of the Source Connection ID that they receive.
+
+During the handshake, an endpoint might receive multiple packets with the long
+header, and thus be given multiple opportunities to update the Destination
+Connection ID it sends.  A client MUST only change the value it sends in the
+Destination Connection ID field in response to the first packet of each type
+(Retry, or Handshake) that it receives; a server MUST only change its value
+based on an Initial packet.  This avoids problems that might arise from
+stateless processing of multiple Initial packets producing different connection
+IDs.
+
+Short headers only include the Destination Connection ID and omit the explicit
+length.
+
+The very first packet sent by a client client includes a random value for

too many clients

+1. I can't reason about packet type changes easily, but largest packet number seems robust.

> @@ -1856,9 +1899,23 @@ following layout:
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~~~
 
-A server copies the connection ID field from the packet that triggers the
-stateless reset.  A server omits the connection ID if explicitly configured to
-do so, or if the client packet did not include a connection ID.
+This design ensures that a stateless reset packet is - to the extent possible -
+indistinguishable from a regular packet.
+
+A server generates a random 18-octet Destination Connection ID field.  For a
+client that requires that the server include a connection ID, this will mean
+that this value differs from previous packets with two consequences:

too many "that"s... and this is a bit of a run-on sentence.

> @@ -1856,9 +1899,23 @@ following layout:
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~~~
 
-A server copies the connection ID field from the packet that triggers the
-stateless reset.  A server omits the connection ID if explicitly configured to
-do so, or if the client packet did not include a connection ID.
+This design ensures that a stateless reset packet is - to the extent possible -
+indistinguishable from a regular packet.
+
+A server generates a random 18-octet Destination Connection ID field.  For a
+client that requires that the server include a connection ID, this will mean
+that this value differs from previous packets with two consequences:
+
+* The packet might not reach the client.  If the Destination Connection ID is
+  critical for routing toward the client, then this packet could be incorrectly
+  routed and dropped.  This causes the stateless reset to be ineffective in

remove "and dropped".

> @@ -1856,9 +1899,23 @@ following layout:
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~~~
 
-A server copies the connection ID field from the packet that triggers the
-stateless reset.  A server omits the connection ID if explicitly configured to
-do so, or if the client packet did not include a connection ID.
+This design ensures that a stateless reset packet is - to the extent possible -
+indistinguishable from a regular packet.
+
+A server generates a random 18-octet Destination Connection ID field.  For a
+client that requires that the server include a connection ID, this will mean
+that this value differs from previous packets with two consequences:
+
+* The packet might not reach the client.  If the Destination Connection ID is
+  critical for routing toward the client, then this packet could be incorrectly
+  routed and dropped.  This causes the stateless reset to be ineffective in
+  causing errors to be quickly detected and recovered.  In this case, clients
+  will need to rely on other methods such as timers to detect that the

"other methods - such as timers - to detect"

> -do so, or if the client packet did not include a connection ID.
+This design ensures that a stateless reset packet is - to the extent possible -
+indistinguishable from a regular packet.
+
+A server generates a random 18-octet Destination Connection ID field.  For a
+client that requires that the server include a connection ID, this will mean
+that this value differs from previous packets with two consequences:
+
+* The packet might not reach the client.  If the Destination Connection ID is
+  critical for routing toward the client, then this packet could be incorrectly
+  routed and dropped.  This causes the stateless reset to be ineffective in
+  causing errors to be quickly detected and recovered.  In this case, clients
+  will need to rely on other methods such as timers to detect that the
+  connection has failed.
+
+* The connection ID can be used by entities other than the client to identify

"The randomly generated connection ID"

> +This design ensures that a stateless reset packet is - to the extent possible -
+indistinguishable from a regular packet.
+
+A server generates a random 18-octet Destination Connection ID field.  For a
+client that requires that the server include a connection ID, this will mean
+that this value differs from previous packets with two consequences:
+
+* The packet might not reach the client.  If the Destination Connection ID is
+  critical for routing toward the client, then this packet could be incorrectly
+  routed and dropped.  This causes the stateless reset to be ineffective in
+  causing errors to be quickly detected and recovered.  In this case, clients
+  will need to rely on other methods such as timers to detect that the
+  connection has failed.
+
+* The connection ID can be used by entities other than the client to identify
+  this as a potential stateless reset.  A server that occasionally uses

Capitalize Stateless Reset

> @@ -2350,15 +2401,28 @@ Sequence:
 
+Length:
+
+: An 8-bit unsigned integer containing the length of the connection ID.  Values
+  less than 4 and greater than 18 are invalid and MUST be treated as a
+  connection error of type PROTOCOL_VIOLATION.

It's a bit unfortunate that this length is a different encoding than DSIL and SSIL. Nothing to do about it I suppose.

 Stateless Reset Token:
 
 : A 128-bit value that will be used to for a stateless reset when the associated
   connection ID is used (see {{stateless-reset}}).
 
+An endpoint MUST NOT send this frame if it currently requires that its peer send
+packets with a zero-length Destination Connection ID.  Changing the length of a
+connection ID to or from zero-length makes it very difficult to identify when
+the new connection ID was used.  An endpoint that is sending packets with a a

I don't understand this sentence. Which is the "new connection ID"? I'm inclined to remove this sentence entirely.

 Stateless Reset Token:
 
 : A 128-bit value that will be used to for a stateless reset when the associated
   connection ID is used (see {{stateless-reset}}).
 
+An endpoint MUST NOT send this frame if it currently requires that its peer send
+packets with a zero-length Destination Connection ID.  Changing the length of a
+connection ID to or from zero-length makes it very difficult to identify when
+the new connection ID was used.  An endpoint that is sending packets with a a

too many articles ("with a a")

-- 
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/1151#pullrequestreview-102088652

---

From: MikkelFJ <[email-masked]>
Date: Wed, 07 Mar 2018 21:59:03 +0000 (UTC)

There is a discussion on list about version negotiation attacks by man-on-the-side. One proposed solution was to queue some packets and wait for the best outcome. I'm not so sure what is best, but it overlaps with the considerations in the above text and comments.

-- 
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/1151#discussion_r172998817

---

From: MikkelFJ <[email-masked]>
Date: Wed, 07 Mar 2018 14:02:56 -0800

+based on an Initial packet.  This avoids problems that might arise from
+stateless processing of multiple Initial packets producing different connection
+IDs.
+
+Short headers only include the Destination Connection ID and omit the explicit
+length.
+
+The very first packet sent by a client client includes a random value for
+Destination Connection ID.  The same value MUST be used for all 0-RTT packets
+sent on that connection ({{packet-protected}}).  This randomized value is used
+to determine the handshake packet protection keys (see Section 5.2.2 of
+{{QUIC-TLS}}).
+
+A Version Negotiation ({{packet-version}}) packet MUST use both connection IDs
+selected by the client, inverted to ensure correct routing toward the client.

inverted -> swapped, mirrored, reflected?

-- 
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/1151#pullrequestreview-102115216

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 07 Mar 2018 22:48:14 +0000 (UTC)

siyengar commented on this pull request.

> @@ -178,16 +192,17 @@ version-specific semantics are marked with an X.

+short header does not include the Connection ID Lengths, Source Connection ID,
+or Version fields.

Two sentences like 

"A load balancer may uses variable length connection IDs for different clients in order to grease the length. Even though the short header does not have an explicit length field for the connection ID, a load balancer could encode the length of the connection ID in the connection ID with it's own encoding scheme"

might be useful to clarify the intention of not having length fields in the short headers

-- 
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/1151#pullrequestreview-102128182

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 08 Mar 2018 07:05:37 +0000 (UTC)

kazuho commented on this pull request.

-|                                                               |
-+                     [Connection ID (64)]                      +
-|                                                               |
+|                Destination Connection ID (0..148)           ...

Maybe this needs be corrected to `Destination Connection ID (0/32..144)`?

I see the same issue in the definition of the Stateless Reset (it says 148) and also in short header definition in the invariants draft.

-- 
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/1151#pullrequestreview-102204243

---

From: Martin Thomson <[email-masked]>
Date: Thu, 08 Mar 2018 09:19:54 +0000 (UTC)

d7a18a0  Moar bad numerz

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/7bfa8ab3ae3db5a9ccacc51dc06f614bc3706374..d7a18a031595190971e419dddefd4d8b15b41461

---

From: Martin Thomson <[email-masked]>
Date: Thu, 08 Mar 2018 09:23:20 +0000 (UTC)

dc887e8  My sed-fu is lacking

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/d7a18a031595190971e419dddefd4d8b15b41461..dc887e85a50ece81bfbb87c44dfaf27d91c42f28

---

From: ianswett <[email-masked]>
Date: Thu, 08 Mar 2018 13:56:30 +0000 (UTC)

This seems potentially helpful to me.

-- 
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/1151#discussion_r173163531

---

From: Martin Thomson <[email-masked]>
Date: Thu, 08 Mar 2018 22:39:40 +0000 (UTC)

c6c06e5  For @siyengar/@ianswett regarding connection ID construction

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/dc887e85a50ece81bfbb87c44dfaf27d91c42f28..c6c06e50504ad98dcf4040296804ca7a48121134

---

From: MikkelFJ <[email-masked]>
Date: Thu, 08 Mar 2018 22:49:36 +0000 (UTC)

> @@ -1115,7 +1166,6 @@ language from Section 3 of {{!I-D.ietf-tls-tls13}}.
       initial_max_data(1),
       initial_max_stream_id_bidi(2),
       idle_timeout(3),
-      omit_connection_id(4),
       max_packet_size(5),
       stateless_reset_token(6),
       ack_delay_exponent(7),

Renumber?

-- 
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/1151#pullrequestreview-102490452

---

From: Martin Thomson <[email-masked]>
Date: Thu, 08 Mar 2018 14:50:24 -0800

Largest packet number fails for the simple reason that it might allow for multiple changes.  Lowest packet number works better.  And that's all I'm looking for.  Latching is what we are looking for, not a continuous sequence of changes.

Also, I added a note to ignore packets with different Source Connection ID values.  That deals neatly with the problem where two server instances both attempt to start a connection with you as a result of you sending multiple Initial packets.

-- 
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/1151#discussion_r173317712

---

From: MikkelFJ <[email-masked]>
Date: Thu, 08 Mar 2018 15:33:42 -0800

Just a thought:

Middleware or man-in-the-middle could replace the Initial Random Connection ID. This could be done to direct traffic further into the infrastructure or it could be a DoS attack. This may not be a sufficiently strong case to do anything about it considering all else that is possible to do at this point, and it could even be beneficial on occasion. But there is the option of having the client verifying it via TP or similar - e.g. as part of crypto key derivation - I don't think this is currently the case, though I'm not sure.

-- 
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/1151#issuecomment-371661918

---

From: Martin Thomson <[email-masked]>
Date: Thu, 08 Mar 2018 16:02:56 -0800

3ea70b9  Some review-related changes and polish

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/c6c06e50504ad98dcf4040296804ca7a48121134..3ea70b965749b0525468a09b33b55dcff9eb0347

---

From: Martin Thomson <[email-masked]>
Date: Thu, 08 Mar 2018 16:02:54 -0800

I put that in the transport doc, where I think that sort of exposition is more valuable.

Echoing the source connection ID *might* provide protection, but that assumes that it is high enough entropy.  A value chosen for the purposes of routing is not guaranteed to have entropy (particularly at our new low low minumum of 32 bits).

 Connection ID:

I wanted to define the general concept, not the specific field.

 ~~~

Done.

Oh, I had a whole thing about multiple random values being great for measuring RTT then I remembered that you don't really want to be stuck with trial decryption for the server's first packet.

Servers don't send Initial packets.

I added text that says that you discard those.

Actually I want to add field at least once.  When "Destination Connection ID" is used, it always refers to the field.  "Connection ID" refers to the concept.  Is that OK?

       initial_max_data(1),

Maybe later.

It isn't Germanic anywhere else.

 Stateless Reset Token:

This requirement seemed to need justification, that's all.

-- 
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/1151#discussion_r173318824

---

From: Martin Thomson <[email-masked]>
Date: Fri, 09 Mar 2018 05:33:58 +0000 (UTC)

A server has to treat Initial with suspicion anyway.  Nothing new in that.

-- 
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/1151#issuecomment-371718252

---

From: mirjak <[email-masked]>
Date: Fri, 09 Mar 2018 08:19:29 +0000 (UTC)

or in the manageability statement...?

-- 
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/1151#discussion_r173387818

---

From: mirjak <[email-masked]>
Date: Fri, 09 Mar 2018 00:20:45 -0800

It also probably something to discuss in the manageability statement, no?

-- 
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/1151#issuecomment-371744758

---

From: Martin Thomson <[email-masked]>
Date: Fri, 09 Mar 2018 01:13:06 -0800

I think that text on how to construct a connection ID that has the sorts of properties we care about (unlinkability, etc...) would be good things to add to that sort of draft.

-- 
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/1151#discussion_r173397729

---

From: ianswett <[email-masked]>
Date: Fri, 09 Mar 2018 05:44:01 -0800

During the handshake, an endpoint might receive multiple packets with the long
 header, and thus be given multiple opportunities to update the Destination
 Connection ID it sends.  A client MUST only change the value it sends in the
-Destination Connection ID field in response to the first packet of each type
-(Retry, or Handshake) that it receives; a server MUST only change its value
-based on an Initial packet.  This avoids problems that might arise from
-stateless processing of multiple Initial packets producing different connection
-IDs.
+Destination Connection ID in response to the first packet of each type (Retry,

I'm still concerned this 'first packet of each type' rule ends up being more complex to reason about than the connection ID on the largest processed packet number.

-- 
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/1151#pullrequestreview-102645798

---

From: Nick Banks <[email-masked]>
Date: Fri, 09 Mar 2018 16:07:33 +0000 (UTC)

Generally looks pretty good. Just a few comments.

> @@ -614,10 +634,20 @@ off-path attackers.
 
-The client populates the connection ID field with randomly selected values,
-unless it has received a packet from the server.  If the client has received a
-packet from the server, the connection ID field uses the value provided by the
-server.
+If the client has not previously received a Retry packet from the server, it
+populates the Destination Connection ID field with a randomly selected value.
+This MUST be at least 8 octets in length.  Until a packet is received from the
+server, the client MUST use the same random value unless it also changes the
+Source Connection ID (which effectively starts a new connection attempt).  The
+randomized Destination Connection ID is used to determine packet protection
+keys, but is not included in server packets.
+
+If the client received a Retry packet and is sending a second Initial packet,
+then it sets the Destination Connection ID to the value from the Source
+Connection ID in the Retry packet.

Should it be stated here that if the Retry packet changes the Connection ID, then the packet protection keys should be updated to reflect the new Connection ID, and that the second Initial packet should use those keys?

> @@ -2326,9 +2390,7 @@ The NEW_CONNECTION_ID is as follows:
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Sequence (i)                       ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                                                               |
-+                        Connection ID (64)                     +
-|                                                               |
+|   Length (8)  |          Connection ID (32..144)            ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Does it really make sense to support multiple different length Connection IDs for the same connection? Why not just require all Connection IDs be the same length as the original, and then remove this length field altogether? I'm just thinking of the additional complexity of multiple different length Connection IDs, per connection, would be for hardware offload.

> -When the server receives a Initial packet and decides to proceed with the
-handshake, it chooses a new value for the connection ID and sends that in a
-Retry ({{packet-retry}}) or Handshake ({{packet-handshake}}) packet.  The server
-MAY choose to use the value that the client initially selects.
-
-Once the client receives the connection ID that the server has chosen, it MUST
-use it for all subsequent Handshake ({{packet-handshake}}) and 1-RTT
-({{packet-protected}}) packets but not for 0-RTT packets ({{packet-protected}}).
-
-Server's Version Negotiation ({{packet-version}}) and Retry ({{packet-retry}})
-packets MUST use connection ID selected by the client.
+A connection ID is used to ensure consistent routing of packets.  The long
+header contains two connection IDs: the Destination Connection ID is chosen by
+the recipient of the packet and is used to provide consistent routing; the
+Source Connection ID is used to set the Destination Connection ID used by a
+peer.

Personally, I think changing `a peer` to `the peer` sounds better.

-- 
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/1151#pullrequestreview-102689792

---

From: MikkelFJ <[email-masked]>
Date: Fri, 09 Mar 2018 08:14:07 -0800

I tend to agree. If it were the case that a connection ID was path specific it would be a different matter, but it is required to work for all paths. It could be argued that removing the ability to change length would complicate multi-path design later on - but that is hard to predict.

Another point if view is that a connection ID might be related to infrastructure provided and it might change suddenly for a large number of live connections. But still, it seems a bit contrived.

-- 
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/1151#discussion_r173494362

---

From: mirjak <[email-masked]>
Date: Fri, 09 Mar 2018 11:35:00 -0800

-|                                                               |
-+                     [Connection ID (64)]                      +
-|                                                               |
+|                Destination Connection ID (0..144)           ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Given the dest conn ID is variable length now, can we maybe have the packet number before the connection id in the header?

-- 
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/1151#pullrequestreview-102763657

---

From: Nick Banks <[email-masked]>
Date: Fri, 09 Mar 2018 19:43:41 +0000 (UTC)

-|                                                               |

Packet number isn't an invariant. So it cannot precede any invariant field (Connection ID).

-- 
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/1151#discussion_r173549066

---

From: Mike Bishop <[email-masked]>
Date: Fri, 09 Mar 2018 23:02:53 +0000 (UTC)

-|                                                               |

Technically, it could, but there would have to be an invariant way of determining the offset of the Connection ID field.

-- 
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/1151#discussion_r173590427

---

From: ianswett <[email-masked]>
Date: Fri, 09 Mar 2018 17:58:15 -0800

-|                                                               |

As Nick implied, I think the best order is version, connection ID(s), then packet number, regardless of what we decide on encrypting packet numbers.

-- 
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/1151#discussion_r173607397

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Mar 2018 14:48:57 +0000 (UTC)

4e837b2  Fixups

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/3ea70b965749b0525468a09b33b55dcff9eb0347..4e837b2dae103afa2fe9fb8a8e0db681a175db49

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Mar 2018 03:14:35 -0700

0d51024  Small tweaks regarding the change to dcid

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/4e837b2dae103afa2fe9fb8a8e0db681a175db49..0d51024752d67da74c725ad8df4df12a990099b2

---

From: ianswett <[email-masked]>
Date: Tue, 13 Mar 2018 10:46:50 +0000 (UTC)

ianswett approved this pull request.

-- 
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/1151#pullrequestreview-103376102

---

From: janaiyengar <[email-masked]>
Date: Tue, 13 Mar 2018 04:58:29 -0700

~~~

These first two sentences are redundant. I think you can remove the first sentence.

-- 
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/1151#pullrequestreview-103397488

---

From: janaiyengar <[email-masked]>
Date: Tue, 13 Mar 2018 12:22:02 +0000 (UTC)

Just a few minor nits

+During the handshake, packets with the long header are used to establish the
+connection ID that each endpoint uses.  Each endpoint uses the Source Connection
+ID field to specify the connection ID that is used in the Destination Connection
+ID field of packets being sent to them.  Upon receiving a packet, each endpoint
+sets the Destination Connection ID it sends to match the value of the Source
+Connection ID that they receive.
+
+During the handshake, an endpoint might receive multiple packets with the long
+header, and thus be given multiple opportunities to update the Destination
+Connection ID it sends.  A client MUST only change the value it sends in the
+Destination Connection ID in response to the first packet of each type it
+receives from the server (Retry or Handshake); a server MUST set its value based
+on the Initial packet.  Any additional changes are not permitted; subsequent
+packets of those types include a different Source Connection ID, they MUST be
+discarded.  This avoids problems that might arise from stateless processing of

This sentence needs grammar. I think you might be missing an "if" in "if subsequent packets of those types ..."

> +ID field of packets being sent to them.  Upon receiving a packet, each endpoint
+sets the Destination Connection ID it sends to match the value of the Source
+Connection ID that they receive.
+
+During the handshake, an endpoint might receive multiple packets with the long
+header, and thus be given multiple opportunities to update the Destination
+Connection ID it sends.  A client MUST only change the value it sends in the
+Destination Connection ID in response to the first packet of each type it
+receives from the server (Retry or Handshake); a server MUST set its value based
+on the Initial packet.  Any additional changes are not permitted; subsequent
+packets of those types include a different Source Connection ID, they MUST be
+discarded.  This avoids problems that might arise from stateless processing of
+multiple Initial packets producing different connection IDs.
+
+Short headers only include the Destination Connection ID and omit the explicit
+length.  The length of the Destination Connecton ID field is expected to be

s/Connecton/Connection/

+Connection ID it sends.  A client MUST only change the value it sends in the
+Destination Connection ID in response to the first packet of each type it
+receives from the server (Retry or Handshake); a server MUST set its value based
+on the Initial packet.  Any additional changes are not permitted; subsequent
+packets of those types include a different Source Connection ID, they MUST be
+discarded.  This avoids problems that might arise from stateless processing of
+multiple Initial packets producing different connection IDs.
+
+Short headers only include the Destination Connection ID and omit the explicit
+length.  The length of the Destination Connecton ID field is expected to be
+known to endpoints.  Endpoints with a load balancer that uses a connection ID
+can agree to a fixed or minimum length for connection IDs with necessary
+information in the fixed portion.  If that fixed portion instead encodes an
+explicit length, the entire connection ID can vary in length and still be used
+by the load balancer.

This part about load balancers is confusing. I would at least make it a separate paragraph. I do wonder if this is necessary ... it's basically a suggestion for how load balancers are implemented, and I would be more explicit about that in this para. Here's a suggested rephrasing:

"Endpoints using a connection-ID based load balancer could agree with the load balancer on a fixed or minimum length and on an encoding for connection IDs. This fixed portion could encode an explicit length, which allows the entire connection ID to vary in length and still be used by the load balancer."

> @@ -901,33 +958,30 @@ Incoming packets are classified on receipt.  Packets can either be associated
 with an existing connection, or - for servers - potentially create a new
 connection.
 
-Hosts try to associate the packet with an existing connection. If the
-packet has a connection ID corresponding to an existing connection, QUIC
+Hosts try to associate the packet with an existing connection. If the packet has

s/the packet/a packet/

 ### Client Packet Handling {#client-pkt-handling}
 
-If a client receives a packet with an unknown connection ID, and it matches
-the tuple of a connection with no received packets, it is a reply to an
-Initial packet with a server-generated connection ID and will be processed
-accordingly. Clients SHOULD discard any packets with new connection IDs that
-do not meet these criteria.
-
-Note that a successfully associated packet may be a Version Negotiation
-packet, which is handled in accordance with {{handle-vn}}.
+Valid packets sent to clients always include a Destination Connection ID that
+matches the value the client selects.  Clients that choose to receive
+zero-length connection IDs can use the address/port tuple to identify a
+connection.  Packets that don't match an existing connection can be discarded.

s/can be discarded/MAY be discarded/

-- 
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/1151#pullrequestreview-103400863

---

From: janaiyengar <[email-masked]>
Date: Tue, 13 Mar 2018 12:54:07 +0000 (UTC)

janaiyengar approved this pull request.

-- 
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/1151#pullrequestreview-103414003

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Mar 2018 12:58:37 +0000 (UTC)

9d1512f  Jana's improvements

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1151/files/0d51024752d67da74c725ad8df4df12a990099b2..9d1512f32b0c8a2db2ee64d7ea6e66737ac1224e

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Mar 2018 06:00:50 -0700

Merged #1151.

-- 
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/1151#event-1518511008