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

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 1 Jun 2018 11:54:40 +0200 (CEST)

On Thu, 31 May 2018, Joe Touch wrote:

> 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.

You're fundamentally right, unfortunately operational reality adds lots of 
more points to your list, meaning the end outcome is that IP fragmentation 
doesn't work well in real life.

I am as opposed to letting bad practices win as you probably are, but I 
also don't think this is fixable. This means applications need to have a 
mode where they do not rely on IP fragments for basic operation.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tom Herbert <[email-masked]>
Date: Fri, 1 Jun 2018 11:47:37 -0700

On Fri, Jun 1, 2018, 2:54 AM Mikael Abrahamsson <[email-masked]> wrote:

> > UDP fragmentation has its benefits and uses, but should not be required
> when a transport layer isn’t needed - e.g., for IP tunneling.
> >
> > 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 agree with Joe. Would also note that #3 is not a problem with
fragmentation itself, but with middle boxes attempting to parse transport
layer information. That problem potentially exists any time a
"non-standard" IP protocol number is used (ie something other than UDP it
TCP). It would be best if the solution is to use generic mechanisms to
provide functionality, as opposed to discouraging use of protocols or
fragmentation. Using flow label for ECMP is s good example, this eliminates
need for DPI and works with fragmentation or any IP protocol.

I think this draft should distinguish problems inherent in IP fragmentation
and those that have be created by middle boxes that can't deal with
fragments

Tom

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 01 Jun 2018 12:04:45 -0700

On 2018-06-01 02:54, Mikael Abrahamsson wrote:

>> UDP fragmentation has its benefits and uses, but should not be required when a transport layer isn't needed - e.g., for IP tunneling.
>> 
>> 1) the ID space is small (which shouldn't matter unless there is a very large amount of reordering)
>> 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".
>> 
> You're fundamentally right, unfortunately operational reality adds lots of more points to your list, meaning the end outcome is that IP fragmentation doesn't work well in real life.
> 
> I am as opposed to letting bad practices win as you probably are, but I also don't think this is fixable. This means applications need to have a mode where they do not rely on IP fragments for basic operation.

I am OK if the conclusion says: 

1) this is a bug/incorrect implementation that needs to be fixed 
2) in the meantime, users (not just apps) should consider using other
ways, esp. if their system cannot detect whether the use of IP fragments
fails 
3) #2 should not be interpreted to let implementers off the hook for #1 

I.e., IP fragmentation should not be deprecated; its avoidance should
not imply that deprecation, and vendors are responsible for the bug that
not supporting fragmentation represents. 

Joe

---

From: Ron Bonica <[email-masked]>
Date: Sat, 2 Jun 2018 14:57:50 +0000

Hi Tom,

Thanks for your review. Comments inline.....

> -----Original Message-----
> From: Tom Herbert <[email-masked]>
> Sent: Tuesday, March 6, 2018 11:03 AM
> To: Ron Bonica <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
> 
> On Mon, 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-
> 3A__tools.ietf.org_html_draft-2Dbonica-2Dintarea-2Dfrag-2Dfragile-
> 2D01&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=u5HvJHkDXwhk6jsejlj0NpC-
> dEFpKMg3Pz0cKt63Xjs&s=4s_vPVzBk1YX8N_0eHzibCwEjp5cGS9TDYigTud_c5
> o&e=.
> >
> Ron,
> 
> This draft should reference RFC4459 which gives a very good description of
> MTU and fragmentation problems and handling for network tunnels.
> 

RB> Agree. Added in next version.

> GUE could be mentioned in the "IP encapsulations" sections. As proposed by
> RFC4459, GUE extensions include a fragmentation option within the
> encapsulation headers in lieu of doing IP fragmentation.
> This is addresses several of the problems described for IP fragmentation.
> 

RB> Could we defer this until GUE gets and RFC number. Otherwise, the draft may be required to list an amazing number of IP-in-IP encapsulations.

                                  Ron

---

From: Joe Touch <[email-masked]>
Date: Sat, 2 Jun 2018 11:00:59 -0700

> On Jun 2, 2018, at 7:57 AM, Ron Bonica <[email-masked]> wrote:
> 
> ...
>> 
>> 

intarea-tunnels will be updating that RFC. It would be useful to not repeat its incorrect recommendations.

> RB> Could we defer this until GUE gets and RFC number. Otherwise, the draft may be required to list an amazing number of IP-in-IP encapsulations.

That’s already in intarea-tunnels and can be cited there.

However, the IP-in-IP direct case is still very relevant - it is the basis of IPsec (e.g., see in particular RFC3884). This document should not undermine that case.

Joe