Subject: [v6ops] Review of draft-gont-v6ops-ipv6-ehs-packet-drops-01

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 7 Jan 2016 17:15:00 +0100

Hello all,

Below go my notes from reading the https://www.ietf.org/id/draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt

Overall:

The document is easy to read. Most of my comments are nits and suggestions of additional content that I thought might be on-topic.

My only bigger question mark is about the last part of section 5 - covered in more detail in the last comment below.

Page 1:

"Discussions about the security and operational implications of IPv6
   extension headers are a regular feature in IETF working groups and
   other places.  Often in these discussions, important security and
   operational issues are overlooked.

This document tries to raise awareness about the security and
   operational implications of IPv6 Extension Headers, and presents
   reasons why some networks drop packets containing IPv6 Extension
   Headers."

==> First paragraph reads to me like it makes a rather broad assertion. I’d rephrase it from the authors’ viewpoint, something along the lines of:

 “The authors had been involved in numerous discussions about the IPv6 extension headers: both within IETF and outside of it. They noticed that a number of security and operational issues were unknown to the larger audience participating in these discussions. This document aims to correct this by presenting these issues - so as to explain how some networks might choose their policy towards the packets containing IPv6 Extension Headers”. 

(the reason for “their policy” vs. just “drop” is section 5 presents the consequences of dropping, and the way I read it - implicitly advocates against it).

Page 2:

Evasion of security controls

==> Pure L3 ACLs are not affected by EH parsing, are they ? If they aren’t - putting a qualifier “security controls aiming at layers above the network layer” or something of that kind could be useful. 

Page 3:

“This has presented implementation
   difficulties, and packet filtering mechanisms on several security
   devices can be trivially evaded by inserting IPv6 Extension Headers
   between the main IPv6 header and the upper layer protocol.”

==> “packet filtering mechanisms based protocol data above the network layer” (the same idea as previous comment - qualify that pure L3 filtering is not affected if it isn’t.

To expose my idea behind these two comments: 

L4 ACL is an operationally useful and convenient layer violation. In IPv4 it was reliable and easy and in IPv6 it isn’t.
This is a pretty bad feature disparity between the two protocols. But one can imagine an alternative IPv6-only universe where unikernel-run apps simply would not have their OS support for any other ports than the ones they use, thus making the L4 ACLs on intermediate nodes less relevant. Back on planet Earth, as implemented in iron, IPv6 L3 ACLs do work and with IPv6 L4 ACLs you can’t be sure - unless you drop EHs - thus, network architect, beware.

Page 4:

"4.1.3.  ECMP and Hash-based Load-Sharing"

==> A naive question pops up in the mind while reading this paragraph - “but, the flow label…” - RFC6438 has nice words on the subject. Not sure if it’s worth it dragging the flow label here though. Up to you..

"(e.g.  Tertiary CAM or RLDRAM)"

==> I’ve only heard "Ternary CAM" as an established term. Tertiary is also harder to pronounce.

Page 6:

"4.2 Route-Processor Protection"

==> There’s RFC6192 talking about protecting control plane with ready made examples of L3 and L4 ACLs for two vendors - it might be useful to reference that. That would make this section talk about the ACLs, which might also make it worth reordering 4.1.x, e.g.: 4.1.4 then 4.1.3 then 4.1.1 then 4.1.2 - this way it flows from ‘how the hardware performs lookups’ to  ‘some of the lookups being done’ to ‘Why we need L4 ACLs’ - and thus 4.2 would logically glue with the end of 4.1.

"Communication between any two systems through to public network"

==> seems like extraneous “to” here 

Page 8:

[I-D.ietf-6man-deprecate-atomfrag-generation] has recently proposed
   to deprecate the generation of IPv6 atomic fragments, and update SIIT
   [RFC6145] such that it does not rely on ICMPv6 atomic fragments.
   Thus, any of the above mitigations would eliminate the attack vector
   without any interoperability implications.

==> I see several issues here:

1. Glancing through deprecate-atomfrag, seems there is a circular dependency of sorts: ehs-packet-drops document says the blackhole exists because the atomic fragments are generated/used, and the deprecate-atomfrag says the problem exists because the atomic fragments are dropped. My understanding is that the dependency is that first the EHs are blocked by the network operator(s) for reasons unrelated to atomic fragments, which creates the blackhole preventable by not sending atomic fragments while continuing to block the EHs.

2. Really a comment for deprecate-atomfrag, but given the presence of this paragraph and its wording, I’ll bring it up here: http://www.arkko.com/tools/allstats/citations-rfc6145.html shows quite a graph of dependencies that will be shaken upon a 6145 update. I didn’t go through the list to see if there are protocol dependencies (4rd and MAP-T come to mind but maybe something else ?) - but a document proposing changing 6145 and asserting that there will be no interoperability implications needs to ensure that none of the dependencies get out of whack.

3. SIIT and friends can appear in different topologies, with some of the topologies being affected differently from the others, e.g. with MAP-T the atomic fragments are not ever leaving the service provider network, so the generation, filtering and processing is within the same admin domain. The difference in the impact might affect the policy decisions.

So I’d probably rephrase and have the paragraph say that full analysis is being done as part of deprecate-atomfrag, or something of sorts - or delete it all together. Not sure. So take it FWIW. I’ll need to carefully read the deprecate-atomfrag document to get a clearer opinion about the interaction of these two documents.

That’s it, HTH!

—a

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Jan 2016 08:44:24 +1300

> ==> A naive question pops up in the mind while reading this paragraph - “but, the flow label…” - RFC6438 has nice words on the subject. Not sure if it’s worth it dragging the flow label here though…

I don't think it's naive. RFC 6438 and RFC 7098 tackle two aspects of this.
The flow label is the fix for this, indeed (by incorporating the layer 4
information in the hash at the source host).

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 8 Jan 2016 16:08:35 -0300

Hi, Andrew,

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

On 01/07/2016 01:15 PM, Andrew Yourtchenko wrote:
> Hello all,
> 
> Below go my notes from reading the
> https://www.ietf.org/id/draft-gont-v6ops-ipv6-ehs-packet-drops-01.txt
>
>  Overall:
> 
> The document is easy to read. Most of my comments are nits and
> suggestions of additional content that I thought might be on-topic.

Thanks!

> ==> First paragraph reads to me like it makes a rather broad
> assertion. I’d rephrase it from the authors’ viewpoint, something
> along the lines of:
> 
> “The authors had been involved in numerous discussions about the IPv6
> extension headers: both within IETF and outside of it. They noticed
> that a number of security and operational issues were unknown to the
> larger audience participating in these discussions. This document
> aims to correct this by presenting these issues - so as to explain
> how some networks might choose their policy towards the packets
> containing IPv6 Extension Headers”.
> 
> (the reason for “their policy” vs. just “drop” is section 5 presents
> the consequences of dropping, and the way I read it - implicitly
> advocates against it).

Not sure I follow. What we're trying to say is that some ops have
concrete and valid reasons for dropping packets with EHs, even if we
don't like that.

> ==> Pure L3 ACLs are not affected by EH parsing, are they ? If they
> aren’t - putting a qualifier “security controls aiming at layers
> above the network layer” or something of that kind could be useful.

Do you mean just filter on IP addresses, or do you consider "upper
protocol type" to be part of such l3 ACLs?

If the former, you're absolutely right. If the later, you're not. :-)

