quicwg / load-balancers

In-progress version of draft-ietf-quic-load-balancers

Home Page:https://quicwg.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Server actions and load-balancer actions may not be right

martinthomson opened this issue · comments

When encrypting, you usually have an encryption routine and a decryption routine. This doesn't. The server apparently doesn't decrypt. Maybe it just remembers the value it got, but you should say that.

I would define encryption and decryption routines, then explain a few optimizations:

  1. The server can remember connection IDs (it has to remember lots of other stuff, so this is no big deal) so it doesn't need to do any decryption.
  2. The load balancer can stop one step short of the full decryption routine if it only needs what is in the left-hand piece.

This is probably a better basis then for talking about the extension stuff, like where the server ID is a process ID or there are multiple layers of routing going on.

I'm not sure I understand.

  1. Remembering issued connection IDs (or somehow recovering the context?) is already an RFC9000 requirement, so I'm not sure what else needs to be said here.

  2. This is already in Sec 4.4.2

You've put your finger on the fact that this is a one-way communication channel from server to load balancer. That's somewhat useful to understanding the security properties, but I'm not sure what kind of change would scratch your itch.

Let me try again: you don't describe how a LB might recover the information that a server encrypts. This might be OK (for the stated reasons), but not always.

isn't this Section 4.4? I'm not sure what you're getting at.

OK, I have no idea what I was originally thinking now. There are routines in 4.4.x (maybe not very precise ones, but I can understand them). Maybe just let this one go.