Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices
sthaug@nethelp.no Wed, 17 June 2015 12:02 UTC
Return-Path: <sthaug@nethelp.no>
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 3AFEC1A8A84 for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 05:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 GuL_yoAOIqWS for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 05:02:38 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 3F9651A89B5 for <v6ops@ietf.org>; Wed, 17 Jun 2015 05:02:37 -0700 (PDT)
Received: (qmail 27355 invoked from network); 17 Jun 2015 12:02:35 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 17 Jun 2015 12:02:35 -0000
Date: Wed, 17 Jun 2015 14:02:35 +0200
Message-Id: <20150617.140235.74748217.sthaug@nethelp.no>
To: fred@cisco.com, furry13@gmail.com
From: sthaug@nethelp.no
In-Reply-To: <CAFU7BAR0YeGe7NbYTqNSAcMukGjAz6akWaVcODWVJwpTJKQhWQ@mail.gmail.com>
References: <20150517191841.GA26929@ernw.de> <C07DF957-9A2D-4962-ABAA-DE61F5C5D533@cisco.com> <CAFU7BAR0YeGe7NbYTqNSAcMukGjAz6akWaVcODWVJwpTJKQhWQ@mail.gmail.com>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/JMKG4YSnziO-jEXUCJCV8V75geY>
Cc: v6ops@ietf.org, ipv6-wg@ripe.net
Subject: Re: [v6ops] [ipv6-wg] 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, 17 Jun 2015 12:02:46 -0000
> On Wed, Jun 17, 2015 at 9:41 AM, Fred Baker (fred) <fred@cisco.com> wrote: > > Fernando would like to see a specification of how long the entire list of extension headers may be, in terms of "how large of a hardware buffer has to be implemented in a switch?" That has a couple of issues related to "why does one have to ask the question?" The hardware should definitely be large enough to read in the IPv6 header, the HBH Header, and the Routing Header. After that, the only host that SHOULD need to read it all in is the host itself, and the host can do its processing from RAM. There is one "gotcha" case, which is when someone uses an ACL (disallowing Fragmentation Headers, perhaps, or looking for the TCP port, meaning one has to ask whether a given packet is TCP and what its port number is). The firewall is going to have to chase down the chain of extension headers. You may call it a firewall. I call it a "border router" - and the difference between this and a firewall is striking. Most importantly, my border routers don't keep state for the sessions passing through them. However, I *do* expect them to handle basic stateless ACLs, including L4 info (port numbers). For IPv4 and IPv6. > I agree. There is a definitely a big difference in requirements for > "traditional routers" and devices which are going to implement ACLs > (and other types of "multifields classifications" (as QoS based other > data than IP header). IMHO it's reasonable to assume that one might > need different hardware for "just routing" and enhanced QoS/ACL > services (it's a case nowadays anyway). You may feel it is reasonable. Not everybody agrees. If we compare with IPv4: All modern routers I know of (including high speed boxes with multiple 10G and 100G ports) are able to handle stateless ACLs based on IPv4 addresses and port numbers. The boxes with multiple 10G and 100G ports process these ACLs at line rate. I don't pay extra for this functionality - possibly because a box *without* such functionality would have a limited market. > For the latter case the device > has to either, as you said, chaise the whole chain down (which might > be as long as the whole packet) or have a way to deal with packets it > could not parse (applying a specific policy to such packets). > > > How big is a HBH header? How big is a routing option such as the Segment Routing option? If that's a list of 27 services, each with a 16 byte IPv6 address... A small but possibly relevant digression here: My border routers (which happen to be Juniper routers) are configured to disallow source routing. This has been the Juniper *default* since around 2008, see http://www.juniper.net/techpubs/software/junos/junos85/swconfig85-routing/frameset.html I expect (but do not know with certainty) that Juniper changed this source routing default behavior based on customer feedback. Back to IPv6: I might allow "interesting" IPv6 extension headers within my own AS - because in such cases I have much more control. There is no way I'm going to allow IPv6 packets with long chains of "interesting" IPv6 header chains to pass my border routers. Either they have short enough header chains that my border routers can inspect the L4 info at line rate - or they get dropped. > I'd like to point out that the problem is not specific to IPv6 at all. > How deep is MPLS label stack? Where are TCP flags or port number in > the packet (so I can match 'tcp established' or 'tcp 443')? oops, we > don't know....it depends...so some linecards do not copy enough data, > some (newer ones) do. The MPLS label stack is normally used with a single provider - thus the provider is in control. I agree that the IPv4 packet may have options, making it variable length. However the length is still limited by the IHL field, which has a max value of 15 (60 bytes). Steinar Haug, AS 2116
- [v6ops] Extension Headers / Impact on Security De… Enno Rey
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Mark ZZZ Smith
- Re: [v6ops] Extension Headers / Impact on Securit… Gert Doering
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Silvia Hagen
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Ole Troan
- Re: [v6ops] Extension Headers / Impact on Securit… sthaug
- Re: [v6ops] Extension Headers / Impact on Securit… Nick Hilliard
- Re: [v6ops] Extension Headers / Impact on Securit… Fernando Gont
- Re: [v6ops] Extension Headers / Impact on Securit… Ted Lemon
- Re: [v6ops] Extension Headers / Impact on Securit… Gert Doering
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Ted Lemon
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Sander Steffann
- Re: [v6ops] Extension Headers / Impact on Securit… Mark ZZZ Smith
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Tim Chown
- Re: [v6ops] Extension Headers / Impact on Securit… Eric Vyncke (evyncke)
- Re: [v6ops] Extension Headers / Impact on Securit… Silvia Hagen
- Re: [v6ops] Extension Headers / Impact on Securit… Nick Hilliard
- Re: [v6ops] Extension Headers / Impact on Securit… Mark ZZZ Smith
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Gert Doering
- Re: [v6ops] Extension Headers / Impact on Securit… Ray Hunter
- Re: [v6ops] Extension Headers / Impact on Securit… Tim Chown
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Eric Vyncke (evyncke)
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Stefano Previdi (sprevidi)
- Re: [v6ops] Extension Headers / Impact on Securit… Stefano Previdi (sprevidi)
- Re: [v6ops] Extension Headers / Impact on Securit… Howard, Lee
- Re: [v6ops] Extension Headers / Impact on Securit… Fred Baker (fred)
- Re: [v6ops] Extension Headers / Impact on Securit… Fred Baker (fred)
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Enno Rey
- Re: [v6ops] Extension Headers / Impact on Securit… Eric Vyncke (evyncke)
- Re: [v6ops] Extension Headers / Impact on Securit… Ca By
- Re: [v6ops] Extension Headers / Impact on Securit… Mark ZZZ Smith
- Re: [v6ops] Extension Headers / Impact on Securit… Ca By
- Re: [v6ops] Extension Headers / Impact on Securit… Jen Linkova
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- Re: [v6ops] Extension Headers / Impact on Securit… Fred Baker (fred)
- Re: [v6ops] Extension Headers / Impact on Securit… Ca By
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Fred Baker (fred)
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Jen Linkova
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … sthaug
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Nick Hilliard
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Jen Linkova
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Jen Linkova
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … sthaug
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Jen Linkova
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] Extension Headers / Impact on Securit… Ca By
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Fred Baker (fred)
- Re: [v6ops] Extension Headers / Impact on Securit… Jen Linkova
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian Haberman
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] Extension Headers / Impact on Securit… Fred Baker (fred)
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Tore Anderson
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian Haberman
- Re: [v6ops] Extension Headers / Impact on Securit… Joe Touch
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Tore Anderson
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … sthaug
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian E Carpenter
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Warren Kumari
- Re: [v6ops] Extension Headers / Impact on Securit… Brian E Carpenter
- [v6ops] So what is or are the problem or problems… Mark ZZZ Smith
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … sthaug
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian Haberman
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Gert Doering
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Joe Touch
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Ole Troan
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … sthaug
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Ole Troan
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Enno Rey
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Mark ZZZ Smith
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian E Carpenter
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Warren Kumari
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Ronald Bonica
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Mark ZZZ Smith
- Re: [v6ops] Extension Headers / Impact on Securit… Fernando Gont
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Fernando Gont
- Re: [v6ops] [ipv6-wg] Extension Headers / Impact … Brian Haberman