Subject: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt

From: Warren Kumari <[email-masked]>
Date: Wed, 3 Jul 2013 19:58:35 -0400

Begin forwarded message:

> A new version of I-D, draft-wkumari-long-headers-01.txt
> has been successfully submitted by Warren Kumari and posted to the
> IETF repository.
> 
> Filename:	 draft-wkumari-long-headers
> Revision:	 01
> Title:		 Operational Issues Associated With Long IPv6 Extension Header Chains
> Creation date:	 2013-07-04
> Group:		 Individual Submission
> Number of pages: 8
> URL:             http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-wkumari-long-headers
> Htmlized:        http://tools.ietf.org/html/draft-wkumari-long-headers-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-wkumari-long-headers-01
> 
> Abstract:
>   This document explains why IPv6 header chain length affects the cost
>   of ASIC-based packet forwarding.  It also explains why some network
>   service providers discard packets with exceptionally long header
>   chains.  Finally, it identifies a reasonable header chain length.
>   While a network service provider can enforce any filtering policy
>   that supports its security model, a network service provider should
>   not discard IPv6 packets based solely upon header chain length if the
>   header chain is not longer than the value specified herein.
> 

--
What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?"

    -- (Terry Pratchett, Pyramids)

---

From: Bill Jouris <[email-masked]>
Date: Wed, 3 Jul 2013 17:25:34 -0700 (PDT)

So in summary, ASIC-based forwarders (and ISPs which use them) can call themselves IPv6-compliant, even though they are unable to (or choose not to) parse IPv6 headers.  Just as long as they don't discard packets with IPv6 headers which are shorter than 128 bytes. 

Which would appear to be another way to say that, even though IPv6 has been around for over a decade, we won't (now or, presumably, ever) require that the Internet be able to actually deal it.  Or with IPv6 packets, even though they conform entirely to the long-standing IPv6 specifications.  Is there a reason for this, other than avoiding forcing vendors to actually get around to finally dealing with the specifications that we wrote?  Pr, more to the point, being able to claim that they are "IPv6 complaint" when they manifestly are not?

Why not just tell them to admit that they are not compliant?  If they don't want to change, just indulge in a little truth in advertising. 

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

________________________________
 From: Warren Kumari <[email-masked]>
To: "[email-masked] Operations" <[email-masked]> 
Sent: Wednesday, July 3, 2013 4:58 PM
Subject: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "cb.list6" <[email-masked]>
Date: Wed, 3 Jul 2013 17:47:05 -0700

On Jul 3, 2013 5:25 PM, "Bill Jouris" <[email-masked]>
wrote:
>
> So in summary, ASIC-based forwarders (and ISPs which use them) can call
themselves IPv6-compliant, even though they are unable to (or choose not
to) parse IPv6 headers.  Just as long as they don't discard packets with
IPv6 headers which are shorter than 128 bytes.
>
> Which would appear to be another way to say that, even though IPv6 has
been around for over a decade, we won't (now or, presumably, ever) require
that the Internet be able to actually deal it.  Or with IPv6 packets, even
though they conform entirely to the long-standing IPv6 specifications.  Is
there a reason for this, other than avoiding forcing vendors to actually
get around to finally dealing with the specifications that we wrote?  Pr,
more to the point, being able to claim that they are "IPv6 complaint" when
they manifestly are not?
>
> Why not just tell them to admit that they are not compliant?  If they
don't want to change, just indulge in a little truth in advertising.

The internet, including ipv4, does not work as originally specified.

That does not matter.

What matter is that the internet evolves and adapts according to various
stressors

CB

> > URL:
http://www.ietf.org/internet-drafts/draft-wkumari-long-headers-01.txt
> > Status:
http://datatracker.ietf.org/doc/draft-wkumari-long-headers
> > Htmlized:
http://tools.ietf.org/html/draft-wkumari-long-headers-01
> > Diff:
http://www.ietf.org/rfcdiff?url2=draft-wkumari-long-headers-01

---

From: "cb.list6" <[email-masked]>
Date: Wed, 3 Jul 2013 17:52:28 -0700

stressors
> CB

Or as a visual of what is going on
http://blogs.cisco.com/wp-content/uploads/tyre_swing1.jpg

CB

---

From: Bill Jouris <[email-masked]>
Date: Wed, 3 Jul 2013 17:54:00 -0700 (PDT)

