Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices

Enno Rey <erey@ernw.de> Wed, 17 June 2015 17:43 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 B3EA01B2ADE for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 10:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6QtYjDt7fT1T for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 10:43:24 -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 501281B2C60 for <v6ops@ietf.org>; Wed, 17 Jun 2015 10:43:17 -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 C1ED874CA1; Wed, 17 Jun 2015 19:43:15 +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 9E292466; Wed, 17 Jun 2015 19:43:15 +0200 (CEST)
Received: by ws25.ernw.net (Postfix, from userid 1001) id 7B9A6C49E1; Wed, 17 Jun 2015 19:43:15 +0200 (CEST)
Date: Wed, 17 Jun 2015 19:43:15 +0200
From: Enno Rey <erey@ernw.de>
To: "Fred Baker (fred)" <fred@cisco.com>
Message-ID: <20150617174315.GA17641@ernw.de>
References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <20150517191841.GA26929@ernw.de> <C07DF957-9A2D-4962-ABAA-DE61F5C5D533@cisco.com> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/2g2-SrZBs3PyA1b9u3Kc99-4nVA>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "ipv6-wg@ripe.net" <ipv6-wg@ripe.net>
Subject: Re: [v6ops] [ipv6-wg] 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: Wed, 17 Jun 2015 17:43:32 -0000

Fred,

On Wed, Jun 17, 2015 at 04:46:03PM +0000, Fred Baker (fred) wrote:
> 
> 
> Cutting to the chase, on the surface it looks like most of the cases you specified conform to the sequence rule, with the exception of one that has three Destination Option Headers. What I *think* you're pointing out is (from your PDF) that this is part of a sequence of messages, one of which is fragmented, accepted by the intrusion detector, and not accepted by the ultimate host (perhaps a TCP checksum failed?), and as a result bypasses the signature that the intrusion detector is looking for. The issue wasn't that the sequence was incorrect, in most cases; it was that the intrusion detector made a different choice than the end host.

Let's put it slightly different: the intrusion detector is supposed to detect/block certain application layer attacks. Which it does as long as those come in/pass by without extension headers/fragmentation.
Once the attack packets are crafted in certain ways, the intrusion detector let's them through, the end host happily reassembles and gets hit. The end host does so as the overall datagram does not violate RFC 2460's (dubious) liberty. The detector is "blind" as parsing a single datagram split into an arbitrary number of fragments with an arbitrary number of extension headers in a (mostly) arbitrary order is a, well, complex task.
It's not only intrusion detectors facing this type of difficulty, it's other "black list approach" security controls (like so-called First Hop Security features or Infrastructure ACLs), too. [see, for example, http://www.insinuator.net/2015/01/dhcpv6-guard-do-it-like-ra-guard-evasion/).

> 
> Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)?

'm tempted to reply that this would make the Internet world a safer place (without losing any current functionality) and might speeden up overall IPv6 deployment, as some organizations had one (for some of them: severe) concern less. So it's not about my personal happiness; though the factors mentioned might actually contribute to that as well ;-).

>From that angle RFC 7112 is certainly a step into the right direction. It's just not widely implemented - while IPv6 is "finally here" - and it doesn't "solve" certain cases (see the link above).
That's why I think that a major revision of the whole extension header concept is needed.

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
=======================================================