Subject: [Int-area] Comment on draft-ietf-intarea-frag-fragile-02

From: Jen Linkova <[email-masked]>
Date: Thu, 8 Nov 2018 19:46:55 +1100

Network Operators Recommendations section

(https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-02#section-7.4)

recommends that operators do not filter ICMPv6 PTB. I believe it would
be beneficial to make an explicit recommendation to permit fragmented
packets to/from operator's DNS servers.
I apologia if it's been discussed before and rejected (I did not find
such discussion on the list).

-- 
SY, Jen Linkova aka Furry

---

From: Joe Touch <[email-masked]>
Date: Thu, 8 Nov 2018 07:32:19 -0800

> On Nov 8, 2018, at 12:46 AM, Jen Linkova <[email-masked]> wrote:
> 

Fragment forwarding is a MUST in our standards.

This document is BCP and cannot update a standard. It cannot relax that requirement, so the middlebox needs to be updated accordingly.

*Additionally*, it’s bad practice to indicate “SHOULD” unless the text also explains why it isn’t a MUST, i.e., under what conditions it is OK to not forward fragments.

Joe

---

From: Jen Linkova <[email-masked]>
Date: Mon, 12 Nov 2018 11:02:43 +1100

> Fragment forwarding is a MUST in our standards.

I believe you are talking about routers supporting forwarding
fragmented packets, not about policy decisions. While the
recommendations in the draft (not to filter ICMP PTB messages) are
about policies.
So just another policy-related recommendation makes sense, IMHO.

> This document is BCP and cannot update a standard. It cannot relax that requirement, so the middlebox needs to be updated accordingly.

If we already have a document which is saying 'operators MUST NOT
filter any fragmented packets' then
it would be nice to reference it in the draft.

> *Additionally*, it’s bad practice to indicate “SHOULD” unless the text also explains why it isn’t a MUST, i.e., under what conditions it is OK to not forward fragments.

Sorry, I'm a bit confused. Which standard would need to be updated if
the proposed recommendation is made?

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Nov 2018 08:12:57 -0800

> On Nov 11, 2018, at 4:02 PM, Jen Linkova <[email-masked]> wrote:
> 

So first, what is the *policy* reason for doing this? The policy of “Rocket” (Guardians of the Galaxy movie)? “Because I really want to”?

There are some ICMP messages you could argue might be useful to block or throttle, though RFC1812 and its updates already lists those. But the blanket blocking of ICMPs by routers for “policy” reasons has itself caused problems - in the name of “protecting the endpoints”, operators end up creating damage to those endpoints themselves.

However, let’s just look at fragments - who are you trying to protect by blocking them?
	- endpoints can already drop whatever they can’t reassemble 
	- an endpoint that lets fragments interfere with complete packets isn’t implementing reassembly correctly

Let’s please not dance around the issue - the only policy at play here is “vendors want to make money lying about what they sell”.

> it would be nice to reference it in the draft.

We don’t have a document saying they MAY. 

> the proposed recommendation is made?

If you’re going to systematically drop fragments:
	RFC791 - which creates them for a reason; you need to show that reason as invalid/risky for operators to allow at all OR provide an alternative
	RFC8200 - see RFC791
	RFC1812 - revise the forwarding rules to explain how dropping all fragments is needed for policy reasons

Joe

---

From: Jen Linkova <[email-masked]>
Date: Tue, 13 Nov 2018 13:31:57 +1100

> So first, what is the *policy* reason for doing this? The policy of “Rocket” (Guardians of the Galaxy movie)? “Because I really want to”?

Well, usually the security policies are based on "permit only things
you need, drop everything else". Therefore in many cases fragments are
dropped because it's not obvious why they should be permitted. My
understanding is that teh main goal of BCP is document the problem,
explain what would happen if fragments are dropped and provided
recommendations to those who are looking for such recommendations.
That's why I suggested to add one more explicit recommendation on that topic.

>         - an endpoint that lets fragments interfere with complete packets isn’t implementing reassembly correctly

(Just to clarify: you don't need to convince *me* that dropping
fragments is not necessary a good idea)

> Let’s please not dance around the issue - the only policy at play here is “vendors want to make money lying about what they sell”.

My experience is different. It has nothing to do with vendors most of
the time. It's mostly about engineers who has no idea why they should
explicitly permit fragments, so those poor packets hit the default
deny rule. That's why the BCP makes perfect sense. If fragments are
dropped because vendors are lying about what they sell (not sure I
understand what do you mean, actually) then no BCP would change it..

> We don’t have a document saying they MAY.

Er...I somehow suspect most operators apply "Everything which is not
forbidden is allowed" principle, not the converse one ;)

Again, when an engineer builds a set of filtering rules, they would
look for reason to allow some traffic ('if I do not allow those
packets a service I need would break") and the BCP provides such a
guidance.

> If you’re going to systematically drop fragments:

Now I'm totally confused. Nobody suggests to drop fragments. Quite the opposite.

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 Nov 2018 19:01:35 -0800

> On Nov 12, 2018, at 6:31 PM, Jen Linkova <[email-masked]> wrote:
> 
> dropped because it's not obvious why they should be permitted.

Operators are in no position to KNOW whether endpoints need fragments or not - unless they’re running these boxes on the edge of *their* enterprise.

The Postel Principle is “be liberal in what you accept, be conservative in what you do”. Security is based on blocking what you don’t trust - so what about fragments makes you not trust them?

If they come at a high rate, sure - throttle (but not drop all).
If they can’t be DPI-inspected, then it is the middle box that is in the wrong location to do its job; this isn’t the fault of the transmitter or its generation of fragments.

Security does not mean “drop what I don’t understand”; that’s just a recipe for over-ossifying the services you provide.

> My

Sure, but sometimes that recommendation means “don’t deploy the middlebox there” or “you need to do virtual reassembly”. Anything that includes “and you can drop all fragments” is incorrect advice because it does not benefit the endpoints — it interferes with them.

> deny rule.

That may occasionally be true, but turning off features either means the vendor sets them as defaults (which they do) or operators figure out what to turn off. I doubt the latter is the more frequent case.

> That's why the BCP makes perfect sense. If fragments are

It would take forever to decide what to turn on to make anything work if that were the case.

> Now I'm totally confused. Nobody suggests to drop fragments. Quite the opposite.

NAT boxes do. DPI devices do. And even load balancers that could have simple default rules do. This document needs to speak to them too.

Joe