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

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> 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
>
>
> > On May 9, 2017, at 4:01 PM, Eric Rescorla <[e-mail]> wrote:
> >
> >
> >
> > 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
> >
>
>