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

Tore Anderson <tore@fud.no> Wed, 17 June 2015 19:12 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 F0D111A1A94 for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 12:12:43 -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 kcobuA8HZYbY for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 12:12:42 -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 9B8A41A017C for <v6ops@ietf.org>; Wed, 17 Jun 2015 12:12:23 -0700 (PDT)
Received: from [2a02:fe0:c412:1fe0::2] (port=53379 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 1Z5Il1-0005Q3-BG; Wed, 17 Jun 2015 21:12:19 +0200
Date: Wed, 17 Jun 2015 21:12:18 +0200
From: Tore Anderson <tore@fud.no>
To: Enno Rey <erey@ernw.de>
Message-ID: <20150617211218.677e5a88@envy.fud.no>
In-Reply-To: <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> <20150617184026.GA17859@ernw.de>
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/k1pEwJ0ddp7wb1zi1N8mU4QrbRw>
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 19:12:44 -0000

Hi Enno,

* Enno Rey

> On Wed, Jun 17, 2015 at 08:18:09PM +0200, Tore Anderson wrote:
> > 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?"

Well, ESP at least. And, by extension, any protocol that might be
carried inside ESP, so pretty much all of them.

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

There is a big difference between an operator dropping all packets with
EHs that are destined for *his own devices/routers* (I have no problem
with that - your devices, your rules), and an operator that drops
*transit* traffic destined for his customers because his routers cannot
understand/parse/filter its L4/EH payload.

In my opinion, an ISP/IP transit network shouldn't even attempt to
parse the L4/EH payload in customer traffic (except if the customer
asks for it of course), it should just deliver the packets.

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

The first operator I mentioned above won't lose any customers because
his filtering activities doesn't impact customer traffic. The second
operator would lose my business, at least. And probably others' too, as
business customers might want their site2site IPSEC tunnels to work,
residental customers might want their Xbox One online gaming to work,
and so on.

Tore