Subject: Re: [quicwg/base-drafts] Packet number transform should be negotiated (#1296)

From: bobdug <[email-masked]>
Date: Mon, 04 Jun 2018 17:56:28 -0700

With the rapid increase in Ethernet and bus speeds, the need for hardware offload has become critical in encryption applications.  Besides the reasons stated by @pravb, from this hardware vendor’s point of view, requiring packet number encryption makes the QUIC protocol less friendly to offload.  It requires an added pass through the hardware crypto engine and depending on the hardware implementation, this can result in a loss of performance or additional complexity.  It would hence be ideal to make this feature optional.  That would have the added benefit of allowing the hardware ecosystem time to mature to support this feature, especially at higher speeds.

-- 
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/1296#issuecomment-394546103

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 05 Jun 2018 09:22:00 -0700

@martinthomson I see that the issue is on the agenda to be discussed. PNE aims to solve two problems - ossification and unlinkability for voluntary migration. The primary motivation for making it optional is that there are deployments where one or both of these problems do not exist. Using versions does not help if the version number is not standardized and it also effectively halves the version space. I would prefer that we use a transport parameter for this. Always encrypting PNE for long headers is not a concern since the TLS handshake is already many orders of magnitude costlier. The primary concern around PNE is performance and hardware offloads, so making it optional for short headers solves this issue and can be negotiated in transport parameters. 

-- 
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/1296#issuecomment-394772384

---

From: borisPis <[email-masked]>
Date: Sat, 09 Jun 2018 23:38:28 -0700

>From another hardware vendor's perspective. It is not only additional complexity or performance loss. QUIC will be the only protocol to require a second pass over encrypted data. It means that this hardware circuitry must be implemented exclusively for QUIC, and it is unlikely to be reused.

IPsec has plaintext sequence numbers, and IPsec crypto offload in the data path increases performance by about 5x. Is there any indication of IPsec sequence numbers being ossified? I would assume that QUIC sequence numbers wouldn't be any different.

-- 
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/1296#issuecomment-396024817

---

From: janaiyengar <[email-masked]>
Date: Sun, 10 Jun 2018 10:26:14 -0700

IPsec isn't exactly suffering problems that come with being wildly
successful.
PNE solves at least two problems; ossification is just one of them, linkage
across connection migration is the other one.

On Sat, Jun 9, 2018 at 11:38 PM borisPis <[email-masked]> wrote:

> From another hardware vendor's perspective. It is not only additional
> complexity or performance loss. QUIC will be the only protocol to require a
> second pass over encrypted data. It means that this hardware circuitry must
> be implemented exclusively for QUIC, and it is unlikely to be reused.
>
> IPsec has plaintext sequence numbers, and IPsec crypto offload in the data
> path increases performance by about 5x. Is there any indication of IPsec
> sequence numbers being ossified? I would assume that QUIC sequence numbers
> wouldn't be any different.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1296#issuecomment-396024817>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AKjg1N2sQqW6b6EEKchUhCWVsolNLR1Xks5t7L7kgaJpZM4TY4b4>
> .
>

-- 
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/1296#issuecomment-396066372

---

From: Praveen Balasubramanian <[email-masked]>
Date: Sun, 10 Jun 2018 11:40:50 -0700

Connection migration cannot be incrementally deployed without changing load balancers and not all QUIC connections need migration support. So one could limit PNE to connections needing gratuitous migration by adding negotiation. Ossification is a concern and I would prefer lower cost alternatives compared to encryption if possible. That said, my main interest in adding the transport parameter is for backend connections and connections within DC with neither of these two problems exist. 

-- 
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/1296#issuecomment-396071399