RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)

["Lubashev, Igor" <[e-mail]>]

Ø  Or another way of solving the issue will be to always route the packet based on CID, then forward the packet between the endpoints behind the load balancer.

This would not really work for a global load balancer – the one capable of forwarding across a continent to a different anycast pop (due to client’s change in attachment point or BGP reconvergence).

Moreover, the routing info in a random CID may look “syntactically valid” but be “semantically invalid” (pointing at a dead path or a set of servers not capable of serving QUIC traffic).


From: Lubashev, Igor [mailto:ilubashe=[e-mail]]
Sent: Thursday, April 05, 2018 2:21 PM
To: Kazuho Oku <[e-mail]>
Cc: Mirja Kühlewind <[e-mail]>; Christian Huitema <[e-mail]>; Mike Bishop <[e-mail]>; Mikkel Fahnøe Jørgensen <[e-mail]>; IETF QUIC WG <[e-mail]>; Frederick Kautz <[e-mail]>
Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)


  *   It would not, *if* the stateless load balancer can AES-decrypt the packet (using the key derived from the packet header) to see if the packet is in fact a initial packet.

Would not it need to first decide that the CID in the packet is unknown (which means stateful)?  It would need to do some integrity check on CID, which would require a large nonce to avoid accidentally classifying a random CID as valid, because the cost of this mistake can be very large for the client (see below).


  *   Or another way of solving the issue will be to always route the packet based on CID, then forward the packet between the endpoints behind the load balancer.

This would not really work for a global load balancer – the one capable of forwarding across a continent to a different anycast pop (due to client’s change in attachment point or BGP reconvergence).



From: Kazuho Oku [mailto:[e-mail]]
Sent: Thursday, April 05, 2018 2:09 PM
To: Lubashev, Igor <[e-mail]<mailto:[e-mail]>>
Cc: Mikkel Fahnøe Jørgensen <[e-mail]<mailto:[e-mail]>>; Mike Bishop <[e-mail]<mailto:[e-mail]>>; Christian Huitema <[e-mail]<mailto:[e-mail]>>; IETF QUIC WG <[e-mail]<mailto:[e-mail]>>; Mirja Kühlewind <[e-mail]<mailto:[e-mail]>>; Frederick Kautz <[e-mail]<mailto:[e-mail]>>
Subject: Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)



2018-04-06 2:59 GMT+09:00 Lubashev, Igor <[e-mail]<mailto:[e-mail]>>:

  *   I'd prefer making handshake packets indistinguishable from short header packets. In essence, you move the flags of the long header inside the AEAD-protected area. An endpoint that receives a packet carrying a CID that does not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful reset if the trial-decryption fails.
This change would wreck stateless load balancers that rely on being able to distinguish CI packets (and route them based on IPs) from other packets (and route them based on CID).

It would not, *if* the stateless load balancer can AES-decrypt the packet (using the key derived from the packet header) to see if the packet is in fact a initial packet. Or another way of solving the issue will be to always route the packet based on CID, then forward the packet between the endpoints behind the load balancer.

I agree that it would be a no-deal for stateless load balancers that are incapable of doing such things.


- Igor

From: Mikkel Fahnøe Jørgensen [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, April 05, 2018 1:31 PM
To: Mike Bishop <[e-mail]<mailto:[e-mail]>>; Christian Huitema <[e-mail]<mailto:[e-mail]>>; Kazuho Oku <[e-mail]<mailto:[e-mail]>>
Cc: IETF QUIC WG <[e-mail]<mailto:[e-mail]>>; Mirja Kühlewind <[e-mail]<mailto:[e-mail]>>; Frederick Kautz <[e-mail]<mailto:[e-mail]>>
Subject: RE: Privacy holes (was: Re: Getting to consensus on packet number encryption)

Hi


On 5 April 2018 at 19.27.24, Mike Bishop ([e-mail]<mailto:[e-mail]>) wrote:

 An endpoint that receives a packet carrying a CID that does not belong to any known connection trial-decrypts the packet as a initial packet and handles it as a connection initiation, or sends a stateful reset if the trial-decryption fails.

I can see hiding things may be a good thing, but having to trial decrypt all unknown packets as potentially creating a huge load, unless you combine it with my proposal to add a checksum to the encrypted packet number so you only need one crypto block on average to reject random packet content.

It won’t solve all DDoS, but it will help. Forcing trial decryption fo the full packet makes me a bit anxious.



Mikkel





--
Kazuho Oku