[Int-area] draft-bonica-intarea-frag-fragile-01

Discussion:

Ron Bonica

2018-03-05 14:16:59 UTC

Folks,

Please review draft-bonica-intarea-frag-fragile-01 and provide comments. The URL is https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile-01.

Ron

Joe Touch

2018-03-05 15:01:24 UTC

Permalink

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.

As a result, IMO the recommendations and conclusions are incorrect.

Joe

Post by Ron Bonica
Folks,
Please review draft-bonica-intarea-frag-fragile-01 and provide comments. The URL is https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile-01.
Ron
_______________________________________________
Int-area mailing list
https://www.ietf.org/mailman/listinfo/int-area

Ron Bonica

2018-03-05 15:42:51 UTC

Permalink

Hi Joe,

The draft does talk about a case where outer fragmentation is required. This is a problem that remains to be solved.

Please remember that this is a very new draft. It doesn't claim to have all of the answers, yet. Let's chat in London.

Ron

-----Original Message-----
Sent: Monday, March 5, 2018 10:01 AM
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
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.
As a result, IMO the recommendations and conclusions are incorrect.
Joe

Post by Ron Bonica
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=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
AWF2EfpHcAwrDThKP8&m=gSNpTcaRgeLalrZ3qiQd75blm0UVJ8xCMRqRFbX
UqgQ&s=wk0DX-Xnmbk2xXTQPuWpTkC76wT_PQRvDMvbe2UjlEE&e=.

Post by Ron Bonica
Ron
_______________________________________________
Int-area mailing list
https://urldefense.proofpoint.com/v2/url?u=https-

3A__www.ietf.org_mailman_listinfo_int-
2Darea&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
AWF2EfpHcAwrDThKP8&m=gSNpTcaRgeLalrZ3qiQd75blm0UVJ8xCMRqRFbX
UqgQ&s=IgKKm8ZzwQrQquREE1eEzDHxQyIpdXLba8-kYLj-Dzc&e=

Joe Touch

2018-03-05 15:57:30 UTC

Permalink

Hi, Ron,

I will not be in London.

Joe

Post by Ron Bonica
Hi Joe,
The draft does talk about a case where outer fragmentation is required. This is a problem that remains to be solved.
Please remember that this is a very new draft. It doesn't claim to have all of the answers, yet. Let's chat in London.
Ron

Post by Ron Bonica
Folks,
Please review draft-bonica-intarea-frag-fragile-01 and provide comments.

Post by Ron Bonica
Ron
_______________________________________________
Int-area mailing list
https://urldefense.proofpoint.com/v2/url?u=https-

Bob Hinden

2018-03-05 16:46:34 UTC

Permalink

Joe,

Post by Joe Touch
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

Post by Joe Touch
As a result, IMO the recommendations and conclusions are incorrect.
Joe

_______________________________________________
Int-area mailing list
https://www.ietf.org/mailman/listinfo/int-area

Joe Touch

2018-03-06 14:38:40 UTC

Permalink

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

Post by Bob Hinden
Joe,

Good point. We will take a look at intarea-tunnels and look at some changes to the fragmentation draft.
Bob

Post by Joe Touch
As a result, IMO the recommendations and conclusions are incorrect.
Joe

_______________________________________________
Int-area mailing list
https://www.ietf.org/mailman/listinfo/int-area

Mikael Abrahamsson

2018-03-06 09:57:22 UTC

Permalink

Post by Ron Bonica
Folks,
Please review draft-bonica-intarea-frag-fragile-01 and provide comments.
The URL is
https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile-01.

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.

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.

5.1. Can we have some kind of strong recommendation that hosts enable
PLMTUD for TCP?

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.

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

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

...

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

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.

--
Mikael Abrahamsson email: ***@swm.pp.se

Tom Herbert

2018-03-06 16:02:44 UTC

Permalink

Post by Ron Bonica
Folks,
Please review draft-bonica-intarea-frag-fragile-01 and provide comments. The URL is https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile-01.

Ron,

This draft should reference RFC4459 which gives a very good
description of MTU and fragmentation problems and handling for network
tunnels.

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.

Tom

Joe Touch

2018-03-06 17:38:40 UTC

Permalink

Agreed but note that draft tunnels will update that RFC in some important ways.

Joe

Post by Tom Herbert

Post by Ron Bonica
Folks,
Please review draft-bonica-intarea-frag-fragile-01 and provide comments. The URL is https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile-01.

Ron,
This draft should reference RFC4459 which gives a very good
description of MTU and fragmentation problems and handling for network
tunnels.
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.
Tom
_______________________________________________
Int-area mailing list
https://www.ietf.org/mailman/listinfo/int-area

