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

[Eric Rescorla <[e-mail]>]

On Mon, May 8, 2017 at 9:20 PM, Suresh Krishnan <[e-mail]>
wrote:

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

OK.



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


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?



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


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"



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


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


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

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



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

SGTM.

-Ekr


>
> Thanks
> Suresh
>