Re: New Plaintext QUIC-LB Design

[Martin Duke <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> wrote:
>
> Hi Mikkel,
>
> Answers inline
>
> On Mon, Jan 11, 2021 at 3:19 PM Mikkel Fahnøe Jørgensen <
> [e-mail]> 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.
>
>
>