Ole Troan

2018-03-06 19:16:38 UTC

Permalink

Joe,

Post by Joe Touch
Agreed but note that draft tunnels will update that RFC in some important ways.

With other concerns than those raised in e.g. 4459 and 7597?
Unfortunately there are cases where there are no other choice than to do fragmentation/reassembly on tunnel endpoints, but still the recommendation holds.
It is so problematic, that it is strongly recommended to engineer the network to avoid that happening.

Cheers,
Ole

Templin, Fred L

2018-03-06 19:40:55 UTC

Permalink

I think it is important to remember that this draft is about *IP* layer
fragmentation. Tunnels can employ tunnel-layer fragmentation at a
layer above IP:

https://datatracker.ietf.org/doc/draft-ietf-intarea-gue-extensions/
https://datatracker.ietf.org/doc/draft-templin-intarea-grefrag/

Or, if the draft intends to also cover tunnel-layer fragmentation it
should probably be updated to say so.

Thanks - Fred

-----Original Message-----
Sent: Tuesday, March 06, 2018 11:17 AM
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
Joe,

Post by Joe Touch
Agreed but note that draft tunnels will update that RFC in some important ways.

With other concerns than those raised in e.g. 4459 and 7597?
Unfortunately there are cases where there are no other choice than to do fragmentation/reassembly on tunnel endpoints, but still
the recommendation holds.
It is so problematic, that it is strongly recommended to engineer the network to avoid that happening.
Cheers,
Ole

Tom Herbert

2018-03-06 19:41:34 UTC

Permalink

Post by Ole Troan
Joe,

Post by Joe Touch
Agreed but note that draft tunnels will update that RFC in some important ways.

Hi Ole,

That may be recommendation, but that is not was has been done all
networks. I worked in two very large datacenter networks that use a
lot encapsulation, but they didn't do anything special to engineer the
network for encapsulation. There was reluctance to set an MTU below
1500 and jumbo frames were always discussed, but in the end they
deploying them seem to be more complicated than it was worth. So
fragmentation did occur pretty regularly at tunnel ingress.

Fragmentation never popped up as a problem because of some mitigating
factors: 1) packets from the Internet be encapsulated usually were
already less than 1500 bytes(when encapsulating for VIPs) 2) This
always generated precisely two fragments 3) encapsulation is being
done on a closed network so there is no chance of DOS attack on the
reassembly cache (fragments from the Internet are dropped) 4)
encapsulation is otherwise rare relative non-encapsulation, so
lowering the MTU would only benefits the special case and hurts the
common case.

Tom

Post by Ole Troan
Cheers,
Ole

Joe Touch

2018-03-07 02:57:23 UTC

Permalink

Post by Ole Troan
Joe,

Post by Joe Touch
Agreed but note that draft tunnels will update that RFC in some important ways.

With other concerns than those raised in e.g. 4459 and 7597?

draft-tunnels corrects an error in 4459 that deals with the details, not the overall recommendation (AFAIR, at least).

Post by Ole Troan
Unfortunately there are cases where there are no other choice than to do fragmentation/reassembly on tunnel endpoints, but still the recommendation holds.
It is so problematic, that it is strongly recommended to engineer the network to avoid that happening.

IMO, there are two truths:

1) use of IP fragmentation SHOULD be avoided where possible, largely because it has reliability issues (ICMP blocking, NATs won’t tunnel frags and fail to [as required if they act on transport info] reassemble, etc.)

2) support for IP fragmentation MUST remain required, as MUST (IMO) NAT reassembly before transport rewriting

Yeah, I know a lot of devices fail the MUSTs in #2, but the requirements ought to set the goal, not describe the (sorry) current state.

#2 has to persist until we deprecate IP-in-IP tunneling (including tunnel-mode IPsec), as well as any IP-in-X*-in-IP for zero or more intermediate layers X where no layer supports fragmentation and reassembly

I’ve been working to fix the need for IP frag by developing support for that in UDP, but it doesn’t mean we should be ready to outlaw it.

I’m not sure what this doc does to add to this scene, though - it might be useful if the authors could explain how it affects 1 and 2 above and what else it adds in a *brief* post.

Joe

Ron Bonica

2018-03-07 15:39:47 UTC

Permalink

Joe,

Your "Two Truths" are in line with the recommendations in Section 7 of draft-bonica-intarea-frag-fragile-01. The draft recommends that upper-layer protocols avoid doing things that cause fragmentation. It does not recommend the deprecation of fragmentation.

Ron

.

