[v6ops] Extension Headers / Impact on Security Devices

Enno Rey <erey@ernw.de> Fri, 15 May 2015 11:37 UTC

Return-Path: <erey@ernw.de>
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 57E0E1A0161 for <v6ops@ietfa.amsl.com>; Fri, 15 May 2015 04:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 KBWr3Ch7Eyym for <v6ops@ietfa.amsl.com>; Fri, 15 May 2015 04:37:32 -0700 (PDT)
Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (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 982071A00ED for <v6ops@ietf.org>; Fri, 15 May 2015 04:37:30 -0700 (PDT)
Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id CF4806226B; Fri, 15 May 2015 13:37:28 +0200 (CEST)
Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id ACA09DCE; Fri, 15 May 2015 13:37:28 +0200 (CEST)
Received: by ws25.ernw.net (Postfix, from userid 1001) id 8685AC49CD; Fri, 15 May 2015 13:37:28 +0200 (CEST)
Date: Fri, 15 May 2015 13:37:28 +0200
From: Enno Rey <erey@ernw.de>
To: v6ops@ietf.org
Message-ID: <20150515113728.GH3028@ernw.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/X4k7PyYq1VMpErRlpvcpme_IJSg>
Subject: [v6ops] Extension Headers / Impact on Security Devices
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: Fri, 15 May 2015 11:37:34 -0000

All,

yesterday's IPv6 WG session at the RIPE meeting saw another debate on extension headers.
Pls allow to submit our contribution to v6ops as well. Let me know if you think that the 6man mailing list would be the more appropriate place.

Here's some material/sources we'd like to bring up:

- this is a paper laying out how we could circumvent some major (both commercial and FOSS) IDPS solutions in their at the time of testing latest versions, by various combinations of extension headers and fragmentation:
https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf.

- here's some thoughts and preliminary results of tests performed to circumvent stateless ACLs:
http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/.
http://www.insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-security/.

We have a (somewhat) ongoing research project looking more closely on the interaction of ACLs and extension headers. For the moment I can only state that it's not just Cisco who are "affected". More results will be available in some months.

As for the topic itself I'd like to summarize our position as follows:
- it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up.
- we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic.
- from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they are blocked at the _border_ of networks that have not yet managed to identify a compelling use case.
- looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear soon (the main reason why we did not continue the IDPS research was that the involved student eventually delivered his thesis. one can probably find much more issues provided time & resources. following LANGSEC it might be impossible to "fix" all of them either).
Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case.
- the results of this (blocking) approach have been observed and documented by Jen & Fernando and others (Tim Chown).
- now that "this vicious circle" has gained sufficient ground it will be even less incentivized to develop a compelling use case. which is why we do not expect to see one in the future.

===

Everybody have a great weekend

Best

Enno




-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

----- End forwarded message -----

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================