Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 13 October 2014 07:31 UTC

Return-Path: <swmike@swm.pp.se>
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 8A4C81A88B9; Mon, 13 Oct 2014 00:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.223
X-Spam-Level:
X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 geltaRjASGVL; Mon, 13 Oct 2014 00:31:56 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12511A88B7; Mon, 13 Oct 2014 00:31:56 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1FD46A2; Mon, 13 Oct 2014 09:31:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413185515; bh=C93cgaL71FWfshnw2cV7UkBeS+OK7DzylvzHdzVUUv8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WOQjD+g8DhFCu7GWEtIfiR25PtwdhFD1voTmzW4zrn+6SGTWSMuGt469xSaeDbZP4 pUmyScwRbWyk5nSHyPWitAA4P3V9D8AwaHPebyqc+rcm6jwyWe2mEZMe4zsBNIbYhr K4UhPAIaA4xcvrjDtSvBkIrtlU33n+S136VYaOEE=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 15056A1; Mon, 13 Oct 2014 09:31:55 +0200 (CEST)
Date: Mon, 13 Oct 2014 09:31:55 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ole Troan <otroan@employees.org>
In-Reply-To: <B499E06A-887A-4A9B-8FB9-EE2D3A1F9095@employees.org>
Message-ID: <alpine.DEB.2.02.1410130926090.14735@uplift.swm.pp.se>
References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <alpine.DEB.2.02.1410130907280.14735@uplift.swm.pp.se> <B499E06A-887A-4A9B-8FB9-EE2D3A1F9095@employees.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rswykNx_VpeZUpU-hPzuEx2sVZc
Cc: opsec <opsec@ietf.org>, v6ops <v6ops@ietf.org>
Subject: Re: [v6ops] [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers
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, 13 Oct 2014 07:31:58 -0000

On Mon, 13 Oct 2014, Ole Troan wrote:

>>> shouldn't this be a draft authored by operators? giving operational recommendations coming out of... well, actual operations?
>>
>> Well, another way of looking at this is that operators just want things to work as well as they can, so they need guidance from vendors and protocol designers.
>>
>> Isn't this a BCOP style document? I believe at least one of the authors is active in one or more BCOP group.
>
> the protocol designer's recommendation does appear pretty clear, RFC2460:
>
>   "With one exception, extension headers are not examined or processed
>   by any node along a packet's delivery path, until the packet reaches
>   the node (or each of the set of nodes, in the case of multicast)
>   identified in the Destination Address field of the IPv6 header."
>
> my point is that I don't think the IETF should be making recommendations about how they should run their network, and certainly not make recommendations that are at odds with the functioning of the protocol.

You mean you don't want non-operators in the IETF to make recommendations?

The way I see it is that vendors are making equipment based on customer 
requirements. Since a lot of vendor equipment obviously inspect packets, 
including those with extension headers along the way (probably to do 
ACLs), then this equipment is already violating the functioning of the 
protocol (which of course is nothing new).

My opinion is that it's better to look at common implementation and 
document and give recommendations where this differs from the blueprints.

What I don't like is that if we follow along this path we're basically 
saying "extension headers don't work on the Internet" which has the 
implication that fewer will use them, meaning the vendors that don't 
follow the protocol designer intention has little downside, and thus 
perpetuating the problem.

I don't know how to make it right though. I would like to see extension 
headers working well, but I also understand that people want to be able to 
do filtering.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se