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

Enno Rey <erey@ernw.de> Wed, 17 June 2015 18:40 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 EAB651B2CD4 for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 11:40:33 -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 aqUl0cdlJTpM for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 11:40: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 90C211A1AA6 for <v6ops@ietf.org>; Wed, 17 Jun 2015 11:40: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 645D674CAC; Wed, 17 Jun 2015 20:40:27 +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 28279482; Wed, 17 Jun 2015 20:40:27 +0200 (CEST)
Received: by ws25.ernw.net (Postfix, from userid 1001) id D1785C49E4; Wed, 17 Jun 2015 20:40:26 +0200 (CEST)
Date: Wed, 17 Jun 2015 20:40:26 +0200
From: Enno Rey <erey@ernw.de>
To: Tore Anderson <tore@fud.no>
Message-ID: <20150617184026.GA17859@ernw.de>
References: <20150517191841.GA26929@ernw.de> <C07DF957-9A2D-4962-ABAA-DE61F5C5D533@cisco.com> <CAFU7BAR0YeGe7NbYTqNSAcMukGjAz6akWaVcODWVJwpTJKQhWQ@mail.gmail.com> <20150617.140235.74748217.sthaug@nethelp.no> <20150617201809.54a31cd2@envy.fud.no>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20150617201809.54a31cd2@envy.fud.no>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/jjptHWzjsEzFnFmHUhS6bBd0cIE>
Cc: v6ops@ietf.org, 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 18:40:34 -0000

Hi Tore,

On Wed, Jun 17, 2015 at 08:18:09PM +0200, Tore Anderson wrote:
> * sthaug@nethelp.no
> 
> > Back to IPv6: I might allow "interesting" IPv6 extension headers
> > within my own AS - because in such cases I have much more control.
> > There is no way I'm going to allow IPv6 packets with long chains of
> > "interesting" IPv6 header chains to pass my border routers. Either
> > they have short enough header chains that my border routers can
> > inspect the L4 info at line rate - or they get dropped.
> 
> Hi Steinar,
> 
> I wouldn't react to the above if you were operating an enterprise
> network, but considering you're an ISP and transit provider, I find the
> above rather surprising (and I do not mean that in a good way).
> 
> First, your customers might have a perfectly valid reason to send or
> receive IPv6 headers with IPv6 extension header chains you apparantly
> will drop at your border. FWIW, if I found out that my upstream
> arbitrarily dropped packets because they found them "interesting",
> breaking my applications

that brings us directly to the core of the debate: break "exactly which application?". there's no single application/service using EHs other than AH/ESP and, maybe in a few corner cases, FH today and I doubt we'll see some tomorrow (given developing such a thing is heavily de-incentivized by the growing number of operators mostly dropping EHs).

Taking into account that stateless ACLs of all router vendors we tested (results tb published soon) can be avoided/evaded by adding ~5 extension headers to datagrams I fully understand any operator who does not want SSH on its devices to be reachable from the Internet (over v6 with extension headers) and hence acts in a way similar to the one Steinar described.
I doubt Steinar loses many customers (due to "application breakage") by taking that path. In contrary I expect many of his customers valueing the increased level of device & network availability gained by eliminating an entire class of attacks.

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