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

Ted Lemon <Ted.Lemon@nominum.com> Tue, 19 May 2015 18:14 UTC

Return-Path: <Ted.Lemon@nominum.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 4F5681A90C9 for <v6ops@ietfa.amsl.com>; Tue, 19 May 2015 11:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 aPs8KD0LuE6P for <v6ops@ietfa.amsl.com>; Tue, 19 May 2015 11:14:06 -0700 (PDT)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF051A9129 for <v6ops@ietf.org>; Tue, 19 May 2015 11:14:05 -0700 (PDT)
Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C2AEDDA00A7; Tue, 19 May 2015 18:14:05 +0000 (UTC)
Received: from [10.0.1.29] (8.20.190.66) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 19 May 2015 11:14:05 -0700
References: <20150515113728.GH3028@ernw.de> <878002773.794.1431739346723.JavaMail.yahoo@mail.yahoo.com> <555AB8FA.2080405@si6networks.com>
MIME-Version: 1.0 (1.0)
In-Reply-To: <555AB8FA.2080405@si6networks.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-ID: <F6AA9AEA-49F0-488C-84EA-50BE103987C8@nominum.com>
X-Mailer: iPad Mail (12F69)
From: Ted Lemon <Ted.Lemon@nominum.com>
Date: Tue, 19 May 2015 14:14:04 -0400
To: Fernando Gont <fgont@si6networks.com>
X-Originating-IP: [8.20.190.66]
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/ViP_leJ2-KL2Jr_lCJqiyDN6XkI>
Cc: "v6ops@ietf.org" <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: Tue, 19 May 2015 18:14:07 -0000

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