Subject: [quicwg/base-drafts] Suggest linking CCID to SCID (#637)

From: MikkelFJ <[email-masked]>
Date: Sun, 18 Jun 2017 03:21:19 -0700

Suggest that all unprocted server packets reflect both SCID and CCID until client sends at least one packet with SCID, or until 1RTT handshake.
```

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)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                       Connection ID (64)                      +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                CCID (64)                      +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
```

This will

- make clear text handshake robust against address spoofing.
- allow client side load balancers to route packets to client side backend.
- simplify implementations by always having an ID to associate the connection with.connection.
- allow handshake error packets that are robust against adversarial off-path reset attempts.
- allow implementations to not rely on unique 5-tuples when both endpoints agree (e.g. high speed net map implementations), and to easier reject suspicious on-path packets.
- reduce reliance on robustness of NAT middle boxes.

Note: a client could embed in the CCID in handshake data on stream 0, but the handshake can span multiple packets and will not support client side load balancers. The CCID field can be ommitted for certain packet types such as client initial and stateless retry, but it might not be worth the complexity - and then CCID can reflect the Connection ID.

The extra CCID should be removed for all 1RTT protected communication. Path migration should also provide a similar linkage from old to new, but it must be in encrypted form.

Some concerns are already being addressed by reflecting the packet number and / or the CCID in some flows, but it is does not cover all cases in a unified form.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/637

---

From: MikkelFJ <[email-masked]>
Date: Sun, 18 Jun 2017 03:40:09 -0700

An alternative option might be to keep using CCID as the Connection ID in both directions until 1RTT handshake where a new SCID is provided in the handshake encrypted. This would avoid the extra CCID field but still deal with all of the above points, I believe.

However, it is not clear to if there are reasons to have SCID online before handshake.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/637#issuecomment-309269468

---

From: ekr <[email-masked]>
Date: Sun, 18 Jun 2017 06:07:47 -0700

As I indicated earlier, I would prefer to fold the CCID into a MAC rather than reflect it. That's more consistent with our general idiom for preventing packet injection, which is the authentication tag.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/637#issuecomment-309276716

---

From: MikkelFJ <[email-masked]>
Date: Sun, 18 Jun 2017 10:58:38 -0700

Adding CCID to the MAC would solve some of the issues listed without taking up additional space.

However, it is fairly simple to support a high number of client requests from a single port using the above proposal. This could avoid issues with ephemeral port exhaustion and would allow for a simple OS interface in high volume configurations.

"Limits Implied by the Ephemeral Port Range"
http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/637#issuecomment-309292587

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Jun 2017 15:58:09 -0700

Closed #637.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/637#event-1131949057

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Jun 2017 15:58:10 -0700

After discussing with editors, we're getting too many issues that suggest a particular design.  Rather than phrase issues as suggestions for designs, we need to have the underlying problem identified.  That way we avoid opening multiple issues for the same actual problem and we can discuss alternative designs in the one place.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/637#issuecomment-309915171