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

[Joe Touch <[e-mail]>]

> On Nov 12, 2018, at 6:31 PM, Jen Linkova <[e-mail]> wrote:
> 
> On Tue, Nov 13, 2018 at 3:13 AM Joe Touch <[e-mail]> wrote:
>>>> 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”?
> 
> 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.

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

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.

> That's why I suggested to add one more explicit recommendation on that topic.
> 
>> 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
> 
> (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 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
> dropped because vendors are lying about what they sell (not sure I
> understand what do you mean, actually) then no BCP would change it..
> 
>>> 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.
> 
> Er...I somehow suspect most operators apply "Everything which is not
> forbidden is allowed" principle, not the converse one ;)

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

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