-----Original Message-----
Sent: Tuesday, March 6, 2018 9:57 PM
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Post by Ole Troan
Joe,

Post by Joe Touch
Agreed but note that draft tunnels will update that RFC in some important

ways.

Post by Ole Troan
With other concerns than those raised in e.g. 4459 and 7597?

draft-tunnels corrects an error in 4459 that deals with the details, not the
overall recommendation (AFAIR, at least).

Post by Ole Troan
Unfortunately there are cases where there are no other choice than to do

fragmentation/reassembly on tunnel endpoints, but still the
recommendation holds.

Post by Ole Troan
It is so problematic, that it is strongly recommended to engineer the

network to avoid that happening.
1) use of IP fragmentation SHOULD be avoided where possible, largely
because it has reliability issues (ICMP blocking, NATs won’t tunnel frags and
fail to [as required if they act on transport info] reassemble, etc.)
2) support for IP fragmentation MUST remain required, as MUST (IMO) NAT
reassembly before transport rewriting
Yeah, I know a lot of devices fail the MUSTs in #2, but the requirements
ought to set the goal, not describe the (sorry) current state.
#2 has to persist until we deprecate IP-in-IP tunneling (including tunnel-
mode IPsec), as well as any IP-in-X*-in-IP for zero or more intermediate
layers X where no layer supports fragmentation and reassembly
I’ve been working to fix the need for IP frag by developing support for that in
UDP, but it doesn’t mean we should be ready to outlaw it.
I’m not sure what this doc does to add to this scene, though - it might be
useful if the authors could explain how it affects 1 and 2 above and what else
it adds in a *brief* post.
Joe

Joe Touch

2018-03-07 16:52:12 UTC

Permalink

Post by Ron Bonica
Joe,
Your "Two Truths" are in line with the recommendations in Section 7 of draft-bonica-intarea-frag-fragile-01. The draft recommends that upper-layer protocols avoid doing things that cause fragmentation. It does not recommend the deprecation of fragmentation.

Understood, but without #2 being included and explicitly co-reinforced there is an implication to router designers that I would hope can be avoided.

Joe

Post by Ron Bonica
Ron
.

-----Original Message-----
Sent: Tuesday, March 6, 2018 9:57 PM
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Post by Ole Troan
Joe,

Post by Joe Touch
Agreed but note that draft tunnels will update that RFC in some important

ways.

Post by Ole Troan
With other concerns than those raised in e.g. 4459 and 7597?

draft-tunnels corrects an error in 4459 that deals with the details, not the
overall recommendation (AFAIR, at least).

Post by Ole Troan
Unfortunately there are cases where there are no other choice than to do

fragmentation/reassembly on tunnel endpoints, but still the
recommendation holds.

Post by Ole Troan
It is so problematic, that it is strongly recommended to engineer the

Joe Touch

2018-03-07 16:56:52 UTC

Permalink

Also IMO the lack of frag support should be called out as a bug, not merely acknowledged or (worse) commended. Reassembly by middle boxes should be called out as well - or by any DPI (or the equivalent, I e by reassembling a copy used for frag processing context.)

Joe

Post by Joe Touch

Understood, but without #2 being included and explicitly co-reinforced there is an implication to router designers that I would hope can be avoided.
Joe

Post by Ron Bonica
Ron
.

-----Original Message-----
Sent: Tuesday, March 6, 2018 9:57 PM
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Post by Ole Troan
Joe,

Post by Joe Touch
Agreed but note that draft tunnels will update that RFC in some important

ways.

Post by Ole Troan
With other concerns than those raised in e.g. 4459 and 7597?

draft-tunnels corrects an error in 4459 that deals with the details, not the
overall recommendation (AFAIR, at least).

Post by Ole Troan
Unfortunately there are cases where there are no other choice than to do

fragmentation/reassembly on tunnel endpoints, but still the
recommendation holds.

Post by Ole Troan
It is so problematic, that it is strongly recommended to engineer the

Templin, Fred L

2018-03-07 17:13:03 UTC

Permalink

Joe,

About middle-box reassembly, it should probably also mention Virtual Fragment
Reassembly where the middlebox gathers fragments but does not reassemble
them. Then, when all fragments have been received the middlebox performs
any transformations then releases the fragments. Several cisco webpages talk
about this.

Thanks - Fred

-----Original Message-----
Sent: Wednesday, March 07, 2018 8:52 AM
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Post by Ron Bonica
Joe,
Your "Two Truths" are in line with the recommendations in Section 7 of draft-bonica-intarea-frag-fragile-01. The draft recommends

