Subject: Re: [Int-area] [OPSEC] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt

From: Joe Touch <[email-masked]>
Date: Wed, 16 Jul 2014 10:09:57 -0700

Hi, all,

I'm including INTAREA in the discussion because this doc seems to be an 
end-run around intending to deprecate IPv6 HBH options, or at least to 
redefine the option behavior bits defined in RFC 2460. IMO, that ought 
to be addressed in INTAREA, not V6OPS.

IMO, the real DOS attack here is twofold:

	1) vendors who misrepresent their boxes as IPv6-capable
	at a given packet rate

	2) documents, such as this,
	that invert the Postel Principle into the Gont Principle:

	- Postel Principle:
		Be conservative in what you send
		and liberal in what you receive.

	- Gont Principle:
		Be paranoid in what you receive.

Just because you receive something you didn't expect, does NOT make it 
an attack.

I sincerely hope there are others who share this view, or we might as 
well just go straight to the conclusion that IPv6 routers that can't 
process 128-bit addresses really ought to be OK just forwarding based on 
the last 32.

Joe

On 7/15/2014 5:44 PM, Fernando Gont wrote:
> On 07/15/2014 09:36 PM, Joe Touch wrote:
>>
>> On 7/15/2014 5:08 PM, Brian E Carpenter wrote:
>>> The problem with both of these great inventions is that a single
>>> box on the path that takes the "drop" option breaks everything,
>>> whereas "ignore" at least provides best effort service and
>>> protects against any specific attack on the middlebox.
>>> As far as the destination host goes, HbH can't be any more
>>> dangerous than a destination option.
>>
>> IPv6 already indicates - inside the option type - what to do if an
>> option isn't supported.
>>
>> Why is honoring that set of flags not the only correct behavior?
>
> Because, with the world as we know it, that ends up killing performance
> -- with the corresponding implications (DoS) in extreme cases.
>
> Cheers,
>

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 16 Jul 2014 15:13:16 -0700 (PDT)

On Wed, 16 Jul 2014, Joe Touch wrote:
JT> I'm including INTAREA in the discussion because this doc seems to be an
JT> end-run around intending to deprecate IPv6 HBH options, or at least to
JT> redefine the option behavior bits defined in RFC 2460. IMO, that ought to be
JT> addressed in INTAREA, not V6OPS.

I think this would be within the purview, not of INTAREA, but of 6MAN, which, as 
noted by Brian Carpenter earlier in this thread, has recently spoken the subject:

On Mon, 14 Jul 2014, Brian E Carpenter wrote:
BEC> In fact, RFC [7045] changes that:
BEC> 
BEC> > 2.2.  Hop-by-Hop Options
BEC> > 
BEC> >    The IPv6 Hop-by-Hop Options header SHOULD be processed by
BEC> >    intermediate forwarding nodes as described in [RFC2460].  However, it
BEC> >    is to be expected that high-performance routers will either ignore it
BEC> >    or assign packets containing it to a slow processing path. 
BEC> 
BEC> You could s/must/should/.
BEC> 
BEC> More important:
BEC> 
BEC> > 2.3.1.5. Advice
BEC> > 
BEC> >    Intermediate systems should, by default, drop packets containing a
BEC> >    IPv6 Hop-by-Hop Option Extension Header.
BEC> 
BEC> You can't say that! Firstly, RFC 7045 makes it permissible to
BEC> simply ignore them. That's the simplest DoS defence. Secondly,
BEC> well, dropping them is the wrong default because it breaks stuff.
BEC> You could discuss whether to inspect them for valid contents, and
BEC> you could discuss rate-limiting, which I understand some vendors
BEC> support already.

JT> IMO, the real DOS attack here is twofold:
JT> 
JT> 	1) vendors who misrepresent their boxes as IPv6-capable
JT> 	at a given packet rate
JT> 
JT> 	2) documents, such as this,
JT> 	that invert the Postel Principle into the Gont Principle:
JT> 
JT> 	- Postel Principle:
JT> 		Be conservative in what you send
JT> 		and liberal in what you receive.
JT> 
JT> 	- Gont Principle:
JT> 		Be paranoid in what you receive.
JT> 
JT> Just because you receive something you didn't expect, does NOT make it an
JT> attack.
JT> 
JT> I sincerely hope there are others who share this view, or we might as well
JT> just go straight to the conclusion that IPv6 routers that can't process
JT> 128-bit addresses really ought to be OK just forwarding based on the last 32.

I've complained before about "default deny" bias harming the internet, and so have 
many others.  It is a real problem.  And it appears that both of the factors you
mention are responsible for large-scale dropping of packets with IPv6 fragment 
headers in today's Internet.

That being said, it is a different and more hostile Internet than in Postel's day.  
Under the Postel Principle, something useless but harmless (w.g., the IPv4 stream 
ID option) would be ignored; nowadays, you will probably find consensus that it is 
OK, or even desirable, to block things like that.  In fairness to Mr. Gont, this 
draft is MUCH better that the initial versions of the corresponding IPv4 options 
filtering document.  Even it I don't agree with all of them, the filtering 
recommendations in this draft do seem to motivated by legitimate operational 
concerns, not blanket paranoia.

I think we should move further discussion back to OPSEC and V6OPS.

//cmh

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Jul 2014 13:11:15 -0700

On 7/16/2014 3:13 PM, C. M. Heard wrote:
> Even it I don't agree with all of them, the filtering

They need to be characterized as what they are:

	- an attempt to accommodate devices that are NOT IPv6-compliant

