Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 2 Feb 2017 09:37:16 +0000

Hi,

the last paragraph of the introduction reads:

   An extension to Path MTU Discovery defined in this document can be
   found in [RFC4821].  It defines a method for Packetization Layer Path
   MTU Discovery (PLPMTUD) designed for use over paths where delivery of
   ICMP messages to a host is not assured.

Given that ICMP delivery cannot be assured over the vast majority of paths in the current Internet, should this document make a recommendation to implement RFC4821?

Also, even if ICMP delivery is assured, there are additional complications for UDP, which has been seeing a lot of interest both as a tunneling encapsulation and for applications (e.g., QUIC). Many platforms do not provide UDP-sending applications any information about arriving ICMP messages that were triggered by their transmissions. So even if the path delivers ICMP, the OS makes ICMP-based PMTUD for UDP often impossible. Another reason to recommend 4821?

Lars

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Feb 2017 06:54:16 -0300

Hi, Lars,

On 02/02/2017 06:37 AM, Eggert, Lars wrote:
> found in [RFC4821].  It defines a method for Packetization Layer
> Path MTU Discovery (PLPMTUD) designed for use over paths where
> delivery of ICMP messages to a host is not assured.
> 
> Given that ICMP delivery cannot be assured over the vast majority of
> paths in the current Internet, should this document make a
> recommendation to implement RFC4821?

