Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Nov 2012 09:35:32 +0000

On 31/10/2012 18:58, Joe Touch wrote:
> 
> 
> On 10/31/2012 11:34 AM, Fernando Gont wrote:
>> On 10/31/2012 04:11 PM, Joe Touch wrote:
>>> Yes, but the whole point of the IPv6 option architecture was to avoid
>>> the issues seen with IPv4 options.
>>
>> The only thing in that IPv6 would avoid is requiring routers to parse
>> *all* options, just to find the ones that need to be processed by
>> routers.
> 
> Yes.

No. The only extension header that *needs* to be parsed by intermediate
routers is the hop-by-hop options header, and that is the first one (if
present).

(You can legitimately argue that the hbh header and the routing header
are effectively useless, but that doesn't break fundamental connectivity.)

IPv6 routers should have nothing to do with fragmentation.

The problem is due to middleboxes that break the IPv6 spec by inspecting
any part of the packet beyond the hop-by-hop header and discarding what
they don't understand.

    Brian
> 
> However, since fragmentation is near the end of the set of possible
> options, that means that ANY recommendations about how IPv6 routers
> handle options will require deep option parsing. How does that help?
> 
>> While the IPv6 extension header syntax is good in terms of extensibility
>> (in principle, you can include as many options as you want, it also
>> allows for pathological cases in which the header chain is split among
>> multiple fragments (we're working on fixing that one), and also requires
>> any box that wants to find the upper-layer header to parse the entire
>> IPv6 header chain -- something that a large number of devices cannot do
>> at wire speed.
> 
> I thought we were talking more about fragmentation - which defeats
> filtering on upper layer info anyway.
> 
> The non-HBH options can be split across fragments, but not the HBH ones.
> 
>> For filtering purposes, it'd been interesting to have a pointer to the
>> upper-layer header -- although with the original specs, it might simply
>> not be there. With IPv4, at the very least it's trivial to find the
>> upper layer protocol: just skip the first IHL of the packet, and you're
>> there. With IPv6, at leasts in theory, it might be impossible (unless
>> you reassemble-filter-and-refragment).
> 
> In both cases fragmentation defeats DPI. But then so does IPsec.
> 
> Yes, IPv6's chained header structure is not DPI-friendly. But this isn't
> news, is it?
> 
>>> Consider that:
>>>
>>>      - routers don't like fragments because they can't inspect them
>>>
>>>      - so we tunnel and fragment in a higher level protocol
>>>
>>>          the router now needs to implement the higher protocol
>>>          and still fragment or else we cannot have tunnels
>>>
>>>          the routers on the path still cannot inspect the
>>>          higher-level fragments
>>>
>>> So we're back to the reason this all breaks - routers doing something
>>> that we simply cannot support in the architecture.
>>
>> It's probably time to accept that firewalls and routers implementing
>> ACLs are part of the architecture.
> 
> We need to accept one of three things:
> 
>     DPI is part of the architecture
>         either don't use IPv6 options
>         or don't use IPv6
> 
>     IPv6 options are part of the architecture
>         DPI isn't meaningful anymore
> 
>> One might argue that the use of
>> firewalls couldn't be foreseen with IPv4. But at the time IPv6 was
>> designed, it was already a reality.
> 
> So that means IPv6 was designed to inhibit the use of options, or
> designed to inhibit its own deployment.
> 
> Seems like the latter is coming to fruition.
> 
> Joe
>

---

From: Ole Trøan <[email-masked]>
Date: Thu, 1 Nov 2012 12:16:36 +0100

> any part of the packet beyond the hop-by-hop header and discarding what

quite.
what stops these boxes from filtering IPsec, TLS, or anything that isn't HTTP with a
whitewashed URL?

I don't see how we can build protocols to accommodate middle boxes, and
we have already done RFC3514.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Nov 2012 20:55:09 +0900

On Thu, Nov 1, 2012 at 8:16 PM, Ole Trøan <[email-masked]> wrote:

> I don't see how we can build protocols to accommodate middle boxes, and we
> have already done RFC3514.
>

I'm sorry, but there are real operational needs here.

Here's an example: suppose I am under attack by a TCP SYN flood and want to
rate-limit it or filter it out so I can process legitimate traffic.

It would be reasonable for me to want to do this on a peering router,
because it's as close as possible to the source, and it's a high-capacity,
scalable box that needs to process each packet anyway.

I don't want to carry tens of gigabits of useless attack packets all the
way the way through the network to the end host, and overwhelm it, so I can
drop them there. And I also don't want to put stateful firewalls at each
peering connection, because the firewalls cost a lot of money, take up
space in POPs and connecting them wastes expensive ports on peering routers.

The right way to deal with this is to rate-limit or drop on the
routers. You're saying the architecture doesn't allow this? Then I'm sorry,
but we need a better architecture.

---

From: Ole Trøan <[email-masked]>
Date: Thu, 1 Nov 2012 14:09:41 +0100

Lorenzo,

> I don't see how we can build protocols to accommodate middle boxes, and we have already done RFC3514.
> 
> Here's an example: suppose I am under attack by a TCP SYN flood and want to rate-limit it or filter it out so I can process legitimate traffic.
> 
> It would be reasonable for me to want to do this on a peering router, because it's as close as possible to the source, and it's a high-capacity, scalable box that needs to process each packet anyway.
> 
> I don't want to carry tens of gigabits of useless attack packets all the way the way through the network to the end host, and overwhelm it, so I can drop them there. And I also don't want to put stateful firewalls at each peering connection, because the firewalls cost a lot of money, take up space in POPs and connecting them wastes expensive ports on peering routers.
> 
> The right way to deal with this is to rate-limit or drop on the routers. You're saying the architecture doesn't allow this? Then I'm sorry, but we need a better architecture. 

yes, we need a better architecture. IPv4 and IPv6 are not different here.
I disagree that the architecture you propose is a better one though.

if I understand you correctly, to solve the above problem you need:
 - deprecate all IPv6 extension headers
 - deprecate IPv4 and IPv6 fragmentation
 - ban use of IPsec
 - ban any new transport protocol, e.g. SCTP

aren't there other solutions to this problem? no other attack signature?

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Nov 2012 15:06:52 +0000

> we have already done RFC3514.

We can't; it's an arms race, because however we try to hide the good stuff,
those boxes will eventually be "improved" to find it.

All we can do is understand and document the harm.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Nov 2012 11:25:23 -0700

On 11/1/2012 4:55 AM, Lorenzo Colitti wrote:
> On Thu, Nov 1, 2012 at 8:16 PM, Ole Trøan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Here's an example: suppose I am under attack by a TCP SYN flood and want
> to rate-limit it or filter it out so I can process legitimate traffic.
 >
> because it's as close as possible to the source, and it's a
> high-capacity, scalable box that needs to process each packet anyway.
 >
> way the way through the network to the end host, and overwhelm it, so I
> can drop them there. And I also don't want to put stateful firewalls at
> each peering connection, because the firewalls cost a lot of money, take
> up space in POPs and connecting them wastes expensive ports on peering
> routers.
>
> routers. You're saying the architecture doesn't allow this? Then I'm
> sorry, but we need a better architecture.

The "right way" is to drop them at the offending source, but I hope we 
all agree we cannot do that because there's no viable solution.

The architecture already allows the router to shed load by dropping 
packets either arbitrarily or per-destination. However, you want to 
preferentially drop these at your ingress router, but there's no viable 
solution there that doesn't require stateful firewalls.

So your conclusion is that the architecture is broken.

If you have a better architecture - one that also supports tunnels, 
which are ubiquitous now too - it might be useful to disclose it.

Otherwise, it might be time to admit that you can't always get what you 
want.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Nov 2012 11:34:34 -0700

> routers is the hop-by-hop options header, and that is the first one (if

The first one could be:

	A. a known HBH option
		indicating there are HBH options
	B. a known E2E option
		indicating there are no HBH options
	C. an unknown option or a pad option
		indicating NOTHING

In the case of C, the router needs to keep looking at subsequent options 
until one of three things happens:

	1. a known HBH option is seen
		indicating there are HBH options
	2. a known E2E option is seen
		indicating there are no HBH options
	3. there are no more options
		indicating there are no HBH options

As a result, it's entirely possible that a router could need to parse 
the entire option chain before it can determine whether there are any 
HBH options.

> IPv6 routers should have nothing to do with fragmentation.

+1

> any part of the packet beyond the hop-by-hop header and discarding what

+1

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Nov 2012 12:00:57 -0700

> all agree we cannot do that because there's no viable solution.

Isn't ingress filtering the means by which packets are
dropped as close to the offending source as possible? And,
shouldn't ingress filtering be implemented by all legitimate
sites?

Thanks - Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Nov 2012 19:06:46 +0000

Joe,

>     C. an unknown option or a pad option

Actually there is another unfortunate aspect of RFC 2460 here. It would
be better if it said that the hbh options extension header MUST be
first, instead of just recommending it. I think I will add that to my draft.

> the entire option chain before it can determine whether there are any

Yes, because of the point I just mentioned. That's a bug IMHO.
However, the observed problems come from middleboxes that don't
parse regular extension headers, not hbh option headers.

     Brian

---

From: joel jaeggli <[email-masked]>
Date: Thu, 01 Nov 2012 12:06:53 -0700

> shouldn't ingress filtering be implemented by all legitimate
Yeah so, I can  clearly turn off all my ACLs because all my upstreams 
will filter unwanted traffic for me when it enters their network...

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 01 Nov 2012 14:20:15 -0200

Hi, Joe,

> filtering on upper layer info anyway.

Well, it's the combination of both that defeats stateless filtering.
However, please see draft-ietf-6man-oversized-header-chain.

> In both cases fragmentation defeats DPI. But then so does IPsec.

But the two are completely different cases. With IPsec, there's a trust
relationship between the two endpoints. That doesn't necessarly mean
that you wouldn't like any DPI, though.

> Yes, IPv6's chained header structure is not DPI-friendly. But this isn't

Agreed.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Thu, 01 Nov 2012 14:08:26 -0200

> we have already done RFC3514.

Well, you simply do not rely on stuff that is unreliable.

e.g., any protocol that relies on extension headers is likely to have
deployment problems. So, you better e.g. carry your options somewhere
else, as opposed to putting them in IPv6 extension headers.

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 01 Nov 2012 14:25:18 -0200

On 10/31/2012 06:00 PM, Joe Touch wrote:
>> mm.. not sure what you mean. Could you elaborate a bit more?
> 
> The fragment header is not required to be the first header; it's
> required to come after the HBH and before the E2E ones.
> 
> So "must drop IPv6 fragments" implies parsing ALL HBH headers that come
> before the frag header (or you'd never know the frag header was there).

That's why it's very likely that IPv6 packets with extension headers
(whether Frag Header, Dst pts header, or some other one9 will be unreliable.

>> It *currently* does in v6, but not in v4: in v4 the first fragment
>> always has, at the very least, the IP addresses, upper-layer protocol,
>> and transport ports. In v6 (with the current specs), that might not be
>> the case.
>>
>>
>> And...?
> I'm not sure what bug you're implying above ("we're working on fixing
> that one"), but it's not that the entire chain is split among the
> fragments.

Please see: draft-ietf-6man-oversize-header-chain. I wouldn't call it a
"bug" but rather a pathological case that, while non-existent in
practice, was still allowed by the current specs.

Cheers,

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Nov 2012 12:33:45 -0700

> -----Original Message-----
> From: joel jaeggli [mailto:[email-masked]]
> Sent: Thursday, November 01, 2012 12:07 PM
> To: Templin, Fred L
> Cc: Joe Touch; Lorenzo Colitti; Fernando Gont; [email-masked]
> Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
> 

I posed the question facetiously - yet, wasn't "the plan" about
a decade ago to push for ingress filtering at all sites? Have
we given up on that?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Nov 2012 13:04:01 -0700

On 11/1/2012 12:06 PM, Brian E Carpenter wrote:
...
> parse regular extension headers, not hbh option headers.

Isn't the real bug the fact that the option numbers don't indicate 
whether an option is HBH or not?

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Nov 2012 13:02:06 -0700

> shouldn't ingress filtering be implemented by all legitimate

The "most correct" way is to block them at the origin.

Ingress filtering happens after that point.

The former is not feasible, and so we do not pursue it.

I claim that the latter is increasingly not feasible in a modern 
Internet either, due to the prevalence of secure tunnels.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Nov 2012 08:17:55 +0000

> whether an option is HBH or not?

Why is that a problem? The extension header that contains the options
tells you that (0 for hbh options, 60 for destination options).

    Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Nov 2012 06:49:21 -0700

Hi, Brian,

On 11/2/2012 1:17 AM, Brian E Carpenter wrote:
...
> tells you that (0 for hbh options, 60 for destination options).

Except for extension headers that are yet to be defined.

I.e., while you're fixing the order, another key issue is that:

	all HBH options MUST occur only in the HBH extension header

(similarly, 60 isn't strictly the only destination header; see esp. the 
end of Sec. 4.6, but that is much less problematic)

Frankly, the HBH extension header is misnamed; AFAICT, this is intended 
to be the true forwarding plane options. Other other currently defined 
options (AFAICT), including the routing option, occur only when the 
router is really acting as a host (i.e., where that router owns the 
destination IP address of the packet).

Joe

---

From: joel jaeggli <[email-masked]>
Date: Fri, 02 Nov 2012 13:01:35 -0700

>> IPv6 routers should have nothing to do with fragmentation.
That horse left the barn when we use L4 headers as part of a 
load-balancing hash key.

While the potential for reordering due to differing path selection is 
superficially irrelevant in the core (I do have four 4 ECMPed 
cross-country paths in the US with about 12ms difference in rtt between 
the shortest and longest), when fronting a stateful device like load 
balancer(s) or firewall(s)  it is not.

Now, if the flow label were reliably immutable and non-zero it might be 
a suitable replacement for the L4 header in the hash calculation.

> what stops these boxes from filtering IPsec, TLS, or anything that isn't HTTP with a
So, I'm providing service to an application we are generally inclined to 
limit the service area exposed on  the application, which I think of a 
pretty good fit for L4-leveraging stateless ACLS.
> we have already done RFC3514.
Nor do i think it's likely that we'll come to a great deal of consensus 
on "you absolutely cannot use L4 headers in forwarding filtering 
calculations." it's pretty clear from modern router platforms that 
customers demand those.

What I think we can do is document the observance of the phenomenon, 
acknowledge what gets broken as a result, and perhaps provide advice 
that limits the scope of the damage.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Nov 2012 07:38:15 +0000

> a suitable replacement for the L4 header in the hash calculation.

So, ask your suppliers to implement RFC 6437/6438. It's the best we can do.

   Brian

---

From: joel jaeggli <[email-masked]>
Date: Sat, 03 Nov 2012 08:41:01 -0400

> So, ask your suppliers to implement RFC 6437/6438. It's the best we can do.
Unfortunately I have a network to run in the interim.

---

From: Randy Bush <[email-masked]>
Date: Sat, 03 Nov 2012 21:58:21 +0900

> So, ask your suppliers to implement RFC 6437/6438. It's the best we

i have a limited number of brownie points with vendors, a limited budget
to use as a carrot, and limited time.  i am sure flow labels are on my
list somewhere.  i just can not see that far down without binoculars.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 04 Nov 2012 00:51:27 +0000

> list somewhere.  i just can not see that far down without binoculars.

Seriously, I think binoculars are appropriate. This is a long game.
At the moment we're trying to make IPv6 do what IPv4 does but with
bigger addresses, and that is v6ops' main business obviously. The long game
is to enable things that work badly or are impossible with IPv4.

I *fully* realise that people trying make a crust by running actual stuff
have to focus on what can be done right now.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Sun, 04 Nov 2012 09:56:53 +0900

>> i have a limited number of brownie points with vendors, a limited
>> budget to use as a carrot, and limited time.  i am sure flow labels
>> are on my list somewhere.  i just can not see that far down without
>> binoculars.
> 
> bigger addresses, and that is v6ops' main business obviously. The long
> game is to enable things that work badly or are impossible with IPv4.
> 
> I *fully* realise that people trying make a crust by running actual
> stuff have to focus on what can be done right now.

the problem, as joel pointed out, is that current approaches will be
cast in cement.

randy

---

From: Mark Andrews <[email-masked]>
Date: Mon, 05 Nov 2012 11:00:15 +1100

While flow labels work for distributing traffic, they do not work
for filtering as there is guarentee that fragments will arrive in
order.  For filtering their need a copy of the headers routers are
using to filter to be available in all of the fragments.  At a
minimum this is the UDP header.  TCP should be able to be handled
with PTB being returned on fragmented packets.  I havn't thought
about other protocols.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Sun, 4 Nov 2012 19:13:28 -0800

> with PTB being returned on fragmented packets.  I havn't thought

TCP is supposed to react to PTB already. If you're getting fragments in v6 they're generated at the source. Why would PTB not just result in more, smaller fragments?

And what if/when PTB is blocked or dropped by operators like you? 

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Nov 2012 15:00:10 +0000

> first, instead of just recommending it. I think I will add that to my draft.

I was wrong. 2460 does have this as a lower case "must".

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Nov 2012 15:07:14 +0000

> Except for extension headers that are yet to be defined.

I don't get your point, Joe. It is very clear in 2460 that extension
headers are only interpreted at the destination, except for the HBH
options header. So there's no scope to develop a new header with HBH
semantics. In any case, this is already covered in RFC 6564:
  "New IPv6 extension
   header(s) having hop-by-hop behavior MUST NOT be created or
   specified.  New options for the existing Hop-by-Hop Header SHOULD NOT
   be created or specified unless no alternative solution is feasible."

    Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 07 Nov 2012 08:17:23 -0800

On 11/7/2012 7:07 AM, Brian E Carpenter wrote:
....
> options header.

That was not at all clear from RFC2460, however, your pointer to 6564 
corrects that omission (sorry I hadn't caught that).

> So there's no scope to develop a new header with HBH

There's remains other problematic language in 2460, however:

    Each extension header should occur at most once, except for the
    Destination Options header which should occur at most twice (once
    before a Routing header and once before the upper-layer header).

So it still seems open to have more than one HBH header, which certainly 
complicates things even though they'd be clearly marked.

Joe

---

From: Ole Trøan <[email-masked]>
Date: Thu, 8 Nov 2012 14:05:59 -0500

Joe,

> So it still seems open to have more than one HBH header, which certainly complicates things even though they'd be clearly marked.

I don't see how you can read that to imply you can have more than one Hop-by-Hop extension header.
my reading (and what I think the _intention_ of the text was) is that there can only be one Hop-By-Hop extension header, and
that the HBH header must be the first extension header in the chain. this way routers only need to check the Next Header field
for the value of 0.

cheers,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Thu, 8 Nov 2012 16:05:46 -0500

+1

Bob

---

From: Joe Touch <[email-masked]>
Date: Thu, 08 Nov 2012 13:19:49 -0800

Well, I see only the word "should" here. Given how vendors already 
ignore "musts", I doubt we can expect them to be held to "shoulds".

I agree with the intent, but am suggesting that any update on this issue 
might take the opportunity to clarify intent.

Joe