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

sthaug@nethelp.no Fri, 19 June 2015 07:39 UTC

Return-Path: <sthaug@nethelp.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 C6D0B1A00EC for <v6ops@ietfa.amsl.com>; Fri, 19 Jun 2015 00:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 OjMzR3p6CKc5 for <v6ops@ietfa.amsl.com>; Fri, 19 Jun 2015 00:39:13 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 54FE71A00E9 for <v6ops@ietf.org>; Fri, 19 Jun 2015 00:39:12 -0700 (PDT)
Received: (qmail 36071 invoked from network); 19 Jun 2015 07:39:11 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 19 Jun 2015 07:39:11 -0000
Date: Fri, 19 Jun 2015 09:39:11 +0200 (CEST)
Message-Id: <20150619.093911.74722344.sthaug@nethelp.no>
To: otroan@employees.org
From: sthaug@nethelp.no
In-Reply-To: <CE57FBE0-B6C0-423D-A7F6-4FFF20FD2C4A@employees.org>
References: <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150618220058.GP67883@Space.Net> <CE57FBE0-B6C0-423D-A7F6-4FFF20FD2C4A@employees.org>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp-2
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/xdR0Dh_dTbJKcCEYdEvOmgPRrMg>
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: Fri, 19 Jun 2015 07:39:15 -0000

> >> Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)? I think Fernando would support such a statement (I think I have "heard" him make such a statement).
> > 
> > It would certainly make *me* happier$,1s&(B
> 
> done.
> RFC7112.

As I wrote in another mail,

> It may be relevant to ask for RFC 7112 support next time we're doing
> an equipment RFQ (in a few years).
...
> But until RFC 7112 support is available, I believe we will
> see a significant amount of breakage for IPv6 extension headers - and
> header chains will be limited to significantly less than 1280 bytes.

And until such support is available, we have to deal with the current
mess. Which may imply more filtering than some people would like.

Steinar Haug, AS 2116