I think that RFC4821 should be recommended, at least for dealing with
ICMP blackholes (i.e., use ICMP if you can, but be able to deal with
scenarios in which you don't receive them).

> Also, even if ICMP delivery is assured, there are additional
> complications for UDP, which has been seeing a lot of interest both
> as a tunneling encapsulation and for applications (e.g., QUIC). Many
> platforms do not provide UDP-sending applications any information
> about arriving ICMP messages that were triggered by their
> transmissions. So even if the path delivers ICMP, the OS makes
> ICMP-based PMTUD for UDP often impossible. Another reason to
> recommend 4821?

Agreed... although in this case this would be more of an app-layer
implementation than one at the transport layer?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 2 Feb 2017 10:21:35 +0000

> implementation than one at the transport layer?

There are two dimensions here, one is in kernel vs. in userspace, the other which "layer" something is at. It used to be that "transport layer" (or "network layer" always implied "in kernel", but those days are past.

Lars

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Feb 2017 07:58:17 -0300

On 02/02/2017 07:21 AM, Eggert, Lars wrote:
>>> complications for UDP, which has been seeing a lot of interest
>>> both as a tunneling encapsulation and for applications (e.g.,
>>> QUIC). Many platforms do not provide UDP-sending applications any
>>> information about arriving ICMP messages that were triggered by
>>> their transmissions. So even if the path delivers ICMP, the OS
>>> makes ICMP-based PMTUD for UDP often impossible. Another reason
>>> to recommend 4821?
>> 
> There are two dimensions here, one is in kernel vs. in userspace, the
> other which "layer" something is at. It used to be that "transport
> layer" (or "network layer" always implied "in kernel", but those days
> are past.

I was refering to "layer" as in a reference model. i.e., PMTU assumes
that you can repacketize your data. For TCP, that can be done at the
transport layer, since it's byte-stream oriented. OTOH, UDP is
essentially record-based... so any "re-packetization" must be done at
the upper (app) layer.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Feb 2017 13:18:27 +1300

> scenarios in which you don't receive them).

Many people think that, but this draft is constrained by the rules in
RFC6410 about "high degree of technical maturity" and "widespread
deployment" in the move from PS to Standard. Adding new stuff is not
supposed to happen. If I recall correctly, the WG tuned the language
to its present state for that reason.

    Brian

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 3 Feb 2017 08:14:06 +0000

> to its present state for that reason.

So in that case IMO the WG has made the wrong decision by trying to take this to Standard. A rev at PS that had brought the content up-to-date with regards to Internet reality would have been the better choice.

Lars

---

From: [email-masked]
Date: Fri, 3 Feb 2017 09:38:28 +0100

Lars,

> Given that ICMP delivery cannot be assured over the vast majority of paths in the current Internet, should this document make a recommendation to implement RFC4821?

Could you please substantiate that assertion?

Best regards,
Ole

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 3 Feb 2017 10:21:47 +0000

> Could you please substantiate that assertion?

Matthew Luckie and Ben Stasiewicz. 2010. Measuring path MTU discovery behaviour. In Proceedings of the 10th ACM SIGCOMM conference on Internet measurement (IMC '10). ACM, New York, NY, USA, 102-108. DOI=http://dx.doi.org/10.1145/1879141.1879155

PDF here: https://www.caida.org/~mjl/pubs/measuring-pmtud.pdf

"This paper measures PMTUD behaviour for
50,000 popular websites and finds the failure rate in IPv4
is much less than previous studies. We measure the overall
failure rate between 5% and 18%, depending on the MTU of
the constraining link."

5-18% is pretty bad. I would expect that the widespread deployment of CGNs since this was published in 2010 to not have improved things.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 3 Feb 2017 10:22:42 +0000

> 5-18% is pretty bad. I would expect that the widespread deployment of CGNs since this was published in 2010 to not have improved things.

And yeah, this is for v4. I'm not aware of v6 measurements in this space.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 3 Feb 2017 10:28:16 +0000

On 2017-2-3, at 11:22, Eggert, Lars <[email-masked]> wrote:
> I'm not aware of v6 measurements in this space.

But Google is: http://tma.ifip.org/2016/papers/tma2016-final51.pdf

Lars

---

From: [email-masked]
Date: Fri, 3 Feb 2017 11:52:14 +0100

Lars,

> 5-18% is pretty bad. I would expect that the widespread deployment of CGNs since this was published in 2010 to not have improved things.

Emilie also did some work on this:
https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters

If you took this argument to it's extreme logical conclusion, wouldn't you then just state that the only thing that works in the Internet is TCP port 443 and UDP port 53?
I'm not sure how much sense it makes to let broken middlebox behaviour steer standardisation.
1981 is proven to work well. If a network operator has chosen to pull the plug on ICMP then there really isn't much IETF can do about that.

PLMTUD is better, and it is even better combined with PMTUD. But PLMTUD isn't deployed everywhere, nor used for UDP etc..
I don't see how that has any bearing on making 1981 an Internet standard.

I would really encourage more work on the Path MTU discovery problem though. Possibly combined with removing fragmentation from the IP layer. But that's far outside of the context of taking 1981 to Internet standard.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Feb 2017 23:00:27 -0300

> to its present state for that reason.

My apologies: my comments were probably misleading. Certainly, this
document is simply RFC1981 to Std, and hence recommending RFC4821 would
be kind of ou of scope, here.

That say, one might wonder to what extent, and for the general Internet,
RFC1981 can be considered succesful (given the filtering of ICMP
messages). -- i.e., at this point in time you wouldn't rely on RFC1981
(icmp-based pmtud) for path-mtu discovery.

Cheers,

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 4 Feb 2017 10:59:56 +0000

> (icmp-based pmtud) for path-mtu discovery.

What Fernando said: I'm certainly not opposed to lifting this to Standard, but it is painting an incorrect picture - PLPMTUD is de facto mandatory these days, and has been for years.

Lars

---

From: [email-masked]
Date: Sat, 4 Feb 2017 19:40:36 +0100

Lars,

> What Fernando said: I'm certainly not opposed to lifting this to Standard, but it is painting an incorrect picture - PLPMTUD is de facto mandatory these days, and has been for years.

While I'm all in favour of PLMTUD. It doesn't seem like a complete solution.
PMTUD on the other hand supports all protocols on top of IP.

Looking just at our specifications, we cannot state that PLMTUD can replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example.

O.

---

From: Bob Hinden <[email-masked]>
Date: Sat, 4 Feb 2017 10:50:04 -0800

Lars,

> On Feb 4, 2017, at 10:40 AM, [email-masked] wrote:
> 
> Lars,
> 

In addition to what Ole says here, I don’t think rfc1981bis is the right place to describe this.  6MAN is working on an update to IPv6 Node Requirements ( https://tools.ietf.org/html/draft-clw-rfc6434-bis-00 ).  I think is a better place to describe the relationship between PMTUD and PLMTUD, where they work and don’t, and what the current recommendations are.  I hope you will contribute to that work.

Thanks,
Bob

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Feb 2017 10:25:33 -0800

> PMTUD on the other hand supports all protocols on top of IP.
If by "supports" you mean "doesn't work", then yes. That's why we now
have PLPMTUD.

> Looking just at our specifications, we cannot state that PLMTUD can replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example.
See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2

(yes, that doc has expired while we're preparing the 04 update, which
should be issued shortly)

Joe

---

From: [email-masked]
Date: Tue, 7 Feb 2017 20:20:26 +0100

Joe,

> If by "supports" you mean "doesn't work", then yes. That's why we now

PLMTUD is unfortunately not a (complete) replacement of PMTUD.

> should be issued shortly)

Is this the paragraph you are referring to?

   PLPMTUD requires a separate,
   direct control channel from the egress to the ingress that provides
   positive feedback; the direct channel is not blocked by policy
   filters and the positive feedback ensures fail-safe operation if
   feedback messages are lost [RFC4821].

I'm very much in favour of working on better ways of doing Path MTU discovery.
A blanket statement of "use "PLMTUD" seems very premature though.

RFC1981 has 70 citations:
http://www.arkko.com/tools/allstats/citations-rfc1981.html

Could you expand on your view of how this pertains to advancing RFC1981?

Best regards,
Ole

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Feb 2017 11:42:29 -0800

> PLMTUD is unfortunately not a (complete) replacement of PMTUD.

PLMTUD is a directive to protocols above the IP layer; it isn't a single
protocol, so it wouldn't replace anything.

>    feedback messages are lost [RFC4821].
That is nowhere near section 5.5.2.

5.5.2 indicates places where RFC2473 has errors, esp. in how it
interprets the MTU of the tunnel as being defined by the MTU of the path
within the tunnel, rather than by the tunnel egress reassembly limit.

> A blanket statement of "use "PLMTUD" seems very premature though.
The point is that this document fails to indicate the current state of
PMTUD. It correctly notes that:

   An extension to Path MTU Discovery defined in this document can be
   found in [RFC4821 <https://tools.ietf.org/html/rfc4821>].  It defines a method for Packetization Layer Path
   MTU Discovery (PLPMTUD) designed for use over paths where delivery of
   ICMP messages to a host is not assured.

IMO, it fails to note that this case - where ICMP messages are assured
along a path - is effectively a unicorn except within systems maintained
by a single entity.

> Could you expand on your view of how this pertains to advancing RFC1981?
It's called last call input. My input is that this document needs to be
more realistic in noting that, for all intents, ICMP-based MTU discovery
isn't viable and that other methods need to be *expected*, not just that
they're available.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 7 Feb 2017 19:45:56 +0000

Hi Joe,

In my understanding, RFC4821 does not adequately address scenarios where the
probe packets may (for legitimate reasons) take a different path than the data
packets, e.g., when Equal-Cost Multi Path (ECMP) is present. This is not only a
consideration for tunnels, but also for path MTU sharing between transport layer
sessions where an MTU learned by a first session is shared with a second session
bound for the same destination. In that case, the probes of the first session may
take a different path than the data packets of the second session, and a black
hole is possible.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: tsv-area [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Tuesday, February 07, 2017 10:26 AM
> To: [email-masked]; Eggert, Lars <[email-masked]>
> Cc: [email-masked]; [email-masked]; 6man WG <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
> 
> 
> 
> >> What Fernando said: I'm certainly not opposed to lifting this to Standard, but it is painting an incorrect picture - PLPMTUD is de facto
> mandatory these days, and has been for years.

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Feb 2017 11:52:33 -0800

Hi, Fred,

This is a separate issue with RFC4821, though.

My point for 1981bis is that it needs to be more clear that ICMP
blocking renders this technique ineffective for the most part. I'm not
saying that PLPMTUD is perfect or the only alternative, but this doc
should be more clear about its own viability.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 7 Feb 2017 19:57:53 +0000

Hi Joe,

> From: Joe Touch [mailto:[email-masked]]
> Sent: Tuesday, February 07, 2017 11:53 AM
> To: Templin, Fred L <[email-masked]>; [email-masked]; Eggert, Lars <[email-masked]>

Agreed. Fred Baker and I were discussing about whether an erratum
should be filed.

> should be more clear about its own viability.

I could agree if suitable language could be adopted.

Thanks - Fred

---

From: [email-masked]
Date: Tue, 7 Feb 2017 21:06:51 +0100

Joe,

[...]

> PLMTUD is a directive to protocols above the IP layer; it isn't a single protocol, so it wouldn't replace anything.
> 
>> 

No, but it was unfortunately all that was written about how to use PLMTUD for tunnels.

> 5.5.2 indicates places where RFC2473 has errors, esp. in how it interprets the MTU of the tunnel as being defined by the MTU of the path within the tunnel, rather than by the tunnel egress reassembly limit.
> 
> The point is that this document fails to indicate the current state of PMTUD. It correctly notes that:
>    found in [
> RFC4821
> ].  It defines a method for Packetization Layer Path
> IMO, it fails to note that this case - where ICMP messages are assured along a path - is effectively a unicorn except within systems maintained by a single entity.
> 
> It's called last call input. My input is that this document needs to be more realistic in noting that, for all intents, ICMP-based MTU discovery isn't viable and that other methods need to be *expected*, not just that they're available.

Right, but if you are correct that ICMP-based MTU discovery is not viable then this document should not be advanced.
At the same time for many protocols we have nothing else. An operator can break any protocol if that's their policy. And that's the breakage we're talking about here, not any issues with the protocol specification.

There is a philosophical aspect of this. (Which I'm not the best person to represent as I skipped my University studies in philosophy and used the student loan to buy a motorcycle... (and only read the art of motorcycle maintenance years later) )
This is a tussle. The IETF specifies protocols under the assumption that operators treat those protocols largely as specified. The 5-10% failure of PMTUD messages may be caused by misconfiguration, misunderstanding or mis-intent... Many of our protocols are suffering from the same fate. Should the IETF adjust all its protocols to be as middlebox friendly as possible? You can make this argument about IPv6 fragments, any packet with IPv6 extension headers, IPv4 fragments. Or anything but TCP port 443/80 and UDP port 53 for that matter. Are we as the IETF going to continue standardising protocols to work as best as they possible can, ignoring protocol abuse, or are we going to bend over and do whatever it takes to make it work for those 5-10% who've actively broken the protocol? What about the 90-90% where the protocols work as expected?

Best regards,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 7 Feb 2017 20:14:39 +0000

Hi Ole and Joe,

Also not to be lost in this discussion is the potential for spoofed ICMP messages
that would report a size that is either too large or too small.

Thanks - Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, February 07, 2017 12:07 PM
> To: Joe Touch <[email-masked]>
> Cc: 6man WG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Eggert, Lars
> <[email-masked]>; [email-masked]
> > 5.5.2 indicates places where RFC2473 has errors, esp. in how it interprets the MTU of the tunnel as being defined by the MTU of the
> path within the tunnel, rather than by the tunnel egress reassembly limit.
> >
> > It's called last call input. My input is that this document needs to be more realistic in noting that, for all intents, ICMP-based MTU
> discovery isn't viable and that other methods need to be *expected*, not just that they're available.
> 
> At the same time for many protocols we have nothing else. An operator can break any protocol if that's their policy. And that's the
> breakage we're talking about here, not any issues with the protocol specification.
> 
> There is a philosophical aspect of this. (Which I'm not the best person to represent as I skipped my University studies in philosophy
> and used the student loan to buy a motorcycle... (and only read the art of motorcycle maintenance years later) )
> This is a tussle. The IETF specifies protocols under the assumption that operators treat those protocols largely as specified. The 5-10%
> failure of PMTUD messages may be caused by misconfiguration, misunderstanding or mis-intent... Many of our protocols are suffering
> from the same fate. Should the IETF adjust all its protocols to be as middlebox friendly as possible? You can make this argument about
> IPv6 fragments, any packet with IPv6 extension headers, IPv4 fragments. Or anything but TCP port 443/80 and UDP port 53 for that
> matter. Are we as the IETF going to continue standardising protocols to work as best as they possible can, ignoring protocol abuse, or
> are we going to bend over and do whatever it takes to make it work for those 5-10% who've actively broken the protocol? What about
> the 90-90% where the protocols work as expected?
> 
> Best regards,
> Ole
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Feb 2017 12:18:16 -0800

> Joe,
...
> Right, but if you are correct that ICMP-based MTU discovery is not viable then this document should not be advanced.
Not necessarily. It's fine to update a protocol that works inside an
enterprise or other controlled environment.

> At the same time for many protocols we have nothing else. An operator can break any protocol if that's their policy. And that's the breakage we're talking about here, not any issues with the protoc…

Well, it's a problem with the protocol spec that it's susceptible to
operator interference.

> This is a tussle. The IETF specifies protocols under the assumption that operators treat those protocols largely as specified. The 5-10% failure of PMTUD messages may be caused by misconfiguration,…

What I'm suggesting is a lot simpler - just text that makes it clear
what the current state of deployment of support (or interference) for
this protocol is.

I appreciate that you want to not point at PLPMTUD because it's not
widely supported, but **for the same reason** this doc should not hold
up this solution without pointing out very clearly that it basically
isn't going to be work.

Joe

---

From: [email-masked]
Date: Tue, 7 Feb 2017 21:32:33 +0100

Joe,

Thanks!

> up this solution without pointing out very clearly that it basically

Would something like this help?
(borrowed from https://en.wikipedia.org/wiki/Path_MTU_Discovery)

"Many network security devices block all ICMP messages for perceived
 security benefits, including the errors that are necessary for the proper
 operation of PMTUD. This can result in connections that complete the
 TCP three-way handshake correctly, but then hang when data is transferred.
 This state is referred to as a black hole connection."

Best regards,
Ole

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Feb 2017 13:24:23 -0800

I'd add one sentence about Fred's observation too:

In addition, spoofed ICMP messages can also affect the correct operation
of PMTUD.

That'd do it...

Joe

---

From: [email-masked]
Date: Tue, 7 Feb 2017 22:31:57 +0100

Thanks Joe.

> In addition, spoofed ICMP messages can also affect the correct operation

You don't think that's covered by the existing security considerations:

   This Path MTU Discovery mechanism makes possible two denial-of-
   service attacks, both based on a malicious party sending false Packet
   Too Big messages to a node.

   In the first attack, the false message indicates a PMTU much smaller
   than reality.  This should not entirely stop data flow, since the
   victim node should never set its PMTU estimate below the IPv6 minimum
   link MTU.  It will, however, result in suboptimal performance.

   In the second attack, the false message indicates a PMTU larger than
   reality.  If believed, this could cause temporary blockage as the
   victim sends packets that will be dropped by some router.  Within one
   round-trip time, the node would discover its mistake (receiving
   Packet Too Big messages from that router), but frequent repetition of
   this attack could cause lots of packets to be dropped.  A node,
   however, should never raise its estimate of the PMTU based on a
   Packet Too Big message, so should not be vulnerable to this attack.

Best regards,
Ole

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Feb 2017 13:35:50 -0800

IMO it's worth including a sentence that highlights these things
elsewhere in the doc.

But if others disagree, the existing text is sufficient.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Feb 2017 21:45:55 -0300

> that would report a size that is either too large or too small.

RFC5927 is all about this.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Feb 2017 21:52:32 -0300

Hi, Joe,

> But if others disagree, the existing text is sufficient.

The text is actually incorrect (see below).

>>    link MTU.  It will, however, result in suboptimal performance.

If you are employing EHs this could indeed stop the data flow.

>>    Packet Too Big message, so should not be vulnerable to this attack.

This one is probably not worth elaborating: at the end of the day, it
doesn't work.

There are many other things to note here, e.g.:
*  many stacks don't even check that the ICMPv6 PTB referes to e.g. an
ongoing TCP connection

* Some stacks cache the PMTU for all packets sent to the target IPv6
address (i.e., the attack might affect multiple flows)

etc.

Much of this is covered in RFC5927.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Feb 2017 10:07:02 -0300

On 02/07/2017 05:06 PM, [email-masked] wrote:
>> It's called last call input. My input is that this document needs
>> to be more realistic in noting that, for all intents, ICMP-based
>> MTU discovery isn't viable and that other methods need to be
>> *expected*, not just that they're available.
> 
> Right, but if you are correct that ICMP-based MTU discovery is not
> viable then this document should not be advanced. At the same time
> for many protocols we have nothing else. An operator can break any
> protocol if that's their policy. And that's the breakage we're
> talking about here, not any issues with the protocol specification.
> 
> There is a philosophical aspect of this. (Which I'm not the best
> person to represent as I skipped my University studies in philosophy
> and used the student loan to buy a motorcycle... (and only read the
> art of motorcycle maintenance years later) ) This is a tussle. The
> IETF specifies protocols under the assumption that operators treat
> those protocols largely as specified. The 5-10% failure of PMTUD
> messages may be caused by misconfiguration, misunderstanding or
> mis-intent... Many of our protocols are suffering from the same fate.
> Should the IETF adjust all its protocols to be as middlebox friendly
> as possible? You can make this argument about IPv6 fragments, any
> packet with IPv6 extension headers, IPv4 fragments. Or anything but
> TCP port 443/80 and UDP port 53 for that matter. Are we as the IETF
> going to continue standardising protocols to work as best as they
> possible can, ignoring protocol abuse, or are we going to bend over
> and do whatever it takes to make it work for those 5-10% who've
> actively broken the protocol? What about the 90-90% where the
> protocols work as expected?

There are two things to note here:

1) the folk breaking PMTUD is probably not the guy suffering from that
breakage. So the had that "bad-hevaed" nodes hurt the "well behaved"
nodes (i.e., you cannot claim "you're shooting your own foot).

2) Being an engineering group I would expect our protocols to work in
the real world -- that's the point of engineering: solving problems.  At
the end of the day, you can build stuff that works, or complain that way
too many people are doing dumb things (for some meaning of "dumb"). --
But the later will not make protocols work, nor solve problems.

In that sense, I agree with Joe, and Randy Bush here.

Thanks,

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 8 Feb 2017 16:35:58 +0000

Hi Fernando,

> From: Fernando Gont [mailto:[email-masked]]
> Sent: Tuesday, February 07, 2017 4:46 PM
> To: Templin, Fred L <[email-masked]>; [email-masked]; Joe Touch <[email-masked]>
> Cc: 6man WG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]

Right. The point is that these data points would seem to indicate that standard
PMTUD per rfc1981bis is not reliable nor secure enough for operation on open
internetworks such as the global public Internet. Maybe the security section
should say that?

Thanks - Fred

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Feb 2017 19:35:50 -0300

Hi, Fred,

> internetworks such as the global public Internet. Maybe the security section

PMTUD as per rfc1981bis is certainly not reliable, since ICMPv6 messages
are not reliable (actually, ICMP itself is obviously unreliable, but the
widespread filtering of ICMPv6 messages results in more deterministic
failures)

"security"-wise, you can improve things to a decent level. e.g., for TCP
based traffic all IPv6 implentations check the TCP sequence number (and
por numbers) in the embedded packet.

Besides, if you look at RFC5927, there a PMTUD-specific mitigation which
essentially means that during the life of a connection, upon receipt of
an ICMP PTB, you save the message, but only honor the message if there's
not progress on the connection. -- somehow mimicking RFC4821.

So I'd say that the issue with PMTUD is mostly reliability than security.

Thanks,

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 14 Feb 2017 18:23:20 +0100

I have some late transport comments on this ID. The update seems to 
retain a lot of thinking that is really historical and I'd really 
encourage people to look again to making the document uptodate.

Detailed comments follow.

Best wishes,

Gorry

----
The following text strikes me as a little odd in an update:
  " Moreover, TCP implementations that follow the "slow-
    start" congestion-avoidance algorithm [CONG] typically calculate and
    cache several other values derived from the PMTU.  It may be simpler
    to receive asynchronous notification when the PMTU changes, so that
    these variables may be updated.”
- A modern TCP caches at least some path information in the TCB, why 
start with this clause at all:
  "Moreover, TCP implementations that follow the "slow start" 
congestion-avoidance algorithm [CONG] typically calculate and”
and simply replace this with something like:
"TCP implementations”?
—---

The following text also seems to not reflect a modern TCP stack:
" It is sufficient
    to treat this as any other dropped segment, and wait until the
    retransmission timer expires to cause retransmission of the segment.”
(and following 3 paras).
Could this be replaced by text that does not exclude modern 
retransmission methods:
" It is sufficient
    to treat this in the same way as any other dropped segment, and
    will be recovered by normal retransmission methods."
—
There is a block of text that describes retransmission triggered by ICMPv6.
Has this code been implemented in modern releases of TCP?:
"   Alternatively, the retransmission could be done in immediate response
    to a notification that the Path MTU has changed, but only for the
    specific connection specified by the Packet Too Big message.”
- It seems to expose a number of attack vectors that really should not 
be exposed!!
---
The discussion of NFS may still be a reasonable historic example, but to 
be current it should really refer also to NFSv4/TCP as utlising the MTU 
discovery provided by TCP, since UDP-based NFS is no longer a key 
application.
---
There is no mention that paths including tunnels can eat ICMPv6 PTB 
messages on the tunnel segment, blackholing them, which prevents 
reaching the destination.
---
I think the security consideration is naive!

This statement in particular seems to open DOS vulnerability:
"
   When a node receives a Packet Too Big message, it MUST reduce its
    estimate of the PMTU for the relevant path, based on the value of the
    MTU field in the message."
- Introdueces a significant vulnerability.  A rogue PTB message that 
reduces the PMTU to a minimum, can result in a path too small to carry 
an encapsulated packet. (Recently noted by Fernando Gont).

Moreover, other layers view ICMP messages with suspicion and have long 
noted the need to check ICMP payload and match only packets that relate 
to actual 5-tuples in use (effectively reducing vulnerability to 
off-path attacks). For example, the Guidelines for UDP, rfc5405bis, state:

" Applications SHOULD appropriately validate the payload of ICMP
    messages to ensure these are received in response to transmitted
    traffic (i.e., a reported error condition that corresponds to a UDP
    datagram actually sent by the application). …“
- clearly handling this in IP-layer tunnels can be troublesome, but 
that's a problem that should be described, not obscured.

——

I’d finally  like to add my concerns about the understatement of the 
value of PLPMTUD, which seems to not reflect the recommendations to use 
this method:
“  It defines a method for Packetization Layer Path
    MTU Discovery (PLPMTUD) designed for use over paths where delivery of
    ICMP messages to a host is not assured.”
This  seems under-stating the value and recommendations to deploy 
PLMTUD, compared with current transport-area recommendations, for 
instance, the UDP Guidelines provide much more on this important design 
consideration:

"   Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not
    rely upon network support for ICMP messages and is therefore
    considered more robust than standard PMTUD.  It is not susceptible to
    "black holing" of ICMP message.  To operate, PLPMTUD requires changes
    to the way the transport is used, both to transmit probe packets, and
    to account for the loss or success of these probes.  This updates not
    only the PMTU algorithm, it also impacts loss recovery, congestion
    control, etc.  These updated mechanisms can be implemented within a
    connection-oriented transport (e.g., TCP, SCTP, DCCP), but are not a
    part of UDP, but this type of feedback is not typically present for
    unidirectional applications."

----

The examples used in the definition of  "upper layer" and "link" also 
makes this document appear as historic, rather than a new RFC!

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Feb 2017 13:25:03 -0800

Hi, Gorry (et al.),

> reaching the destination. 

Nor should there be, IMO.

A tunnel is a link layer to the network whose packets it transits.

ICMPs generated inside a tunnel aren't "eaten", so much as they operate
at a different layer for a different reason (e.g., to tune
ingress-egress source fragmentation of encapsulated packets).

PTB messages inside a tunnel are (IMO) most correctly interpreted by the
ingress (which is an *interface* on a router or host, most correctly
IMO) as changing the MTU of the tunnel as a link. If that MTU change
affects packets that arrive later, then it would be the router where the
ingress is attached that would generate the ICMP, never the (ingress)
interface whose MTU is insufficient.

Again, I'm in the process of updating draft-ietf-intarea-tunnels to be
much more clear on this point (the update should be issued in a day or two).

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Feb 2017 13:26:22 -0800

Hi, Gorry (et al.),

Again, the following text should not drift into discussing how tunnels
are handled IMO. That should be addressed in a different document (and I
don't think it's troublesome at all if viewed correctly).

Joe

On 2/14/2017 9:23 AM, Gorry Fairhurst wrote:
> noted the need to check ICMP payload and match only packets that
> relate to actual 5-tuples in use (effectively reducing vulnerability
> to off-path attacks). For example, the Guidelines for UDP, rfc5405bis,
> state:
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 16 Feb 2017 14:04:28 +0000

> much more clear on this point (the update should be issued in a day or two).

I really disagree Joe - not in what you say about how things need to be, 
nor the relevance of draft-ietf-intarea-tunnels.

The point of disagreement, is that I think the text needs to explain 
enough that people do NOT blindly believe this always works. the current 
text mentions tunnels in more than one place, as if they are just 
another usage of PMTUD.

Tunnels can make path MTU diiscovery unreliable, because many deployed 
tunnel ingresses do not propagate ICMPv6 PTB messages upstream to 
reflect the limits of the Tunnel MTU. draft-ietf-intarea-tunnels 
discusses how a tunnel should be implemented to effectively work with a 
Tunnel MTU.

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 16 Feb 2017 14:08:37 +0000

The text below is not about tunnels - this is about  the operation of 
transport, and the quoted text is from the new UDP Guidelines ID.

On 15/02/2017 21:26, Joe Touch wrote:
>> - Introduces a significant vulnerability.  A rogue PTB message that

The comment below could easily be handled by something that clearly 
indicates the problem and points to the tunnel draft for guidance, I 
agree no need to go into algorithms/methods here.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Feb 2017 07:59:27 -0800

Hi, Gorry,

> transport, and the quoted text is from the new UDP Guidelines ID.
Oh - I was distracted by some of the text then - see below...

>>> an encapsulated packet. (Recently noted by Fernando Gont). .

The issue is the IPv6 limit. Issues of "encapsulated packets" not
fitting in this limit are already handled by transport protocols using
IPv6 (if this is about layering encapsulation) and tunneling (if this is
about tunneling, which is how I inferred "encapsulated packets").

> agree no need to go into algorithms/methods here.

The problem isn't unique to tunnels - it happens on any link whose MTU
can vary, and IMO the solution is the same. React to the change in
subsequent traffic, rather than attempting to rely in ICMP relaying from
signaling inside the link layer -- regardless of that link layer.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 16 Feb 2017 16:47:17 +0000

> about tunneling, which is how I inferred "encapsulated packets").
The point was that according to this spec (as currently written), an 
off-path attacker can trivially inject an ICMPv6 message into the 
traffic, which then causes a host to accept a different PathMTU. 
Normally a transport design would expect ICMP messages to be at least 
checked against the list of known connections, so that successfully 
mounting this attack required the  packet to correspond to ports that 
are in use. (Usually unknown to an off-path attacker).

> signaling inside the link layer -- regardless of that link layer.
I'd be fine with recommending that way of working - but if the host 
reacts to ICMP, it is important to try to verify ICMPv6 messages before 
accepting them.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Feb 2017 09:05:39 -0800

Hi, Gorry,

> are in use. (Usually unknown to an off-path attacker).

Agreed - but IMO this has nothing to do with "encapsulation" or
tunneling, AFAICT.

> reacts to ICMP, it is important to try to verify ICMPv6 messages
> before accepting them. 

I think that's a fine punchline. The key is what "verification" means -
as you note, a transport connection might not want to react to
conflicting information and no entity (transport, OS, etc.) ought to
react to nonsensical info (attempts to push MTU below required minimums).

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 16 Feb 2017 17:13:05 +0000

I think we agreed.

Gorry

> Agreed - but IMO this has nothing to do with "encapsulation" or
Yes. This simply to do wth input processing by the PMTUD routine.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Feb 2017 10:46:52 -0800

Hi, Gorry  (et al.),

On 2/16/2017 6:04 AM, Gorry Fairhurst wrote:
> I really disagree Joe - not in what you say about how things need to
> be, nor the relevance of draft-ietf-intarea-tunnels.
>
> enough that people do NOT blindly believe this always works. the
> current text mentions tunnels in more than one place, as if they are
> just another usage of PMTUD.
>
> reflect the limits of the Tunnel MTU. 

I'll send you a preview of the updated tunnel text privately (it will be
posted in a few days). Even the last version, however, explains why
individual PTB messages should not be relayed directly upstream.

The solution is as follows: PTB messages should update the ingress's
link MTU (where the tunnel is a link and the ingress is a network
interface). Subsequent messages at a router where the ingress is
attached would already generate the correct ICMP errors when they
receive later packets that are larger than that updated MTU.

> draft-ietf-intarea-tunnels discusses how a tunnel should be
> implemented to effectively work with a Tunnel MTU.
The above is a brief summary of what it discusses.

This document doesn't need to do much on this matter at all, except NOT
provide contradictory advise or imply otherwise.

IMO, whether a tunnel works correctly or not is a tunnel issue, not an
issue for a network protocol, just as this doc shouldn't enumerate other
link layer issues, such as problems with the need for broadcast on NBMA
links, etc.

Joe