Skip to main content

ICMPv6 Errors for Discarding Packets Due to Processing Limits
draft-ietf-6man-icmp-limits-08

Note: This ballot was opened for revision 07 and is now closed.

Roman Danyliw
No Objection
Comment (2020-03-09 for -07) Sent
** Section 2.1.  As discussed in response to Bernard Aboba’s TSVART feedback on “The pointer will point beyond the end of the ICMPv6 packet if the field having a problem is beyond what can fit in the maximum size of an ICMPv6 error message.” please add caution about not de-referencing this pointer.  The same caution applies to Section 3.1.

** Section 5.2. Duplicate word.  s/to to/to/

** Section 6.  Per “In some circumstances, the sending of ICMP errors might conceptually be exploited for denial of service attack or as a means to covertly deduce processing capabilities of nodes”, one could conceivably conduct various active fingerprinting to determine more than just processing capabilities of nodes (say, device or OS identification) and perhaps also infer the middleboxes fielded in-path too.
Éric Vyncke
No Objection
Comment (2020-03-06 for -07) Sent
Tom,

Thank you for the work put into this document. It is short and easy to read while addressing a real problem in real deployments.

********************
*  I was about to add a DISCUSS for not using the right BCP14 RFC 8174 template but please FIX this
*       (as this is the first review, I would suggest to issue today a revised I-D with just this fix 
*       before other IESG reviews). 
*  
*  I was also about to ballot a DISCUSS on the comment in section 2.4...
*******************

Please find below some non-blocking COMMENTs and NITs. An answer will be appreciated.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1.2 --
Just wondering why the "aggregate header limits" has a section on its own. Feel free to keep it like it is but this looks weird.

-- Section 2 --
Strongly suggest to use TBA1, TBA2, ... in order to avoid mistakes done by the IANA.

-- Section 2.2 --
Why not using a new code for 'unrecognized header' by intermediate node ? I really wonder why: it can only be confusing to existing implementation.

Please also ensure what is meant by 'destination' here... I would prefer to avoid discussions when a routing-header is used (too many discussions around this in 6MAN already)

-- Section 2.4 --
How can the original source distinguish among the two potential causes ? Why not using two code points?
Or am I missing something obvious? I was really about to issue a blocking DISCUSS on this one.

-- Section 3 --
Some justifications on why using a different ICMPv6 format would really help the reader.

-- Section 4.1 --
The wording "1) Real error (existing codes)" looks weird because the code points in this documents will also be existing. Why not using "1) RFC 4443 error codes" ?

-- Section 5.2 --
Is applicable to RFC 4443 in general, so, I wonder why it is in this document.

== NITS ==

-- Section 1.1 --
If I was picky, then I would argue that "Extension Headers are placed between the IPv6 header and the Upper-Layer Header in a packet" is not always true: if Next-Header is 59 (No Next Header per RFC 8200 section 4.7) ;-)

-- Section 2.1 + 3.1--
s/IPv6 Fields:/IPv6 Header Fields:/
Suresh Krishnan Former IESG member
Yes
Yes (for -07) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (2020-03-11 for -07) Not sent
I only did a very quick scan and I have no objection. I am trusting my co-AD Barry with his review.
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2020-03-19) Sent for earlier

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2020-03-09 for -07) Sent
(1) There are a couple of normative statements that left me wanting more details.  For the cases below, I have these questions (to start with):  Are there more details on how this is done?  Are the actions implementation dependent?  Should these sentences even use rfc2119 keywords?  How can they be normatively enforced?

   - §4.2: "The packet in the ICMP data SHOULD be validated to match the upper 
   layer process or connection that generated the original packet."  What if 
   the validation fails?

   - §4.2: "A host MAY modify its usage of protocol headers in subsequent 
   packets to avoid repeated occurrences of the same error."

   - §4.2: "A host system SHOULD take appropriate action if it is creating 
   packets with extension headers on behalf of the application."  What is an 
   "appropriate action"?  


(2) §4.2: "An error SHOULD be reported to an application if the application enabled extension headers for its traffic."

What is an application in the context of this document?  I ask because traditional applications (email, video) are probably not aware of the use (or not) of extensions headers in their traffic -- but others (segment routing, for example) probably are.   


(3) §5.1: "...this specification RECOMMENDS the sending of ICMP errors even in cases where a node might be discarding packets per a nonconformant behavior."  Recommending conformance when nonconformant behavior already exists sounds a little naïve to me.  It seems to me that using a lower case "RECOMMENDS" (BTW, the actual keyword is "RECOMMENDED".) would achieve the same thing.


