Re: Review of draft-ietf-6man-rfc2460bis-05

[Bob Hinden <[e-mail]>]

Tim,

> On Sep 16, 2016, at 4:26 AM, Tim Chown <[e-mail]> wrote:
> 
> Hi Bob,
> 
>> On 30 Aug 2016, at 21:19, Bob Hinden <[e-mail]> wrote:
>> 
>> Tim,
>> 
>> Thanks for the detailed review.  Comments below.
> 
> And thanks for checking them. I’ve looked at the differences to -06, which is looking good, and I have only a handful of responses to your comments (I’ve deleted the rest, which are fine, for brevity).  Some points were also covered off/resolved in the meeting in Berlin.

Thanks.

> 
>>> On Jul 18, 2016, at 12:08 AM, Tim Chown <[e-mail]> wrote
>>> 
>>> p.8 in the “If, as a result…” paragraph, is the text now contradictory to RFC7045, which says "If a forwarding node discards a packet containing a standard IPv6 extension header, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header.”? The 2460-bis text implies a discard, while 7045 implies that shouldn’t happen unless as a result of configured policy?
>> 
>> A node that is required by RFC2460bis to process a header must discard it if it encounters an unrecognized next header value. RFC7045 defines additional reasons why packet might be discarded.
> 
> I’m still not so sure about this. It seems to be at odds with RFC7045, unless done by configured policy.
> 
> Paragraph 3 of section 2.1 of RFC7045 differentiates between forwarding and receiving nodes (destination hosts); perhaps the “If, as a result…” paragraph on p.8 should do the same?

RFC7045 is providing guidance for forwarding nodes that look at Extension headers.  The text in RFC2460 is about destination nodes.  Specifically earlier in this section it says:

   With one exception, extension headers are not processed by any node
   along a packet's delivery path, until the packet reaches the node (or
   each of the set of nodes, in the case of multicast) identified in the
   Destination Address field of the IPv6 header.  Note: If an
   intermediate forwarding node examines an extension header for any
   reason, it must do so in accordance with the provisions of [RFC7045].

The first sentence sets the context.

> 
>>> p.16 A note about RFC7112 would be best placed after the “The Fragmentable Part” paragraph. As it stands, the RFC7112 principle (all EHs in the first frag) isn’t mentioned until further into the document, on p.17 item (3), and even then 7112 isn’t cited.  A note about not creating overlapping fragments could also be inserted here, as per RFC5722.
>> 
>> This was a case where I incorporated the ideas of the update and kept the terminology as close as possible as the original.  There were several updates that had to be incorporated.
>> 
>> I continue to think it reads OK.  The text you mention is on the next page.  A subtle change here is that this text doesn’t allow overlapping fragments to be created, unlike the origional, as the text separates the rules for the first and subsequent fragments.  The non-overlaping text is later because it should only happen if sent by a non-conforming or malicious sender.
> 
> OK, I appreciate the text might be different if writing afresh as opposed to doing an update.
> 
> There was a general question here raised in Berlin as to whether newer RFCs like RFC7112 should cited in the main body of 2460-bis, as would be the case here for note (3) in Section 4.5, or whether the references are only made in the Appendix listing the changes. Some do, like RFC7045, but some don’t. Other examples of this that don’t are RFC6564, RFC5722, RFC6946, which are in Appendix B but not the main body.  Personally, I think for clarity for the reader, they should be in the main text.

See my response to your comments on rfc4291bis, but I think we are going to have to disagree on this one.

> 
>>> p.16 should we mention here that ND messages should not be fragmented, as per RFC6980, section 6?
>> 
>> No, RFC6980 doesn’t update RFC2460.  There is no other mention of ND in this document.
> 
> Fair point, but I’d argue that we have gathered other important advice/requirements wrt to fragmentation into 2460-bis, and a pointer here for fragmentation of ND messages could be valuable for readers. I agree it would be more appropriate in any 4861-bis that happens in the future, and it is a formal update to 4861, but it’s also the one 4861 update that is applicable to 2460 in that it has explicit advice wrt fragmentation.

This is the IPv6 specification, I don’t think it is the place to list protocols that shouldn’t use IPv6 fragmentation.  It should, as you say, go into an ND bis document, and an update to node requirements.

> 
>>> p.18 the “Fragments must not be created…” line is a duplication of the last paragraph on p.19.  Move that larger para forward?   Also perhaps note the requirement to slinky discard, as per RFC5722?
>> 
>> One is about performing fragmentation, the second is about reassembly.  It needs to say it in both places.
>> 
>> “slinky” ?  Did you mean silently?  If so, the text at the bottom of page 19 says to discard (and doesn’t say to send an ICMP).
> 
> Sorry, autocorrect at play.  Yes, I meant silently. So the bit (that was moved in -06) that says:
> 
> "If any of the fragments being reassembled overlaps with any other
>      fragments being reassembled for the same packet, reassembly of
>      that packet must be abandoned and all the fragments that have been
>      received for that packet must be discarded.”
> 
> could say "MUST be silently discarded”. (and cite RFC5722).

“Silently” is an odd word here, since the opposite is “loudly”.  We aren’t taking about making noise, the issue is should an ICMP error should be sent :-)

Instead of trying to define “silently”, I could add something like “and no ICMP error should be sent”.  This is the only case where ICMP errors are not sent.

> 
>>> p.20 is the 60 second rule commonly implemented? This seems a very high value, and could contribute to DoS effectiveness?
>> 
>> It sets an upper bound, that is “within 60 seconds”.  It does not say all fragments must be held for 60 seconds.
> 
> This was asked in Berlin; I recall Tim Winters reported that in his experience of tests run, common platforms do obey the 60 second requirement (whether or not that may be an issue for DoS in a high-speed network).

I don’t think we have any basis to change this and move to Internet Standard.  We don’t want to invalidate any implementations.  Then there is the whole issue of what to change it to.  30 seconds, 1 seconds, .1 second, etc.  I see it as an issue for how manage a fragment reassembly queue, this is more complicated than a timeout number.

This falls into the category of resource management in implementations.  I think there is lots of advice on that topic in a range of documents, and it is much broader than how long single fragments are kept around.

> 
>>> p.22 is Next Header value 59 used in practice? (Just curious… it was omitted from RFC7045).
>> 
>> I am not 100% sure, but think it is used.  But it is not something that has been updated.
> 
> I think Christian Huitema reported that it’s used by Teredo. Brian also clarified reference of it in RFC7045, so I think it’s fine as is.

Right.

Thanks,
Bob

> 
> Best wishes,
> Tim
>