Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

[Mikael Abrahamsson <[e-mail]>]

On Mon, 14 Jan 2019, Wassim Haddad wrote:

> This email starts an Int-Area WG Last Call on the latest version of "IP Fragmentation Considered Fragile” draft:
>
> https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-05
>
> Please respond to this email to support the document and/or send comments by 2019-01-28.

I re-read the entire document as if I never read it before. Commenting as 
I am reading it:

2.1

"Therefore, the downstream router drops the packet and sends an
    Internet Control Message Protocol (ICMP) [RFC0792] [RFC4443] Packet
    Too Big (PTB) message to the source node.  The ICMP PTB message"

Yes, that's what it's supposed to do, and it does that unless it doesn't 
because something is wrong. Everything in 2.1 describes the way things are 
supposed to work in a language that just states "this is what happens". 
Wouldn't it make more sense to write it in a wording that is "this is 
supposed to happen" or "the design states that this should happen" or 
"this is expected behavior"?

The header about PMTUD characteristics is a bit short, it has lots of 
other characteristics. There are a lot of other things it relies on. Does 
this need to be enhanced somehow? Otherwise, change wording to make it 
explicit that these are just examples?

2.2

"   When an upper-layer protocol submits data to the underlying IP
    module, and the resulting IP packet's length is greater than the
    PMTU, the packet can be divided into fragments.  Each fragment
    includes an IP header and a portion of the original packet."

What about changing this to:

"   If an upper-layer protocol submits data to the underlying IP
    module, and the resulting IP packet's length is greater than the
    PMTU, the packet will be divided into fragments.  Each fragment
    includes an IP header and a portion of the original packet."

Since the whole idea of this document is to try to steer people away from 
using fragmentation, doesn't it make sense to word things in a way that 
states what will happen, and the "if" is more "please don't do this"?

"  [RFC0791] describes IPv4 fragmentation procedures.  An IPv4 packet
    whose DF-bit is set to one cannot be fragmented."

I thought the DF bit was instructions to the downstream routers and not to 
the host itself? What happens if I send an fragmented IPv4 packet with the 
DF bit set? Is this invalid?

RFC 791 says:

"An internet datagram can be marked "don't fragment."  Any internet
     datagram so marked is not to be internet fragmented under any
     circumstances."

Does this really prohibit the host from sending fragmented packets with 
the DF bit set?

4.3. Does this paragraph imply that a stateful firewall uses virtual 
re-assembly? Perhaps this should be stated explicitly? As an answer to 
"This problem does not occur in stateful firewalls." Perhaps 4.2 can be 
enhanced to talk about NAT/PAT and stateful firewalls (I imagine they 
share similar characteristics when it comes to handling fragmented 
packets?)

4.4. I'm sure there are other load balacing algorithms that uses all kinds 
of input, not only 5-tuple. Text should reflect that the use of 5-tuple is 
an example of an algorithm, not exhaustive list.

4.7

"Transient loss of ICMP PTB messages can cause transient black holes."

suggested new text:

"Transient loss of ICMP PTB messages can cause transient PMTU black 
holes."

Perhaps even the 4.7 header should be changed the same way to talk about 
"PMTU black hole" instead of just "black hole"

4.7.x. The case where a router doesn't generate PTB messages at high 
enough rate to handle all the flows. A few months back I helped diagnose a 
misconfiguration where MTU on an interface had been set to 150. That 
router wasn't able to generate PTB messages at the required rate to handle 
this situation.

4.8

I don't like the word "filtering". Filtering for me conveys intent. I have 
seen platforms that handle packets with fragment header differently than 
packets without fragment header, by default. So out of the box, this 
device had horrible forwarding performance for packets with fragmentation 
header. I'd like to have the word "filtering" here replaced with "loss" or 
similar word that doesn't convey intent. The main text already does this, 
but the 4.8 header says "filtering".

5.1

"While TCP will never cause the underlying IP module to emit a packet
    that is larger than the PMTU estimate, it can cause the underlying IP
    module to emit a packet that is larger than the actual PMTU.  If this
    occurs, the packet is dropped, the PMTU estimate is updated, the
    segment is divided into smaller segments and each smaller segment is
    submitted to the underlying IP module."

This is the ideal case and works well until it doesn't. If there is no 
PTB received and PLPMTUD isn't turned on, above will never happen and PMTU 
blackhole will persist.

7.4.

I'd like to start this paragraph with

"Operators MUST ensure proper PMTUD operation
    in their network"

... or similar text. This is the #1 thing for operators to do, and that 
implies for instance not filtering PTBs. So to put even more emphasis on 
this, I'd like to see this text re-structured to bring this requirement to 
the start of the paragraph. I believe I will be pointing to 7.4 for many 
years to come in discussions with fellow ISP colleagues.


Final comment:

I think this document is in good shape, valuable to the community, and I 
support it proceeding to publication with above comments.

-- 
Mikael Abrahamsson    email: [e-mail]