Subject: Re: [2nd] Working Group Last Call for draft-ietf-6man-mtu-option-06

From: [email-masked]
Date: Wed, 1 Sep 2021 10:30:57 +0200

I did my shepherd's/chair's review is on google docs:
https://docs.google.com/document/d/1jffQL-nWfsIkbBsCLzeyJIje1raKiHR8z7-mthHSRcw/edit?usp=sharing

Best regards,
Ole

> On 18 Aug 2021, at 09:12, [email-masked] wrote:
> 
> Signed PGP part
> Just a reminder of the WGLC for the MTU option.
> Thanks for the comments so far.
> 
> Are there anyone who would volunteer to do a very thorough review as part of the WGLC as well?
> 
> Best regards,
> Ole, co-chair 6man.
> 
> 
> This message starts a new two week 6MAN Working Group Last Call on advancing:
> 
>  Title           : IPv6 Minimum Path MTU Hop-by-Hop Option
>  Authors         : Robert M. Hinden
>                    Godred Fairhurst
>  Filename        : draft-ietf-6man-mtu-option-06.txt
>  Pages           : 19
>  Date            : 2021-08-07
> 
> https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/
> 
> as an Experimental Track document.
> 
> Substantive comments and statements of support for publishing this document should be directed to the [email-masked] mailing list. Editorial suggestions can be sent to the author.
> 
> This last call will end on 23 August 2021.
> 
> Thanks,
> Ole
> 
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Sep 2021 21:45:15 -0300

Hi, all,

I happened to read this thread, and took some time to look at the draft.
Sorry for the bad timing... but I felt it was probably better to send
this now that during IETF LC.

I took a quick look at the document, and have the following comments:

* Meta:

It is not quite clear to me if this option is expect to provide an
alternative to e.g. PMTUD or PLPMTUD, or complement it. But in any case,
I think this should be more evident early in the document, and probably
even in the abstract itself.

* Meta:

It seems this option would allow for a PMTU increase, whereas previous
PMTU mechanisms (ICMP-based PMTU) can only increase the PMTU when
specifically probing the path for PMTU increases.

* Meta:

In many parts the document talks about "the minimum Path MTU". HOwever,
this is a bit confusing. as "Path MTU" typically implies "the minimum
MTU along the path".

* Section 1:
   At each subsequent hop where the option is processed, the router
   compares the value of the Min-PMTU Field in the option and the MTU of
   its outgoing link.  If the MTU of the link is less than the Min-PMTU,
   it rewrites the value in the option data with the smaller value.

I'm probably missing something, but: if the outgoing MTU is smaller that
the MTU value in the option (possibly because the outgoing link will
reduce the PMTU), wouldn;t the packet be dropped? -- in which case, how
would the associated information be communicated?

* 1.1.  Example Operation

For the figure, I;d use symbols in all cases, are numeric MTU values in
all cases (and hence two figures).

* Section 2: "Motivation and Problem Solved"

The document essentially notes that this option could solve the issue of
Path-MTU being broken. However, IPv6 options are as broken (or more) in
the public Internet as PMTUD.

In that sense, if this option is meant for the general Internet, then
there's no indication whatsoever that this option will produce an
improvement (actually, data seems to argue quite the contrary).

And, if the option is mean for limited domains, then... if you can make
this option work, you could also make PMTUD work -- unless I;m missing
something.

* 4.  Applicability Statements

At the risk of sounding our own horn, I'm surprised this section (and
the previous one) do not reference RFC7872 and the upcoming RFC 9098,
which essentially cover the issue of IPv6 option processing.

* 5.  IPv6 Minimum Path MTU Hop-by-Hop Option

There's no checksum in IPv6. How does this affect this option? -- i.e.,
the option being corrputed and hence signaling incorrect information.

* Section 5:
     Min-PMTU: n 16-bits.  The minimum MTU recorded along the path
                 in octets, reflecting the smallest link MTU that
                 the packet experienced along the path.
                 A value less than the IPv6 minimum link
                 MTU [RFC8200] should be ignored.

s/should/SHOULD/ ?  Or actually s/should/MUST/?

* 6.2.2.1.  Including the Option in an Outgoing Packet

   *  The use of this option with DNS and DNSSEC over UDP ought to work
      for paths where the PMTU is symmetric.  The DNS server will learn
      the PMTU from the DNS query messages.  If the Rtn-PMTU value is
      smaller, then a large DNSSEC response might be dropped and the
      known problems with PMTUD will then occur.  DNS and DNSSEC over
      transport protocols that can carry the PMTU ought to work.

This probably implies that the option would be used in the public
Internet. However, RFC7872 argues that it will not work reliably.

* 8.2.  Validating use of the Option Data

Port randomization is discussed in RFC6056.

* 8.2.  Validating use of the Option Data

Generally speaking, relying *only* on port randomizayion is not
considered acceptable. For validation, it would seem to me that
validations similar to RFC5927. Or, more explicitly, one could require
that packets are "in windows" (e.g., when the upper layer protocol is
TCP). As with the considerations in RFC5927 for the ICMP-based attacks,
catching the PMTU on a per-src-dst basis might not be a good idea if the
info was generated by a transport protocol that doesn;t allow for even
basic validation.

