Re: New Version Notification for draft-dawkins-quic-what-to-do-with-multipath-03.txt

Spencer Dawkins at IETF <> Fri, 08 January 2021 21:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F6AF3A130D for <>; Fri, 8 Jan 2021 13:27:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 J-dTBRtkPwDZ for <>; Fri, 8 Jan 2021 13:27:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 951B93A130B for <>; Fri, 8 Jan 2021 13:27:22 -0800 (PST)
Received: by with SMTP id y4so10687650ybn.3 for <>; Fri, 08 Jan 2021 13:27:22 -0800 (PST)
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=LGArI3hY8yuStSrOCyLLSxdW8JlsepglANArgwmDFuU=; b=dnwzAUOLWgJUlCCSaJfajy3suuewrqa4NkYeokq7KKMggVSWL5Nu5oauSweyL0cZ5a 1ol7Bd86B+pEC82ri0eXjkKRkEIsVkTqZXophLzrF2/gp4axnkRwe1Du6O/BJI3u71xw UCtt2wfNBiYldlVx4qvuZ3wezhMpPBlykP4eYDugvt4H2nXSgykxY0Mx77y4R30eyZhN nl+SyrpOHawMfBXG9NnI/4RjuumlTi/Vgl0DWe5LxVP0ARuL32TZYtdr5MLJeHqZLUY9 dAIgmwkwoERB59wpuURo5XU9m2+Zo4VOuYINQc1vO/fK9afcSTJDg+rm4u42qRUVNJRW rTJQ==
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=LGArI3hY8yuStSrOCyLLSxdW8JlsepglANArgwmDFuU=; b=q7K8CYb/aIWU4sYBLVlFhmFgDZvn7HqsXWjtaq+SRW2ZU7tGNv5VOIdMhLeCjCUNz7 CKezSH7ayAczFpz2xymO0jUMCFMGpfSdzF0vikpMDMSgqGUekir3iLyAB4gtc+KOOrUG w214HCQ5YXfnPVqw8NlUcPmIVhyQZwqeCNm8iv8SHsOH8qnxm0GPKiQpzZDUnKkME0Rb aqjFTbxJtYuG5e5/714gP4odG5lH6zQuFFTv4Zb4YCgmJaYvZc9BlAfj3DX2ADbyzbVo kmYjZnmevDlpVOlARj+36XVTb10tr4em+zLvsaF+OJHDYc7UonVFf+d0ku7HgtSsLrZb M7Nw==
X-Gm-Message-State: AOAM531sjIAhAy8jsYkr6D80MhgnoF6NdK2u6u10xLuY0rvgnCOpWsxH MGSBn3x4qC2U7sfQ9e9VV4nN1E/g9Xy2KIRxRBE=
X-Google-Smtp-Source: ABdhPJwiA4tcAjFD3/0K44zuthqq/cz4NwVGXR8maY7gksIJQnnigWfh+bEliLhfU3WnSXiHdvoFdiwEq7vqtacYkgg=
X-Received: by 2002:a25:1182:: with SMTP id 124mr8106274ybr.154.1610141241910; Fri, 08 Jan 2021 13:27:21 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Fri, 08 Jan 2021 15:26:55 -0600
Message-ID: <>
Subject: Re: New Version Notification for draft-dawkins-quic-what-to-do-with-multipath-03.txt
To: Paul Vixie <>
Cc: Mikkel Fahnøe Jørgensen <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000c32a3405b86a38ad"
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: Fri, 08 Jan 2021 21:27:24 -0000

Hi, Paul and Mikkel,

On Fri, Jan 8, 2021 at 1:46 AM Paul Vixie <> wrote:

> Mikkel Fahnøe Jørgensen wrote on 2021-01-07 09:17:
> > ...
> >
> > From a quick read, I believe you have captured many relevant use cases
> > but perhaps the document does not capture the concerns related til NAT
> > translation and firewalls.
> >
> > ...
> i'm not sure enterprise concerns such as NAT or firewalls are important
> to this audience. QUIC is policy-immune by design, and those of us who
> operate secure private networks (schools, enterprise, military, police,
> and many homes) are expecting to simply deny UDP and force the use of an
> outbound proxy.
> i'd love to be wrong, but section 3 of
> seems
> clear as to the intended entropy level and that this level really is
> intentional. unfortunately for me as a security private network
> operator, my needs in this regard are the same as russia's.

My goal in this draft was to focus on strategies for path selection when
you have two or more validated paths available.

I think that in order to have those paths validated, you already have to
have navigated the potentially twisty maze of NATs and firewall policies.

I recognize that actually getting multiple QUIC paths validated across NATs
and firewalls is important to actual deployments, but I think it's
orthogonal to path selection in a scheduler with multiple paths already

Does that make sense?

And thanks for taking a look at this draft. I know there's a lot of mailing
list traffic with all the ballot e-mail going back and forth!