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

Joe Touch <touch@isi.edu> Thu, 18 June 2015 22:32 UTC

Return-Path: <touch@isi.edu>
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 1B4EA1A1AAD for <v6ops@ietfa.amsl.com>; Thu, 18 Jun 2015 15:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pWiyu6N18sDa for <v6ops@ietfa.amsl.com>; Thu, 18 Jun 2015 15:32:44 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4631A00FD for <v6ops@ietf.org>; Thu, 18 Jun 2015 15:32:44 -0700 (PDT)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t5IMWJ2s011713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Jun 2015 15:32:22 -0700 (PDT)
To: Gert Doering <gert@space.net>, "Fred Baker (fred)" <fred@cisco.com>
References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <20150517191841.GA26929@ernw.de> <C07DF957-9A2D-4962-ABAA-DE61F5C5D533@cisco.com> <20150617081424.GA15514@ernw.de> <505DC30B-8ED1-4C75-A13B-FAC9D4E5348C@cisco.com> <20150618220058.GP67883@Space.Net>
From: Joe Touch <touch@isi.edu>
Message-ID: <558346F3.3050509@isi.edu>
Date: Thu, 18 Jun 2015 15:32:19 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <20150618220058.GP67883@Space.Net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: t5IMWJ2s011713
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/btJ9xPuEOcXqrAO2DFUAj8h6ew0>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "ipv6-wg@ripe.net" <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: Thu, 18 Jun 2015 22:32:45 -0000


On 6/18/2015 3:00 PM, Gert Doering wrote:
> Hi,
>
> On Wed, Jun 17, 2015 at 04:46:03PM +0000, Fred Baker (fred) 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 makes sense to require all of the HBH and routing headers in the 
first fragment.

The rest is impossible to mandate and irrelevant. Anything that looks 
far enough into a packet to need to find the transport header might be 
looking several layers of encapsulation in; that's acting as an 
endpoint, and ought to reassemble the packet at that point.

Joe