[v6ops] Security Considerations for draft-gont-v6ops-ipv6-ehs-in-real-world
Fernando Gont <fgont@si6networks.com> Wed, 03 September 2014 17:23 UTC
Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C6D1A0361 for <v6ops@ietfa.amsl.com>; Wed, 3 Sep 2014 10:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 5MKcm9xLqpl8 for <v6ops@ietfa.amsl.com>; Wed, 3 Sep 2014 10:23:51 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2D61A0235 for <v6ops@ietf.org>; Wed, 3 Sep 2014 10:23:50 -0700 (PDT)
Received: from [2001:5c0:1000:a::d3d] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XPEHZ-0003cG-9d; Wed, 03 Sep 2014 19:23:45 +0200
Message-ID: <54074E9B.5030007@si6networks.com>
Date: Wed, 03 Sep 2014 14:23:39 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: IPv6 Operations <v6ops@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/a85U3dGB1Mp-uRxysvluVMOQTyg
Cc: draft-gont-v6ops-ipv6-ehs-in-real-world@tools.ietf.org
Subject: [v6ops] Security Considerations for draft-gont-v6ops-ipv6-ehs-in-real-world
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Sep 2014 17:23:55 -0000
Folks, Based on the recent discussions, we're planning to update Section 5.2 (which contains all the discussion about the ICMP-based attack vector) of the aforementioned I-D as follows. Please let us know if you have any comments: ---- cut here ---- 5.2. A possible attack vector The widespread filtering of IPv6 packets employing IPv6 Extension Headers can, in some scenarios, be exploited for malicious purposes: if packets employing IPv6 EHs are known to be filtered on the path from one system (say, "A") to another (say, "B"), an attacker could cause packets sent from A to B to be dropped by sending a forged ICMPv6 Packet Too Big (PTB) [RFC4443] error message to A (with a Next-Hop MTU smaller than 1280), such that subsequent packets from A to B include a fragment header (i.e., they result in atomic fragments [RFC6946]). Possible scenarios where this attack vector could be exploited include (but are not limited to): o Communication between any two systems through to public network (e.g., client from/to server or server from/to server), where packets with IPv6 extension headers are filtered by some intermediate router o Communication between two BGP peers employing IPv6 transport, where these BGP peers implement ACLs to drop IPv6 fragments (to avoid control-plane attacks) The aforementioned attack vector is exacerbated by the following factors: o The attacker does not need to forge the IPv6 Source Address of his attack packets. Hence, deployment of simple BCP38 filters will not help as a counter-measure. o Only the IPv6 addresses of the IPv6 packet embedded in the ICMPv6 payload need to be forged. While one could envision filtering devices enforcing BCP38-style filters on the ICMPv6 payload, the use of extension (by the attacker) could make this difficult, if at all possible. o Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and documented in [RFC5927]. It should be noted that in some cases, such as when an ICMPv6 error message has (supposedly) been elicited by a connection-less transport protocol (or some other connection-less protocol being encapsulated in IPv6), it may be virtually impossible to perform validation checks on the received ICMPv6 error messages. And, because of IPv6 extension headers, the ICMPv6 payload might not even contain any useful information on which to perform validation checks. o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big" error messages, the Destination Cache [RFC4861] is usually updated to reflect that any subsequent packets to such destination should include a Fragment Header. This means that a single ICMPv6 "Packet Too Big" error message might affect multiple communication instances (e.g., TCP connections) with such destination. o A node cannot simply "just filter/drop all incoming ICMPv6 Packet Too Big error messages", or else it would create a PMTUD blackhole. Possible mitigations for this issue include: o Filtering incoming ICMPv6 Packet Too Big error messages that advertise a Next-Hop MTU smaller than 1280 bytes. o Artificially reducing the MTU to 1280 bytes and filter incoming ICMPv6 PTB error messages. Both of these mitigations come at the expense of possibly preventing communication through SIIT [RFC6145] that rely on IPv6 aomic fragments (see [I-D.gont-6man-deprecate-atomfrag-generation]), and also implies that the filtering device has the ability to filter ICMP PTB messages based on the contents of the MTU field. [I-D.gont-6man-deprecate-atomfrag-generation] has recently proposed to deprecate the generation of IPv6 atomic fragments, and update the SIIT [RFC6145] such that it does not rely on ICMPv6 atomic fragments. Thus, any of the above mitigations would eliminate the attack vector without any interoperability implications. ---- cut here ---- Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- [v6ops] Security Considerations for draft-gont-v6… Fernando Gont
- Re: [v6ops] Security Considerations for draft-gon… Mark Andrews
- Re: [v6ops] Security Considerations for draft-gon… Brian E Carpenter
- Re: [v6ops] Security Considerations for draft-gon… Mark Andrews
- Re: [v6ops] Security Considerations for draft-gon… Brian E Carpenter
- Re: [v6ops] Security Considerations for draft-gon… Fernando Gont
- Re: [v6ops] Security Considerations for draft-gon… Fernando Gont