RE: Is the invariants draft really standards track?

Mike Bishop <> Mon, 22 June 2020 15:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDDC23A0E0A for <>; Mon, 22 Jun 2020 08:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c9mpQHC6HckW for <>; Mon, 22 Jun 2020 08:33:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BECF63A0E01 for <>; Mon, 22 Jun 2020 08:33:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=Q9WL0P7APZWxE3P2m1m8aGR4Hb/CEiddrBwHQOXpj8/KQyzmqx2e6xYQN+KvkPlG/MV24WQ//JBeWkJpdecbvU1wbi/BdYePUemCeDgTUfQuMEmBZc0sA+pgujxK4wMP8TL709lRFgihjKjmUXyB2ueRyAffO4iz87G2qBjI/iQ/VWpRAkJ52IlDfMu35tqOefM+f2/S+lZs4I2++uwIAiqfpdnFMxsBaCfInz8YxLISjcIINA1l5c6ZBBvQZcf24LOr2tR7hfDlgYB1kUgSsCRP3PuaQZ8k7ti89HZS16rpUCSzT/RNTTAlS+BPmUCeTDRRtJ8Axb2WFxUmZMxxjQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t5p9zzJJzZy3yvVHhhWKkJTpdwTSdHhg8XIj/xVZ28E=; b=gSMsXfxiHzRhnLco5CBB40lu7r5CgDlaG8OklbYIvmoyydSP45EUM9MNyCk8jnF92Qy+VxB0lxCCpJ3VZUqITT8Ct6PWpw83hDJbKXnnj481qBqQChTjK1kUmxrVilErqluqT5bUESkUKMBeuHxVgQSFo7VCxTL+80aMMbeU2/eaXdixbCjlpnSSoWGRuQnGYA1Ezafn0pLV2T9RyiJv2i2XPsl38kXNL8M/e2odZMH8aY3xUaAP1nnFSAlZ/WavEpt6riZ5GhZH0yoa7YIoVHiOUOTgJnTzykScSIHFV6FTmTXLWzhXUBEFzf+pUaUL7RJxJHa2EgSErYa0s5Bvuw==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t5p9zzJJzZy3yvVHhhWKkJTpdwTSdHhg8XIj/xVZ28E=; b=uIsJ11YdrZPfCmCJJlI8Xn7EXoJj+RhFhidu0AsBjK1cfO9QR+C+soEX8wZseroSxgRkxdwo54GEeyefZVT5+7X2r2jgsHWA+VeW8HOvzHaeRX7PriXCyTEfHFs86NXiO7tiWocEJe/4XWXI0lQ6YfgR0H3MTWE/am2TKXnAvGw=
Received: from (2603:10b6:610:8c::8) by (2603:10b6:610:89::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Mon, 22 Jun 2020 15:33:45 +0000
Received: from ([fe80::f0e6:8202:6056:a596]) by ([fe80::f0e6:8202:6056:a596%5]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 15:33:44 +0000
From: Mike Bishop <>
To: Paul Vixie <>, IETF QUIC WG <>
Subject: RE: Is the invariants draft really standards track?
Thread-Topic: Is the invariants draft really standards track?
Date: Mon, 22 Jun 2020 15:33:44 +0000
Message-ID: <>
References: <> <> <> <1621715.PBmxXT1aCC@linux-9daj>
In-Reply-To: <1621715.PBmxXT1aCC@linux-9daj>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: [2600:2b00:9309:6a01:a435:b5c6:6ad3:1dd0]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9d4d16f3-2774-4632-df2f-08d816c1a65d
x-ms-traffictypediagnostic: CH2PR22MB2008:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0442E569BC
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RTbq++dgvzld9yOnjXpY7uzmdYaiUZkWA+mLFlW6Cz8SKL5A1ChHVn5hGc/rrTDoW81Xs0gPGvyZl6XPkOvVwYZruhRqwyrXhga9qfrzja0EqqMl8Li6yjnndwiBm+/qKhxKLNGYq7AAgrymSE/lQUOiv4mrFGgJRn237fTR6tTiViL8XcQZ2Zdbl/DCGKijf6GWYioZ3EVJVO6wgjApVXvDkk/AtDxg+f0/QUlGdgZVofWApbcSCFZ2Eb/+KLCBaY2ZlltNQTi/JldTxdMLUv33x/xNzI8ggzB77fYn87/0ZFFQ6mVwzHv9C8lbYQrkkidQiC8k0enpckL/qI/96w==
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; PTR:; CAT:NONE; SFTY:; SFS:(396003)(39830400003)(136003)(376002)(346002)(366004)(508600001)(5660300002)(52536014)(66946007)(66446008)(64756008)(66476007)(66556008)(33656002)(76116006)(316002)(9686003)(55016002)(86362001)(2906002)(71200400001)(8676002)(110136005)(66574015)(53546011)(6506007)(83380400001)(186003)(8936002)(7696005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 8/ZFY56pXk+Qxt635ZZKZdLgfUSsvXNLEo2tnWRP1TKTcT7SaGo10OpawPEd3/i+AdJqHZDq7c6G2bS8MuaEyQ8zJ1TRX10a0VyFTIIwxOpQT+MjoFQnl8XHKqdWIrbw1JZYiZJzRwXWCrEEe5mU4g4tQioiOIlBsCOFYIr1q+B5ZFovVmSigEXlN2ICjO6PfVCNivzfF4EH3Abf7yo4SSAORe1Dp9VrMMeOoytP7gF+VCGSaWhORnSEIL6kZZJfa9UYYCZBWRVUqS2OaJmix0ouVKrJay9VgnmgAhD6FIL/xOepo0+wju96JkxNjmA2+as3EfJ2V/Zv+6ak+y4q2IELVvo0MQ/2mzGZzUyQLpUBIQjLygQzNUn6OTDtEhzwskTxUesO2JYgqDRBzTRdXAz/JfTyT2wMMIcU3VXkhXiqX2urOt7HxspFryk6QecTcZxVAV/ow3nAG7BPZeoFyJQRm8rzFIP97+DB2r8gGnjEuW0Pwlx8MdsKE/XUhRrA8lIKiRa9HDI6j39esrj5tS2fxx88SoIdans4bJKl334=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9d4d16f3-2774-4632-df2f-08d816c1a65d
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2020 15:33:44.7080 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9Is5Xi8+ewW1RJNmISfxonc3CfoYSqsaw6IgSEgj2xd1rZxP1FrR4NlxbSBi00XdZobD1uVkG01nIkjwn5znFA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR22MB2008
Archived-At: <>
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: Mon, 22 Jun 2020 15:33:50 -0000

Negotiating the 5-tuple in-band is problematic in the client-server direction; in the presence of a NAT, the client doesn't know what address/port the server is going to see when it uses a new path.  For the same reason (NAT opening), the client always goes first with connection migration, even if it's the server's address changing.  However, we're assuming that the server has the ability to provide the client a directly-reachable address, so that probably covers your in-band negotiation.

-----Original Message-----
From: QUIC <> On Behalf Of Paul Vixie
Sent: Saturday, June 20, 2020 2:35 PM
Subject: Re: Is the invariants draft really standards track?

On Friday, 19 June 2020 23:51:39 UTC Christian Huitema wrote:
> ...
> The DOS box does not have to worry about what kind of traffic is 
> coming in. It just has to open a context for the 5 tuple, and check 
> whether it sees 1-RTT packets coming back. And then maybe count the 
> volume of 1-RTT packets coming back.
> The worry is that one of the bots might start a legitimate connection, 
> then disclose its five tuple to the rest of the botnet. The whole 
> botnet can then spoof the 5 tuple that was just pin-holed by the DOS 
> box. A simple "open-close" logic is thus not good enough. The DOS box 
> must also enforce some kind of rate limiting per 5 tuple.
> Which also means that if a botnet can predict the 5 tuple used by a 
> legitimate connection and then spoof it, it can DOS it. Once you start 
> digging that particular rabbit hole, the joy never stops...

pinholing based on outbound is the worst possible solution to DDoS, except for all the others. stateful firewalls of this kind create _almost_ as many problems as they solve, and would not be used if an alternative existed. this is a BCP38 problem not a QUIC problem. QUIC's only responsibility is to not make this known-bad situation worse.

there are two important ways that QUIC can avoid making the situation worse.

first, make connection mobility an outbound-first activity for initiators. the new 5-tuple would have to be negotiated in-band, and the first packet of the new flow would have to come from the initiator, to create the new pinhole.

second, make the new flow identifiable by the DOS box (or other filtering router such as a firewall box) using some low-entropy invariant. at the moment all we have to go on for detecting new outbound QUIC flows is a destination UDP port number, and that's both constraining and fragile.