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

From: Eric Rescorla <[email-masked]>
Date: Mon, 08 May 2017 06:00:37 -0700

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.

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

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.

   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?

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?

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.

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.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 9 May 2017 00:20:25 -0400

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

> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/

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.

>    the same link as itself, it might have a PMTU lower than the

Sounds good.

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

> Same thing, what are you requiring. How could I be nonconformant to

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

> However, this section contains a lot of normative language. Is that all

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

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

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 9 May 2017 06:01:30 -0700

> 4-6% for ICMPv4 PTB messages.

OK.

> need to demote this to Proposed Standard.

So, I see your point as a process point, but given that this actually
is a security condition, doesn't this suggest that the document
does not perhaps meet the "no known technical omissions" requirement
for PS, let alone the bar for IS?

> detecting PMTU decreases is mandatory. I agree that this text could be

Sorry, I'm concerned about "force to end" and "as fast as possible". For
instance, suppose that I have an implementation of IPv6 which uses
message queues to process all incoming packets, and I receive
in order an IPv6 datagram and an ICMPv6 Packet Too Big datagram
before I can process either. Am I required to have the ICMPv6 datagram
jump the queue. That would be consistent with "as fast as possible"

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

But it's full of things which sound normative. They should perhaps all be
rewritten in some way?

> received from the peer even if the PMTU is larger.

Sure, but that doesn't mean you can't exceed the PMTU.

> node does and not a normative statement.

SGTM.

-Ekr

---

From: Bob Hinden <[email-masked]>
Date: Tue, 9 May 2017 16:32:40 +0300

Ekr,

Please see Gorry’s email on the list responding to Mirja Discuss.  What he proposes seems fine with me and addresses a lot of your comments.

Thanks,
Bob

> On May 9, 2017, at 4:01 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Mon, May 8, 2017 at 9:20 PM, Suresh Krishnan <[email-masked]> wrote:
> Hi Ekr,

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 9 May 2017 07:10:32 -0700

Hi Bob,

I have read Gorry's email but I'm not sure how many of my comments it
actually addresses. Hopefully, my response to Suresh clarifies my points?
And of course, these aren't DISCUSS points so maybe you should just ignore
me :)

-Ekr

On Tue, May 9, 2017 at 6:32 AM, Bob Hinden <[email-masked]> wrote:

> Ekr,
>
> Please see Gorry’s email on the list responding to Mirja Discuss.  What he
> proposes seems fine with me and addresses a lot of your comments.
>
> Thanks,
> Bob
>
>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 9 May 2017 17:25:24 +0300

Ekr,

> On May 9, 2017, at 5:10 PM, Eric Rescorla <[email-masked]> wrote:
> 
> Hi Bob,
> 
> I have read Gorry's email but I'm not sure how many of my comments it actually addresses. Hopefully, my response to Suresh clarifies my points? And of course, these aren't DISCUSS points so maybe you should just ignore me :)

Would I ever ignore you :-)

In this case, I think we should deal with the Discusses first, then circle back and look at the comments.  Otherwise, too many moving parts.

Thanks,
Bob