Re: New Plaintext QUIC-LB Design

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 12 January 2021 00:10 UTC

Return-Path: <mikkelfj@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 65A813A03FC for <quic@ietfa.amsl.com>; Mon, 11 Jan 2021 16:10:23 -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 J-_Y51kEDp-6 for <quic@ietfa.amsl.com>; Mon, 11 Jan 2021 16:10:21 -0800 (PST)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 852453A03F4 for <quic@ietf.org>; Mon, 11 Jan 2021 16:10:21 -0800 (PST)
Received: by mail-lf1-x132.google.com with SMTP id b26so639685lff.9 for <quic@ietf.org>; Mon, 11 Jan 2021 16:10:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nMd+890rC9yr6nHMbi7V6b6lBbjASR/1y04cQ4O6Q2A=; b=KWVFOTCkuEaJ3AcYl0rz2tZA99NFlwAs0fvszvllsaOKF2Ujvf+xfv4Jgr6KV4FGer dIExi4Vs5cq+tjvNLAnDcDSgPAfUA9xMpOm0p/D4fnXAmfqmbVGFLpox/zVBexaeN187 +Cvc6IccY4li9GRqm8KsUXuzeqx21ycF1GsPrO/8zuYJG6oZVHyRs9qEa4n1hKl0PWN0 pXB3jHG3x89sN79y4hKngSV9mEEHe0GskQOjcBfIbdxRwxMmUlxCArdBnkH/5I0fSOGM yPQO1QqEvWcKpVr4RW0xPd5QM5kRaLEYD7JoSMff1XzCQ46+fV91+LdIlm4jEeAXjVoh BEfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nMd+890rC9yr6nHMbi7V6b6lBbjASR/1y04cQ4O6Q2A=; b=Ck7WfVcLzgOiyyS7KLC0uKyZFrOjW2s8OhPOZ02OQMYuNjuOG5A6Axk/6uFxP8flQA 2KKsm3BX+TrPOwz44ZRHLLIy6jtOd8nqMEFen8mVYKe2EkL7uEzio/K/hzZXn2/dM5YW CviW6wzJijQWpM7LiBaSMWSb3NP84qj6ctqTXVqiHralEt4Jfv6AFvCyyGZhFxX6dE8a LeKLzNXCxQpmVSUpvzCu9DQfCAXF5pvCB4fUr2TRZ8gZOCMdtsncIqh+Fx4YZDJ85az0 Y9418jo09dplAcwmYQM9VyQ64/vRtYrLZGZsaqpefyorFFa4W3qAS/au8RN5QwxMAE+o m87g==
X-Gm-Message-State: AOAM532H8uXChMb5fTToPOcHRlAu/CqSAhgM7v10AFHpboX+x5XL1Rkx XCZL+YQQJzKVh1KuSVPo6uc=
X-Google-Smtp-Source: ABdhPJxssvLBLJ7XZ96j0GdLStnAOkcFd8UadIuq7v9rj9zuQ57Ml4ap1iL13je1Vw64cJV1186KsA==
X-Received: by 2002:ac2:54b9:: with SMTP id w25mr884213lfk.8.1610410219290; Mon, 11 Jan 2021 16:10:19 -0800 (PST)
Received: from mobile.3.dk ([2a02:aa7:4604:5103:1d01:5a1e:a05f:e067]) by smtp.gmail.com with ESMTPSA id q16sm165593lfb.8.2021.01.11.16.10.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jan 2021 16:10:18 -0800 (PST)
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Message-Id: <B4D950F6-452A-4CFC-9707-DC1C9B3AB49B@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5A605CEE-334C-487B-901E-E3F47D239842"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: New Plaintext QUIC-LB Design
Date: Tue, 12 Jan 2021 01:10:16 +0100
In-Reply-To: <CAM4esxSyn7uEiUsYvtiUbQ=4Qt-Bp+yLYBK+re+a+V3ea0BjcQ@mail.gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
To: Martin Duke <martin.h.duke@gmail.com>
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>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/A_E66i6gI08Tf1ZFYsp2Y1S8Il4>
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 00:10:23 -0000

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 <mailto: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.
>