* Section  8.2

   A network node on the path has visibility of all packets it forwards.
   By observing the network packet payload, the node might be able to
   construct a packet that might be validated by the destination host.
   Such a node would also be able to drop or limit the flow in other
   ways that could be potentially more disruptive.  Authenticating the
   packet, for example, using IPsec [RFC4301] or TLS [RFC8446] mitigates
   this attack.

How would these help protect the option?

* 10.  Implementation Status

   At the time this document was published there are two known
   implementations of the Path MTU Hop-by-Hop option.  These are:

   *  Wireshark dissector.  This is shipping in production in Wireshark
      version 3.2 [WIRESHARK].

I might be wrong, but the WIreshark disector, while useful, wouldn;t
count as an implementation of the option.

Apologies for the delay in sending feedback. I've been strucling to keep
up with IETF stuff.

Thanks,
Fernando

On 1/9/21 05:30, [email-masked] wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

--
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
“This communication is the property of EdgeUno or one of its group companies and/or affiliates. This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and if you are not the intended recipient be aware that any non-explicitly authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, and will be considered a criminal offense. Please notify [email-masked] about the unintended receipt of this electronic message and delete it.”

---

From: Bob Hinden <[email-masked]>
Date: Sat, 4 Sep 2021 09:36:19 -0700

Fernando,

> On Sep 2, 2021, at 5:45 PM, Fernando Gont <[email-masked]> wrote:
> 
> Hi, all,
> 

Thanks for the comments.

> even in the abstract itself.

This is clarified in the next version based on Ole’s review.  Overall, we believe it compliments (D)PLPMTUD.

> specifically probing the path for PMTU increases.

Correct, it does allow increases and decreases.
It is best used to suggest a suitable size to probe. This can be really helpful when looking to use a large PMTU.

> MTU along the path”.

This arises because we capitalized the "P" in "Minimum Path MTU", it's less confusing when we talk about "minimum path MTU option", but since "Path MTU", aka PMTU is something specific, it becomes odd to speak about the Minimum Path MTU as being the smallest MTU discovered by the path, not the PMTU discovered by PMTUD.

Actually, Min-PMTU has the same subtle meaning, would it better if Min-MTU was used?

> would the associated information be communicated?

That is not correct, the Min-PMTU field is not the size of a packet, it is value with the smallest supported MTU value, collected across the path.   The draft discusses not sending the option in max sized packets for the reason you note, see Section 6.2.2.1.  Including the Option in an Outgoing Packet.

> all cases (and hence two figures).

Sorry, we don’t follow this.

> this option work, you could also make PMTUD work -- unless I;m missing

We think this has a lot of promise compared to the the current ICMPv6 approach, because the information is sent in data packets, there is higher likelihood that packets sent by the end points will arrive, and as you noted, it can detect increases and decreases.   There are issue as you note with the use of IPv6 options.   That is why it is it is proposed as Experimental and for limited domains.

The Applicability Statement text that describes this is improved in the next version based on Ole’s review.

> which essentially cover the issue of IPv6 option processing.

RFC7872 described a measurement study, while we don't think that should prevent the IETF from standardizing methods, it is a useful datapoint.  We could note that RFC9098 analyzes reasons why packets with IPv6 extension headers are often dropped in the current public Internet.  What is specific about RFC 9098 that relates to this draft?

> the option being corrputed and hence signaling incorrect information.

That is pretty much true in the case where such corruption is not detected by a link of all IPv6 headers, and even IPv4’s checksum isn’t very strong for that matter.  If there are undetected errors remaining in a packet (e.g., after CRC processing for links using a CRC), the fields could be corrupted. Just as the IP address, Flow label, and other fields could have been changed. This will cause inconsistent information at the receiving host. The final effect would not disturb the flow if this resulted in a larger value and were used as input to DPLPMTUD - since the packet probe to check that the new PMTU is supported would not be used. You could speculate that a lower PMTU could cause the endpoint to react in PMTUD, which is likely the case. But still, would be so if a PTB message were somehow corrupted or misdirected. We are not sure there is anything new here.

> s/should/SHOULD/ ?  Or actually s/should/MUST/?

Thanks, we will change to a MUST.

> Internet. However, RFC7872 argues that it will not work reliably.

As noted in the draft does not need to work reliably - i.e. on all paths, it gains benefit where it does work.

> Port randomization is discussed in RFC6056.

RFC8085 describes how this can be used, we could add a reference to that RFC.

> TCP).

You of could check if the sequence numbers fall in windows and you might choose to do that PLPMTUD with TCP, we are not sure what would be best. This would be a PLPMTUD decision. For DPLPMTUD, we decided this wasn't required.  The difference here is that a probe doesn't need to carry data - if it avoids that it can NOT be used to inject data.

> As with the considerations in RFC5927 for the ICMP-based attacks,

We are not fans of PMTU without validation, and RFC8201 already notes concerns, as does RFC8899, both are referenced in this draft.

> How would these help protect the option?

Validation in this sense is a check that the packet belonged to an actual flow. Not that the values in the HBH option were not changed - that's not impossible unless the entities on path can be authenticated.

> count as an implementation of the option.

We think it does count, and is good to include in this section, as it is an implementation.

> Apologies for the delay in sending feedback. I've been strucling to keep

Always good to have another review.  Thanks!

Bob & Gorry