I have no problem at all with the specifications evolving to make the Internet work better.  But this isn't what we are talking about here.  Rather, we are talking about changing the specifications for the convenience, not of those using the Internet, but of those building the infrastructure.

Or are you (or the authors) suggesting that there are technical problems with making a device which could handle longer headers in hardware?  If that is the contention, then I apologize for missing that in the discussion.  (And I suggest that the RFC ought to include at least some discussion of what those techincal issues.)

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

________________________________
 From: cb.list6 <[email-masked]>
To: Bill Jouris <[email-masked]> 
Cc: IPv6 Ops WG <[email-masked]> 
Sent: Wednesday, July 3, 2013 5:47 PM
Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt

The internet, including ipv4, does not work as originally specified. 
That does not matter.
What matter is that the internet evolves and adapts according to various stressors
CB

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Jul 2013 01:13:50 +0000

> Or are you (or the authors) suggesting that there are technical problems with making a device which could handle longer headers in hardware?  If that is the contention, then I apologize for missing…

Yes, that's what's been said.   See paragraphs 1 and 2 of the introduction, as well as the second-to-last paragraph of section 3.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Jul 2013 01:15:15 +0000

On Jul 3, 2013, at 9:13 PM, Ted Lemon <[email-masked]> wrote:
> See paragraphs 1 and 2 of the introduction

Sorry, paragraphs 2 and 3 if you count from 1.

:)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Jul 2013 15:45:33 +1200

On 04/07/2013 12:47, cb.list6 wrote:
...
> What matter is that the internet evolves and adapts according to various

Fair enough. But that's why we should not relax the requirements too
readily - to keep tension between making things work as designed
and designing to minimise cots. I'd go for SHOULD and 256 bytes,
to set an ambitious goal.

   Brian

---

From: Gert Doering <[email-masked]>
Date: Thu, 4 Jul 2013 11:46:31 +0200

Hi,

On Wed, Jul 03, 2013 at 05:54:00PM -0700, Bill Jouris wrote:
> Or are you (or the authors) suggesting that there are technical 
> problems with making a device which could handle longer headers in hardware?

Just the small technicality that someone has to actually pay for that,
and the cost of walking a header chain that could be up to 65k long at
100Gbit/s is higher than "if it's not in the first 128 byte, drop the 
packet and/or ignore what comes after it".

Gert Doering
        -- Operator
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Mark Andrews <[email-masked]>
Date: Fri, 05 Jul 2013 00:06:41 +1000

> packet and/or ignore what comes after it".

Nodes are only required to be able reassemble to 1500 bytes.  Why are
people putting additional requirements on routers?
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Bill Jouris <[email-masked]>
Date: Thu, 4 Jul 2013 08:10:39 -0700 (PDT)

> packet and/or ignore what comes after it".
 
Of course.  But then, every time any technology changes, someone has to pay for it.  And frequently the straight out-of-pocket cost to buy the new technology is higher (at least initially) than just buying more of the old technology.  

But that doesn't mean that any change should simply be ignored.  At minimum, I would expect to see a cost/comparison analysis from those who object to meeting the long-standing specifications.  Showing what it would cost to meet them and, for comparison, what the cost of dropping all those packets is.  (And note that we aren't talking, necessarily, of doing an immediate and wholesale replacement of the existing infrastructure.  Just of using the upgraded hardware for new/replacement purchases.)

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

________________________________
 From: Gert Doering <[email-masked]>
To: Bill Jouris <[email-masked]> 
Cc: IPv6 Ops WG <[email-masked]> 
Sent: Thursday, July 4, 2013 2:46 AM
Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt

Hi,

Gert Doering
        -- Operator

---

From: joel jaeggli <[email-masked]>
Date: Thu, 04 Jul 2013 09:31:07 -0700