> 
> Page 3:
> 
> “This has presented implementation difficulties, and packet filtering
> mechanisms on several security devices can be trivially evaded by
> inserting IPv6 Extension Headers between the main IPv6 header and the
> upper layer protocol.”
> 
> ==> “packet filtering mechanisms based protocol data above the
> network layer” (the same idea as previous comment - qualify that pure
> L3 filtering is not affected if it isn’t.
> 
> L4 ACL is an operationally useful and convenient layer violation. In
> IPv4 it was reliable and easy and in IPv6 it isn’t. This is a pretty
> bad feature disparity between the two protocols. But one can imagine
> an alternative IPv6-only universe where unikernel-run apps simply
> would not have their OS support for any other ports than the ones
> they use, thus making the L4 ACLs on intermediate nodes less
> relevant. Back on planet Earth, as implemented in iron, IPv6 L3 ACLs
> do work and with IPv6 L4 ACLs you can’t be sure - unless you drop EHs
> - thus, network architect, beware.

Agreed. Also, please see my comment regarding "upper protocol type" above.

> ==> A naive question pops up in the mind while reading this paragraph
> - “but, the flow label…” - RFC6438 has nice words on the subject. Not
> sure if it’s worth it dragging the flow label here though. Up to
> you..

This was on our todo list. We'll certainly point to RFC6438. A second
question is what's the situation regarding:

* hosts setting the flow label
* load balancers being able to do anything useful with it

> ==> There’s RFC6192 talking about protecting control plane with ready
> made examples of L3 and L4 ACLs for two vendors - it might be useful
> to reference that. 

Will do.

> That would make this section talk about the ACLs,
> which might also make it worth reordering 4.1.x, e.g.: 4.1.4 then
> 4.1.3 then 4.1.1 then 4.1.2 - this way it flows from ‘how the
> hardware performs lookups’ to  ‘some of the lookups being done’ to
> ‘Why we need L4 ACLs’ - and thus 4.2 would logically glue with the
> end of 4.1.

I'll come back to you regarding this one.

> ==> seems like extraneous “to” here

I'll s/to/the/

> to deprecate the generation of IPv6 atomic fragments, and update
> SIIT [RFC6145] such that it does not rely on ICMPv6 atomic
> fragments. Thus, any of the above mitigations would eliminate the
> attack vector without any interoperability implications.
> 
> 1. Glancing through deprecate-atomfrag, seems there is a circular
> dependency of sorts: ehs-packet-drops document says the blackhole
> exists because the atomic fragments are generated/used,

The intent, at least, was to say that:

* widespread filtering of EHs means that packets with EHs may get blackholed
* Atomic fragments represent probably the only case in which an attacker
can remotely trigger the use of EHs for a third party connection
* Hence, an attacker can trigger atomic fragments, such that the
widespread filtering of EHs essentially blackholes the target traffic.

> and the
> deprecate-atomfrag says the problem exists because the atomic
> fragments are dropped. My understanding is that the dependency is
> that first the EHs are blocked by the network operator(s) for reasons
> unrelated to atomic fragments,

Agreed.

> which creates the blackhole
> preventable by not sending atomic fragments while continuing to block
> the EHs.

Agreed.

> 2. Really a comment for deprecate-atomfrag, but given the presence of
> this paragraph and its wording, I’ll bring it up here:
> http://www.arkko.com/tools/allstats/citations-rfc6145.html shows
> quite a graph of dependencies that will be shaken upon a 6145 update.
> I didn’t go through the list to see if there are protocol
> dependencies (4rd and MAP-T come to mind but maybe something else ?)
> - but a document proposing changing 6145 and asserting that there
> will be no interoperability implications needs to ensure that none of
> the dependencies get out of whack.

RFC6145 itself notes that atomic fragments are not reliable, and
proposes a workaround for that -- the big question, to me, is why such
workaround wasn't made "on by default".  (RFC6145 itself contains stats
regarding how bad atomic fragments fail to be generated.). Some
implementations never generated them. Others, such as Linux, have
removed support for atomic fragments for a while now. Some FreeBSD
versions generate them, other's don't.

