Re: [Gen-art] Gen-ART review of draft-atlas-icmp-unnumbered-08

[Carlos Pignataro <[e-mail]>]

David,

Thank you for your time to review, please see inline.

On 12/27/2009 5:52 PM, [e-mail] wrote:
> I have been selected as the General Area Review Team (Gen-ART) 
> reviewer for this draft (for background on Gen-ART, please see 
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call
> comments you may receive.
> 
> Document: draft-atlas-icmp-unnumbered-08
> Reviewer: David L. Black
> Review Date: December 27, 2009
> IETF LC End Date: January 1, 2010
> 
> Summary:
> This draft is on the right track, but has open issues, described
> in the review.
> 
> Comments:
> The draft defines an extension to ICMP messages that allows additional
> network interface information to be provided with some ICMP messages.
> The information may be an ifIndex, an IP address, an Interface Name
> and/or an MTU.
> 
> The one open issue in this review involves the use of ifIndex to
> identify an interface.  The motivating use cases in section 3
> involve traceroute, ACL-caused-blockage, and the need to determine the
> MTU - those use cases are "public" in the sense that they clearly
> encompass use of the ICMP messages by other than the network operator
> whose device generated those messages.

I disagree with the intrinsic '"public"' nature and the 'clearly' use
you mention; and so does the I-D, as the Security Considerations section
explicitly negates what you are saying here.

Moreover, the motivation is not (as you say) in the use cases in Section
3. The motivation is spelled out in the Introduction (ifIndex identifies
an unnumbered interface within the router). Section 3 provides exemplary
(and not all inclusive) use cases.

> 
> In this context, IP address, Interface Name and MTU are all clearly
> useful, but I am concerned about ifIndex.  An ifIndex is effectively
> private to the SNMP management infrastructure of the network operator.
> Determining what interface an ifIndex designates generally involves
> SNMP access that a network operator may be reluctant to grant to
> outsiders due to the level of detail that such access may expose.
> 
> I suspect that the ifIndex could be *very* useful to an ifIndex-
> enhanced traceroute issued from a network operator's management station
> as alluded to in paragraphs 3-5 of Section 6 (Security Considerations).
> My open issue is that I should have to go all the way down to the latter
> part of the Security Considerations section in order to find the
> motivations for and intended usage of one of the major features of this
> extension.

OK, so your open issue is that the security concern is addressed in the
Security Considerations? Existing text addresses your concern. We expect
implementors to read the complete spec, including the Security
Considerations. And folks will not implement a spec without
understanding its use.

The details: The motivation is in Section 1, Introduction:

   If all of the following conditions are true, the source address of
   the ICMPv4 message identifies the interface upon which the original
   datagram arrived:

   o  the device sends an ICMPv4 message through the same interface upon
      which the original datagram was received
   o  that interface is numbered

   However, the incoming and outgoing interfaces may be different due to
   an asymmetric return path, which can occur due to asymmetric link
   costs, parallel links or Equal Cost Multipath (ECMP).

and the concern you raise is explicitly addressed in the spec:

   It may be desirable to provide this information to a particular
   network's operators and not to others.

> 
> I suggest adding a Section 3.3 to discuss use of ifIndex with ICMP and
> network management tools (e.g., enhanced traceroute plus an SNMP
> manager)

Thank you for the suggestion.
I strongly disagree with this suggestion.

I highly suspect that doing so would be harmful to the spec, as it would
(implicitly) limit the scope of applicability and use of the extension.
We do not what to spell out potential uses in so much detail, as they
would become obsolete before the spec is. And we do not want to pretend
we cover all use cases.

> by a network operator to debug his/her own network.  This new section
> should also contain some sort of warning that ifIndex information may
> not be available to other than the network operator's management
> applications (with a pointer to the Security Considerations section).

This is understood from the definition (and _Normative_ citation
pointer) of ifIndex in the spec. It would be, IMHO, redundant and
therefore be another distraction to the reader.

> 
> Nits:
> - Section 2: "o  that interface is numbered"  Please add a definition
> 	of "numbered" for an interface.

We could add a pointer to [RFC1812], although I really do not think it
is needed. There is ample precedence that this is not needed, e.g., OSPF
RFCs like RFC2328, RFC5185, etc, etc.

> - Section 4.1: Explain what a C-Type is.  A few words and a reference
> 	to Section 8 of RFC 4884 should suffice.

Again we could add it but... RFC4884 is a _normative reference_, meaning
that (from RFC3967]:

   normative reference specifies a document that must be read to fully
   understand or implement the subject matter in the new RFC, or whose
   ...

Therefore, not needed, as it is defined in the Normative reference.
Another data point, IANA understood waht was meant.

> - Section 5.4: This appears to be poorly stated:

There is no Section 5.4 in the document... I suspect you meant Section 4.5.

>    A single instance of IP Address information MAY be included only in
>    the following circumstances:
> 
>    Included in what? 

It is, I think, self-evident when read in context (including previous
sentence):

   more than one instance of each of these three information
   elements MUST NOT be included per Interface Information Object.

   A single instance of IP Address information MAY be included only in
   the following circumstances:

We can s/be included/be included in an Interface Information Object/ at
expense of being repetitive.

> I presume an Interface Information Object.  Also,
>    MAY ... only is poor usage of RFC 2119 terminology.

Why? We are saying that the item (an IP Address information element) is
truly optional, and the definition of MAY says:

   5. MAY This word, or the adjective "OPTIONAL", mean that an item is
      truly optional...

So how is the usage poor?

>  Here's an
> attempt
>    at better phrasing:  
> 
>    When an Interface Information Object contains an IP Address, one of
>    the following two conditions MUST be true:
> 

Thank you for the suggestion, we will consider it as a nit.

> idnits 2.11.15 did not find any nits.

Ack.

Again, thank you for the time and review !

-- Carlos.

> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
>