Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01

From: Ron Bonica <[email-masked]>
Date: Thu, 31 May 2018 18:57:41 +0000

Hi Mikael,

Thanks for your careful review. Responses inline.

                           Ron

> -----Original Message-----
> From: Mikael Abrahamsson <[email-masked]>
> Sent: Tuesday, March 6, 2018 4:57 AM
> To: Ron Bonica <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
> 
> On Mon, 5 Mar 2018, Ron Bonica wrote:
> 
> > Folks,
> >
> > Please review draft-bonica-intarea-frag-fragile-01 and provide comments.
> > The URL is
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dbonica-2Dintarea-2Dfrag-2Dfragile-
> 2D01&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=rEnXuPqkshyKZKBjvbX5C4azFkl4x3umDYP-
> M8MPk9k&s=fzVLPQb705xxBUc4zque37mctCX2lPbU4hREEMOtsjU&e=.
> 
> I like it.
> 
> 4.6. There are cases where this "misconfiguration" is due to vendor default
> not being changed. I do not equate "misconfiguration" with "didn't change
> default configuration". Some others might. It might also be due to "hardware
> limitation". Generally, I do not like the "filtering" (I have opposed to this in
> other drafts), as for me "filtering" conveys intent. If there is no intent, there
> is no filtering, but instead there is "dropping"
> or some other word.

Agree. I have expanded this text in the next draft version.

> 
> 4.7 Can we please have 4.7 that describes cases where ICMP PTB are never
> emitted because of misconfiguration? For instance intermediate L2 switch
> that has lower MTU than the L3 nodes connected to it, or mismatched
> MTU/MRU on two nodes connected to each other.

I have added this text in Section 7.2 saying that network devices must be configured so that they emit ICMP PTBs when required to do so.

> 
> 5.1. Can we have some kind of strong recommendation that hosts enable
> PLMTUD for TCP?
> 
While I agree with this recommendation, I am not sure if the INT AREA is empowered to make it. Wouldn't such a recommendation have to come from the TSV area?

> 6. "IP encapsulations". Shouldn't this be "some packet-in-packet
> encapsulations"? Or does "IP encapsulations" mean "anything encapsulated
> in IP"? 6.3 talks about this as well, I think it's worthwile to put in a sentence
> that whatever is said in this document, probably applies to all kinds of
> encapsulations.

I have changed the term "IP encapsulations" to "Packet-in-packet encapsulations"
> 
> 6.1. Err, last paragraph, aren't we getting ahead of ourselves here? I guess
> this is because of Geoff Hustons claims? That last paragraph is in dispute (I'd
> say, from talking to other people involved in DNS).
> 

I will defer to Geoff on this one.

> 7.2. I strongly believe we need more text here. It should be something along
> the lines of:
> 
> "As per RFC4890, network operators MUST assure proper operation of
> PMTUD by making sure that PTB packets are emitted by all equipment when
> it can't fit a packet into a smaller MTU link, and that large MTU packets are
> not silently discarded due to misconfiguration. Network operators MUST
> NOT filter ICMP PTB packets."

Agree. It is in the next version

> 
> ...
> 
> As a last comment, do we know documents that tell application developers
> how to do what this document recommends in 5.2? If someone developers
> applications that use UDP for instance, how do they know what the
> operating system PMTUD is at any given time, to avoid the host stack
> fragmenting the packet? I've been interacting with people who had this
> specific problem, and it wasn't easy to figure out exactly how to do what
> is being said in this text (which I agree should be done).
> 
If I understand you correctly, such documentation would be available on per-OS basis.

> Generally, I think the IETF should strongly recommend application/protocol
> developers to not rely on IP fragmentation, generally. So the ones listed
> in 6 (and I imagine there are more of them), should change the way the
> protocol is done. This includes DNS. So all working groups should be put
> on notice to start working on this problem if they don't already have a
> solution for it.
> 

This draft is intended to bring the IETF community to the conclusion that you have drawn.

                                                      Ron

