IETF Logo Mail Archive

Re: Should QUIC have a path-verifiable proof of source address?

"Brian Trammell (IETF)" <ietf@trammell.ch> Wed, 31 May 2017 13:22 UTC

Return-Path: <ietf@trammell.ch>
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 43F35129BEC for <quic@ietfa.amsl.com>; Wed, 31 May 2017 06:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham 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 WSimV3Cg9n8k for <quic@ietfa.amsl.com>; Wed, 31 May 2017 06:22:43 -0700 (PDT)
Received: from capri.iway.ch (capri.iway.ch [212.25.24.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138FC129BDB for <quic@ietf.org>; Wed, 31 May 2017 06:22:43 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0A1DA340D4D; Wed, 31 May 2017 15:22:41 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.8096); Wed, 31 May 2017 15:22:40 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 31 May 2017 15:22:40 +0200 (CEST)
Received: from [195.176.111.18] (account ietf@trammell.ch HELO public-docking-cx-1324.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 19254275; Wed, 31 May 2017 15:22:40 +0200
Subject: Re: Should QUIC have a path-verifiable proof of source address?
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_54DE166D-BEAB-432E-A1AA-8704A7419ECE"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
In-Reply-To: <CAAedzxr2VyXpvvz8iyiyUWUZA4TZeWfCY58-tDgNfhRHqg5Oqg@mail.gmail.com>
Date: Wed, 31 May 2017 15:22:40 +0200
Cc: QUIC WG <quic@ietf.org>
Message-Id: <C46523AE-6145-4CF1-9ED3-791F87DE9E3E@trammell.ch>
References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <CAAedzxr2VyXpvvz8iyiyUWUZA4TZeWfCY58-tDgNfhRHqg5Oqg@mail.gmail.com>
To: Erik Kline <ek@google.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/-xS1xgKMJpz0ZicCbZ_w-ifSwMg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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, 31 May 2017 13:22:45 -0000

Hi, Erik,


> On 31 May 2017, at 14:04, Erik Kline <ek@google.com> wrote:
> 
>> On 31 May 2017 at 20:53, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>> Greetings, all,

<snip>

>> "Shoud QUIC allow devices on path to distinguish QUIC traffic with valid source addresses from traffic with spoofed source addresses?"

<snip>

> My main concern here would be that preserve the ability to migrate connections.
> 
> Allowing on-path but non-endpoint devices to distinguish traffic as you describe opens up the opportunity for them to do it incorrectly/badly thereby making some implementations of connection migration unreliable (at best).
> 
> There may still be ways to support connection migration and support this kind of traffic analysis, though.

Okay... so I'll mark that down "this seems useful, but not at the cost of any flexibility in connection migration."

Actually, your answer suggests an alternate and potentially more useful framing for this question: "which design properties are you not willing to sacrifice to get the ability for devices on path to distinguish QUIC traffic with valid source addresses from traffic with spoofed source addresses?", which captures the risk/utility tradeoff nicely.

Thanks, cheers,

Brian

v2.23.0 | Report a Bug | By Email