Re: [quicwg/base-drafts] Fix for off-path migration attack (#2033)

Kazuho Oku <notifications@github.com> Wed, 21 November 2018 06:45 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766AA128766 for <quic-issues@ietfa.amsl.com>; Tue, 20 Nov 2018 22:45:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.47
X-Spam-Level:
X-Spam-Status: No, score=-8.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 haKJ1o09QyXv for <quic-issues@ietfa.amsl.com>; Tue, 20 Nov 2018 22:45:47 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7742A1277BB for <quic-issues@ietf.org>; Tue, 20 Nov 2018 22:45:47 -0800 (PST)
Date: Tue, 20 Nov 2018 22:45:46 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1542782746; bh=/TVwVxFdmy2pxHfNkFXezNSNv2RDFkG7SaCGMJ5gCFs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FrAM3SMBL/0JI5f82iMCECOPLf7N6JEemE1SEgkftBigmicenhN1ir/9HmKNWUOUX A8CcqooL+a+yU5ita3wrbsl2FLRqvR/OoM8XZoZxbTgsYkhzvfwt0vzkuUsl1LwGLL xTG0ZG1vZ4gxWc+bAo2UZOqVawizJhdZ7v5ucGGo=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab7a75a9fdbd507597ae9b7007a3091881117885ce92cf00000001180cc11a92a169ce16d3ac5a@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2033/c440556206@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2033@github.com>
References: <quicwg/base-drafts/pull/2033@github.com>
Subject: Re: [quicwg/base-drafts] Fix for off-path migration attack (#2033)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bf4ff1a60530_5bb33f9c002d45c03523f7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/iO5dvK2iEwSjwHNVje_wqlrDVBo>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Nov 2018 06:45:49 -0000

Thank you for writing down the PR.

I know that this question has been asked before, but do we need PATH_CHALLENGE and PATH_RESPONSE to verify NAT rebinding?

IIUC a client has only one path that can be used for send non-probing packets. Therefore, a server receiving a non-probing packet (with a PN greater than what it has seen before) can be used as a way to determine the current active path.

So to me, it seems that just using PING will be sufficient for the server to verify what the client thinks as the current path. In other words, there is no reason for a _server_ to send PATH_CHALLENGE (and for a client to send PATH_RESPONSE).

The reason I raise the question, even though I understand that the PATH_CHALLENGE / PATH_RESPONSE is nevertheless required for the client to "probe" for a new path, is because removing the requirement for the server to send a challenge / wait for response seems like a simplification (at the cost of increasing asymmetry).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2033#issuecomment-440556206