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

[Bob Hinden <[e-mail]>]

Fernando,

> On Sep 2, 2021, at 5:45 PM, Fernando Gont <[e-mail]> wrote:
> 
> 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.

Thanks for the comments.

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

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

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

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.


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

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?

> 
> 
> * 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?

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.

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

Sorry, we don’t follow this.

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

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.


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

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?


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

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.


> * 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/?

Thanks, we will change to a 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.

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

> 
> * 8.2.  Validating use of the Option Data
> 
> Port randomization is discussed in RFC6056.

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


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

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


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


> 
> * 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?

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.

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

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
> up with IETF stuff.

Always good to have another review.  Thanks!

Bob & Gorry



> Thanks,
> Fernando
> 
> 
> 
> 
> On 1/9/21 05:30, [e-mail] wrote:
>> 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, [e-mail] 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 [e-mail] mailing list. Editorial suggestions can be sent to the author.
>>> 
>>> This last call will end on 23 August 2021.
>>> 
>>> Thanks,
>>> Ole
>>> 
>>> 
>>> 
>> 
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> 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 [e-mail] about the unintended receipt of this electronic message and delete it.”