IETF Logo Mail Archive

RE: draft-duke-quic-load-balancers-00.txt

"Lubashev, Igor" <ilubashe@akamai.com> Wed, 14 February 2018 06:39 UTC

Return-Path: <ilubashe@akamai.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 7D781124F57 for <quic@ietfa.amsl.com>; Tue, 13 Feb 2018 22:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level:
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 4Px-xY6fqau5 for <quic@ietfa.amsl.com>; Tue, 13 Feb 2018 22:39:04 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537E2124B17 for <quic@ietf.org>; Tue, 13 Feb 2018 22:39:04 -0800 (PST)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1E6aq89011958; Wed, 14 Feb 2018 06:39:02 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=dMWWjZv8CEUPdJM1xoBVIXKOsavHGI6P6NqSMSGYQCY=; b=ea3lo95t0i+kofivDSN6C2iaOcFtvof0rXtlzPAP51ZKBAiJfnyu/RqUr2/9JoN0CH0l Rw2rqdRqMDrAPxyWj4T6yfHJJJW/1VS3kjwX5GecyLnFwt65anPGfWYBaEaqc3VLzB4q WtPmRCE0NwL0/ArUqMk2ViGTznT7NwWvWtQW4+ULIb9X9Dp2vNYOCt6Ql0wZJXvluiP1 kuJsnSNyKE4NjFdPJAt6fnNJIJ+uPRzmg8LRh8PI27CYaPUNw8hkX6xzAhPaNkZTUsxX 9RnnRKUmCo/AUn52nIVr4qfVUUdvq1OTw4H6GTv3Er2LoL2iFSudNw1wouLkGeUppPjL cg==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2g48x00xm5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Feb 2018 06:39:02 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1E6aTZc023101; Wed, 14 Feb 2018 01:39:01 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2g1vy0452j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 14 Feb 2018 01:39:01 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 14 Feb 2018 01:39:00 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Wed, 14 Feb 2018 01:39:00 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>
Subject: RE: draft-duke-quic-load-balancers-00.txt
Thread-Topic: draft-duke-quic-load-balancers-00.txt
Thread-Index: AQHTpE5n5n3EqIWdaEi44FdaO/490KOjcQ+w
Date: Wed, 14 Feb 2018 06:38:59 +0000
Message-ID: <4964f7cf3f1b4ddbbc7bf76595cf27c9@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <CAM4esxRq131G7XOC1YNy6N943Bar08gh8vMmhU34-vYcXOAauw@mail.gmail.com>
In-Reply-To: <CAM4esxRq131G7XOC1YNy6N943Bar08gh8vMmhU34-vYcXOAauw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.44.68]
Content-Type: multipart/alternative; boundary="_000_4964f7cf3f1b4ddbbc7bf76595cf27c9usma1exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-14_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802140078
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-14_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802140078
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/aAH5PFxeoh5PMKQnBG0gYYO6y7c>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 14 Feb 2018 06:39:06 -0000

Relatively minor nit:

“A representative encoding that meets these requirements might
   concatenate the server's IPv4 address and a monotonically increasing
   sequence number, and then encrypt the result to obtain the
   connection ID.”

You may want to consider a nonce as an input to your crypto function to detect attacks via forged CIDs.  In case the same backend server maybe used for multiple Virtual IPs, you may also want to include the Virtual IP (and destination port) as an input to the crypto function to increase the number of possible unique CIDs generated (IPv4 and the nonce may leave you with few extra bits, unless 128-bit CID is used, so find extra bits where you can).


From: Martin Duke [mailto:martin.h.duke@gmail.com]
Sent: Monday, February 12, 2018 5:11 PM
To: IETF QUIC WG <quic@ietf.org>
Subject: draft-duke-quic-load-balancers-00.txt

Based on conversations in Melbourne, I posted a straw man for a standard way for load balancers and servers to coordinate on routable, unlinkable connection IDs.

Datatracker: https://datatracker.ietf.org/doc/draft-duke-quic-load-balancers/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dduke-2Dquic-2Dload-2Dbalancers_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=PtSeY0IPCpSZaH_c2HNxbMGPFiJVlgy-o1aCKEnI_v8&s=iqBILT7oIrsafQc7-Cw_gm3I040JmyIbrlnDAc4b9qw&e=>
Github: https://github.com/martinduke/draft-duke-quic-load-balancers<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_martinduke_draft-2Dduke-2Dquic-2Dload-2Dbalancers&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=PtSeY0IPCpSZaH_c2HNxbMGPFiJVlgy-o1aCKEnI_v8&s=RiCfUMP25oJm-L-e9q1vVzgtkwnSn7P2wdC5Q-7ByGM&e=>

There's nothing earthshaking here: we use DTLS for authentication and encryption, and have a few very simple UDP messages to keep the conn IDs synced. The draft isn't very long.

I'll incorporate variable length connection IDs, etc, when and if they enter the mainline. I'm certainly interested if this meets the needs of the people actively looking for a solution in this space.

v2.23.0 | Report a Bug | By Email