Re: New Plaintext QUIC-LB Design

Martin Duke <> Tue, 12 January 2021 01:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DE703A033F for <>; Mon, 11 Jan 2021 17:27:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZQY2yWKiRRxG for <>; Mon, 11 Jan 2021 17:26:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 852753A03EF for <>; Mon, 11 Jan 2021 17:26:59 -0800 (PST)
Received: by with SMTP id u26so657714iof.3 for <>; Mon, 11 Jan 2021 17:26:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F9cLAYCUVJDspGd59ceuYvAKIDb7bYMkWZsIPC8cka0=; b=WEkNb4loRH+2lh+BV19G6akwgiyXAD86Y7AnunkgR/O4xKRymnE61gW6FngiHOCzKL Hc7g1SDxHDjcdrgTpjdn7GyxfDsOQ0vSVfQjEZtg+tmw6XnuopYi2S9V8bt10KHsb3QO iBOOZpkUik2dK6jmMkJfRgL3RBzMI1uCFN1mZ6fP2PIAj6dAUJgToTROYOnFQ1gFY1IY o5uGVK5jhdTARclyRUaoqV7PMSNBAO+JxxT/1HrXpIi/AGtEMnMDRUJClOKo5iBH/ejC aw8FGHusX1wR91scUs8tx4KCvKE0PNmGeE8JIQ8pRQ6THH18MUfVpZxeSmPsmFMqV0pf eI9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F9cLAYCUVJDspGd59ceuYvAKIDb7bYMkWZsIPC8cka0=; b=NZo1HqI9CHiGVaWP1ARGMdz/ZSfIFGXGZcD31oqvL/icPno5g7XiITRzhK4WVJ1OLO tjuUz5XyH4BscFj/i3hmnsLGVF2e/YnxQXvGKwN+zhLXJvX9PaORVIbTj8pfsxAuPgME bxWn4fAPW4OjXxBapA/9afryK8qqam8q1DwZyJ2kzKwGjs66Gv3eXFx8QW59UvTmsQ5g FKc6jQi8ErajTG7wHAkdc93pNVQ6TtasC89oxzZ1es7go5wwpF9J/0eTWlZ6zWDgfnWR cnQmdqNEE+mHVIM1FagTTbfmpMbWlaN/2qySm5Oz5na578DS2JMwdEQ0ioZ8NLTjvejh BiPQ==
X-Gm-Message-State: AOAM530A+DrNWCJU7l7/uvk5sefpcwemQ3T/cLaSZ5i++kmKqA4lV28G uXqXxO2daw+mtvApDPHjnOOb1lt/UcKxwt4g85E=
X-Google-Smtp-Source: ABdhPJzTDCNLMWkqLBrWH51cBM5dEvb0Mkml4o1Ct9c9NmcncW1eS43mFmuUHgFiFd9QnFngLi+6uNsZlLunAfrOpeA=
X-Received: by 2002:a05:6638:1247:: with SMTP id o7mr2017373jas.31.1610414818724; Mon, 11 Jan 2021 17:26:58 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Mon, 11 Jan 2021 17:26:47 -0800
Message-ID: <>
Subject: Re: New Plaintext QUIC-LB Design
To: Mikkel Fahnøe Jørgensen <>
Content-Type: multipart/alternative; boundary="000000000000360fd605b8a9ebeb"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jan 2021 01:27:03 -0000

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 <>

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