IETF Logo Mail Archive

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

"Brian Trammell (IETF)" <ietf@trammell.ch> Thu, 01 June 2017 13:41 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 A782612EC93 for <quic@ietfa.amsl.com>; Thu, 1 Jun 2017 06:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 lzuJT5cHjBRw for <quic@ietfa.amsl.com>; Thu, 1 Jun 2017 06:41:22 -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 8A78112EC8F for <quic@ietf.org>; Thu, 1 Jun 2017 06:41:21 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 754F434080D; Thu, 1 Jun 2017 15:41:19 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.8022); Thu, 1 Jun 2017 15:41:18 +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; Thu, 1 Jun 2017 15:41:18 +0200 (CEST)
Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 19398712; Thu, 01 Jun 2017 15:41:18 +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=_632A21F0-6D86-4D9D-A306-9C1D9CE625A7"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
In-Reply-To: <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch>
Date: Thu, 01 Jun 2017 15:41:17 +0200
Cc: Martin Thomson <martin.thomson@gmail.com>, Christian Huitema <huitema@huitema.net>, QUIC WG <quic@ietf.org>
Message-Id: <2856C4A2-FB68-425D-8B34-043A7EF005E9@trammell.ch>
References: <179F2CCB-89DB-4E6E-9175-F850F89B4E5F@trammell.ch> <30eb5292-ac11-9772-b088-03b1f2fe372b@huitema.net> <CABkgnnWEg0N0WYsdMzsPT--MpRSQ7g2ysu2DvwenQ+mQpo6Anw@mail.gmail.com> <40dc8d2a-92ec-e6f1-b2b8-f4c447313cf5@tik.ee.ethz.ch>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rPyUYZd_dXkrJGD4BSOc6Rwo4lM>
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: Thu, 01 Jun 2017 13:41:25 -0000

> On 01 Jun 2017, at 10:37, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
> 
> Hi all,
> 
> On 01.06.2017 03:29, Martin Thomson wrote:
>> On 1 June 2017 at 06:09, Christian Huitema <huitema@huitema.net> wrote:
>>> Brian, I am not sure I understand your requirement. Do you mean
>>> something like the reachability verification implicit in the three ways
>>> handshake of TCP? Or do you mean some kind of cryptographic proof that
>>> the device is allowed to use the source address?
>> 
>> At risk of speaking for Brian, I think that this is intended to cover
>> the simple reachability verification implicit in TCP.  That is, proof
>> that the endpoint was able to see a packet that was sent to their
>> claimed address.

Or, yeah, what Martin said.

> I just would like to note that TCP has a three-way handshake for this purpose but also during the connection you have the ack number that is visible to the network and also provides some proof that the sender is able to receive packets at the indicated source address.

Yep. This indicates another way to split this question: how important is it to be able to distinguish spoofed from non-spoofed sources for initial packets in a flow, versus to be able to do so in the middle of a connection?


Thanks, cheers,

Brian

> 
> Mirja
> 
>> 
>> The verification provided by ICE also works.  There, it's not a
>> three-way handshake, but two independent request/response validations.
>> 
>> (I think that I see a companion to Brian's "what is an endpoint?" doc:
>> "what is a path?")
>> 
>

v2.23.0 | Report a Bug | By Email