Re: How does a server identify a new connection?

Dmitri Tikhonov <dtikhonov@litespeedtech.com> Thu, 06 December 2018 13:31 UTC

Return-Path: <dtikhonov@litespeedtech.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 24D4F130EDC for <quic@ietfa.amsl.com>; Thu, 6 Dec 2018 05:31:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level:
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.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 8dQwbTtuzzop for <quic@ietfa.amsl.com>; Thu, 6 Dec 2018 05:30:59 -0800 (PST)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 C3BFF130E7E for <quic@ietf.org>; Thu, 6 Dec 2018 05:30:56 -0800 (PST)
Received: by mail-qt1-x830.google.com with SMTP id z16so491835qtq.4 for <quic@ietf.org>; Thu, 06 Dec 2018 05:30:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=UPVxvzXTqxPqDlpC6hxjy2oCuY3tKsRSyoWrzg3bz10=; b=gIhUpLCXWi4088bBqzCYJXT6N2TZacwyDfQhSCm0/7yXQIvZvon2r7IvgE4KvRXKv4 exnwuMTW2Li/amyymqDzbeWa2ZY7vR1/cb3cczqxH21wGcuo5k+Y1+f8KWU9GYf/yYpc OYxzMxowzMUvNJOx2H8l9bW0obAKzNlbz6i8UFNX1H33C/3wm52WH7JHMIM+7/IB4van NDrL0YvnPO2zpgzEmnOMzxq5lGf7LeQQSfx9xxEwsSzG9ZgDH7ihita/j/fRwoRmPKc6 VsfciWMbsfXDqyEOWL4WjFYYiYIh49LuTawxZticNmEmKJW9VwJpO7Ks3BDPVgATC2lK NTog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=UPVxvzXTqxPqDlpC6hxjy2oCuY3tKsRSyoWrzg3bz10=; b=Z7Fyn2hzKP2XhVlor+t2KtigXg7gkk9fJfbUBOuWXaAvaJQIe3fUUO5HPiY0p12alN pLZlVpM0gaTqHt/hgrKcUON579+nWkiYm1TUrlQzHPTzpHtGZh/gpCb20x5fZ9YI2wTW eaiEtIpdWGzWDUCkX1LLvio1dcdpGcxGuJMg5DUYlgWhDlCGgicjeaqXZY5pKNd24Ao1 hDLgcbgR73hILWvAk80VlxZeME8a/zEv3sr9xDUXlfWQeZ2+bc5TRLiGfZFbAicqLh0O XxRCrj8uEbdYnNYz74uVZ3mRUJrD8GUEUXnB3reUfbURwcD2grfq+ScZh7TyM2fbpF0i +XJw==
X-Gm-Message-State: AA+aEWZ7vCz2WHl1ek+5OFu1JMTrWESwzbXxnv0tLKzjFz9KPbjpmLO+ MNal88/NGhj0T+B3RtqNEyumpg==
X-Google-Smtp-Source: AFSGD/USG+70QRgmH1jDJlZ49B9vYOWbThRV+yp5E3P+2DgGbzxz1Z7vU3+UwDxDXd0zqqvLzPedrQ==
X-Received: by 2002:ac8:1490:: with SMTP id l16mr28050628qtj.222.1544103055907; Thu, 06 Dec 2018 05:30:55 -0800 (PST)
Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id j36sm379738qtk.15.2018.12.06.05.30.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Dec 2018 05:30:55 -0800 (PST)
Date: Thu, 06 Dec 2018 08:30:50 -0500
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Kazuho Oku <kazuhooku@gmail.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, chuck_crisler@affirmednetworks.com, IETF QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Subject: Re: How does a server identify a new connection?
Message-ID: <20181206133049.GA26304@ubuntu-dmitri>
Mail-Followup-To: Christian Huitema <huitema@huitema.net>, Kazuho Oku <kazuhooku@gmail.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, chuck_crisler@affirmednetworks.com, IETF QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
References: <20181203135630.GA8140@ubuntu-dmitri> <CAN1APdd8h0wVSr6kpLXnc7T7O5tbPBbsij9jyV6ooUxMAHg8Xw@mail.gmail.com> <CAN1APdceYdWGGBgBLc-b6+SLP0x_dZHXDhDqq3TCpPmYdbssbA@mail.gmail.com> <5250b1be4c8f450f877f310aff0f0785@affirmednetworks.com> <CAN1APdd7LTk+eaOLg5MF7RL0_uzD2HBEosd1Ruyep-nN=-hBJQ@mail.gmail.com> <35a756a3-89e8-e817-bfd4-615fe6dfa2ba@huitema.net> <CANatvzxPvY7o6+7+nLhNBTXsYX6CnggRN58w7ej+KWeyG0VL0A@mail.gmail.com> <20181204135441.GA25658@ubuntu-dmitri> <20181205140959.GA8843@ubuntu-dmitri> <446725aa-b3be-32c9-3ef9-9baaf967e8fe@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <446725aa-b3be-32c9-3ef9-9baaf967e8fe@huitema.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/l_pRnxen1xwysx1QBnV4SdjWDJ8>
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: Thu, 06 Dec 2018 13:31:06 -0000

On Wed, Dec 05, 2018 at 12:28:25PM -0800, Christian Huitema wrote:
> > On Tue, Dec 04, 2018 at 08:54:41AM -0500, Dmitri Tikhonov wrote:
> >>     Is the server to try each of its connection candidates in
> >>     turn to see which one successfully decrypts the packet?
> 
> I understand how to create a separate connection context on the server
> for each different incoming server hello, and I am not concerned too
> much by DoS attacks. Attackers can create fake client hellos at will;
> whether they reuse the same ICID/SCID as current client does not change
> the amount of resource consumed on the server.

That's true -- I was wrong.  I thought that the server would have to
perform trial decryption for the client's second packet, making the
CPU cost quadratic.  I forgot that the server changes its SCID and
thus the second packet could only match a single context.

  - Dmitri.