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

[Joe Touch <[e-mail]>]

> On Nov 11, 2018, at 4:02 PM, Jen Linkova <[e-mail]> wrote:
> 
> On Fri, Nov 9, 2018 at 2:32 AM Joe Touch <[e-mail]> wrote:
>>> (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.
>> 
>> 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.

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

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

We don’t have a document saying they MAY. 

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

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