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

Tore Anderson <tore@fud.no> Wed, 17 June 2015 18:18 UTC

Return-Path: <tore@fud.no>
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 957631B2CD1 for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 11:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 jId0-sC_TMxj for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 11:18:18 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF631B2CB9 for <v6ops@ietf.org>; Wed, 17 Jun 2015 11:18:17 -0700 (PDT)
Received: from [2a02:fe0:c412:1fe0::2] (port=53011 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <tore@fud.no>) id 1Z5Huc-0003ys-Hg; Wed, 17 Jun 2015 20:18:10 +0200
Date: Wed, 17 Jun 2015 20:18:09 +0200
From: Tore Anderson <tore@fud.no>
To: sthaug@nethelp.no
Message-ID: <20150617201809.54a31cd2@envy.fud.no>
In-Reply-To: <20150617.140235.74748217.sthaug@nethelp.no>
References: <20150517191841.GA26929@ernw.de> <C07DF957-9A2D-4962-ABAA-DE61F5C5D533@cisco.com> <CAFU7BAR0YeGe7NbYTqNSAcMukGjAz6akWaVcODWVJwpTJKQhWQ@mail.gmail.com> <20150617.140235.74748217.sthaug@nethelp.no>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/c2NMQFpoBMdZCreuF-gL3Ys0jFY>
Cc: ipv6-wg@ripe.net, v6ops@ietf.org
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:18:19 -0000

* 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 in the process, I would not remain a customer
of theirs for long.

Second, the packets might be encrypted using ESP. In that case, you
have absolutely no way of knowing if the extension header chain is long
enough to be "interesting enough to drop", or if the ESP header is the
only extension header there is ("short enough to forward"). What do you
do then?

Third, your border routers obviously cannot inspect the L4 info in an
ESP-encrypted packet at all, line rate or not. Does that mean you drop
all ESP packets at your AS borders? I really hope not.

Tore