> --
> Mikael Abrahamsson    email: [email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Thu, 31 May 2018 19:07:17 +0000

Joe,

draft-ietf-tsvwg-udp-options is exactly the kind of work that the current draft encourages. If IP fragmentation is fragile, it makes sense for upper-layer protocols to manage fragmentation/mtu issues on their own, without relying on IP fragmentation.

                                                                 Ron

> From: Joe Touch <[email-masked]>
> Sent: Tuesday, March 6, 2018 9:39 AM
> To: Bob Hinden <[email-masked]>
> Cc: Ron Bonica <[email-masked]>; [email-masked]
> You might also want to look at tsvwg-udp-options
> 
> In one case, they’re used to support PLPMTUD (which you already note).
> 
> Alternatively, they provide transport-layer frag/reassembly that might be
> useful for DNSSEC as well as enabling NAT-traversal by retaining ports across
> fragments.
> 
> Joe
> 
> > On Mar 5, 2018, at 8:46 AM, Bob Hinden <[email-masked]> wrote:
> >
> > Joe,
> >
> >> On Mar 5, 2018, at 7:01 AM, Joe Touch <[email-masked]> wrote:
> >>
> >> This doc completely overlooks the role of fragmentation in IP over IP
> tunneling and the reason fragmentation is critical (IP has a maximum packet
> size, not just a minimum).
> >>
> >> See draft-ietf-intarea-tunnels.
> >
> > Good point.  We will take a look at intarea-tunnels and look at some
> changes to the fragmentation draft.
> >
> > Bob
> >
> >
> >
> >>
> >> As a result, IMO the recommendations and conclusions are incorrect.
> >>
> >> Joe
> >>
> >>> On Mar 5, 2018, at 6:16 AM, Ron Bonica <[email-masked]> wrote:
> >>>
> >>> Folks,
> >>>
> >>> Please review draft-bonica-intarea-frag-fragile-01 and provide
> comments. The URL is https://urldefense.proofpoint.com/v2/url?u=https-
> 2D01&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> AWF2EfpHcAwrDThKP8&m=AEfVoWEI_y-
> fXbwagR6fLa9LxTvU84wSqZf7cfq8MMo&s=1BXC0R2MgOhj08X6daQJGuz-
> HFRTMWC9aWrOzYs9YVY&e=.
> >>>
> >>>                                                                                     Ron
> >>>
> >>> _______________________________________________
> >>> Int-area mailing list
> >>> [email-masked]
> 3A__www.ietf.org_mailman_listinfo_int-
> 2Darea&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> AWF2EfpHcAwrDThKP8&m=AEfVoWEI_y-
> fXbwagR6fLa9LxTvU84wSqZf7cfq8MMo&s=0Cvq_laf4iRVWveuZftQ4J1amkse
> XcCNdeMIxTJMEis&e=
> >>
> >> _______________________________________________
> >> Int-area mailing list
> >> [email-masked]
> 3A__www.ietf.org_mailman_listinfo_int-
> 2Darea&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> AWF2EfpHcAwrDThKP8&m=AEfVoWEI_y-
> fXbwagR6fLa9LxTvU84wSqZf7cfq8MMo&s=0Cvq_laf4iRVWveuZftQ4J1amkse
> XcCNdeMIxTJMEis&e=
> >

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 May 2018 19:59:12 -0700

> On May 31, 2018, at 12:07 PM, Ron Bonica <[email-masked]> wrote:
> 
> Joe,
> 

I disagree.

UDP fragmentation has its benefits and uses, but should not be required when a transport layer isn’t needed - e.g., for IP tunneling.

Fundamentally, IP fragmentation is fragile for only a few reasons:
1) the ID space is small (which shouldn’t matter unless there is a very large amount of reordering)
2) loss of fragments creates inefficiencies (true, but routers can fate-share fragments they drop sometimes, just as was eventually done for ATM AAL5)
3) in-network devices can’t find transport ports in some fragments, causing problems for NATs, policy filters and firewalls, etc.

Of these, my view is that #3 is the only reason actually driving a claim of fragility - and all it tells me is that “the Internet is fragile when devices don’t follow the rules”.

I do not think it is appropriate to validate that conclusion.

Joe