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

Ole Troan <otroan@employees.org> Mon, 18 May 2015 10:23 UTC

Return-Path: <otroan@employees.org>
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 C71AD1A88B9 for <v6ops@ietfa.amsl.com>; Mon, 18 May 2015 03:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 2gadT4S3vBqo for <v6ops@ietfa.amsl.com>; Mon, 18 May 2015 03:23:39 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872AF1A8879 for <v6ops@ietf.org>; Mon, 18 May 2015 03:23:36 -0700 (PDT)
Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 094DF6146; Mon, 18 May 2015 03:23:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=0G2D99SXFJlBOT5/7hECjAPysxY=; b= V/+OGsEgFd3oRez2qLnALUh+cc+Z9KIY46TU7lcbpcJoSgpW4Ivwy3P82ClBNOts 40W8UzR31n3PHlfDC/Nmx6CFFvY6sK5haSJPHIkjc0eGR6JDEGZGRAJEh5Wya0to qocYO+ccU1ONibk6KEMh7g1UmFGYJ77VDiSjTj9nvJk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=s0Zrg1rN/R96YHnVZWiJ3OyVRs gOSr093xzhPY3nz7jbz25p0kMobBvG4PEyxIksWJjAvInfmU7Q02aTtjhCUvigky ggqkO158LWZjajX3vG3tcNOAAT3W8fA6N6FB1rPz2T1XGlZw55iTe1ljs72M4BQh 0vaI5sG51g7pNk6dc=
Received: from gomlefisk.localdomain (unknown [173.38.220.33]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id CA6BD6128; Mon, 18 May 2015 03:23:35 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id EC0A344FCE4B; Mon, 18 May 2015 12:23:33 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2100\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9933A365-F4D8-4F6B-BA57-ED05CB3AD304"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Ole Troan <otroan@employees.org>
In-Reply-To: <20150515113728.GH3028@ernw.de>
Date: Mon, 18 May 2015 12:23:33 +0200
Message-Id: <7449B614-BF21-4AD8-A642-831D5B385B41@employees.org>
References: <20150515113728.GH3028@ernw.de>
To: Enno Rey <erey@ernw.de>
X-Mailer: Apple Mail (2.2100)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/W-3ae3QgCEJhp2jKNkd8RwRwCpM>
Cc: v6ops@ietf.org
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: Mon, 18 May 2015 10:23:40 -0000

Enno,

[…]

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

this is clearly wrong. FH, AH, ESP are all widely deployed.
any form of tunnelling is essentially either using the IP header as an extension header. including GRE.

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

open communication is a security nightmare.

cheers,
Ole