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

From: Ron Bonica <[email-masked]>
Date: Wed, 16 Jan 2019 01:40:46 +0000

Folks,

I am not aware of any IPR associated with this document.

                                         Ron

> 
> Please indicate if you are personally aware of any IPR that applies to draft-ietf-
> intarea-frag-fragile-xx?
> If so, has this IPR been disclosed in compliance with IETF IPR rules?
> 
> 
**********************************

---

From: Ron Bonica <[email-masked]>
Date: Wed, 16 Jan 2019 01:56:39 +0000

Brian,

Fair enough.  You will see that text in the next draft version.

                                                Ron

> 
> Me too. I think the root of the problem is the word "compliant". To be
> compliant with the IP model, middleboxes should not exist. I think what the
> text is trying to say is more like:
> 
> "Middle boxes SHOULD process IP fragments in a manner that is consistent
> with RFC 791 and RFC 8200."

---

From: Ron Bonica <[email-masked]>
Date: Fri, 18 Jan 2019 15:30:13 +0000

Mike,

All good points. Look for them all to be addressed in the next revision.

                                                Ron

> ------------------------------
> 
> Message: 3
> Date: Thu, 17 Jan 2019 10:42:47 +0100 (CET)
> From: Mikael Abrahamsson <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dintarea-2Dfrag-2Dfragile-
> 2D05&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=apXTk3scqb76SmzKdfcnrVtBWzmGnnb2YDRK_B
> NCT9M&s=iLCyia0qv4sobEzqqDAly8xsmM2JE7eF3kz85FcrNPY&e=
> >
> > 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: [email-masked]
>