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

Enno Rey <erey@ernw.de> Wed, 17 June 2015 18:04 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 CB0511B2C91 for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 11:04:18 -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 RWNScnTxdzHD for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 11:04:16 -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 855BA1B2C90 for <v6ops@ietf.org>; Wed, 17 Jun 2015 11:04:15 -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 3EE3E74CA6 for <v6ops@ietf.org>; Wed, 17 Jun 2015 20:04:10 +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 1ABFB470 for <v6ops@ietf.org>; Wed, 17 Jun 2015 20:04:10 +0200 (CEST)
Received: by ws25.ernw.net (Postfix, from userid 1001) id E5ED0C49E3; Wed, 17 Jun 2015 20:04:09 +0200 (CEST)
Date: Wed, 17 Jun 2015 20:04:09 +0200
From: Enno Rey <erey@ernw.de>
To: v6ops@ietf.org
Message-ID: <20150617180409.GA17739@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> <20150617174315.GA17641@ernw.de> <5581B2DF.8040207@innovationslab.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5581B2DF.8040207@innovationslab.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/2ec2ZA_YI9QCAiOyP2AO4IgKK90>
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 18:04:19 -0000

On Wed, Jun 17, 2015 at 01:48:15PM -0400, Brian Haberman wrote:
> 
> > 
> > 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
> 
> If the device is trying to inspect application-layer data, it might as
> well act like the destination and re-assemble the fragments. Yes, this
> is costly processing, but it mitigates this bypass mechanism.

in theory yes. Given the majority of end host operating systems happily wait up to 60 seconds for "that last [potentially 42th] fragment" of a single datagram coming in, this is probably not an option for all those types of security controls (intrusion detectors, First Hop Security mechanisms, Infrastructure ACLs) expected to work mostly in wire speed. It is hence not an option for a number of networks using such techniques which is why they usually drop all extension headers except for AH, ESP and (in a few cases) FH.
Doing so is a reasonable decision from their side and will not exactly encourage widespread development of new services using extension headers. Which then raises the question: what's the benefit of this thing called extension headers which do not provide much use today and might - given there's a growing number of networks acting as described - not provide much use tomorrow? This thing then seems to add an undesirable layer of complexity.

thanks

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