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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 19 May 2015 20:48 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 014541B3205 for <v6ops@ietfa.amsl.com>; Tue, 19 May 2015 13:48:07 -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 Db3iwJngZEPd for <v6ops@ietfa.amsl.com>; Tue, 19 May 2015 13:48:05 -0700 (PDT)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (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 4497A1B323E for <v6ops@ietf.org>; Tue, 19 May 2015 13:48:05 -0700 (PDT)
Received: by padbw4 with SMTP id bw4so39346029pad.0 for <v6ops@ietf.org>; Tue, 19 May 2015 13:48:05 -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=/DStZiOSmbJUGmRfDsygcjgF3Pm/D3hv/rym0UIxQgo=; b=D8kx/9YBMPNpVrgLbV2tSb8/yBysfLj1Wlg9w2WQOm+dP82VYqu0AF4K4pyowF4lJU 3mWbEJJqbjveYCOQGoA2dwaIXqbVkAivdWllK4jWl9vQaTAugy2z5p0vYvFt5NveEIwM 04DJ95KUlPCIriGa3Kks1363h+g8Qo7S2GQMRNQji2ktK/YYSc9bKQ5szkW5d2siE2Uu YpWtrm+q1KqLwvYedr0mEIDvFy0K3zzIXOJlGexGxRCU3wVZIfHL6yGDROxjU5nkN3iD LZOlm6GIqcNCjlqAUi1Gtww2VuntSSQauOb2EQDFu78zg7IgyzsYLMwg73ouVYYKYCLQ yxQg==
X-Received: by 10.70.127.138 with SMTP id ng10mr57495001pdb.111.1432068485012; Tue, 19 May 2015 13:48:05 -0700 (PDT)
Received: from ?IPv6:2406:e007:4858:1:28cc:dc4c:9703:6781? ([2406:e007:4858:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id nn6sm13932507pdb.79.2015.05.19.13.48.02 for <v6ops@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 13:48:03 -0700 (PDT)
Message-ID: <555BA184.8080701@gmail.com>
Date: Wed, 20 May 2015 08:48:04 +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.6.0
MIME-Version: 1.0
To: 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>
In-Reply-To: <555B8622.5000806@isi.edu>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/Snt2SLuATnXo_KCFQkTkg3heCdg>
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 20:48:07 -0000

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).

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).

   Brian

> 
> IPv4 knows where the transport header is but has limited option space
> and can't natively support "shim" protocol layers inbetween IP and TCP
> BUT it can find the transport header with localized info.
> 
> IPv6 makes the opposite trade-off.
> 
> Joe
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>