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

Silvia Hagen <silvia.hagen@sunny.ch> Sun, 17 May 2015 17:28 UTC

Return-Path: <silvia.hagen@sunny.ch>
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 56CB81A88A3 for <v6ops@ietfa.amsl.com>; Sun, 17 May 2015 10:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 w5MeGCACnyVI for <v6ops@ietfa.amsl.com>; Sun, 17 May 2015 10:28:56 -0700 (PDT)
Received: from pianosa.iway.ch (pianosa.iway.ch [IPv6:2001:8e0:40:325::37]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D151A886E for <v6ops@ietf.org>; Sun, 17 May 2015 10:28:55 -0700 (PDT)
Received: from pianosa.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9198EE0814; Sun, 17 May 2015 19:28:53 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/2282.31750); Sun, 17 May 2015 19:28:53 +0200 (CEST)
Received: from owa.hextop.ch (owa.hextop.ch [212.25.0.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pianosa.iway.ch (Postfix) with ESMTPS; Sun, 17 May 2015 19:28:53 +0200 (CEST)
Received: from HEX02.hextop.ch ([212.25.0.68]) by hex02 ([212.25.0.68]) with mapi id 14.01.0438.000; Sun, 17 May 2015 19:28:52 +0200
From: Silvia Hagen <silvia.hagen@sunny.ch>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Enno Rey <erey@ernw.de>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices
Thread-Index: AQHQjwOc1Jlz46hQy0yE3Gbhq1u2w519XioAgAMRA0A=
Date: Sun, 17 May 2015 17:28:52 +0000
Message-ID: <F1D4404E5E6C614EB9D3083F4D15A7E7C4A5A3@hex02>
References: <20150515113728.GH3028@ernw.de> <555658DE.6080402@gmail.com>
In-Reply-To: <555658DE.6080402@gmail.com>
Accept-Language: de-CH, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [188.62.163.108]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ZpsVPypoF4pDjS4-jvGpPKhXlIc>
X-Mailman-Approved-At: Sun, 17 May 2015 11:50:44 -0700
Subject: Re: [v6ops] 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: Sun, 17 May 2015 17:42:48 -0000

Yes Brian, I fully support your viewpoint.

Learning to deal with IPv6 takes time, and we have to give it that time.  And give the vendors the time to learn where the pain points are and give them time but also expect them to find solutions.
And they will find solutions.

Silvia

-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:v6ops-bounces@ietf.org] Im Auftrag von Brian E Carpenter
Gesendet: Freitag, 15. Mai 2015 22:37
An: Enno Rey; v6ops@ietf.org
Betreff: Re: [v6ops] Extension Headers / Impact on Security Devices

Enno,
On 15/05/2015 23:37, Enno Rey wrote:

...
> As for the topic itself I'd like to summarize our position as follows:
> - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up.

I object to that logic. Firstly, the timescale is misleading: IPv6 deployment has been so painfully slow that you really can't look at the 17 year span for this argument; it's only within the last 5 years or so that the words "compelling"
and "Internet-scale" could be relevant. That's why the obvious issues in RFC 2460 were only fixed in 2013, by the way (RFC 7045). We haven't even had time for those fixes to reach deployment.

Secondly, "compelling" is entirely a matter of judgement. There's no possibility of a compelling case for something that is undeployable, and it's well known that because of faulty handling of new extension headers by middleboxes, no new extension headers are deployable today.

> - we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic.

Of course you won't, until middleboxes stop breaking them. Extensibility is for the future and unpredictable, by definition.

> - from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they are blocked at the _border_ of networks that have not yet managed to identify a compelling use case.

That is automatically a self-fulfilling prophecy. The new rules in RFC 7045 were carefully constructed to offer a way out of this. I hope your advice is to follow those rules and to insist on products that allow this (correct defaults, for example).

> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear soon (the main reason why we did not continue the IDPS research was that the involved student eventually delivered his thesis. one can probably find much more issues provided time & resources. following LANGSEC it might be impossible to "fix" all of them either).

I assume you are following documents like draft-ietf-6man-deprecate-atomfrag-generation,
RFC 7112, RFC 6946, etc. It isn't as if the IETF is unaware of the issues.

> Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case.

Well, Moore's law is stll with us, so I think that is plain wrong as products evolve, which is exactly why we should update the standards accordingly. Of course that applies to vendors, not operators.

> - the results of this (blocking) approach have been observed and documented by Jen & Fernando and others (Tim Chown).
> - now that "this vicious circle" has gained sufficient ground it will be evfixesen less incentivized to develop a compelling use case. which is why we do not expect to see one in the future.

It's possible, but that doesn't mean that the IETF should give up on extensibility.
We should continue to mitigate the problems, which is what we've been doing for several years, since they became apparent.

Nobody, I think, is arguing that the extensibility design in IPv6 is middlebox-friendly.
But that's history and we have to deal with it.

   Brian

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops