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

Enno Rey <erey@ernw.de> Wed, 17 June 2015 14:00 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 520F21ACD5A for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 07:00:44 -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 OjVY8SKI295b for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 07:00:40 -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 8BC871ACD58 for <v6ops@ietf.org>; Wed, 17 Jun 2015 07:00:34 -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 F37CF7492E; Wed, 17 Jun 2015 16:00:32 +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 B30EEFCD; Wed, 17 Jun 2015 16:00:32 +0200 (CEST)
Received: by ws25.ernw.net (Postfix, from userid 1001) id 8AD49C4102; Wed, 17 Jun 2015 16:00:32 +0200 (CEST)
Date: Wed, 17 Jun 2015 16:00:32 +0200
From: Enno Rey <erey@ernw.de>
To: Jen Linkova <furry13@gmail.com>
Message-ID: <20150617140032.GB16806@ernw.de>
References: <CAFU7BAR0YeGe7NbYTqNSAcMukGjAz6akWaVcODWVJwpTJKQhWQ@mail.gmail.com> <20150617.140235.74748217.sthaug@nethelp.no> <CAFU7BARNa--MEuOzH5ZsBJ+hY8hCxUH4tVDcSEP95BdkmooLgw@mail.gmail.com> <20150617.152750.41635871.sthaug@nethelp.no> <20150617133328.GB16716@ernw.de> <CAFU7BATv3U7TtSnM8Litneq+xGvXmmHLBHHz0HFGE=AjoYeSHg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAFU7BATv3U7TtSnM8Litneq+xGvXmmHLBHHz0HFGE=AjoYeSHg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/TciGSPf2e05Z1lZfnjfq2eF7jCM>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "ipv6-wg@ripe.net IPv6" <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 14:00:44 -0000

Hi,

On Wed, Jun 17, 2015 at 03:41:01PM +0200, Jen Linkova wrote:
> On Wed, Jun 17, 2015 at 3:33 PM, Enno Rey <erey@ernw.de> wrote:
> >> I see *large* variable length headers, in combination with complex
> >> parsing rules, as the problem.
> >
> > (*large* variable headers) exactly, plus fragmentation
> 
> Fragmentation is not specific to IPv6, is it?

right
[even though I'm in the camp of "deprecate fragmentation as a whole" ;-), but let's not open this can of worms here].
BUT: fragmentation becomes a (then somewhat IPv6 specific) huge problem space once you have a datagram containing, say, 20 extension headers of partially variable lenght & pretty much arbitrary order, split into, say, 50 fragments. [again, see https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf].

Such a datagram would be fully valid as of today/RFC2460.

Yes, we're aware of RFC7112. It's just: no OS we know and no devices we're aware of (feel free to provide pointers) implement RFC 7112 as of today. but many attack tools implement the techniques mentioned above. Which is why quite some operators (in particular, but not only) from enterprise and managed service provider/cloud space drop all EHs except, maybe, AH+ESP.

thanks

Enno




 And, as the fragment
> header itself is just 8 bytes (AFAIR, too lazy to check ;)) - I'd not
> classify it as *large* variable header.
> 
> > and "ambiguities" wrt fragmentable vs. unfragmentable part and how headers point to the next one once there's a cut between them due to fragmentation. the, what we consider, "problem space" is much larger, unfortunately.
> 
> Has not RFC7112 addressed this particular problem?




> 
> -- 
> SY, Jen Linkova aka Furry

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