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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 26 May 2015 23:37 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 611661B3323 for <v6ops@ietfa.amsl.com>; Tue, 26 May 2015 16:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 aiQw7OBTc6yM for <v6ops@ietfa.amsl.com>; Tue, 26 May 2015 16:37:52 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A121B3321 for <v6ops@ietf.org>; Tue, 26 May 2015 16:37:52 -0700 (PDT)
Received: by pdea3 with SMTP id a3so101526536pde.2 for <v6ops@ietf.org>; Tue, 26 May 2015 16:37:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Tll4YF9tKtzh+RGq2e35iJf7HJWWKWIc9nD9FHn2/EM=; b=IN3EufuchSR8kjCBiZ7zBkasvqP8x5+pKvJWXWLT9HnM3ylHMvMUpSnJAOupOmeM0i rhdDwa8XWv6frz3tX8zKoElUfrW7bqUy17mydyo8Iu+VOkRHIhfuneFu2/A7kUhrp6oG aw6o6r9zsFmYEkinZuJk0ia/lPI2COV6E/TeIHwmozUXOuo7VeOoOgeMTXxXpalM7EK4 xrawK+6V3Zcsta64V2YFR6weewCmTEd6N3C3F+7yCijjw3f6cuxMm84+3NJdSZH64uJM 7aruhumPadMkEP1Kce9/SyZuXDzI0I0HQAR3N4Ym2ciAfwXEqNXcFQFDGwshovRelZiK QW+g==
X-Received: by 10.66.142.169 with SMTP id rx9mr54140799pab.84.1432683471749; Tue, 26 May 2015 16:37:51 -0700 (PDT)
Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id bn7sm14218953pac.22.2015.05.26.16.37.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 16:37:50 -0700 (PDT)
Message-ID: <556503CF.4030101@gmail.com>
Date: Wed, 27 May 2015 11:37:51 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>, v6ops@ietf.org
References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com> <F6AA9AEA-49F0-488C-84EA-50BE103987C8@nominum.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu>
In-Reply-To: <5564FE3F.4050102@isi.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/u_3BbeW34cY3IR7mla-mwTzD5xU>
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: Tue, 26 May 2015 23:37:53 -0000

On 27/05/2015 11:14, Joe Touch wrote:
> 
> 
> On 5/26/2015 4:02 PM, Brian E Carpenter wrote:
>> On 20/05/2015 08:59, Joe Touch wrote:
> ...
>>>> No. RFC 2460 makes it clear that hops don't modify extension headers
>>>> (except for shuffling within a routing header).
>>>
>>> HBH headers are the exception and can be modified in-transit, which
>>> would affect a transport-offset header.
>>
>> I don't get where RFC 2460 allows that.
> 
> Section 4 states:
> 
>    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.
> ...
> 
>    The exception referred to in the preceding paragraph is the Hop-by-
>    Hop Options header, which carries information that must be examined
>    and processed by every node along a packet's delivery path, including
>    the source and destination nodes.
> 
> In addition, RFC2460 defines a bit to handle when changes to such
> options occurs en-route:
> 
>       1 - Option Data may change en-route
> 
> What is the purpose of that bit if the data can never change en-route?
> 
> Such changes can affect the content and *length* of these options.

Oh yuck. I suspect that allowing a length change is an unintended side
effect, but you're correct that it isn't forbidden. I've certainly
always read that text as allowing an update of the current value
of the content, not an increase in the length.

     Brian