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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Jul 2014 16:29:56 +1200

Hi,

(Excuse cross posting but I'm sure v6ops folk will have an opinion,
and I'm not on opsec.)

Thanks for starting this work.

First, a general point. I think you need to be much clearer in the
Introduction that there are rules in RFC 7045 that need to be followed.
The advice that you give later is all conditional on those rules being
applied first. In particular, 7045 has this requirement:

>    If a forwarding node discards a packet containing a standard IPv6
>    extension header, it MUST be the result of a configurable policy and
>    not just the result of a failure to recognise such a header.  This
>    means that the discard policy for each standard type of extension
>    header MUST be individually configurable.  The default configuration
>    SHOULD allow all standard extension headers.

There is also a reminder in the Security Considerations that this
requirement applies to firewalls. You need to be explicit, perhaps,
that you are advising operational configurations, not changing the
implementation defaults required by RFC 7045.

It was out of scope for 7045, but IMHO we should have the same rule
for IPv6 options: provide a configuration switch (allow/drop) for
each one, and a reasonable default. You could certainly suggest
that. I won't comment in detail on the options - at a quick glance,
your suggested defaults seems about right.

Now some more specific comments on the extension headers:

> 2.3.1.1. Uses
> 
> 
>    The Hop-by-Hop Options header is used to carry optional information
>    that must be examined by every node along a packet's delivery path.

In fact, RFC 7145 changes that:

> 2.2.  Hop-by-Hop Options
> 
>    The IPv6 Hop-by-Hop Options header SHOULD be processed by
>    intermediate forwarding nodes as described in [RFC2460].  However, it
>    is to be expected that high-performance routers will either ignore it
>    or assign packets containing it to a slow processing path. 

You could s/must/should/.

More important:

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

You can't say that! Firstly, RFC 7045 makes it permissible to
simply ignore them. That's the simplest DoS defence. Secondly,
well, dropping them is the wrong default because it breaks stuff.
You could discuss whether to inspect them for valid contents, and
you could discuss rate-limiting, which I understand some vendors
support already.

> 2.3.2. Routing Header for IPv6 (Number=43)
...
> 2.3.2.5. Advice
> 
> 
>    Drop packets containing a RHT0.

In fact there is considerably more detailed guidance already
in RFC 7045 (last paragraph of section 2.1). I think you should
send the reader to that.

> 2.3.9. Shim6 Protocol (Number=140)
...
> 2.3.9.3. Specific Security Implications
> 
> 
>    TBD.

You could mention that shim6 uses CGA or HBA cryptographic
addresses to prevent a 3rd party hijacking a session by
forging shim6 headers with a bogus address. There is an
extensive security discussion in RFC 5533.

> 2.3.10. Use for experimentation and testing (Numbers=253 and 254)
...
> 2.3.10.5. Advice
> 
> 
>    Routers, security gateways, and firewalls SHOULD have configuration
>    knobs for IP packets that contain this extension header to select
>    between "ignore & forward" and "drop & log". 

Well, you might prefer to put that text at the top, since RFC 7045 requires
all headers to have a configuration option. To be precise, 7045 says:

>    Experimental IPv6 extension headers SHOULD be treated in the same way
>    as standard extension headers, including an individually configurable
>    discard policy.  However, the default configuration MAY drop
>    experimental extension headers.

Regards
   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 14 Jul 2014 08:55:17 +0200 (CEST)

> (Excuse cross posting but I'm sure v6ops folk will have an opinion,

Yes, at least I do. Thanks for bringing it to v6ops attention. Weird 
thing, I can't even find the original announcement neither in my opsec nor 
v6ops folder.

Oh, well. Feedback:

I find this document advocates dropping things way too much. It uses the 
term "intermediate" devices. I would like this split up into two types of 
devices, a "pure packet forwarding device" (=core router), and a "security 
inspection device" (=device that might have ACLs or being a stateful 
firewall).

I believe a core router which just forwards packets, should not drop 
packets because of options it can't handle very well. If it can't handle a 
lot of hop-by-hop header packets, then don't inspect these hop-by-hop 
header packets, just forward the packets without looking at them.

The thought of our core networks limiting what we can and can't do in the 
future with IPv6, makes me a sad panda. I can understand devices that 
enforce some kind of security to drop packets they don't understand, but 
generally recommending blanket dropping of some packets in the core 
because of potential edge problems, that just doesn't make sense to me.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Jul 2014 16:21:29 -0300

Hi, Brian,

Thanks so much for your feedback! Please find my comments in-line...

On 07/14/2014 01:29 AM, Brian E Carpenter wrote:
>>    header MUST be individually configurable. 

We will try to make this explicit -- but yes, we were assuming this (the
filtering rules not being the result of failure to recognise a header,
etc.).

> The default configuration

Good point. FWIW, we were kind of hesitating between doing an IPv6
version of RFC7123, and writing a document aimed at firewalls. I'd argue
that this one is mostly an IPv6 version of RFC7126 -- i.e., much more
permisive than what a firewalls document would be.

> that.

I'd generally agree with you. The only issue is that for some
architectures, doing a per-option-type filtering would imply processing
the packet on the slow path.... and this requirement might be deemed as
honerous. I guess one could say something like "If you support filtering
on a per-option-type basis, then such filtering should be configurable
on a per-option-type basis", etc.?

> You could s/must/should/.

Will do. Thanks!

> simply ignore them.

While I understand your point (and agree that RFC7045 is authoritative
here), (FWIW) this is what RFC7126 says about Router Alert option, which
in some sense is analogous to the HBH EH:

---- cut here ----
   This option SHOULD be allowed only in controlled environments, where
   the option can be used safely.  [RFC6398] identifies some such
   environments.  In unsafe environments, packets containing this option
   SHOULD be dropped.

   A given router, security gateway, or firewall system has no way of
   knowing a priori whether this option is valid in its operational
   environment.  Therefore, routers, security gateways, and firewalls
   SHOULD, by default, ignore the Router Alert option.  Additionally,
   routers, security gateways, and firewalls SHOULD have a configuration
   setting that governs their reaction in the presence of packets
   containing the Router Alert option.  This configuration setting
   SHOULD allow to honor and process the option, ignore the option, or
   drop packets containing this option.
---- cut here ----

My question is: do we want to do something different with HBH EH than
what we do with Router Alert in IPv4?

FWIW, defaulting to "ignore" seems sensible to me.

> in RFC 7045 (last paragraph of section 2.1). I think you should

Will do.

> extensive security discussion in RFC 5533.

Thanks for the note!

>>    experimental extension headers.

Our bad :-( -- will cite RFC7045 as appropriate.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Jul 2014 12:08:25 +1200

> what we do with Router Alert in IPv4?

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.

I personally don't care much in the IPv4 case, since router
alert seems to be a dead duck anyway. It's possible that's
going to be the case for HbH, but I think we should give it
a chance.

> FWIW, defaulting to "ignore" seems sensible to me.

I agree, obviously.

Regards
   Brian

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Jul 2014 17:36:44 -0700

> 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?

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Jul 2014 21:36:33 -0300

> protects against any specific attack on the middlebox.

As noted, I think this options is a sensible one.

That said, let me provide a "heads up" on the current state of affairs
with respect to IPv6 EHs:

   +--------------+-----------------+-----------------+----------------+
   |   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%) |
   +--------------+-----------------+-----------------+----------------+

(DO8: Dest Options Header of 8 bytes, etc.)

The numbers indicate the packet drop rate. The numbers within
parenthesis indicate the percentage of cases where such packet drops
occur in an AS different from that of the destination system.

(i.e., this would suggest "think twice before employing IPv6 EHs.. then
don't).

> dangerous than a destination option.

As long as intermmediate systems ignore them (as suggested in RFC7045).

> going to be the case for HbH, but I think we should give it

That's why I raised the question. That said, the numbers I've provided
above would suggest that this other duck is dead already, too. :-(

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: Tue, 15 Jul 2014 21:44:30 -0300

> 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 09:56:46 -0700 (PDT)

> box on the path that takes the "drop" option breaks everything,

In that same vein, I wanted to object to this:

| 2.3.6.  Destination Options for IPv6 (Number=60)
|
| 2.3.6.1.  Uses
|
|    The Destination Options header is used to carry optional information
|    that need be examined only by a packet's destination node(s).
|
| 2.3.6.2.  Specification
|
|    This Extension Header is specified in [RFC2460].  At the time of this
|    writing, no options have been specified for this extension header.
|
| 2.3.6.3.  Specific Security Implications
|
|    No security implications are known, other than the general
|    implications of IPv6 extension headers.
|
| 2.3.6.4.  Operational and Interoperability Impact if Blocked
|
|    None.

Even if there were no destination options currently defined -- which in fact 
is not true -- there is huge operational impact if this extension header is 
routinely blocked: it would make it impossible to deploy any destination options 
at all.  The damage caused to the Internet by such practices is a recurring theme, 
and it should be spelled out explicitly here.  Failure to do so makes the advice 
that follows ("Pass packets that contain the Destination Options Header") seem 
weak and ill-motivated.

In fact, however, an examination of the references in the IANA IPv6 options 
registry indicates that the following destination options have been defined:

Hex Value       Binary Value    Description                     Reference       Status
act     chg     rest

0x04    00      0       00100   Tunnel Encapsulation Limit      [RFC2473]       PS
0xC9    11      0       01001   Home Address                    [RFC6275]       PS
0x8B    10      0       01011   ILNP Nonce                      [RFC6744]       EXP
0x8C    10      0       01100   Line-Identification Option      [RFC6788]       PS

The text in 2.3.6.2 needs to be reworked to mention these options.

Mike Heard

---

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

---

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):

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,

---

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

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,

---

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