[quicwg/base-drafts] ICMP DOS (#2063)

MikkelFJ <notifications@github.com> Wed, 28 November 2018 11:23 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 56C83130EA2 for <quic-issues@ietfa.amsl.com>; Wed, 28 Nov 2018 03:23:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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 kdi4Xi6ngPU4 for <quic-issues@ietfa.amsl.com>; Wed, 28 Nov 2018 03:23:31 -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 81C90130EBE for <quic-issues@ietf.org>; Wed, 28 Nov 2018 03:23:31 -0800 (PST)
Date: Wed, 28 Nov 2018 03:23:30 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543404210; bh=/+CQrxfOjlpgHAGQ6RyglpYwbzsg88aAFcACu87Ip0k=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=lFU06H8Jl0WTcb/fQrlv41FbV/BcnrJaHfD8lB8K2JWC+3aKOxZYJwD8T+QzD/WxT 3+lwzLBGNNIidYxjnfTQxT2cOSc/K7T0uWA9tkIyFIOmpm1tNn/VfK18fweAws4RA2 JZhbJc38RU54+j7qqIs1eXZlmdqau/r783OgsdM8=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abb2c142741d0b593d0eddf6b708610ff4f3e9cbc892cf0000000118163cb292a169ce16f604d0@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2063@github.com>
Subject: [quicwg/base-drafts] ICMP DOS (#2063)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bfe7ab253109_65da3fb9996d45c43362e5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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/KPVipPckxNdeoLdigPJz4960P3c>
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, 28 Nov 2018 11:23:33 -0000

I read through the recent PR #2036 which cleans up the packet size discussion. The text does touch upon ICMP denial of service attacks but I'm afraid the protection is too fragile because it is required that transmission stops on a path where PMTU is suspected to have been decreased. It is not explicitly stated (as far as I can tell) that ICMP packet too big is used for this decision, but it is used in PMTU discovery.

There is no major problem with attacks on discovery, but if ICMP can later close a connection, that is a big problem.

There is protection against off path attackers, but it is easy for a man on the side attack to generate ICMP messages that would pass validation. This only requires one compromised machine on a LAN.

This issue also relates to the ongoing discussion on protection against the initial handshake by man on the side stopping handshake by generating invalid early handshake packets, only here it can happen long after the connection is established.

A possible mitigation could be that a path should not be dropped based in ICMP messages alone but only after one or two new new PMTU probes.


-- 
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/issues/2063