Re: DDoS For this to be a new DDoS vector, the lookup has to be more expensive than a crypto algorithm. Ian says it isn't; a binary search would be on the order of (bits) operations, no?
On Mon, Jan 11, 2021, 16:10 Mikkel Fahnøe Jørgensen <[email protected]> wrote: > 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]> 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. > > >