I agree that there are legitimate operational concerns, but redefining 
the behavior or the IPv6 flags is not the purview of operational or 
management groups in the IETF.

If these features cannot be supported, then deprecate them through 
standards-track updates, not by de-facto deprecation through operational 
neutering.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Jul 2014 14:59:25 -0600

Hi, Joe,

> to be addressed in INTAREA, not V6OPS.

May I ask if you have read the I-D? Because this document is not trying
to do any of the above. It simply aims at providing operational advice
on how to filter packets with IPv6 EHs/options.

>         Be paranoid in what you receive.

This document doesn't follow the "be paranoid principle" (if there's
such a thing): It recommends to pass lots of stuff that that, if you
were really paranoid, you wouldn't pass.

And while Postel principle's aims at interoperability, here we're
talking about avoiding some specific traffic from breaking your network.
SO I don't really follow your analysis.

> I sincerely hope there are others who share this view,

What's "this view"? Have you followed the thread with Brian Carpenter
regarding ignoring rather than dropping HBH?

>  or we might as

This document is an operations-related document, not a std track one. As
such, it provides advice to the folks *running* the routers not the
folks manufacturing them.

Just for the sake of reality check:

Packet drops rates for different traffic types (and, within parenthesis,
the percentage of such drops occurring in a different AS):

   +--------------+-----------------+-----------------+----------------+
   |   Dataset    |       DO8       |       HBH8      |     FH512      |
   +--------------+-----------------+-----------------+----------------+
   |     Web      |      11.88%     |      40.70%     |     30.51%     |
   |              | (17.60%-20.80%) | (31.43%-40.00%) | (5.08%-6.78%)  |
   +--------------+-----------------+-----------------+----------------+
   | Mailservers  |      17.07%     |      48.86%     |     39.17%     |
   |              |  (6.35%-26.98%) | (40.50%-65.42%) | (2.91%-12.73%) |
   +--------------+-----------------+-----------------+----------------+
   | Namerservers |      15.37%     |      43.25%     |     38.55%     |
   |              | (14.29%-33.46%) | (42.49%-72.07%) | (3.90%-13.96%) |
   +--------------+-----------------+-----------------+----------------+

Yes: over 40% of packet drop rate for HBH, already. And quite a few
folks (e.g. Google) drop all packets that contain IPv6 EHs.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Jul 2014 14:43:20 -0700

On 7/17/2014 1:59 PM, Fernando Gont wrote:
> to do any of the above. ...

 From draft-gont-opsec-ipv6-eh-filtering-00.txt:

2.3.1.5. Advice

    Intermediate systems should, by default, drop packets containing a
    IPv6 Hop-by-Hop Option Extension Header.

The currently required behavior of HBH option type "00" in RFC2460:

4.2 Options

    Two of the currently-defined extension headers -- the Hop-by-Hop
    Options header and the Destination Options header -- carry a variable
    number of type-length-value (TLV) encoded "options", of the following
    format:
...
    The Option Type identifiers are internally encoded such that their
    highest-order two bits specify the action that must be taken if the
    processing IPv6 node does not recognize the Option Type:

       00 - skip over this option and continue processing the header.

       ...

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Jul 2014 16:03:45 -0600

>     - an attempt to accommodate devices that are NOT IPv6-compliant

I'd have a hard time coming uup with a vendor/device that can process
IPv6 packets with HBH header with the same performance as regular
packets. So.. are you suggesting that we start claiming that "we
currently do not know of any ipv6-compliant routers", or what? (fwiw, I
expect you are not)

> management groups in the IETF.

We're not redefining anything. We're just saying "look, if you're
running an IPv6 network, this is probably the most sane thing to do".
Having that sane advice doesn't prevent you from doing something else if
you know better, if you want to allow everything withing your
organization, or if you just don't care if your network melts down.

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, 17 Jul 2014 16:05:52 -0600

Hi, Mike,

On 07/16/2014 04:13 PM, C. M. Heard wrote:
> filtering document.

Thanks. And it's an individual -00 version. Nothing is set on stone.

> I think we should move further discussion back to OPSEC and V6OPS.

Agree.

Thanks!

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Jul 2014 15:38:38 -0700

> currently do not know of any ipv6-compliant routers", or what? (fwiw, I

If we are, then it's time to adjust RFC2460.

IMO, we ought to:

	- define the features/capabilities we think are necessary

	- require that anything that doesn't support what's necessary
	as non-compliant

Otherwise, you're just un-doing all the work that goes into the 
standards process in the first place. All because you think that 
anything you don't expect is an attack. It isn't. It just means you're 
not prepared.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Jul 2014 22:21:51 -0600

> If we are, then it's time to adjust RFC2460.

I disagree. Operational policy != protocol specification. Actually, the
IETF can do whatever it wants with the protocol specs, but not that much
with the operational stuff (other than providing *advice* -- because ops
folks can do whatever they want with their networks).

> anything you don't expect is an attack. It isn't. It just means you're

We seem to be in disagreement. If anything, anything that I don't want
is not an attack, but rather an unnecessary attack surface. But again,
please read the I-D... because it really doesn't follow that reasoning.

Thanks,

---

From: Warren Kumari <[email-masked]>
Date: Fri, 18 Jul 2014 11:51:59 -0400

On Fri, Jul 18, 2014 at 12:21 AM, Fernando Gont <[email-masked]> wrote:
> is not an attack, but rather an unnecessary attack surface.

Related to this is
http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02 -- Why
Operators Filter Fragments and What It Implies

This expired, but I suspect we may need to revive it...

W

> But again,
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec