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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 26 May 2015 23:02 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 9F95A1B32DC for <v6ops@ietfa.amsl.com>; Tue, 26 May 2015 16:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 9dXPq7IIWnu7 for <v6ops@ietfa.amsl.com>; Tue, 26 May 2015 16:02:13 -0700 (PDT)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 08B811B32D8 for <v6ops@ietf.org>; Tue, 26 May 2015 16:02:13 -0700 (PDT)
Received: by pacwv17 with SMTP id wv17so103343867pac.2 for <v6ops@ietf.org>; Tue, 26 May 2015 16:02:12 -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=6dwsuZXZdaH9N30B5JKYIC602kgchQu6LFdIGkJ0BeE=; b=cuqcXk3/r6Ax3rA3Y7bMYGyOieZUoVy3IDve2xm2zhZOiQyywr1/wB6Ch+rwL+kG+1 DkPmbjp3IPVnW14hwXkrm+L0LmT+xdZsKWGeWuEeObaVp4G79bNT4LCblr5BMhgbNi0T KDSN2+gldeTlmv1DQSI2lIyM5jyK3LVipwZVB+pRUi8BUUSrso8+lC+dvjsWkz0hzZ/a 8VQA1teiMUgfnHiaKgLhsxxpczSzFZFfYRQztpN+oiypMMMSqiCczA6dyuNhjrOlttNq oxldT/wIDaWV7e3gE4ldQFFx8d5RABr95wQX9zRkV2QfpLk6dONvsfL4dds20rSspiXH Ng+A==
X-Received: by 10.68.204.133 with SMTP id ky5mr53216971pbc.67.1432681332705; Tue, 26 May 2015 16:02:12 -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 pw9sm14184395pac.27.2015.05.26.16.02.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 16:02:10 -0700 (PDT)
Message-ID: <5564FB74.5020303@gmail.com>
Date: Wed, 27 May 2015 11:02:12 +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>
In-Reply-To: <555BA43F.8010303@isi.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/-yzh2TPAjTcnGrqjmdijyzGbEDg>
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:02:14 -0000

On 20/05/2015 08:59, Joe Touch wrote:
> 
> 
> On 5/19/2015 1:48 PM, Brian E Carpenter wrote:
>> On 20/05/2015 06:51, Joe Touch wrote:
>>>
>>>
>>> On 5/19/2015 11:14 AM, Ted Lemon wrote:
>>>> On May 19, 2015, at 12:15 AM, Fernando Gont <fgont@si6networks.com> wrote:
>>>>> * The size of IPv4 options is very limited (well under 128 bytes)
>>>>>
>>>>> * IYou only need to look at the IHL of the IPv4 packet to be able to
>>>>> jump to the layer-4 protocol header. -- there's no such a thing in IPv6.
>>>>
>>>> I think it's generally agreed that we can expect devices to be somewhat limited as to how far into the packet they can peek on the fast path, and that we may need to tolerate a certain degree of non-compliance in such devices until Moore's law fixes the problem, or people become willing to pay more for it (which they probably won't absent some significant application).
>>>>
>>>> Maybe we should have an extension header that says where the transport header is... ;)
>>>
>>> I briefly considered this at various times when this thread keeps
>>> reappearing, but it would need to be another "HBH" header because it
>>> needs to be examined and/or modified at any hop that modifies any other
>>> extension header.
>>
>> 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.

> 
> FWIW, though, RFC2460 also clearly 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.
> 
> If that were actually enforced, we would not need a transport-offset
> header because routers would never be looking there.
> 
>> Also, there is a draft for this:
>> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01
>>
>> (which does discuss the security issue; as with the evil bit, a firewall
>> would be foolish to trust this option).
> 
> But fails to address the fact that this option might need to be updated
> whenever any other extension header is modified.

s/updated/hacked/
s/modified/hacked/

Yes, anyone who munges headers en route has to deal with the consequences.
That isn't news.

    Brian
> 
> Joe
> 
>