QUIC-LB Packets Should use Encryption Instead of Token

[nibanks]

Currently, QUIC-LB packets use a Token to prove authenticity (in both directions). This provides protection from off path attackers (in the backend network) but not man-on-the-side or man-in-the-middle attackers. Both of those attackers can see the Token and then create their own QUIC-LB packets to reconfigure back end servers.

If encryption is used instead, then the packets cannot be tampered with or spoofed. The best attacks that man-on-the-side attackers can do is try to interrupt each individual connection (a lot of work compared to sending 1 QUIC-LB packet to misconfigure a backend server). Man-in-the-middle can still drop any packets they want, but nothing can be done to protect against that.

More over, I think we should explicitly default the key used to a null (all zeros) key. In deployments where the entire backend is completely controlled, and there is no fear of attack, there would be no need to configure the encryption key out of band, and the default would be used.

[martinduke]

While I agree that the computational cost of this proposal is not high, I like the fact that the current spec allows a load balancer to implement no crypto whatsoever. Do other people think that this is important?

[nibanks]

If the backend environment is truly untrusted enough to warrant authentication, then it seems to me that authentication without security is pointless. Either you have both or neither.

[martinduke]

It depends on what kind of attack you're dealing with. The authentication blocks injection of messages by off-path attackers to break routing. Encryption is about protection from on-path attackers. By definition, these already can observe the mapping; encryption would prevent them from injecting bogus routing info, I suppose.

[nibanks]

From previous mail threads there were scenarios, apparently, where the backend is completely untrusted. In that case, encryption is your only option. If you really want to continue to support a token model, we could have a bit in the header that indicates token or encryption, but I feel that would make this unnecessarily complicated.

[martinduke]

I would really like the opinion of others about this, but if you have a design in mind for this you could consider a PR.

If we discuss this in Bangkok, I would like to summarize your position by explaining the attack you hope to defeat. Is it that an on-path, inside attacker could break routing by injecting bogus packets, and that this is more efficient that injecting packets into QUIC handshakes

I confess that I have no problem with the idea of encrypting and decrypting these packets. If, as a cloud provider, you are fine with your LBs doing this, perhaps my fear of driving away LB vendors is overblown.

[dtikhonov]

I like the fact that the current spec allows a load balancer to implement no crypto whatsoever.

So do I. The token is not a defense against inside on-path attackers. The draft states:

The Token [...] is used to verify that the sender is not an inside off-path attacker.

Are inside on-path attackers a consideration? I was under impression that the backend network is more or less trusted.

[nibanks]

When the LB group was first started I asked whether backends could be trusted or not and this is the response I got:

From: Artyom Gavrichenkov Sent: Friday, July 13, 2018 7:06:19 AM To: Nick Banks Subject: Re: Welcome to the QUIC Load Balancer Group!

Good day, Nick,

One use case here is a service which is split across multiple server farms with unicast IP addresses hidden behind an anycast IP for DDoS protection.

It is theoretically possible to still use SPA, assigning a separate anycast IP address for each and every hidden downstream IP address for 1-to-1 translation, and one more for an SPA distribution point, but this requires allocating (2*n+1) IP addresses to protect each such service, compared to (n+1) in the load balancing scenario. With IPv4, this is a huge issue.

чт, 12 июл. 2018 г., 20:53 Nick Banks Hello Artyom,

Can you give me any more information on the setup/topology for the scenario of an untrusted network between the load balancer and backend server? Is this over the open internet? If so, I don’t think you should be doing load balancing, but instead using the Server’s Preferred Address feature instead.

Thanks, Nick

From: Artyom Gavrichenkov Sent: Monday, July 9, 2018 4:37 AM To: Nick Banks Subject: Re: Welcome to the QUIC Load Balancer Group!

Good day, Nick,

It depends heavily on your definition of "immediately". On the day QUIC is released and industry starts using it, such a use case would appear very soon. We do have it already with HTTP/HTTPS.

вс, 8 июл. 2018 г., 6:20 Nick Banks I have a related question:

Does anyone have an immediate goal to support load balancing QUIC where there is no implied trust in the path between the backend server and the load balancer? If not, we could make it a non-goal for V1 of the load balancing design to support untrusted environments.

Nick

So I have been going under the assumption that the design must handle untrusted backend environments.

[martinduke]

Yes, the design does not assume a trusted back-end. However, an on-path inside attacker can obtain the server mapping by looking at IP addresses, so I did not see a need to have any effort to defeat these.

Nick's argument, IIUC, is that an on-path inside attacker can not only get the mapping, but break routing by sniffing the token and injecting a bogus QUIC-LB packet. This is much more efficient than breaking every QUIC handshake as it goes by.

I feel like this is a small difference. If no LB vendors are actually concerned about encrypting a tiny number of QUIC-LB packets, I see no reason to be too cute with tokens vs. encryption. (that is, I'm fine with @nibanks submitting a PR to change it).

[martinduke]

Obviated by deletion of in-band protocol.