> >> problems with making a device which could handle longer headers in 
Yeah, I think that's pretty explicit in the draft. the memory into which 
the fragment of a packet expected contain the header is copied into is a 
lot more expensive and faster than the packet buffer. in merchant 
silicon that powers L3 switches that expense is basically the bounding 
of the asic size/power envelope/cost since the forwarding logic 
associated with a group of ports is a discrete single chip potentially 
with offboard packet buffer (take a look at broadcom trident 2 or Dune 
Arad for 10/40/100Gb/s examples).
> Of course.  But then, every time any technology changes, someone has 
> to pay for it.  And frequently the straight out-of-pocket cost to buy 
> the new technology is higher (at least initially) than just buying 
> more of the old technology.
>
Oddly I expect the future version of my network to cost less and be 
faster than previous version.
> But that doesn't mean that any change should simply be ignored.  At 
> minimum, I would expect to see a cost/comparison analysis from those 
> who object to meeting the long-standing specifications.
So the reason you see drafts today describing what network operators and 
content-provider/enterprise networks can actually do is because that's 
at odds with assumptions made before these things were widely deployed. 
Level-setting expectations to match reality is not an unreasonable 
thing, nor is asking for more in the future, being reaslistic about the 
prospects for many outcomes outcomes is helpful.
>   Showing what it would cost to meet them and, for comparison, what 
> the cost of dropping all those packets is. (And note that we aren't 
> talking, necessarily, of doing an immediate and wholesale replacement 
> of the existing infrastructure.  Just of using the upgraded hardware 
> for new/replacement purchases.)
>
> Bill Jouris
> Inside Products, Inc.
> www.insidethestack.com
> 831-659-8360
> 925-855-9512 (direct)
>
>
> ------------------------------------------------------------------------
> *From:* Gert Doering <[email-masked]>
> *To:* Bill Jouris <[email-masked]>
> *Cc:* IPv6 Ops WG <[email-masked]>
> *Sent:* Thursday, July 4, 2013 2:46 AM
> *Subject:* Re: [v6ops] Fwd: New Version Notification for 
> draft-wkumari-long-headers-01.txt
>
> Hi,
>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 04 Jul 2013 12:32:35 -0700

