Re: Please review PRs for the Manageability Draft

Ian Swett <> Wed, 21 April 2021 14:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AF303A2A60 for <>; Wed, 21 Apr 2021 07:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bn1bFYzRcL_K for <>; Wed, 21 Apr 2021 07:40:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF8303A2A61 for <>; Wed, 21 Apr 2021 07:40:49 -0700 (PDT)
Received: by with SMTP id i21-20020a05600c3555b029012eae2af5d4so1424267wmq.4 for <>; Wed, 21 Apr 2021 07:40:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c8MJgc6NI8QRYyA64cyQqHl+ZP8PoFFNietiv3JgDKU=; b=AvOe9RhcorjcRxzYXIHzOJr1w7ThYaNUqE+EEVP4OkgPBJFYbqkijXp1DmKXHqQeLE Ub0J1A6y0QyJl0RCjAi7q+feZZsRkOEJ9HYCCtHDZNLWBvlWODWU9Ui+RhT/B9jXkN+e TKxzFqk74HGUGhjFPMJhbxkFL6WkBzDfegZYO0BNqJZGZCt1kcr6Oabij8iWwDPZRzsC 7npBzsoZBQeks2O43CYoNpXpAAUDX/4vaIbGZtuoGB5PgqLWHN5tjlS0EaHRQvUb9o4C l2Skgz5z97RWye6UqP+PVQdggjc3W65P1c/iQ4DUH2e7Tw71rMSFGfjLH3xXiwtoLODc 2O6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c8MJgc6NI8QRYyA64cyQqHl+ZP8PoFFNietiv3JgDKU=; b=r2AX1VLgfMSrqlK0le71S1O3rt2r35T9uKNSdwSFwE4J4UNKRLwU5UufLgRCwvWui3 ronbtr9ShfkfTtWnu7CAp+9uv55vYdgicnVuv6drqawOdEyZWwmHAAL5QH7fXtrC3jtI tPW+f0qcDeZlkZBqDFAlvzhU8A3KV5veGo8l+HnqmONo9nF/IzML0a+igPT5usBhhu7v 5Vh9ZZUJzs4fS4biu97BNq62Fm14+SJQ931lcDOsAXLU73tnCbTy2h/FE53p9+aMTcLh yWYGvilWoPZSscTmKf+lOoanEo6euQ2j/8MrGfiqDQreKQhVZAwdo3km4rBSo/VjELWO iQhw==
X-Gm-Message-State: AOAM532HcWlLlipTcLRJeISHhffHNJBDIAy7QwXpPDHTfUxYhsuGkStq wEnsLKu7/Ik98B3+aqS1P8xSpO9Vf5S7wa8VRqWLSQ==
X-Google-Smtp-Source: ABdhPJy5cFJUao2VCKzz/Nn9mVJH5/geHRavFXJoWmsQqQMcxnUvGm2xesCkugvV1V/5YMP2dIX5kBWOj41F6szmAm4=
X-Received: by 2002:a05:600c:3796:: with SMTP id o22mr10132049wmr.139.1619016045659; Wed, 21 Apr 2021 07:40:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Ian Swett <>
Date: Wed, 21 Apr 2021 10:40:33 -0400
Message-ID: <>
Subject: Re: Please review PRs for the Manageability Draft
To: Mirja Kuehlewind <>
Content-Type: multipart/alternative; boundary="0000000000004a149205c07c8c2d"
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: Wed, 21 Apr 2021 14:40:54 -0000

Thanks for progress on these drafts Mirja.

I wanted to call out a key recommendation in #305
<>, since I think it
could cause unexpected issues in the presence of NAT rebinding.  I'm not
sure what the best options are here, but I wanted to ensure this saw a
slightly wider audience of deployments.

Further, if UDP traffic is desired to be throttled, it is recommended to
> block individual
> QUIC flows entirely rather than dropping packets randomly. When the
> handshake is
> blocked, QUIC-capable applications may failover to TCP
> However, blocking a
> random fraction of QUIC packets across 4-tuples will allow many QUIC
> handshakes
> to complete, preventing a TCP failover, but the connections will suffer
> from
> severe packet loss (see also {{sec-filtering}}).

The issue is called out at the end of the section, and maybe that's

While QUIC endpoints are often able to survive address changes, e.g. by NAT
> rebindings, blocking a portion of the traffic based on 5-tuple hashing
> increases
> the risk of black-holing an active connection when the address changes.

I would advise dropping Initial packets and not other packets, which would
solve the NAT rebind case, but that only rate-limits QUIC flows, and
presumably QUIC flows aren't even the real issue here, it's other UDP

The one positive is that this can be mitigated for QUIC with port migration
upon one or more PTOs.  Chrome/gQuiche currently implements that, but it's
fairly new.



On Mon, Apr 12, 2021 at 11:00 AM Mirja Kuehlewind <mirja.kuehlewind=> wrote:

> Hi again,
> there is one more new PR that would benefit from more review:
> Initial endpoint DDoS cooperation text #312
> This PR is to address issue #240 on Endpoint cooperation for DoS
> mitigation. This issue was discuss at the last meeting and we were looking
> for an author. We got some initial text from Gorry (thanks!) but if people
> have more insights what else should be added here (maybe something about
> handling of 0-RTT packets?), that would be more than welcome!
> We plan to merge all open PR on Wednesday and then submit new draft
> revision by end of week!
> Mirja and Brian
> ´╗┐On 09.04.21, 17:42, "Mirja Kuehlewind" <>
> wrote:
>     Hi all,
>     we are about drain the remaining issues for both ops draft. There are
> currently 7 PRs which are more or less ready to merge, however, we didn't
> merge them yet in order to give more people a chance to review.
>     Especially there are two larger PRs on the manageability draft that do
> change/extend the recommendation given in this draft and therefore more
> review would be appreciated.
>     Here are the links:
>     Update on UDP policing section #305
>     Rewrite Stateful Treatment section #300
>     Thanks in advance!
>     Brian and Mirja