[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: [2nd] Working Group Last Call for draft-ietf-6man-mtu-option-06
From:       Bob Hinden <bob.hinden () gmail ! com>
Date:       2021-09-04 16:36:19
Message-ID: EEB7E72C-D9C4-476A-B002-912F98033F0F () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Fernando,

> On Sep 2, 2021, at 5:45 PM, Fernando Gont <fernando.gont@edgeuno.com> 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, otroan@employees.org 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, otroan@employees.org 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 ipv6@ietf.org 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
> > ipv6@ietf.org
> > 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 \
> legal@edgeuno.com about the unintended receipt of this electronic message and \
> delete it."


["signature.asc" (signature.asc)]

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmEzoIMACgkQrut0EXfn
u6gKQAgAmG7W+pQcQXBPY1EmPmh4U89l3TWKRsVip8dLp9zqJqf8mJpXB/3EzG7E
0ZqwYqNtK6GlvnzdIIIwZOS733oCLu9E1jejDpo7Qw6oIZwushTbnvd/nEVW0rmH
ZLJ1uAwVLoE3H9R+Vgohmnr6m6sZhQx+n+J5F1NeCsBqjTDXEVmmosYTkQsXbiao
Yb2vAcQ0U0NGm5SgGW6TceK06a5swwvhZeTk/nlbc+NGzvJ9aU9AimDKggVt7XYJ
DFCRBfq/woo1OgjDzFmrFWzUnZPbM0t2cr0R9F+hUshl0tK1dCVJA7aR8y7kufK1
PRJq0S3FnsTXoozct5oVMCKpYHzRhQ==
=uihs
-----END PGP SIGNATURE-----


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]