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

From: Fernando Gont <[email-masked]>
Date: Tue, 12 Aug 2014 05:53:51 -0400

Hi, Mikael,

Thanks so much for your feedback! Comments in-line...

On 07/14/2014 02:55 AM, Mikael Abrahamsson wrote:
> 
> I find this document advocates dropping things way too much.

Actually, of the top of my head, the only EH that we were advocated
dropping (from the standard set) is/was HBH (this is to be changed in
the upcoming rev of the document).

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

Me, I'd probably stick to intermmediate device, or maybe "forwarding
node" or "router". If you bring "firewalls" into the game, reality is
that a firewall will typically be "default deny".

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

We're trying to provide advice to the same sort of devices that are
dropping packets in draft-gont-v6ops-ipv6-ehs-in-real-world....

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

That's not what we're doing (modulo HBH, as noted above). Please let us
know if there are specific portions of the document that you're
objecting to or that you'd like to be clarified.

Thanks!

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Aug 2014 12:32:10 +0200 (CEST)

> the upcoming rev of the document).

Ok, good! Another thing I don't know if I mentioned, is that there is a 
mix of different ways of saying the same thing in the advice section, 
sometimes it's "pass", sometimes it's "do not drop". Are you fixing that 
as well?

Anyhow, I'll wait until the next rev and give it a complete read-through.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Tue, 12 Aug 2014 06:40:36 -0400

Hi, Mikael,

> sometimes it's "pass", sometimes it's "do not drop". Are you fixing that

I wasn't... but now I will.

> Anyhow, I'll wait until the next rev and give it a complete read-through.

Thanks so much!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 12 Aug 2014 07:45:23 -0400

Hi, Brian,

On 07/14/2014 12:29 AM, Brian E Carpenter wrote:
>> 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.

Does this look reasonable:

---- cut here ----
The recommended configuration for the processing of these packets
depends on the features and capabilities of the underlying platform. On
platforms that allow forwarding of packets with HBH Options on the fast
path, we recommend that packets with HBH be forwarded as normal (for
instance, [RFC7045] allows for implementations to ignore the HBH Options
extension header when forwarding packets). Otherwise, on platforms where
processing of packets with IPv6 HBH Options is carried out in the slow
path, and an option is provided to rate-limit these packets, we
recommend that this option is selected. Finally, when packets with HBH
Options are processed in the slow-path, and the underlying platform does
not have any mitigation options available for attacks based on these
packets, we recommend that such platforms drop packets containing IPv6
HBH Options.

Those intermediate systems processing the contents of this extension
header should drop packets that contain more than one instance of the
Router Alert option (see [RFC2711]).

Finally, we note that, for obvious reasons, RPL routers must not drop
packets based on the presence of an IPv6 Hop-by-Hop Option Extension Header.
---- cut here ----

?

Thanks!

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

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 12 Aug 2014 14:44:27 +0000

We have language for that in other rfcs. Drop usually means silent drop.
So is drop a silent drop or a reject?
http://tools.ietf.org/html/rfc3871

"Ability to Specify Filter Actions

   Requirement.

      The device MUST provide a mechanism to allow the specification of
      the action to be taken when a filter rule matches.  Actions MUST
      include "permit" (allow the traffic), "reject" (drop with
      appropriate notification to sender), and "drop" (drop with no
      notification to sender).  Also see Section 2.7.7 and Section 2.9"

Are there cases where reject (with notification) makes more sense then drop?
Or where the end user should get to choose one over the other?

(coffee != sleep) & (!coffee == sleep)
 [email-masked]

From: OPSEC [[email-masked]] on behalf of Fernando Gont [[email-masked]]
Sent: Tuesday, August 12, 2014 4:40 AM
To: Mikael Abrahamsson
Cc: [email-masked]; [email-masked]; IPv6 Operations
Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt

Hi, Mikael,

Thanks so much!

Best regards,

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Aug 2014 11:42:42 +1200

Hi Fernando,

Yes, that works for me. Maybe you need a reference for the
RPL exception.

Thanks
    Brian