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

[Fernando Gont <[e-mail]>]

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