Re: Is the invariants draft really standards track?

Benjamin Kaduk <bkaduk@akamai.com> Fri, 19 June 2020 21:53 UTC

Return-Path: <bkaduk@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 31CBC3A0EB5 for <quic@ietfa.amsl.com>; Fri, 19 Jun 2020 14:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 R4PziQzrZj0g for <quic@ietfa.amsl.com>; Fri, 19 Jun 2020 14:53:38 -0700 (PDT)
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 053303A0EB3 for <quic@ietf.org>; Fri, 19 Jun 2020 14:53:37 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05JLmkQJ004453; Fri, 19 Jun 2020 22:53:29 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=anecQlIMAEQB3rlazaaizObML9FpjzsLrjdGoFMfo1s=; b=lpvSJep+K7610x4FTNIJnZiKe4Nv2V0ZhTnuWlc/f3qoCkU8DcfGhVxBMe0TYxItmkUa ar31//nmAHLUpQdSzS4BR/dHRkvph+7lponn5Il2/BfXnJjAaCVRzeC9Kr+zphFu6Cv8 dN/x7S1uaCauLSZSN/09OYfl4h+Xk9i7M0tJ/b74GcfeYwUGWQZ/b3K7eV+pHo55+3mg aufCsIO/Xk29TwE9tnHYg/ZsuJ4EqxN6MFGgwXfNXd6KLhjDLXuzXnAYn7SKMfKXxDmm RXlo2HzZBEWyWOmkchwKtCuGpPU20YQ6CH1WTaJ6+c8NB1PNdjikur8tDEiFQePBSDA6 Uw==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 31qqyc961s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Jun 2020 22:53:29 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05JLkrjp003631; Fri, 19 Jun 2020 17:53:28 -0400
Received: from prod-mail-relay18.dfw02.corp.akamai.com ([172.27.165.172]) by prod-mail-ppoint2.akamai.com with ESMTP id 31qjm1eac1-1; Fri, 19 Jun 2020 17:53:28 -0400
Received: from akamai.com (unknown [172.19.16.134]) by prod-mail-relay18.dfw02.corp.akamai.com (Postfix) with ESMTP id 46D86885; Fri, 19 Jun 2020 21:53:26 +0000 (GMT)
Date: Fri, 19 Jun 2020 14:53:25 -0700
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Christian Huitema <huitema@huitema.net>
Cc: "Lubashev, Igor" <ilubashe=40akamai.com@dmarc.ietf.org>, Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>, Lars Eggert <lars@eggert.org>, Kyle Rose <krose@krose.org>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Jared Mauch <jared@puck.nether.net>
Subject: Re: Is the invariants draft really standards track?
Message-ID: <20200619215324.GF20623@akamai.com>
References: <833A693C-62E6-4889-9954-FCE65A839A7C@eggert.org> <CAKcm_gPMO2DtqvKucqVw0zDjSniSOmFD4p1Tp4YLjr9WSWdEUw@mail.gmail.com> <CAJU8_nUN42gGmQof24XD9-EjXedyzcarDyRP8MGe1qW-BZ=+Aw@mail.gmail.com> <9cd91c24-c730-22a4-7aa0-baf61613b3ce@huitema.net> <f4922cdb59014202900de44cc5fea0ff@usma1ex-dag1mb5.msg.corp.akamai.com> <CAM4esxQvwkTvpUcu6-+W5zWo22m-R1jvN7DcCpXfuw8Hb55qsw@mail.gmail.com> <95dd02c92b32472d9cab0dd47b98c637@usma1ex-dag1mb5.msg.corp.akamai.com> <CAM4esxQxxXn27rZEY75-AsHD5VF0fqiV1VDyeSrzQ=-sM7JNCg@mail.gmail.com> <9c2e300c30f74d1794d11cf4334ea07b@usma1ex-dag1mb5.msg.corp.akamai.com> <2c40f3d9-fa40-9834-ac30-36bc9a1a6303@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2c40f3d9-fa40-9834-ac30-36bc9a1a6303@huitema.net>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-19_22:2020-06-19, 2020-06-19 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 suspectscore=0 phishscore=0 mlxlogscore=394 adultscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006190151
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-19_22:2020-06-19, 2020-06-19 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 phishscore=0 suspectscore=0 mlxlogscore=327 mlxscore=0 clxscore=1011 adultscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006190152
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/QhWjIMMoqzTWiOJJ_-zACtPj-JE>
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: Fri, 19 Jun 2020 21:53:39 -0000

On Fri, Jun 19, 2020 at 02:48:48PM -0700, Christian Huitema wrote:
> When under DOS attack, you want to "minimize blowback", i.e., as much as
> possible avoid generating packets in response to attack traffic. So,
> yes, a server may choose to not send stateless resets to anyone when
> under attack; in fact, my recommendation would be that a server SHOULD
> NOT send stateless resets to anyone when under attack.
> 
> That said, Igor raised an interesting point about return traffic. It
> would be very nice if DOS protection boxes could distinguish between
> "validated traffic" that the server presumably intends to process, and
> "unsolicited traffic" that will just consume resource. The box can then
> reserve some share of the resource for validated traffic, and place the
> rest of the traffic in a lower priority queue. Fine, but there needs to
> be a test. The classic test is that incoming traffic is "validated" if
> the protection box can match it with return traffic coming from the
> server -- for some definition of matching.
> 
> From that point of view, stateless reset is definitely not helpful. But
> problematic traffic goes beyond that. The server will reply to a
> client's initial with a server's initial packet. Does that validate the
> response traffic? OK, maybe the protection box can programmed to only
> validate traffic if it sees 1RTT packets. But many servers will send
> 1-RTT packets as 0.5 RTT. Does that validate the response traffic?
> 
> We might say that traffic is validated when the handshake is confirmed,
> but the protection box does not understand the TLS handshake, it just
> sees packet types and packet sizes. It cannot distinguish between 0.5RTT
> data and 1RTT data, and thus the closest approximation of "validation"
> would be seeing more than an initial window worth of traffic coming back
> from the server. That does not sound great.
> 
> On the other hand, things get much better if the server under attack can
> adopt a defensive posture and help the DOS protection box do its job.
> Suppose that a server can detect that it is under attack -- or be
> explicitly configured so. The simplest defensive posture would be to (1)
> disable stateless reset and (2) not send any 0.5RTT packet, including in
> response to 0-RTT. The protection boxes can at that point take the 1-RTT
> packets from the server as indicating validation.
> 
> Maybe we should specify that.

It might also be an interesting thought experiment to see what
kind of things the QUIC server could send to the DoS protection box if
the QUIC server acts as a DOTS (RFCs 8782 and 8783) client to a DOTS
server controlling the DoS protection box.

-Ben