Subject: [quicwg/base-drafts] Segmented Packet Numbers (#1105)

From: MikkelFJ <[email-masked]>
Date: Sat, 10 Feb 2018 19:05:00 +0000 (UTC)

There is a long ongoing discussion on the mailing list about packet number encryption.
Here is proposal extracted from that discussion which does not involve packet number encryption.

NOTE: this is not a consensus and I am not personally convinced this is best option, but it is one option.

The packet number is segmented in a lower 32-bit counter (nonce) and an upper 30+bit path identifier (PID). The packet number is globally unique across all paths and is used directly in ACK frames, but it is never transmitted in clear text on the wire. The lower 32-bit nonce is transmitted in clear text in place of the packet number as a varint. The nonce starts at zero and increments for every packet sent on a given path and a path cease to be valid no later than when the counter reaches 2^32-1. The PID starts at 0 and is incremented for every new path in use. It is not strictly required to increment by one, but each path MUST have a unique PID that is known to both enpoints. There must be a mapping from connection ID to a PID pair.

This solution provides dense ACK ranges only having gaps where a new path is in use. The packet number directly identifies that path the packet was transmitted on which could help congestion control.

It may be relevant to allow more than 30 bits for the PID range because the packet number space is exhausted relatively fast, but then the packet number cannot be encoded in a 64 bit varint.

It is also proposed to use asymmetric CID's so there is a 1-1 mapping from PID to CID, but it is not strictly necessary. (https://github.com/quicwg/base-drafts/issues/1089)

Additionally, if each path is given two PID's differing only by only the lower bit, this can be used instead of skipping packet numbers in gapless ACK attack mitigation (https://github.com/quicwg/base-drafts/issues/1092). If the CID is absent, a bit in the header can select which PID is in use. 

The major upside to the approach

1. Avoids PN encryption which could add an estimated 18% overhead for low-latencey applications.
2. AEAD IV (nonce/packetnumber) not in clear text affects hardware offload and pipelined operation.
3. Reduces ACK fragmentation.
4. Simplifies per path network monitoring
5. Easily handles multi-path.
6. Congenstion control might be easier to handle across paths because the PN identifies its path directly.

The major downside to the approach:

1. per path counters could be abused to re-sort packets that shoudn't be (increased latency), but tunneling could do that anyway, so...
2. The packet number space is exhausted faster when constrained to 64 bit varints.

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

---

From: MikkelFJ <[email-masked]>
Date: Sat, 10 Feb 2018 19:42:15 +0000 (UTC)

A variation of this theme involves nonce encryption which is similar to already proposed packet number encryption, except it is faster:

A derived path encryption key is used to produce a random number sequence in CTR mode (Path PRNG). Each counter increment produces 16 random bytes (the symmetric crypto block size). The nonce is var length encoded and only as many bytes as needed is drawn the path PRNG. The nonce is XOR'ed with these bytes.

With AES-NI this leads to a 4-fold increase in per block crypto performance due to parallel operation with a pregenerated stream of 64 bytes at a time. Because much less than a block size is needed, (at most 1/4 block), this further leads to a 4-fold increase, so we improve the crypto with a factor 16.

This results in a nonce crypto overhead of only a few nano seconds per packet, which is sufficient to alleviate low-latency concerns.

However, it still prevents some crypto pipelining of packets because the nonce is not in clear text, but it does prevent ossficiation of the nonce 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/issues/1105#issuecomment-364683705

---

From: MikkelFJ <[email-masked]>
Date: Sat, 10 Feb 2018 11:56:47 -0800

A futher variation is to use the proposed packet number encryption schema (https://github.com/quicwg/base-drafts/pull/1079) but still use segmented packet numbers to help per path loss management.

-- 
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/1105#issuecomment-364685469

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Feb 2018 02:48:34 +0000 (UTC)

I think that this would be better expressed in terms of an extant problem.  We have plenty of open issues on this topic 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/issues/1105#issuecomment-367196452

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Feb 2018 02:48:34 +0000 (UTC)

Closed #1105.

-- 
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/1105#event-1483813463