that upper-layer protocols avoid doing things that cause fragmentation. It does not recommend the deprecation of fragmentation.
Understood, but without #2 being included and explicitly co-reinforced there is an implication to router designers that I would hope
can be avoided.
Joe

Post by Ron Bonica
Ron
.

-----Original Message-----
Sent: Tuesday, March 6, 2018 9:57 PM
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Post by Ole Troan
Joe,

Post by Joe Touch
Agreed but note that draft tunnels will update that RFC in some important

ways.

Post by Ole Troan
With other concerns than those raised in e.g. 4459 and 7597?

draft-tunnels corrects an error in 4459 that deals with the details, not the
overall recommendation (AFAIR, at least).

Post by Ole Troan
Unfortunately there are cases where there are no other choice than to do

fragmentation/reassembly on tunnel endpoints, but still the
recommendation holds.

Post by Ole Troan
It is so problematic, that it is strongly recommended to engineer the

_______________________________________________
Int-area mailing list
https://www.ietf.org/mailman/listinfo/int-area

Joe Touch

2018-03-07 17:33:39 UTC

Permalink

Post by Templin, Fred L
Joe,
About middle-box reassembly, it should probably also mention Virtual Fragment
Reassembly where the middlebox gathers fragments but does not reassemble
them.

That’s part of what I was referring to in my other post.

Joe

Post by Templin, Fred L
Then, when all fragments have been received the middlebox performs
any transformations then releases the fragments. Several cisco webpages talk
about this.
Thanks - Fred

-----Original Message-----
Sent: Wednesday, March 07, 2018 8:52 AM
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Post by Ron Bonica
Joe,
Your "Two Truths" are in line with the recommendations in Section 7 of draft-bonica-intarea-frag-fragile-01. The draft recommends

Post by Ron Bonica
Ron
.

-----Original Message-----
Sent: Tuesday, March 6, 2018 9:57 PM
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Post by Ole Troan
Joe,

Post by Joe Touch
Agreed but note that draft tunnels will update that RFC in some important

ways.

Post by Ole Troan
With other concerns than those raised in e.g. 4459 and 7597?

draft-tunnels corrects an error in 4459 that deals with the details, not the
overall recommendation (AFAIR, at least).

Post by Ole Troan
Unfortunately there are cases where there are no other choice than to do

fragmentation/reassembly on tunnel endpoints, but still the
recommendation holds.

Post by Ole Troan
It is so problematic, that it is strongly recommended to engineer the

_______________________________________________
Int-area mailing list
https://www.ietf.org/mailman/listinfo/int-area

Templin, Fred L

2018-03-07 15:30:18 UTC

Permalink

Hi Tom,

-----Original Message-----
Sent: Tuesday, March 06, 2018 8:03 AM
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Post by Ron Bonica
Folks,
Please review draft-bonica-intarea-frag-fragile-01 and provide comments. The URL is https://tools.ietf.org/html/draft-bonica-

intarea-frag-fragile-01.
Ron,
This draft should reference RFC4459 which gives a very good
description of MTU and fragmentation problems and handling for network
tunnels.
GUE could be mentioned in the "IP encapsulations" sections. As
proposed by RFC4459,

RFC4459 does not propose tunnel fragmentation (i.e., fragmentation
at a layer above IP but below the transport protocol).

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.

Tunnel fragmentation was first discussed in RFC2764, then later by
me in RFC5320 and in all of my subsequent writings, which is how
it found its way into GUE extensions.

Thanks - Fred

Tom
_______________________________________________
Int-area mailing list
https://www.ietf.org/mailman/listinfo/int-area

Tom Herbert

2018-03-07 15:46:38 UTC

Permalink

On Mar 7, 2018 7:30 AM, "Templin, Fred L" <***@boeing.com> wrote:

Hi Tom,

-----Original Message-----
Sent: Tuesday, March 06, 2018 8:03 AM
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Post by Ron Bonica
Folks,
Please review draft-bonica-intarea-frag-fragile-01 and provide

comments. The URL is https://tools.ietf.org/html/draft-bonica-

RFC4459 does not propose tunnel fragmentation (i.e., fragmentation
at a layer above IP but below the transport protocol).

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.

Tunnel fragmentation was first discussed in RFC2764, then later by
me in RFC5320 and in all of my subsequent writings, which is how
it found its way into GUE extensions.

Yes, RFC4459 suggests the possibility of fragmenting the inner IP packet,
but that is not possible if it's IPv6. Fragmentation with the encapsulation
doesn't have that limitation.

Thanks for the clarification.

Tom

Thanks - Fred

Tom
_______________________________________________
Int-area mailing list
https://www.ietf.org/mailman/listinfo/int-area