From nobody Mon Jan 11 16:10:24 2021 Return-Path: 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 ; 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 ; 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 ; Mon, 11 Jan 2021 16:10:21 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id b26so639685lff.9 for ; 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: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Message-Id: 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: Cc: IETF QUIC WG To: Martin Duke References: <6B05568D-1905-4416-904C-2EEC25491920@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: X-BeenThere: quic@ietf.org 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 00:10:23 -0000 --Apple-Mail=_5A605CEE-334C-487B-901E-E3F47D239842 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99s 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: >=20 > Hi Mikkel, >=20 > Answers inline >=20 > On Mon, Jan 11, 2021 at 3:19 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen = > wrote: > I=E2=80=99m trying to read through the LB document that I haven=E2=80=99= t looked at for quite a while. It isn=E2=80=99t very clear to me, I am = sorry to say. >=20 > 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? >=20 > 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. > =20 > 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? >=20 > 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) > =20 > If the ODCID is modified, what about message authentication, also in = future versions and with possible shared keys? >=20 > It is not modified, see above >=20 > Is the state table affected by the clients choice of ODCID (think = abuse)? >=20 > 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. >=20 --Apple-Mail=_5A605CEE-334C-487B-901E-E3F47D239842 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99s = 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=C3=B8e = J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
I=E2=80=99m trying to read through the LB = document that I haven=E2=80=99t looked at for quite a while. It isn=E2=80=99= 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.


= --Apple-Mail=_5A605CEE-334C-487B-901E-E3F47D239842--