Re: draft-bonica-6man-frag-deprecate

[Brian E Carpenter <[e-mail]>]

On 29/06/2013 01:25, Havard Eidnes wrote:
> Hi,
> 
> some comments from this corner, some small, some not so...:
> 
> 
> In section 1:
> 
>    MTU is a unidirectional metric.  A bidirectional link may be
>    characterized by one MTU in the forward direction and another
>    MTU in the reverse direction.
> 
> I'm sure this is formally true.  However, in practice, I have
> never seen a router where you can separately configure the
> receive and transmit MTU.  So ... I would remove this altogether;
> it may otherwise pave the way for unsuspecting individuals
> reading this to create a path MTU discovery black hole by
> configuring inconsistent MTUs for devices on the same link.

True, but of course *path* MTU may well be unidirectional, if
the forward and reverse paths are different.  PMTUD definitely
has to allow for asymmetry, which is what counts for fragmentation.

   Brian

> 
> 
> In section 2.1:
> 
>    [Kent87] points out that the reassembly process is resource
>    intensive.  It consumes significant compute and memory resources.
> 
> Is that argument still valid today?  Is it impossible to engineer an
> implementaiton which restricts the memory consumption in order to
> improve robustness of the implementation?
> 
> 
> Section 2.2 states "Fragmentation Is Rare".  I think this will be
> hihgly dependent on your choice of observation points.  E.g. in the
> vicinity of an NFS server serving using UDP, I would not be
> surprised to see a lot of fragments.  And, as has been mentioned
> elsewhere in this discussion, in the vicinity of a DNSSEC-validating
> recursive DNS resolver, you would expect to see an increasing
> proportion of fragmented UDP traffic as DNSSEC deployment
> progresses.
> 
> 
> In section 2.2.1, the document appears to dismiss the DNSSEC use of
> UDP and fragmentation with "use TCP instead".  I beleive Mark
> Andrews in <[e-mail]> stated why
> this is far from good enough as an answer.  In addition to TCP PMTUD
> being too slow, you have the issue that TCP in general is about 3
> times slower than UDP in delivering a DNS response even if PMTUD is
> not involved -- I beleive RIPE NCC Labs did a test using their "RIPE
> Atlas" probes to check for this, and they came up with 2.5x - 3x as
> the slowdown factor.  Additionally there is the vastly increased
> need to keep state in DNS name servers by the TCP load which would
> result from the abolishment of UDP as a transport for DNS.
> 
> On top of this, there is the argument that "firewalls and network
> operators may filter DNS over TCP", but I would not use that as an
> argument because I consider it invalid -- more on that below.
> 
> 
> Section 2.3, "Attack vectors".  Isn't this whole section giving bad
> excuses to IP stack implementors for not providing a robust and
> well-tested implementation?!?  BTW, I'm wondering whether there is a
> spec issue lurking within this area, wrt. invalidating the most
> obscure corner cases?
> 
> 
> Section 2.4, "Operator behavior".  It is claimed that IPv6 fragments
> are being dropped in several places, e.g. by enterprise firewalls or
> other environments who want to tightly control what traffic is
> passed.  I claim that is's a matter of principle whether we let the
> tail wag the dog.  Firewall administrators or other users of the
> network may do unwise things when configuring their device, but
> should such behaviour be allowed to restrict what becomes
> standardized?!?  If that were the case, we might as well all
> restrict ourselves to speaking TCP over port 80.
> 
> 
> Section 3, "Recommendation".  I question whether you can in fact
> make the backward-incompatible change of getting rid of the need for
> implementations to support fragment reassembly -- the genie is
> already out of the bottle -- has been for quite a while, and I claim
> it's already too late to try to put it back in.  So some of the
> claimed attack vectors in section 2.3 will also be difficult to get
> rid of, as hosts will in all probability have to continue to support
> fragment reassembly for quite a while.
> 
> At the very least, there's a need to separate the recommendations
> for "sending fragments" and "support reception of fragments".
> 
> 
> Best regards,
> 
> - Håvard
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>