Re: Packet number encryption negotiation

[Christian Huitema <[e-mail]>]

Please don't mix two separate issues, Header Protection and mixing of 
the DCID sequence number in the IV when doing multipath. The latter is 
for ensuring the uniqueness of the nonce when using separate number 
spaces for each path. It does make hardware offload more complex, but 
not in the same way as Header Protection.

We did discuss the impact of adding 32 more bits in the IV on hardware 
encryption last year, before deciding to abandon the "simple multipath" 
option and go for the "number space per DCID" option. At the time, the 
impact on hardware encryption was considered manageable.

-- Christian Huitema

On 3/8/2023 2:02 PM, Ian Swett wrote:
> Speaking as an individual, I would like to see this discussed more in the
> QUIC WG, possibly in Yokohama.
> 
> Header Protection/PNE definitely helps with ossification, but when compared
> with highly optimized and sometimes non-standard networking protocols, QUIC
> without PNE is a huge improvement.  In a datacenter environment,
> ossification is a concern, but it's rarely due to the wire image.
> 
> Ian
> 
> On Wed, Mar 8, 2023 at 8:02 AM Boris Pismenny <[e-mail]>
> wrote:
> 
>>
>>>
>>>> What I want to add is that you should consider multipath QUIC when you
>>>> design your hardware. It affects the AEAD nonce generation.
>>>>
>>>> Regular, unipath, QUIC sets the top 34 bits of the packet number to zero
>>>> when generating the nonce. In the upcoming multipath extension, the top 32
>>>> bits can be set to non-zero values.
>>>>
>>>> https://www.rfc-editor.org/rfc/rfc9001.html#name-aead-usage
>>>>
>>>> https://www.ietf.org/archive/id/draft-ietf-quic-multipath-03.html#name-packet-protection-for-quic
>>>> -
>>>>
>>>
>>> Thanks for the pointers, I've encountered multi-path QUIC on another
>>> discussion about QUIC offload (
>>> https://github.com/microsoft/quic-offloads/issues/9#issuecomment-1305823308
>>> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-88d69ea0099e1120&q=1&e=e27b5977-1b4e-4703-957b-3236511a2976&u=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fquic-offloads%2Fissues%2F9%23issuecomment-1305823308>).
>>> IIUC, the main challenge with multipath will be to synchronize receive side
>>> NIC offloads when two NICs are being used in parallel to carry the same
>>> flow's packet number space.
>>>
>>>
>>> There will only be separate packet number spaces for each path in the
>>> upcoming version of the multipath draft. Then I guess you will not have the
>>> problem you mention above. If you still would, why is this not a problem
>>> with regular unipath QUIC?
>>>
>>>
>> Indeed, this can also happen with unipath QUIC. In both cases, it is
>> probably not the common case. But, if it does happen, it will make
>> offloading more challenging.
>>
>