Early Review of draft-ietf-intarea-frag-fragile-10
review-ietf-intarea-frag-fragile-10-intdir-early-chown-2019-05-15-00

Reviewer: Tim Chown
Review result: Ready with Nits

This is a INT-DIR review of draft-ietf-intarea-frag-fragile-10, which was
updated from the -09 version on 14th May.

Overall:
This is a well-written draft, explaining both the weaknesses of relying on IP
fragmentation for robust operations, and giving recommendations for various
audiences on steps to take to minimise both the use and impact of IP
fragmentation.

The draft is a more pragmatic approach to living with the realities of IP
fragmentation than the somewhat more "aggressive" previous draft from one of
its authors - draft-bonica-6man-frag-deprecate-02.  I note that some elements
from that draft have been carried forward into this, such as the text on OSPF.

I fully support publication of this draft, which is pretty much ready to go.  I
have a small number of comments below, none of which are critical, but which
the authors may wish to address, and a few nits that should be addressed to
minimise the work for the RFC Editor.

Comments:

Section 1
The last sentence in paragraph 2 of the Introduction might better be reworded
to say something like the 2nd para of section 7.1, about environments where IP
fragmentation is supported; as it stands the sentence isn't wholly clear, nor
is it clear how "security and interoperability issues are addressed".

Section 2.1
I understand what NOTE1 is saying, but some reference supporting why "for
practical purposes many network operators consider the IPv4 minimum link MTU to
be 576 bytes" would be welcome.

Section 2.3
Perhaps emphasise that what is described here is existing practice, rather than
what is recommended in Section 7 (which may vary), e.g., the text around
estimating the MPTU to be 1280 for IPv4 with the DNS(SEC) baggage that comes
with that.

Section 4.3
This subject is also talked about in more detail in Section 4.6, so either move
the text or add a pointer there.

Section 4.7:
RFC 4890 targets ICMPv6; the text implies it's generic.
Para 4 should also mention 4.7.4 as we as .2 and .3.
What are the "any other sources" mentioned in the last line?

Section 4.8:
I recall Fernando and I cause some controversy in 6man by discussing such
reasons in our draft that was eventually published as RFC 7872, and had to
remove them leaving just the measurement results and methodology, so you may
run into similar comments here. If you keep it, there is also
draft-taylor-v6ops-fragdrop-02 to consider, which ran into similar choppy
waters.

Section 5.1
In the para beginning "Upper-layer protocols", how do you determine that that
risk is acceptable?  Is the language of 7.1 better here, about IP fragmentation
being known to be supported?

Section 5.1
In para beginning "While TCP will"... there is an example in
draft-bonica-6man-frag-deprecate-02 where this may not be true, if there's
multiple paths being used?

Section 5.1
At the end, is there maybe something to add about QUIC; it would be interesting
to comment on how it handles fragmentation.

Section 6:
In draft-bonica-6man-frag-deprecate-02 there are other examples given, i.e.,
SIIT, DCCP and NFS.  I think it's fine to just list DNS, OSPF and tunnelling,
but maybe emphasise that the key issue with DNS is likely around DNSSEC (as
discussed later).

Section 7.5:
Last para, does that open a door to spoofing attacks using those server IPs? 
Presumably the suggestion is to only dd this for the ISP's own known servers?

Nits:

Section 1
The first two sentences in the Introduction duplicate the same wording and read
rather clumsily.

Page 4 para 2:
IP single -> single IP

Page 4, bottom:
given time, -> given time

Page 5, NOTE3:
is Destination -> is a Destination

Section 2.3, page 7:
relies of -> relies on

Section 4.6:
Add a reference for the Rose attack.
These four issues could also be written as subsections 4.6.1, 4.6.2, etc.

Section 4.7, First para
the networks to -> the network to

Section 5.1
In the para beginning "Upper-layer protocols" should that reference to 2.1 be
2.3 (and maybe 4.7)?

Section 7.1
At the end, state in -> stated in