Re: Is the invariants draft really standards track?

Jared Mauch <jared@puck.nether.net> Wed, 27 May 2020 16:25 UTC

Return-Path: <jared@puck.nether.net>
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 0793D3A0EE8 for <quic@ietfa.amsl.com>; Wed, 27 May 2020 09:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 9Y2yjl4MIAwx for <quic@ietfa.amsl.com>; Wed, 27 May 2020 09:25:52 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D1D3A0ABC for <quic@ietf.org>; Wed, 27 May 2020 09:25:52 -0700 (PDT)
Received: from [10.0.0.155] (c-68-49-104-93.hsd1.mi.comcast.net [68.49.104.93]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id E5801540100; Wed, 27 May 2020 12:25:40 -0400 (EDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-D5DAD09C-66CC-4302-A50F-AD85CF6899F3
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: Is the invariants draft really standards track?
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <f4922cdb59014202900de44cc5fea0ff@usma1ex-dag1mb5.msg.corp.akamai.com>
Date: Wed, 27 May 2020 12:25:39 -0400
Cc: Christian Huitema <huitema@huitema.net>, Kyle Rose <krose@krose.org>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.com>
Message-Id: <283F56BF-16A0-4760-AAFA-549D389766D5@puck.nether.net>
References: <f4922cdb59014202900de44cc5fea0ff@usma1ex-dag1mb5.msg.corp.akamai.com>
To: "Lubashev, Igor" <ilubashe@akamai.com>
X-Mailer: iPhone Mail (17F75)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/q1QSS0tX_peoee4ThPX6lP_pnDs>
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: Wed, 27 May 2020 16:25:55 -0000

As a former (public) backbone operator we had to deploy these limits due to the volume of the attacks and the disruption it posed to our services. 

There is an ongoing thread about how operators can undo this as people are more pitched against certain vectors. 

QUIC will work until it hits these limiters which may be tied to specific port numbers and such. 

I recommend QUIC folks avoid ephemeral ports that align with prior vectors such as NTP, slammer, memcached amongst others. 

UDP/80 and 443 are also used in attacks so expect operators without a clue to limit them similar to how many didn't realize that DNS was a UDP+TCP protocol for queries as well. 

Sent from my iCar

> On May 27, 2020, at 12:07 PM, Lubashev, Igor <ilubashe@akamai.com> wrote:
> 
> 
> I’m working on a manageability draft PR for this (how to rate limit UDP to reduce disruption to QUIC if you have to rate limit UDP).  ETA end of the week (if I do not get pulled into something again).
>  
> The relevant observation is that DDoS with UDP that is indistinguishable from QUIC will happen.  UDP is already the most prevalent DDoS vector, since it is easy for a compromised non-admin app to send a flood of huge UDP packets (with TCP you get throttled by the congestion controller).  So there WILL be DDoS protection devices out there to try to mitigate the problem, possibly by observing both directions of the flow and deciding whether a packet belongs to a valid flow or not.
>  
> Since such middle boxes will be created, the more explicit and normative Invariants are about what one can expect, the less such middle boxes may decide for themselves.  For example (I did not think long about it), if some elements of path validation could land into Invariants (roughly, “no more than X packets/bytes can be sent on a new path w/o a return packet”), a DDoS middle box may use this fact and active connection migration might still have a chance during an attack (NAT rebinding could be linked by DDoS boxes to an old connection via unchanged CID).
>  
> Igor
>  
>  
> From: Christian Huitema <huitema@huitema.net> 
> Sent: Wednesday, May 27, 2020 11:34 AM
> 
> On 5/27/2020 8:28 AM, Kyle Rose wrote:
> On Wed, May 27, 2020 at 10:34 AM Ian Swett <ianswett=40google.com@dmarc.ietf.org> wrote:
> I was agreeing with MT, but I'm happy to see some more MUSTs added if people feel that'd be helpful.
>  
> Coincidentally, we were just talking about this internally at Akamai yesterday. IMO, an invariants document isn't really helpful if it isn't normative, and for it to be normative it (or a related practices doc for operators) really needs to spell out clear boundaries for operators with MUSTs..
>  
> The example that came up yesterday was around operators filtering QUIC in the event of a DDoS: one recommendation based on some conversations going back at least to Prague 2019 was to hash packets on 4-tuple and filter those below a hash value chosen for a desired ingress limit instead of doing what most operators do with UDP today, which is to cap UDP throughput and just drop packets randomly or tail drop.
> Interesting. Did they consider using the CID, or a fraction of it? This looks entirely like the scenario for which we developed stateless retry.
> 
>  
> This recommendation certainly imposes some constraints on future protocol development that motivate new invariants: for instance, it would preclude sharding a connection across multiple source ports (not that there is necessarily a reason to do this; it's just an example). But more importantly, it goes beyond invariants: it's one among many practices compatible with the current set of invariants, some reasonable and some terrible.
> This would break the "preferred address" redirection. Preferred address migration may or may not be spelled out in the invariants.
> 
>  
> Operators are going to do things to QUIC traffic, so it would be good to offer them recommendations that are compatible with broad deployability.
>  
> 
> Yes, we do need the invariants for that.
> 
> -- Christian Huitema