Subject: Re: Review of draft-ietf-6man-rfc1981bis-02

From: Bob Hinden <[email-masked]>
Date: Wed, 7 Sep 2016 13:51:01 -0700

Tim,

Thanks for the review.

The changes to RFC1981 were intended to be limited to only include two things:

     Remove Note about a Packet Too Big message reporting a next-
     hop MTU that is less than the IPv6 minimum link MTU.  This
     was removed from [I-D.ietf-6man-rfc2460bis].

     Include a link to RFC4821 along with a short summary of what
     it does.

Most of your comments are on the original text and go well beyond this.  I don’t think they are in scope.

I also note that this is currently at Draft Standard, so questions about implementations have already been answered.

Comments below.

Thanks,
Bob

> On Jul 18, 2016, at 4:00 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi,
> 
> Ole asked for a review of draft-ietf-6man-rfc1981bis-02.
> 
> Overall, the document looks close to being ready. But an important open question is whether PMTUD meets all the criteria for promotion to IS, as per RFC6410, i.e. that it has "a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community” and it has "widespread deployment and successful operational experience”. The question is on the word “successful”, given the robustness issues of PTB message transmission and receipt.

I think it does meet the criteria.  There are clearly issues with ICMP on the Internet, but the mechanism defined here works fine as long as ICMP are returned.  This document describes specifies PMTUD.

> 
> Related, one general comment is the level to which PLPMTUD (RFC4821) is ‘pushed’ in this document. It is mentioned in Section 1, but then not elsewhere in the document, where Packetization Layer PMTUD issues are discussed in a few places, e.g. Section 5.1 paragraph 2 which seems to suggest not using the 4821 approach.  Some consistency might be desirable here?

It is not being “pushed” it is being noted.  The intent as noted above was to add a note about PLPMTUD, not rewrite RFC1981.

If someone want to write a new draft contrasting the two approaches and make recommendations about how PMTUD and PLPMTUD along with other techniques should be used, that would be useful.  However, I don’t think it should be in RFC1981bis.

> 
> There is a large "Implementation Issues" section (Section 5), from the node’s perspective, but not much that I can see on handling of PMTUD-related messages (PTB) by nodes on a path from the reporter to the original packet sender. There’s a little on this in the Security Considerations. Is there, for example, value in adding a reference to RFC4890 somewhere, and that failure of sites to adhere to 4890 is a reason for using the 4821 approach?

As described above, I think this is out of scope.  There was a lot of discussion on the list on how PLPMTUD should be cited, that resulted in the current text.

> Other comments:

I didn’t see any comments about the changes as noted above, they appear to be about the rest of RFC1981.

> 
> Section 1:
> 
> p.3 does the minimal implementation text belong here, or in the IPv6 Node Requirements document (which is also under revision)?
> 
> p.3 after the “Nodes not implementing…” paragraph, is it worth noting that use of 1280 MTU gives some level of robustness/predictability at the expense of reduced performance? A 1280 MTU is being used in practice in a number of scenarios/deployments. And in 2460-bis we have text that discourages fragmentation and prefers transmission of 1280 MTU non-fragmented packets (section 5, penultimate paragraph).
> 
> p.3 the note here on PLPMTUD (RFC4821) is appropriate, but as stated above, is this sentiment carried consistently through the rest of the document?  As it stands, it seems this note was parachuted in here, without other parts of 1981bis being updated to reflect the addition.
> 

> p.3 further, is use of one, either, or both approaches recommended, given the vagueness of the text about “delivery of ICMP messages not being assured” (for some value of “assured”)?  e.g. RFC4821 says it relaxes the requirements of RFC1981 and “resolves robustness problems”, but the text here doesn’t go further.  Does it need to?
> 

> Section 4:
> 
> p.6 do we have confidence that the 5 minute ‘MUST’ here is observed in common implementations?  (I don’t know, but if moving to IS we should check on existing practice?)
> 

> Section 5:
> 
> p.7 Second para in 5.1, as above, the text isn’t wholly in sync with advice on use of RFC4821?
> 
> p.7 last para of 5.1, in 2460-bis we say unnecessary fragmentation is “discouraged”.  A reference to [FRAG] is used, but is dated; there was also draft-bonica-6man-frag-deprecate-02, which expresses sentiment but was considered too “drastic" to be adopted by 6man.
> 
> p.8 if ND is mentioned here, should we cite RFC6980 on not fragmenting ND messages?
> 
> p.8 there’s mention here of RH0, which of course is deprecated; there are other valid RH types though, but this text needs updating to remove reference to RH0. It might also be worth adding a pointer here to the text in 2460-bis about not by default using the reverse path from any RH to send an ICMP message back to the sender (section 8.4 of 2460-bis)?
> 
> p.10 In 5.4, TCP layer interactions, referencing RFC7414 might be useful reinforcement.
> 
> p.10 do we have examples of the 10 minute rule on stale PMTU information being implemented, and feedback from that? (Again, I don’t know, but…)
> 
> p.11 there’s more packetization layer commentary here in the bottom half of the page; again how does this sit with RFC4821?
> 
> p.12 is it worth a Transport Area person reviewing the examples of other transport protocols given here, and adding more topical examples?
> 
> Section 6:
> 
> p.13 while a ‘malicious party’ may cause problems by stopping a ‘victim’ receiving Packet Too Big messages, failure of sites to adhere to RFC4890 is probably a more likely cause. Should this be mentioned somewhere?
> 
> p.13 is it worth adding a note about nodes on a path inserting an EH potentially causing PTB messages to go to the original source and not the ‘offender’ that made the packet too big?
> 
> Tim
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Tim Chown <[email-masked]>
Date: Fri, 16 Sep 2016 14:41:52 +0000

