Re: New Plaintext QUIC-LB Design

Martin Duke <martin.h.duke@gmail.com> Tue, 12 January 2021 01:27 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE703A033F for <quic@ietfa.amsl.com>; Mon, 11 Jan 2021 17:27:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQY2yWKiRRxG for <quic@ietfa.amsl.com>; Mon, 11 Jan 2021 17:26:59 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852753A03EF for <quic@ietf.org>; Mon, 11 Jan 2021 17:26:59 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id u26so657714iof.3 for <quic@ietf.org>; Mon, 11 Jan 2021 17:26:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CAM4esxRRp5=-YvcPsCdsgB=8O=_RAXq05Ldma0smGsjy95T4=g@mail.gmail.com> <6B05568D-1905-4416-904C-2EEC25491920@gmail.com> <CAM4esxSyn7uEiUsYvtiUbQ=4Qt-Bp+yLYBK+re+a+V3ea0BjcQ@mail.gmail.com> <B4D950F6-452A-4CFC-9707-DC1C9B3AB49B@gmail.com>
In-Reply-To: <B4D950F6-452A-4CFC-9707-DC1C9B3AB49B@gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Mon, 11 Jan 2021 17:26:47 -0800
Message-ID: <CAM4esxQhoBhvt_WOgCaZrTwdCmHS15idxVtpQvoqhYkeQKpd-A@mail.gmail.com>
Subject: Re: New Plaintext QUIC-LB Design
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000360fd605b8a9ebeb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/qsc0p0zTeEXIoLBZW_kn_BkcHcQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=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 <mikkelfj@gmail.com>
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 <martin.h.duke@gmail.com> wrote:
>
> Hi Mikkel,
>
> Answers inline
>
> On Mon, Jan 11, 2021 at 3:19 PM Mikkel Fahnøe Jørgensen <
> mikkelfj@gmail.com> 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.
>
>
>