Bottom line: Can you rely on IPv6 atomic fragments, even in "controlled
environments"? -- No.  Then have your protocol use something that can be
relied upon.

And, if you read atomfrag-deprecation, you'll see that the concrete
negative impact (security, performance, and reliability) outweighs the
possible benefits.

> 3. SIIT and friends can appear in different topologies, with some of
> the topologies being affected differently from the others, e.g. with
> MAP-T the atomic fragments are not ever leaving the service provider
> network, so the generation, filtering and processing is within the
> same admin domain. The difference in the impact might affect the
> policy decisions.

The question here is why you wouldn't design a protocol that is robust,
rather than one that works only in specific scenarios.

> So I’d probably rephrase and have the paragraph say that full
> analysis is being done as part of deprecate-atomfrag, or something of
> sorts - or delete it all together.

I can leave with tweaking the text. Will get back to you regarding this one.

> Not sure. So take it FWIW. I’ll
> need to carefully read the deprecate-atomfrag document to get a
> clearer opinion about the interaction of these two documents.

Please send any further comments whenever you have them.

Thanks so much!

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

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Fri, 8 Jan 2016 23:33:39 +0100

Hi Fernando,

> On 08 Jan 2016, at 20:08, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Andrew,
> 

Dropping EH then leads to a potential DoS, did I not get this right ? As such, that scenario implicitly advocates against dropping EHs.

> If the former, you're absolutely right. If the later, you're not. :-)

Just addresses. Upper protocol type is one EH before the ports so has the same problems.

> * load balancers being able to do anything useful with it

No idea... But as usual - if someone really wants it, they will get the vendors to implement it.. (Whether nudging in this direction is ops is another question though, I don't know..)

> widespread filtering of EHs essentially blackholes the target traffic.

Ok thanks!

> environments"? -- No.  Then have your protocol use something that can be

In controlled environment you absolutely can. E.g. If you control map-t CPE which sends the atomic frags and BR which receives them. We actually had to enable just this in one of the environments to make an application that uses IP IDs work.

> negative impact (security, performance, and reliability) outweighs the

Didn't do it yet - I suppose this means I just volunteered myself to read the doc - will do and write on 6man.

> rather than one that works only in specific scenarios.

I think same reason why people won't just write software that works perfectly - oversights, and limitations caused by the legacy..

> Please send any further comments whenever you have them.

Oki - will send on 6man when I read it! Thanks for all the replies!

--a