On 7/3/13 5:54 PM, Bill Jouris wrote:
> I have no problem at all with the specifications evolving to make the 
> Internet work better.  But this isn't what we are talking about here.  
> Rather, we are talking about changing the specifications for the 
> convenience, not of those using the Internet, but of those building 
> the infrastructure.
On the contrary, two of the three authors are users not vendors. Cameron 
and his customers are likewise consumers not developers. We've arrived 
at a pretty backwards place if you're telling me that's it ok from your 
vantage point that I can't find the L4 header, that's an enterprise 
requirement since along with the ip header it's the basis of firewall 
policy.
> problems with making a device which could handle longer headers in 
> hardware?  If that is the contention, then I apologize for missing 
> that in the discussion.  (And I suggest that the RFC ought to include 
> at least some discussion of what those techincal issues.)
> Bill Jouris
> Inside Products, Inc.
> www.insidethestack.com
> 831-659-8360
> 925-855-9512 (direct)
>
>
> *From:* cb.list6 <[email-masked]>
> *Sent:* Wednesday, July 3, 2013 5:47 PM
> On Jul 3, 2013 5:25 PM, "Bill Jouris" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> > So in summary, ASIC-based forwarders (and ISPs which use them) can 
> call themselves IPv6-compliant, even though they are unable to (or 
> choose not to) parse IPv6 headers.  Just as long as they don't discard 
> packets with IPv6 headers which are shorter than 128 bytes.
> >
> > Which would appear to be another way to say that, even though IPv6 
> has been around for over a decade, we won't (now or, presumably, ever) 
> require that the Internet be able to actually deal it.  Or with IPv6 
> packets, even though they conform entirely to the long-standing IPv6 
> specifications.  Is there a reason for this, other than avoiding 
> forcing vendors to actually get around to finally dealing with the 
> specifications that we wrote?  Pr, more to the point, being able to 
> claim that they are "IPv6 complaint" when they manifestly are not?
> >
> > Why not just tell them to admit that they are not compliant?  If 
> they don't want to change, just indulge in a little truth in advertising.
> >
> > www.insidethestack.com <http://www.insidethestack.com/>
> > 831-659-8360
> > 925-855-9512 (direct)
> >
> > From: Warren Kumari <[email-masked] <mailto:[email-masked]>>
> > To: "[email-masked] <mailto:[email-masked]> Operations" 
> <[email-masked] <mailto:[email-masked]>>
> > [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jul 2013 17:36:06 -0700

On 7/3/2013 5:54 PM, Bill Jouris wrote:
> I have no problem at all with the specifications evolving to make
> the Internet work better. But this isn't what we are talking about
> here. Rather, we are talking about changing the specifications for
> the convenience, not of those using the Internet, but of those
> building the infrastructure.

That is correct. Claims that this is about a technical problem are false.

E.g., it's incorrect to claim that this is a forwarding issue. It is a 
*firewall* (and possibly NAT) issue.

The problem is that IPv6 was designed to make it easier to add and 
delete options and "shim" layers between IP and transport - which it does.

*Everything* an IP *router* ***requires*** to forward a packet is 
visible in the main IP header or the HBH options. The sum of the two is 
already limited to 40 (main header) + 256 (HBH), so it's already the 
case that a compliant IP router never needs to look beyond the first 296 
bytes to forward a packet.

Endpoints - and things that act on their behalf - need to parse the 
chain to find useful information. That information depends on what the 
device does. Many want to look at the transport information - which may 
or may not be visible. Others may want to look at other parts of the chain.

So let's please be very clear about what _this_ draft is saying - it is 
NOT about making routers do something that routers *need* to do.

Joe

---

From: [email-masked]
Date: Fri, 05 Jul 2013 12:16:34 +0200 (CEST)

> bytes to forward a packet.

Looks like we need to come up with a new term here.

A pure IPv6 router, as you define it, is completely useless to me.

My real, operation requirements include IPv4 / IPv6 forwarding for
multiple 10 Gbit/s links *and* very basic, stateless access lists 
that must be able to look at address *and* L4 info (port numbers).

I believe that when most operators talk about routers, they include
this or similar capabilities - simply because that is a necessity in
order to run a production network.

> NOT about making routers do something that routers *need* to do.

It is about making what *operators* call routers useful in real life.

Your definition of router is not the same as that of many operators.
Let's make a note of this and move on.

Steinar Haug, AS 2116

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 05 Jul 2013 11:36:57 +0100

> That is correct. Claims that this is about a technical problem are false.

this statement is disturbingly disconnected from operational reality, imho.

Nick

---

From: Gert Doering <[email-masked]>
Date: Fri, 5 Jul 2013 14:46:51 +0200

Hi,

> NOT about making routers do something that routers *need* to do.

If you can build a router for me that has a control plane which is 
completely unreachable from the outside, that would be sufficient
(but that would likely be a MPLS P router, who wouldn't need to look
at *any* IPv6 bits).

Today's routers *need* to be able to protect themselves, and that can
only be done by L4-aware rate limiting and ACLs.

So please stop repeating this "a router doesn't need any of this" - while
this is fairly nice for a theoretical router, it doesn't work out there,
and *this* is what should be interesting.  Not "ivory tower beauty".

Gert Doering
        -- Operator

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2013 05:50:18 -0700

On 7/5/2013 3:16 AM, [email-masked] wrote:
...
...
> A pure IPv6 router, as you define it, is completely useless to me.

Feel free to come up with a new term, document its requirements, and 
publish a standard on it.

At that point we should consider its implications on existing standards.

Until then, we have a situation where false marketing is driving a 
change to a standard.

> that must be able to look at address *and* L4 info (port numbers).

The Internet doesn't need port examination to function correctly, and 
ports are increasingly meaningful only at the endpoints anyway. Port 
examination provides exactly two things:

- a false sense of security (that services are truly being blocked)
- a false view that the operator has control over traffic by type

> Let's make a note of this and move on.

Feel free. That 'note' would be a standards-track RFC.

Until then, I don't think it's useful to use the IETF for (mis)marketing.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2013 05:52:25 -0700

> only be done by L4-aware rate limiting and ACLs.

Are you referring to forwarded traffic? If so, how is that "protecting 
the router"?

If you're talking about traffic addressed to the router itself, the 
entire chain has to be parsed anyway.

> and *this* is what should be interesting.  Not "ivory tower beauty".

That "ivory tower" is all we have documented requirements for. If you 
want to propose other requirements for routers, please do. But until 
then I do not support changes to standards to support non-existent 
requirements.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2013 05:58:39 -0700

> this statement is disturbingly disconnected from operational reality, imho.

I'll repeat that any claim to the contrary is disturbingly disconnected 
from the documented standards.

I don't object to changing IPv6 requirements to support a *requirement*, 
but not changing them to support false marketing (here's an IPv6 router, 
but oh, we can't actually support the existing IPv6 requirements, and we 
can port-filter, but not if the L4 header is too deep to be implemented 
cheaply).

The reality is that there is no requirement that routers port-filter.

Joe

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 05 Jul 2013 14:07:21 +0100

> The reality is that there is no requirement that routers port-filter.

To take a practical example, could you advise me then on how to set up a
control plane policing policy on a C6500/sup720 or c7600/rsp720 which
protects against ipv6 fragment attacks?

Nick

---

From: Gert Doering <[email-masked]>
Date: Fri, 5 Jul 2013 15:09:35 +0200

hi,

> protects against ipv6 fragment attacks?

Obviously this is no router feature, so the question is not relevant.

Gert Doering
        -- Operator

---

From: Ray Hunter <[email-masked]>
Date: Fri, 05 Jul 2013 15:11:29 +0200

> (but that would likely be a MPLS P router, who wouldn't need to look

Right.

> only be done by L4-aware rate limiting and ACLs.

So could we specify different requirements and solutions for control
traffic which terminates on the router, compared to end user traffic
which only transits it?

If so, couldn't this requirement be implemented as "being able to filter
at wire speed any traffic headed for the control processor based on a
IPV6 source prefix", rather than having to filter on a full L4 header?

And then numbering end user LAN's from prefixes completely disjoint from
your control network ranges and BGP peer addresses?

If it's more than this I think it'd help to better specify the requirement.

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2013 06:13:18 -0700

> protects against ipv6 fragment attacks?

I don't think that's possible unless you also protect "against" 
fragments altogether, and I don't think that is the job of a router.

Joe

---

From: Gert Doering <[email-masked]>
Date: Fri, 5 Jul 2013 15:17:28 +0200

Hi,

> IPV6 source prefix", rather than having to filter on a full L4 header?

This is not actually sufficient.  To make real life operation work, you
need stuff like "permit <x> mbit/s of BGP traffic, <y> mbit/s of ICMP
traffic, and nothing else".

Being able to tell the box "oh, yeah, packets from that IXP are permitted!"
just to get CPU-starved by 10Gbit/s of garbage because another participant
there got hacked is not sufficient.  Trade-off-time again, of course - you 
might not be able to avoid losing BGP-to-the-IXP if you get flooded by 
TCP/179-packets from there, but everything else on that router should 
better not die.

Gert Doering
        -- Operator

---

From: Gert Doering <[email-masked]>
Date: Fri, 5 Jul 2013 15:17:58 +0200

Hi,

> fragments altogether, and I don't think that is the job of a router.

So how do you operate your network?

Gert Doering
        -- Operator

---

From: "cb.list6" <[email-masked]>
Date: Fri, 5 Jul 2013 06:18:08 -0700

> this statement is disturbingly disconnected from operational reality,
imho.

+1

CB

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 05 Jul 2013 14:19:14 +0100

On 05/07/2013 14:13, Joe Touch wrote:
> I don't think that's possible unless you also protect "against" fragments
> altogether, and I don't think that is the job of a router.

so you're ok about the idea of having a router sitting on the Internet DFZ
which you can take down with 20kpps of ipv6 fragments, and where there is
no way of protecting against this because in your own words, you "don't
think it's the job of the router".  And also that "claims that this is
about a technical problem are false".

Nick

---

From: Ivan Pepelnjak <[email-masked]>
Date: Fri, 05 Jul 2013 15:27:53 +0200

Nick, you don't get it.

A proper router has out-of-band management and control planes that we so
loved and cherished with ATM switches and thus never has to touch
anything beyond L3 header. Anything else is not a router.

Ivan

On 05.07.2013 15:19 , Nick Hilliard wrote:
> so you're ok about the idea of having a router sitting on the
> Internet DFZ which you can take down with 20kpps of ipv6 fragments,
> and where there is no way of protecting against this because in your
> own words, you "don't think it's the job of the router".  And also
> that "claims that this is about a technical problem are false".
>
> Nick
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2013 06:32:38 -0700

PS - here's what *I* think would be required to fix this doc, at a minimum.

- make it clear that this is about either NATs, L4 filtering 
(firewalls), or L4 port-based forwarding, not IP forwarding (the latter 
is a well-defined term and does not include L4 ports)

- make the requirement about a network *device*, not a network *provider*

- explain the corner cases in more detail
	you mention a few cases here, but it seems like you need to
	specify a length for nearly every protocol payload because
	you're claiming that you have enough information to handle
	the IP header, the IP options, and the next *header* (at least
	the most interesting parts of it).

	There are a bunch of cases that are common enough that they
	ought to be covered:
		IPv6 (just the inner IPv6? and its HBH?)
		IPv4 (any options?)
		GRE
		MPLS

	What about the TCP header? why stop at just the ports?
	might a future operator want to block traffic on whether
	it used authentication? or SACK?

	What about ICMP - why not also its payload? How far in?

- explain what to do if the chain is too long to see what you want

	MUST forward seems the only viable alternative to me,
	but if you disagree, propose an alternate and justify it

	if you don't forward, then you ought to be sending ICMP errors
	(subject to rate control)

- correct some of the other errors

	IPv6 has HBH headers for exactly the reasons you cite - to limit
	how much of the chain needed to be examined. What really changed
	is the desire for port-filtering and port-forwarding devices.

	IPv4 makes this simpler because the 'jump' to the end of the
	chain is in the header in a fixed location.

	This has nothing to do with ASIC vs. multicore software
	processing (e.g., on a NPU). It has to do with a fixed jump
	vs. a chain of jumps. ASICs and multicore software can
	either one, but the space cost is higher and variable, and the
	time cost is higher and variable.

Joe

---

From: Nalini Elkins <[email-masked]>
Date: Fri, 5 Jul 2013 06:35:50 -0700 (PDT)

>Today's routers *need* to be able to protect themselves, and that can only be done by L4-aware rate limiting and ACLs.

Operators of networks need to protect their networks and users.  Operators also need capabilities which are provided by IPv6 extension headers.   Having said that, network traffic has to be transmitted as quickly as possible.   So, that means reliance on hardware.

I would vote for a compromise position of encouraging 256 bytes for ASIC size.  
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2013 06:35:53 -0700

On 7/5/2013 6:19 AM, Nick Hilliard wrote:
> which you can take down with 20kpps of ipv6 fragments,

The router ought to be able to forward at that rate. Unless these are 
addressed *to* the router they don't cause the router a problem. If they 
are, then limiting the forwarding chain won't help because these aren't 
forwarded by that router.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2013 06:37:05 -0700

> traffic which terminates on the router, compared to end user traffic

Sure. But that's not at all what this doc does; this doc talks about 
forwarded traffic. That won't affect terminated traffic at all.

Joe

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 05 Jul 2013 15:06:55 +0100

On 05/07/2013 14:35, Joe Touch wrote:
> ... then limiting the forwarding chain won't help because these aren't

then your understanding of modern routers is incorrect.

Let's say you have an IPv6 address on a router interface - it doesn't
matter if it's used for management or not.  If it's pingable, then the ping
packets will be directed to the router management or route processor engine
for slow path processing.  We use control plan policing or equivalent
technologies to ensure that packets of this form do not overload the RE / RP.

In order to implement CoPP/RE firewalling, we need hardware ACL support to
be able to distinguish between the sorts of packets that we want to see and
the ones we don't.  In practice, this means implementing sophisticated ACL
+ QoS support in hardware. Consequently, this means that we need the
ability to inspect reasonably deeply into ipv6 packet headers.

On several well known router engines, this functionality is not there
because the lookup engines cannot inspect far enough into the packet header
to handle ipv6 headers properly.  Consequently, large chunks of the
internet run on equipment which cannot be protected against trivial pps
based ipv6 attacks.  On some of them, it turns out that it doesn't matter
whether it's pingable or not, because you can craft IPv6 packets which can
bypass the hardware classification mechanisms.  All you need to know is the
ipv6 address of any interface on the box, and you can trivially trash it
remotely.

On this basis, I would suggest that this is not just a technical problem,
but a really serious technical problem with potentially devastating
operational consequences.

Nick

---

From: Ray Hunter <[email-masked]>
Date: Fri, 05 Jul 2013 16:14:44 +0200

> Joe Touch <mailto:[email-masked]>
> 5 July 2013 15:37
>
>
>
>
Exactly. And the requirement from Geert and Steinar was for protecting
control plane traffic AFAICS.

So what is the requirement to process L4 headers offorwarded traffic at
10 gbps in backbone routers?

And are there alternatives?

RayH

---

From: Gert Doering <[email-masked]>
Date: Fri, 5 Jul 2013 16:17:35 +0200

Hi,

> control plane traffic AFAICS.

Well, actually we need both...

> 10 gbps in backbone routers?

... "drop this UDP/53 flood at the most external borders we can to stop
it from overloading internal links".

Gert Doering
        -- NetMaster

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2013 07:20:54 -0700

On 7/5/2013 7:06 AM, Nick Hilliard wrote:
> matter if it's used for management or not

Agreed. Packets addressed *to* the router need to be fully processed.

That has nothing to do with packets not addressed to the router. Those 
packets pass through the forwarding plane.

The draft talks about this being a forwarding plane issue.

Your explanation has nothing to do with that. However, I can still shut 
down your router any number of ways, by sending lots of interesting 
things in those first 128 bytes that cause the router to overload - 
e.g., fragments to reassemble, source routes to process, etc.

So limiting the chain for packets addressed *to* the router solves the 
problem of how much data to copy before you know you need to something 
else with the packet. But you can easily be asked to do a lot more than 
the router can handle once you copy that. So you've solved the copy 
problem, but not much else.

> ability to inspect reasonably deeply into ipv6 packet headers.

Hardware does not imply short headers. Wanting to do fast copies of 
subsets of a packet does - independent of hardware vs. software.

> ...All you need to know is the

Whether that's true does not seem to depend on the header chain length, 
though.

Joe

---

From: Ray Hunter <[email-masked]>
Date: Fri, 05 Jul 2013 16:23:55 +0200

> Gert Doering <mailto:[email-masked]>
> 5 July 2013 16:17
> Hi,
>
No disrespect, but by the time you've detected the attack and put in the
appropriate L4 filtering config, haven't the attackers long gone?

Doesn't this sort of DoS defence need to be auto-detecting, and
auto-responding, like fair queueing?

Or in the old days, simply reducing the link speed to untrusted peers?

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2013 07:24:01 -0700

> it from overloading internal links".

You don't need to know UDP/53 to do this; you need enough info to 
differentiate this flow from others. That means N bytes into the header; 
the more into the header you copy, the less false positives you drop 
(e.g., if you check only 40, you'd drop all traffic from a source).

That's value added for vendors that want to support looking further into 
a packet, but has nothing to do with whether the source should limit its 
header chain.

Joe

---

From: [email-masked]
Date: Fri, 05 Jul 2013 16:34:24 +0200 (CEST)

> appropriate L4 filtering config, haven't the attackers long gone?

Not necessarily. We see DNS-based spoofed source amplification attacks
that last for *days*.

Steinar Haug, AS 2116

---

From: Gert Doering <[email-masked]>
Date: Fri, 5 Jul 2013 16:43:28 +0200

Hi,

> auto-responding, like fair queueing?

Well, these days people observe UDP/53 flooding that goes on for days.

Who will know what's there tomorrow?

> Or in the old days, simply reducing the link speed to untrusted peers?

All peers are untrusted - and we're not interested in reducing speed for
useful traffic.  

Assume that our external links can handle the traffic, the "bad" traffic 
is easily identified (like: UDP/53 reflective DoS to a web server who 
doesn't need any external UDP in the first place), and that some internal 
link towards the web server would become overloaded.

Being able to filter at the most external borders is a must.

(But I'm not sure this discussion is going anywhere - I'd welcome if all
people that argue that this is not a problem run an ISP network for a 
few weeks, and then come back)

Gert Doering
        -- Operator

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2013 07:47:01 -0700

>> Well, actually we need both...

First, the doc doesn't discuss these as the separate issues they are.

Second, the following are entirely different operational suggestions:

	- limit chains of all IPv6 packets

	- limit chains of IPv6 packets addressed to routers
	(and suggest that routers drop packets that aren't
	as simple as expected to protect their control plane)

The latter is entirely reasonable; if you're running the router, you get 
to decide how long a chain you want to allow to your control plane.

The former has widespread implications on the use of IPv6 options, and 
should be avoided unless absolutely necessary. I still haven't seen 
where this is the case.

Note that other end-systems could similarly limit what they do - DNS 
servers, etc. That's always up to the end system to decide anyway.

Joe

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 05 Jul 2013 15:54:44 +0100

On 05/07/2013 15:20, Joe Touch wrote:
> Your explanation has nothing to do with that. 

In fact it has because it's still the same silicon which is used in both
circumstances.

Alternatively let's talk about infrastructure ACLs.  I also want to be able
to filter ipv6 packets with arbitrary ipv6 headers on my network edge so
that other people cannot reach my core network with known harmful traffic.
 Is that better?  Remember, it's the same silicon which does both.

> However, I can still shut
> down your router any number of ways, by sending lots of interesting things
> in those first 128 bytes that cause the router to overload - e.g.,
> fragments to reassemble, source routes to process, etc.

Eh, no, you generally can't.  Source routed packets have dropped for the
last 15 years.  Reassembly attacks can be protected by dropping packets
from everything except known hosts, and by using infrastructure acls to
stop spoofing.

> Whether that's true does not seem to depend on the header chain length, though.

God almighty, Joe, of course it depends on the header chain length.  It
depends on plenty of other things too, but header chain length is one of them.

This is a ridiculous argument:  you clearly have no operational experience
in this area, nor any clue of how modern routers operate and how their
operational limitations affect production networks.

Nick

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2013 08:27:45 -0700

On 7/5/2013 7:54 AM, Nick Hilliard wrote:
> of course it depends on the header chain length.  It

It would be useful to start by explaining:

a) what traffic you need to inspect?
	- to the router
	- through the router

Which one determines whether you need to suggest limiting header chains 
for all traffic or just traffic to your router.

b) what is the problem with inspecting traffic?

	- the length of the chain
	- how many 'links' in the chain

the former is a memory capacity and bandwidth problem;
the latter is a processing speed problem

Neither one has anything to do with whether you use ASICs; they both 
have to do with whether you are space or time limited and in what resource.

Which one is the problem determines whether you need to limit the length 
of the chain or the number of links in it, or both.

Joe

---

From: Michael H Lambert <[email-masked]>
Date: Fri, 5 Jul 2013 11:32:01 -0400

On 5 Jul 2013, at 11:27, Joe Touch <[email-masked]> wrote:

> Which one determines whether you need to suggest limiting header chains for all traffic or just traffic to your router.

Are hop-by-hop options TO the router, THROUGH the router, or both?

Michael

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jul 2013 09:13:30 -0700

> Are hop-by-hop options TO the router, THROUGH the router, or both?

Both, as per RFC2460 they are examined at every hop, including the 
source and destination.

Joe

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 05 Jul 2013 17:33:48 +0100

> It would be useful to start by explaining:

I already have, multiple times over the past couple of months, and most
recently in my previous email.

> a) what traffic you need to inspect?

Both:
	to: control plane policing / RE firewalling
	through: infrastructure ACLs

Both are equally important to running functional networks and incidentally
both are handled by the same hardware ACL/queueing mechanisms.

>     - how many 'links' in the chain

On current generation forwarding engines, mostly the length of the chain.

> Neither one has anything to do with whether you use ASICs; they both have
> to do with whether you are space or time limited and in what resource.

I made no claim in this regard.  What I said was that your statement
"claims that this is about a technical problem are false" was absurd.

Nick

---

From: joel jaeggli <[email-masked]>
Date: Fri, 05 Jul 2013 12:03:54 -0700

> it from overloading internal links".

closer to the edge of my network, in addition to stateless acls, it's 
hash l4 flows into one of many stateful middle-boxes or endpoints.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 05 Jul 2013 12:16:12 -0700

> appropriate L4 filtering config, haven't the attackers long gone?
The attempt at disruption lasts until the party achieves their goal, or 
gives up.
> auto-responding, like fair queueing?
Given a detection and mitigation platform you can identify and then 
install and remove acls accordingly

http://tools.ietf.org/html/rfc5575

http://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-03

of course that requires that you be able to find the header you're 
trying to match on.

actual deployment of flowspec in the field isn't for everyone, and it 
has a lot of warts in implementations. but it's there.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Jul 2013 10:34:13 +1200

>> 10 gbps in backbone routers?

In any case, we need to process L4 headers at line speed in full-function
firewalls and in load balancers. So even if the argument about core routers
was completely bogus (which it isn't), exactly the same problem would
arise somewhere else on most paths. I don't think there's any way out of
the need to keep the header chain reasonably short, and at least make
fragmentation a rare exception case. Both of these could have been
written into RFC 2460 from the start.

    Brian