Re: Eric Rescorla's No Objection on draft-ietf-6man-rfc1981bis-06: (with COMMENT)

[Suresh Krishnan <[e-mail]>]

Hi Ekr,
  Thanks for your comments. Please find responses inline.

On Mon, May 8, 2017 at 9:00 AM, Eric Rescorla <[e-mail]> wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-6man-rfc1981bis-06: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Document: draft-ietf-6man-rfc1981bis-06.txt
>
> OVERALL
> I see in the shepherd's writeup that you have opted not to cite RFC
> 2119, but that makes the mixed case use of SHOULD/MUST even more
> confusing. I would suggest that at minimum you go through the document
> and evaluate whether each should/must should be capitalized, though I
> would prefer a cite to 2119.
>
> For instance:
>    changed.  Therefore, attempts to detect increases in a path's PMTU
>    should be done infrequently.
>
> Is this normative?
>
>
> I also share the concerns others have raised about whether, given the
> actual state of PMTU this is something we should be making IS, but
> I'm willing to bow to the majority here.

This was certainly one of the things I considered. There is not too
much measurement to back the claims that PMTUD is completely broken.
The only reasonably sized study that I know of

http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf

shows about ~1% packet loss in ICMPv6 PTB messages compared to about
4-6% for ICMPv4 PTB messages.

>
>
> S 3.
>    Note that Path MTU Discovery must be performed even in cases where a
>    node "thinks" a destination is attached to the same link as itself.
>
> I think you need to qualify this must because you just said above that
> you don't need to if you use the minimum. Perhaps:
>
>    Note that even when a node "thinks" a destination is attached to
>    the same link as itself, it might have a PMTU lower than the
>    link MTU...

Sounds good.

>
>
> S 4.
>
>    Nodes SHOULD appropriately validate the payload of ICMPv6 PTB
>    messages to ensure these are received in response to transmitted
>    traffic (i.e., a reported error condition that corresponds to an
> IPv6
>    packet actually sent by the application) per [ICMPv6].
>
> This seems like it ought to be a MUST. Is there a good reason why
> it is not? Perhaps also a cite to how one validates.

This is directly derived from Section 5.2 of RFC4443.

"It is recommended that the upper layers perform some form of
validation of ICMP messages (using the information contained in the
payload of the ICMP message) before acting upon them."

This was precisely the text that made me worried that this is adding a
new requirement. As long as we stick to the requirement level of
ICMPv6, we are OK. If we want to change this to a MUST, I think we
need to demote this to Proposed Standard.

>
>
>    When a node receives a Packet Too Big message, it MUST reduce its
>
> a valid Packet Too Big message, I think because in graf 2 you say you
> should validate.
>
>
>    elicit Packet Too Big messages.  Since each of these messages (and
>    the dropped packets they respond to) consume network resources, the
>    node MUST force the Path MTU Discovery process to end.
>
> It's not clear to me what the requirement is.
>
>    Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast
>    as possible.  Nodes MAY detect increases in PMTU, but because doing
>
> Same thing, what are you requiring. How could I be nonconformant to
> this?

I see this as stating that detecting PMTU increases is optional and
detecting PMTU decreases is mandatory. I agree that this text could be
clarified

>
> S 5.
>    This section discusses a number of issues related to the
>    implementation of Path MTU Discovery.  This is not a specification,
>    but rather a set of notes provided as an aid for implementers.
>
> However, this section contains a lot of normative language. Is that all
> non-normative?

Yes. That is the intention (no normative text here).

>
>
> S 5.3.
>    If the stale PMTU value is too large, this will be discovered almost
>    immediately once a large enough packet is sent on the path.  No such
>    mechanism exists for realizing that a stale PMTU value is too small,
>    so an implementation SHOULD "age" cached values.  When a PMTU value
>    has not been decreased for a while (on the order of 10 minutes), the
>    PMTU estimate should be set to the MTU of the first-hop link, and
> the
>    packetization layers should be notified of the change.  This will
>    cause the complete Path MTU Discovery process to take place again.
>
> Is this really good advice for TCP? It seems like if you have a
> situation where it required several attempts to get the true PMTU (for
> instance, if you have successively narrower tunnels), then a PMTU
> reset could have a pretty material impact on throughput.

There is some TCP related implementation advice in Section 5.4.
Basically, a TCP implementation will not send a packet larger than MSS
received from the peer even if the PMTU is larger.

>
>
> S 6.
>       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.
>
> I get that this is now not a normative statement but rather a claim
> about what nodes who follow the MUST NOT in S 4, but it might still
> be better to make it a MUST to avoid confusion.

How about s/should/will/? That leaves it as a statement of what the
node does and not a normative statement.

Thanks
Suresh