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: Mikkel Fahnøe Jørgensen <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. > > >
- New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Dmitri Tikhonov
- Re: New Plaintext QUIC-LB Design Mikkel Fahnøe Jørgensen
- Re: New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Mikkel Fahnøe Jørgensen
- Re: New Plaintext QUIC-LB Design Mikkel Fahnøe Jørgensen
- Re: New Plaintext QUIC-LB Design Christian Huitema
- Re: New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Christian Huitema
- Re: New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Nick Banks
- Re: New Plaintext QUIC-LB Design Mikkel Fahnøe Jørgensen
- Re: New Plaintext QUIC-LB Design Mikkel Fahnøe Jørgensen
- Re: New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Behcet Sarikaya
- Re: New Plaintext QUIC-LB Design Martin Duke