IETF Logo Mail Archive

Re: [quicwg/base-drafts] Long Header Packets and Routing Connection IDs (#2834)

Kazuho Oku <notifications@github.com> Mon, 24 June 2019 23:53 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E15C120199 for <quic-issues@ietfa.amsl.com>; Mon, 24 Jun 2019 16:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Level:
X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=github.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 bRAWUCau2dOE for <quic-issues@ietfa.amsl.com>; Mon, 24 Jun 2019 16:53:16 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB222120041 for <quic-issues@ietf.org>; Mon, 24 Jun 2019 16:53:16 -0700 (PDT)
Date: Mon, 24 Jun 2019 16:53:15 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1561420396; bh=O4KiJbMJukFgBfxg8JiWUmiWdLsQifK8iIVlMirGaGw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=indskIevPTeEygMjRWQM2RVfhuutcm6CKDsaRU80BuAiGte1d/tAXbZVYu8LGTgZk IFSoOIrvcYS1O4dgYG7lbbUfBdJiTC2CKYdSiDUDJm6ZApc4i31OznDgyUh55OQvCT CkEqT3X5FrQ+9aLB7J1rXuuey6AtPmSWveYO1V18=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4D65O7GB4SZQVHPE53D2KOXEVBNHHBWZGHNE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2834/505223634@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2834@github.com>
References: <quicwg/base-drafts/issues/2834@github.com>
Subject: Re: [quicwg/base-drafts] Long Header Packets and Routing Connection IDs (#2834)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d11626bf252d_5fb33f8b84ecd96c17158c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/qmY7ygicQ_2sffpIX8fmO80svuQ>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2019 23:53:19 -0000

@nibanks 
> @kazuho with the current way things are spec'ed, and assuming you do not use auth tags in the CIDs and that you do not try to decrypt the actual payload, when a stateless LB receives an Initial packet from the client, how exactly is it supposed to chose which backend server to send it to?

My assumption has been that it's the 5-tuple.

As you state, that's how TCP load balancers have operated, and we can do the same for QUIC.

Using client-generated CID for load balancing incoming connections is not a good idea because it is more prone to attacks than relying on the 5-tuple, because spoofing the payload of a UDP packet is easier than spoofing the source address.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2834#issuecomment-505223634

v2.23.0 | Report a Bug | By Email