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

Joe Touch <touch@isi.edu> Tue, 19 May 2015 21:00 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 C77621B2A9A for <v6ops@ietfa.amsl.com>; Tue, 19 May 2015 14:00:18 -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 ItXPiKJ1UJJD for <v6ops@ietfa.amsl.com>; Tue, 19 May 2015 14:00:17 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231AD1B2A99 for <v6ops@ietf.org>; Tue, 19 May 2015 14:00:17 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t4JKxid8024029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 May 2015 13:59:45 -0700 (PDT)
Message-ID: <555BA43F.8010303@isi.edu>
Date: Tue, 19 May 2015 13:59:43 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, 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>
In-Reply-To: <555BA184.8080701@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: t4JKxid8024029
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/4iKmWVMyPcoLhSwiNzG1bZu1zHE>
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, 19 May 2015 21:00:19 -0000


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.

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.

Joe