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

Enno Rey <erey@ernw.de> Fri, 19 June 2015 08:34 UTC

Return-Path: <erey@ernw.de>
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 0EA1F1A8742 for <v6ops@ietfa.amsl.com>; Fri, 19 Jun 2015 01:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 IKKUdw7Wr797 for <v6ops@ietfa.amsl.com>; Fri, 19 Jun 2015 01:34:15 -0700 (PDT)
Received: from mx2.ernw.net (mx2.ernw.net [212.102.247.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E200D1A700F for <v6ops@ietf.org>; Fri, 19 Jun 2015 01:34:14 -0700 (PDT)
Received: from mh1.ernw.net (unknown [172.31.1.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mh1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx2.ernw.net (Postfix) with ESMTPS id 8DA3B74F0E; Fri, 19 Jun 2015 10:34:10 +0200 (CEST)
Received: from ws25.ernw.net (ws25.ernw.net [172.31.100.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "ws25.ernw.net", Issuer "ernw ca1" (verified OK)) by mh1.ernw.net (Postfix) with ESMTPS id 4B922B49; Fri, 19 Jun 2015 10:34:10 +0200 (CEST)
Received: by ws25.ernw.net (Postfix, from userid 1001) id 26AF8C4936; Fri, 19 Jun 2015 10:34:10 +0200 (CEST)
Date: Fri, 19 Jun 2015 10:34:10 +0200
From: Enno Rey <erey@ernw.de>
To: Ole Troan <otroan@employees.org>
Message-ID: <20150619083410.GC39902@ernw.de>
References: <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150618220058.GP67883@Space.Net> <CE57FBE0-B6C0-423D-A7F6-4FFF20FD2C4A@employees.org> <20150619.093911.74722344.sthaug@nethelp.no> <4B24F577-E5F1-4E44-95BA-AEFD502C6BC2@employees.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4B24F577-E5F1-4E44-95BA-AEFD502C6BC2@employees.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/Qt3DBk0ciCtP5Cb881IPnnPnxMI>
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 08:34:17 -0000

Hi,

On Fri, Jun 19, 2015 at 09:56:20AM +0200, Ole Troan wrote:
> >>>> 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&
> >> 
> >> 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.
> 
> I don???t think that follows.

I would second the observation that this (subsequent action) actually happens.
Not least because many consider it a reasonable approach not to process and/or to drop something that induces complexity & insecurity and which at the same time is not needed by any service or application (read: all EHs except ESP and, maybe in some corner cases, AH+FH).


thanks

Enno




> 
> cheers,
> Ole



-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================