Re: [v6ops] draft-taylor-v6ops-fragdrop WGLC

["C. M. Heard" <[e-mail]>]

On Wed, 28 Aug 2013, joel jaeggli wrote:
> Imho this is the first of these documents in recent times. As an 
> author I don't see the goal as guidance to implementors, I see it 
> as guidance from operators.

OK, but that guidance is most helpful if finds its way into atual 
advice to implementors ("here are some things you need to improve in 
order to meet our operational needs") and to maintainers of the IPv6 
specifications ("here are some places where the protocol, as 
specified, does not meet our operational needs").


On Mon, 19 Aug 2013, Havard Eidnes wrote:
> The entire section 2.1.1. "Stateful inspection" is about problems with
> resource exhaustion in middleboxes or end-system firewalls.
> Implementations which willingly devote unlimited resources to fragment
> reassembly display a severe lack robustness, and IMHO should not be
> used as justification for why we can't use fragments.  Yes, I'm
> suggesting that one can forego the specified 60s fragmentation
> reassembly timeout in the case of resource shortage of a fixed pool.

This is true, but the other side of the coin (as is mentioned 
elsewhere in the draft) is that operators often have to deal, at 
least in the short term, with implementations that do have these 
sorts of deficiencies.  Maybe the points that should be made in this 
section are:

- If fragmented datagrams are allowed in at all, there is no way to 
  prevent a malicious party from sending an incomplete series of 
  fragments to a vctim host (or stateful middlebox).

- Such an attach can cause resource exhaustion issues on 
  unsophisticated implementations, owing in part to the 60 sec 
  timeout specified in RFC 2460.

It now becomes easy to provide actionable advice to implentors ("you 
may want to consider doing a better job of managing your resources") 
and possibly to the 6man wg ("you may want to consider revising the 
60 sec timeout, or clarifying that it is an upper bound")

In section 2.15 the draft states:

   The IETF and operators can help this effort by identifying specific
   classes of fragments that do not represent legitimate use cases and
   hence should always be dropped.

That's good, actionable advice.  However, I get great heartburn from 
this:

   However, some cases will remain where legitimate fragments are 
   discarded for legitimate reasons.

If the fragments are legitimate, it seems to me that the operator 
who discards them is shooting himself in the foot.

May I susggest that a more productive thing to say would be that the 
IETF can also help by:

- identifying applications that can be modified to avoid the use of 
  fragmentation

- identifying applications that can't live without it

The hope is that this would lead to specification changes or 
appropriate implementation advice in cases where fragmentation is 
not really needed, and where it is needed to improved middlebox 
implementations that provide smore precisely targeted filtering 
tools than the blunt instrument of indiscriminately discarding all 
fragments (for instance, a middlebox capable of parsing the entire 
header chain if it's available and sufficiently short, and having 
the abiity to discard stuff that does not conform to 
ietf-6man-oversized-header-chain).

On Mon, 19 Aug 2013, Havard Eidnes wrote:
> Under section 2.1.2. Stateless ACLs:
> 
>    Stateless load balancing schemes may
>    hash fragmented datagrams from the same flow to different paths
>    because the 5-tuple may be available on only the initial fragment.
>    While rehashing has the possibility of reordering packets in ISP
>    cores it is not disastrous.  However, in front of a stateful
>    inspection device, load balancer tier, or anycast service instance,
>    where headers other than the L3 header -- for example, the L4 header,
>    interface index (for traffic already rehashed onto different paths),
>    DS fields -- are considered as part of the hash, rehashing may result
>    in the fragments being delivered to different end-systems
> 
> AFAIK the use of a 5-tuple which includes the L4 header to compute a
> hash to make a forwarding decisions among otherwise equal paths is an
> implementation optimization only, it is not something which is
> explicitly prescribed by our standards.  Therefore, I'll claim that
> applying this logic to fragments, causing packet delivery to different
> hosts for initial and subsequent fragments (e.g. in the case of a load
> balancer) is an incorrectly applied optimization, also known as a bug.

+1 to that last sentence.

Note that the problems faced by stateless load balancers are 
discussed in Section 3 of the flow label specification (RFC 6437).

> In section 2.1.4. Other considerations you say:
> 
>    It is common practice [RFC6192] to recommend that control-plane
>    ACLs protecting routers and network devices be configured to drop
>    all fragments.
> 
> Well, there exists an informational RFC [6192] which contains an
> example policy and also some detailed discussion about handling of
> fragments.  I don't think it in sum says what is said here, though.

Agreed, and I think that the document would be improved by leaving 
out the last sentence in 2.1.4.  (The points about disproptionate 
numbers of software errors in fragment processing are on target, 
though.)

Mike Heard