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

Ray Hunter <v6ops@globis.net> Wed, 27 May 2015 11:08 UTC

Return-Path: <v6ops@globis.net>
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 041E01ACDD1 for <v6ops@ietfa.amsl.com>; Wed, 27 May 2015 04:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.081
X-Spam-Level: ***
X-Spam-Status: No, score=3.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 gxFUCUaGke25 for <v6ops@ietfa.amsl.com>; Wed, 27 May 2015 04:08:37 -0700 (PDT)
Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id 967961ACDC2 for <v6ops@ietf.org>; Wed, 27 May 2015 04:08:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7CB3D401AE; Wed, 27 May 2015 13:08:35 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8raS6MN1PmoQ; Wed, 27 May 2015 13:08:33 +0200 (CEST)
Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 255B7401AD; Wed, 27 May 2015 13:08:33 +0200 (CEST)
Message-ID: <5565A588.708@globis.net>
Date: Wed, 27 May 2015 13:07:52 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
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> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com>
In-Reply-To: <55650E82.3090407@gmail.com>
Content-Type: multipart/alternative; boundary="------------020807060505080605050702"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ULKHVAAG-BYirrGFu007KH1GO2E>
Cc: v6ops@ietf.org
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: Wed, 27 May 2015 11:08:39 -0000


Brian E Carpenter wrote:
> On 27/05/2015 11:56, Joe Touch wrote:
>> On 5/26/2015 4:37 PM, Brian E Carpenter wrote:
>>> 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.
>> FWIW, I don't see anything that prohibits adding headers either.
>
> "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."
>
> To me that clearly implies not adding (which is a form of processing).
>
>     Brian
>
I don't see how that text prohibits adding additional hop by hop headers 
though.

e.g. If none are present, then one could theoretcially be added en route.

That could form the basis of a nice resource depletion attack for all 
downstream devices.

[not that I expect anyone to actually process hop by hop headers in the 
real world]
>> Not that I think that's a great thing to play with, but seems in-scope too.
>>
>> Joe
>>
>
>