Subject: draft-duke-quic-load-balancers-00.txt

From: Martin Duke <[email-masked]>
Date: Mon, 12 Feb 2018 14:11:03 -0800

Based on conversations in Melbourne, I posted a straw man for a standard
way for load balancers and servers to coordinate on routable, unlinkable
connection IDs.

Datatracker:
https://datatracker.ietf.org/doc/draft-duke-quic-load-balancers/
Github: https://github.com/martinduke/draft-duke-quic-load-balancers

There's nothing earthshaking here: we use DTLS for authentication and
encryption, and have a few very simple UDP messages to keep the conn IDs
synced. The draft isn't very long.

I'll incorporate variable length connection IDs, etc, when and if they
enter the mainline. I'm certainly interested if this meets the needs of the
people actively looking for a solution in this space.

---

From: Erik Kline <[email-masked]>
Date: Mon, 12 Feb 2018 17:34:46 -0800

I wasn't in Melbourne, but I'm curious: why not specify a protocol
over QUIC itself?

In my experience, load balancers maintain connections to ~essentially~
all the backends for which they balance.  Could this protocol instead
be mapped onto streams in a QUIC connection between LB and backend?
If so, liveness via PING frames could be incorporated.

For security purposes, IP Tries of whitelisted LB IPs and/or running
this kind of thing over connections to backends on non-standard ports
is something I know is done.

On 12 February 2018 at 14:11, Martin Duke <[email-masked]> wrote:
> Based on conversations in Melbourne, I posted a straw man for a standard way
> for load balancers and servers to coordinate on routable, unlinkable
> connection IDs.
>
> Datatracker:
> I'll incorporate variable length connection IDs, etc, when and if they enter
> the mainline. I'm certainly interested if this meets the needs of the people
> actively looking for a solution in this space.
>
>
>

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 13 Feb 2018 16:54:54 -0500

> I wasn't in Melbourne, but I'm curious: why not specify a protocol

+1: As I was reading the draft, I was wondering the same thing.

  - Dmitri.

---

From: Martin Duke <[email-masked]>
Date: Tue, 13 Feb 2018 19:49:08 -0800

Oops, I didn't reply all. Repeated below:

Hi Erik,

That would certainly work. In TCP the load balancers we make have
"monitors" that open up TCP connections periodically with servers to make
sure they're there and functioning.

My thought was that a full-fledged QUIC client implementation might be a
little heavyweight for some of these devices. Certainly, if you have an
existing Linux L4 load balancer and are looking to write some lightweight
code to support QUIC, you probably already have the DTLS APIs you need
there. But I am perfectly happy to go with the consensus here.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 14 Feb 2018 06:38:59 +0000

Relatively minor nit:

“A representative encoding that meets these requirements might
   concatenate the server's IPv4 address and a monotonically increasing
   sequence number, and then encrypt the result to obtain the
   connection ID.”

You may want to consider a nonce as an input to your crypto function to detect attacks via forged CIDs.  In case the same backend server maybe used for multiple Virtual IPs, you may also want to include the Virtual IP (and destination port) as an input to the crypto function to increase the number of possible unique CIDs generated (IPv4 and the nonce may leave you with few extra bits, unless 128-bit CID is used, so find extra bits where you can).

From: Martin Duke [mailto:[email-masked]]
Sent: Monday, February 12, 2018 5:11 PM
To: IETF QUIC WG <[email-masked]>
Subject: draft-duke-quic-load-balancers-00.txt

Based on conversations in Melbourne, I posted a straw man for a standard way for load balancers and servers to coordinate on routable, unlinkable connection IDs.

Datatracker: https://datatracker.ietf.org/doc/draft-duke-quic-load-balancers/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dduke-2Dquic-2Dload-2Dbalancers_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=PtSeY0IPCpSZaH_c2HNxbMGPFiJVlgy-o1aCKEnI_v8&s=iqBILT7oIrsafQc7-Cw_gm3I040JmyIbrlnDAc4b9qw&e=>
Github: https://github.com/martinduke/draft-duke-quic-load-balancers<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_martinduke_draft-2Dduke-2Dquic-2Dload-2Dbalancers&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=PtSeY0IPCpSZaH_c2HNxbMGPFiJVlgy-o1aCKEnI_v8&s=RiCfUMP25oJm-L-e9q1vVzgtkwnSn7P2wdC5Q-7ByGM&e=>

There's nothing earthshaking here: we use DTLS for authentication and encryption, and have a few very simple UDP messages to keep the conn IDs synced. The draft isn't very long.

I'll incorporate variable length connection IDs, etc, when and if they enter the mainline. I'm certainly interested if this meets the needs of the people actively looking for a solution in this space.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 14 Feb 2018 01:16:22 -0800

I was also wondering about why not using QUIC, but a load balancer does not
need to understand QUIC to route QUIC, especially not with this protocol.

But it complicates QUIC endpoints having to deal with another crypto
transport mechanism.
I don’t think the argument of keeping routers simpler is very strong - it
may be true short term - but eventually routers will understand QUIC.

A downside to using QUIC is that routers may stick to an old version of
QUIC for a long time.

One could imagine a set of central control servers providing CID’s rather
than the QUIC server itself - this would remove some of the versioning
concern, but then bother router and QUIC server would have to connect to
the central control system. This isn’t so different from a MQTT
configuration and would simplify the configuration matrix.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 14 February 2018 at 04.49.17, Martin Duke ([email-masked])
wrote:

Hi Erik,