[ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices

> On Wed, Jun 17, 2015 at 9:41 AM, Fred Baker (fred) <fred at 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