Hi Bob,

> On 7 Sep 2016, at 21:51, Bob Hinden <[email-masked]> wrote:
> 
> Tim,
> 
> Thanks for the review.
> 

Apologies, I’d missed the nuance of the scope.

> I also note that this is currently at Draft Standard, so questions about implementations have already been answered.

A couple of responses on these; again other items pruned for brevity.

> I think it does meet the criteria.  There are clearly issues with ICMP on the Internet, but the mechanism defined here works fine as long as ICMP are returned.  This document describes specifies PM…

I agree with you, but there are at least some that hold a different view, and of course that’s a reason we have RFC4821.

The other point that drew strong comments in Berlin (I think from Geoff Huston and Mark Andrews) was on use of a fixed 1280MTU rather than use of PMTUD, especially wrt UDP. If that’s out of scope here, a short -considered-harmful draft on that topic might be useful.

>> p.8 there’s mention here of RH0, which of course is deprecated; there are other valid RH types though, but this text needs updating to remove reference to RH0. It might also be worth adding a poin…

I appreciate the point about scope above but it seems unnecessary to leave RH0 in section 5.2 here, given it is deprecated?

Can we not remove this paragraph and Note?

"For source routed packets (i.e. packets containing an IPv6 Routing
   header [I-D.ietf-6man-rfc2460bis]), the source route may further
   qualify the local representation of a path.  In particular, a packet
   containing a type 0 Routing header in which all bits in the Strict/
   Loose Bit Map are equal to 1 contains a complete path specification.
   An implementation could use source route information in the local
   representation of a path.

      Note: Some paths may be further distinguished by different
      security classifications.  The details of such classifications are
      beyond the scope of this memo.”

>> p.13 is it worth adding a note about nodes on a path inserting an EH potentially causing PTB messages to go to the original source and not the ‘offender’ that made the packet too big?

And I’d argue that updating Security Considerations is a worthwhile thing, even for a Draft Standard document, at the very least for the second point, which has been discussed recently wrt insertion of EHs in 2460-bis.

Best wishes,
Tim

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Sep 2016 13:51:18 +0300

Tim,

> On Sep 16, 2016, at 5:41 PM, Tim Chown <[email-masked]> wrote:
> 
> Hi Bob,
> 

No problem.

> The other point that drew strong comments in Berlin (I think from Geoff Huston and Mark Andrews) was on use of a fixed 1280MTU rather than use of PMTUD, especially wrt UDP. If that’s out of scope h…

I think this is out of scope for rfc1981bis.  Especially since we would like to move it to Internet Standard.  A new document that discusses and contrasts PMTUD, PLPMTUD, and use of fixed 1280 MTU would be interesting.

> I appreciate the point about scope above but it seems unnecessary to leave RH0 in section 5.2 here, given it is deprecated?

I think that makes sense.

>      beyond the scope of this memo.”

How about leaving the first sentence since we still have Routing headers, but remove the text about RH0?

> And I’d argue that updating Security Considerations is a worthwhile thing, even for a Draft Standard document, at the very least for the second point, which has been discussed recently wrt insertio…

I am not sure either of these belong in the Security Considerations section.  Though one could consider middle boxes that drop ICMP PTB messages malicious…

Also, the attacks described in this section are based on receiving (fraudulent) ICMP PTB messages.  If ICMP PTB messages are being blocked, it does sort of eliminate this attack, depending where the attacker is located on the path.

Thanks,
Bob

---

From: Tim Chown <[email-masked]>
Date: Tue, 20 Sep 2016 11:19:02 +0000

Hi,

> On 20 Sep 2016, at 11:51, Bob Hinden <[email-masked]> wrote:
> 
> Tim,
> 

OK, hopefully Mark will be reading this and take up the baton :)

> How about leaving the first sentence since we still have Routing headers, but remove the text about RH0?

OK.

There are now other routing header types defined, e.g. I think 3 is used by RPL, and type 4 is proposed for Segment Routing use (but iirc t’s only a WG draft currently). But I think just keeping that first sentence is enough.

> I am not sure either of these belong in the Security Considerations section.  Though one could consider middle boxes that drop ICMP PTB messages malicious…

:)

> Also, the attacks described in this section are based on receiving (fraudulent) ICMP PTB messages.  If ICMP PTB messages are being blocked, it does sort of eliminate this attack, depending where th…

OK.  And on reflection perhaps best not to add anything about inserted EHs when I don’t think we have consensus on that text yet(?).

Best wishes,
Tim

hanks,

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Sep 2016 14:38:54 +0300

Tim,

> On Sep 20, 2016, at 2:19 PM, Tim Chown <[email-masked]> wrote:
> 
> Hi,
> 

Looking at the text again, I think the Note: should stay.  I think that applies to all Routing Headers.

> OK.  And on reflection perhaps best not to add anything about inserted EHs when I don’t think we have consensus on that text yet(?).

Agree.

Thanks,
Bob

---

From: Tim Chown <[email-masked]>
Date: Tue, 20 Sep 2016 11:45:19 +0000

Bob,

> On 20 Sep 2016, at 12:38, Bob Hinden <[email-masked]> wrote:
> 
> Tim,
> 

Yes, no harm in that, I agree.

Best wishes,
Tim