Right, thanks for clarifying. I was reading over the text several more times and I slowly came to the same conclusion as you have explained below.
So the problem with state table is if you send a lot of small random garbage packets to the LB. It’s probably expensive for one endpoint, but easy to DDOS. The other problem is sending a lot of the same packet to DDOS a target server, but that is probably unavoidable regardless of algorithm, except perhaps this: If the DCID is not understood by the LB, the LB chooses a random target server but does not store any state. The expectation being that the server will assign its own DCID on the return path. The LB will understand how to route the server assigned DCID. The problem being that this generally requires shared state - which Low-Config aims to avoid in exchange of local state. Perhaps there is a middleground where initial packets are routed stateless and semi-randomly, but the server assigned DCID is computed using prime multiplication instead of cryptographic primitives if performance or complexity is a concern. Note that lookups in Gigabyte tables are likely significantly slower than AES block encryption, especially if AES can be pipelined, due to memory access latency. Therefore I would not expect the proposed Low-Config solution to be faster for heavily loaded loadbalancers, especially under attack. Mikkel > On 12 Jan 2021, at 00.32, Martin Duke <[email protected]> wrote: > > Hi Mikkel, > > Answers inline > > On Mon, Jan 11, 2021 at 3:19 PM Mikkel Fahnøe Jørgensen <[email protected] > <mailto:[email protected]>> wrote: > I’m trying to read through the LB document that I haven’t looked at for quite > a while. It isn’t very clear to me, I am sorry to say. > > I do not understand why the highest configuration value is chosen since this > value would eventually wrap? Is there an implied wider config value where > only the lower bits are visible, similar to packet numbers? > > In general, client-generated CIDs might come in with config rotation bits > that don't correspond to an existing config. For the other algorithms, it's > randomly routed and after that the server-generated CID is used. But for this > algorithm, the server needs to extract a server ID somehow. If there's one > configuration, that's simple. If there's more than one, there has to be > deterministic behavior. The choice to use the highest is completely > arbitrary; I'm open to other suggestions that have better properties. > > Also, I do not understand how the server receives the assigned SID. Is the > ODCID replaced in first packets, or are the packets unmodified, or is the SID > prefixed the real packet? > > No, any 8-byte CID will contain a server ID. So the client, in effect, > generates an SID and the load balancer decides which server will get it (and > then use that SID in the future) > > If the ODCID is modified, what about message authentication, also in future > versions and with possible shared keys? > > It is not modified, see above > > Is the state table affected by the clients choice of ODCID (think abuse)? > > Yes, if CIDs are chosen to maximize the number of different SIDs, that will > grow the table. IMO this isn't substantially different from randomly chosen > CIDs, which is of course normal behavior. >