(4) §6: "The ICMP errors described in this document MAY be filtered by firewalls in accordance with [RFC4890]."  s/MAY/may  In this case the text is just making a statement of fact.

   
(5) Consider moving §5 closer to the beginning of the document.  Maybe it makes more sense there.
Barry Leiba Former IESG member
No Objection
No Objection (2020-03-08 for -07) Sent
The correct intended status in the header is “Proposed Standard”.

— Abstract —

   Network nodes may discard packets if they are unable to process
   protocol headers of packets due to processing constraints or limits.

May they discard packets if they are unable to process protocol headers of *other* packets?  Or are you talking about the protocol headers of the packets being discarded?  The latter, yes?  So, “if they are unable to process those packets’ protocol headers” (or “of those packets”).

   When such packets are dropped, the sender receives no indication so
   it cannot take action to address the cause of discarded packets.

This sounds like the reason it receives no indication is to prevent it from taking action. I would say, “receives no indication, thus it cannot”.

— Section 1 —

   New ICMPv6 code points are defined as an update to [RFC4443].

The document header does not say that this “updates” 4443.  Do you maybe mean “as an extension to RFC4443”?

— Section 1.1 —
RFC 8200 does not capitalize “extension header” nor “upper-layer header”; is there a reason you do in this document?  Shouldn’t this be consistent with 8200?

— Section 1.3 —
Éric already got this: Please use the new BCP 14 boilerplate and add a normative reference to RFC8174.

— Section 3.2 —

         This error is sent in response to a node dropping a packet
         because the aggregate header chain exceeds the processing
         limits of a node.

I’m confused, so maybe I just am not understanding:  this says that Destination Unreachable / headers too long is sent *not* by the note that dropped the packet, but *in response* to that node?  What an I missing?  Should this maybe say this instead?:

NEW
         This error response is sent when a node drops a packet
         because the aggregate header chain exceeds the processing
         limits of the node.
END
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2020-03-19) Sent
Thanks for addressing my Discuss and Comment points!

I suggest to additionally apply Alissa's suggestion in Section 1.1:

OLD:                                                                                
   Per [RFC8200], except for Hop by Hop options, extension headers are              
   not examined or processed by intermediate nodes.  Many intermediate              
   nodes, however, do examine extension headers for various purposes.               
                                                                                    
NEW:                                                                                
   Per [RFC8200], except for Hop by Hop options, extension headers are              
   not examined or processed by intermediate nodes.  However, in deployed           
   networks many intermediate nodes do examine extension headers for                
   various purposes.
Deborah Brungard Former IESG member
No Objection
No Objection (2020-03-11 for -07) Not sent
Agree with other comments. Similar to Alvaro, it would help to clarify "application" in section 4.2.
Magnus Westerlund Former IESG member
No Objection
No Objection (2020-03-12 for -07) Sent
One nit, at the top of page 5: s/applicably/applicability

I also urge that the document is updated prior to approval to address Bernard's TSVART review comment.
Martin Vigoureux Former IESG member
No Objection
No Objection (2020-03-12 for -07) Not sent
Hi,

thank you for this document

I'm only reporting nits I found here and there:
s/specification is provide/specification is to provide/
s/may used/may be used/
Mirja Kühlewind Former IESG member
No Objection
No Objection (2020-03-10 for -07) Sent
Question(s): 

In section 1 you say " New ICMPv6 code points are defined as an update to [RFC4443]."
Should this document actually update RFC4443?

And in section 2.2 you have:
"   [RFC8200] specifies that a destination host should send an
   "unrecognized next header type" when a Next Header value is
   unrecognized in a packet. This document extends this to allow
   intermediate nodes to send this same error for a packet that is
   discarded because the node does not recognize a Next Header type."
Does this document also update RFC8200?

Comment(s):

Editorial in Sec 5.3.1:
"      * Increasing prevalence of deep packet inspection in middleboxes.
        In particular, many intermediate nodes now parse network layer
        encapsulation protocols or transport layer protocols."
This sounds like DPI is a reason for longer headers but I think you only mean DPI is a reason for in-network processing. Maybe you can clarify this!


Also I agree with Roman's points and the TSV-ART feedback (Thanks Bernard!) that the security considerations section could be a bit more extensive and a mentioning of PMTU discovery would be good as well. I saw that there was a reply by the author to the TSV-ART review on March 5 but no updates submitted yet.