Subject: Re: [Int-area] updated to draft-atlas-icmp-unnumbered-03

From: Naiming Shen <[email-masked]>
Date: Wed, 19 Sep 2007 09:56:24 -0700

Hi Mark,

Mark Townsley said the following on 07/25/2007 10:51 AM:
> 
> Please also give us feedback on whether or not this document should be 
> published, and on what track. I am considering the Standards Track, 
> shepherded directly by either me or Jari.

I think it should be in the Standard Track.

thansk.
- Naiming

> 
> - Mark
> 
> Alia Atlas wrote:
> 
>> I have updated the draft to reflect its goal of providing better
>> identification of the receiving interface to aid in troubleshooting
>> with traceroute.
>>
>> There are a few common scenarios that this draft is intended to help
>> with.
>>
>> First, the receiving interface may be different than the outgoing
>> interface (which gives the source IP address in the ICMP packet)
>> because of either asymmetric link costs or ECMP.
>>
>> Second, the receiving interface may be unnumbered, so that the source
>> IP address can't identify the interface.  This is a problem for
>> troubleshooting when there are parallel unnumbered links.
>>
>> I would welcome any comments or discussion on this draft.
>>
>> Thanks,
>> Alia
>>
>>
>>
>>
>> On 5/15/07, *Alia Atlas* <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     On 5/14/07, *Pekka Savola* <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         On Mon, 14 May 2007, Alia Atlas wrote:
>>         > In general, I find the specification having features that I
>>         don't see
>>         >>  necessary. Reporting ifIndex is not necessary (and the
>>         index is not
>>         >>  very useful as is to a human) if ifName is
>>         reported.  Addresses are
>>         >>  already known from the source address though somewhat less
>>         reliably so
>>         >>  those need not be reported for outgoing interface use, and
>>         could also
>>         >>  result in reporting IPv6 link-local addresses (or IPv4 
>> private
>>         >>  addresses) which wouldn't necessarily be useful or desired.
>>         >
>>         > The idea with reporting the ifIndex is to provide the easy
>>         ability
>>         > to correlate that to MIB data.  It is a common look-up key 
>> and I
>>         > believe it to be useful.
>>         >
>>         > Using simply the source address doesn't handle topologies with
>>         > parallel links between routers.  In that case, knowing the 
>> exact
>>         > outgoing link for troubleshooting is useful. ...
>>
>>         (A potentially interesting note: at least one implementation
>>         has an
>>         internal 'interface index' which is different from 'SNMP 
>> ifIndex'.
>>         The intent should be clear in the spec.)
>>
>>
>>     Do you have improved phrasing you might suggest?
>>
>>         If ifName is reported, is there significant benefit in reporting
>>         ifIndex as well?
>>
>>         It could be more easily used for correlation, but that's only
>>         useful
>>         for the operators of the network who could know the ifIndexes
>>         on the
>>         routers, not outsiders.  On the other hand, those network
>>         operators
>>         can very well map the ifName to ifIndex using SNMP or similar
>>         tools as
>>         well.
>>
>>
>>     True -  I guess some of it depends whether the name or ifIndex is
>>     more private
>>     and how many steps an operator has to take to get decent results.
>>     On the other hand, normal traceroute gives both the IP address and
>>     the DNS
>>     name, if any.  I was looking to provide the equivalent.
>>
>>         I'm not strongly against being able to report ifIndex (but I'd
>>         rather
>>         that it doesn't get reported by default, at least to
>>         everyone), but it
>>         seems like a feature that's more likely to clutter the traceroute
>>         output with little added value: ifName should already provide
>>         the same
>>         benefits and is a more generic mechanism.
>>
>>
>>     All of the additional info is optional and an operator could
>>     determine what
>>     to show based upon the incoming IP address or such.
>>
>>     Again, I was going for duplicating the information provided if an
>>     IP address existed.
>>
>>     Alia
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Int-area mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/int-area
>>   
> 
> 
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 19 Sep 2007 15:25:47 -0400

On 7/26/2007 2:12 PM, Alia Atlas said the following:
> On 7/26/07, *Shane Amante* <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Mark,
> 
>     Mark Townsley wrote:
>     >
>     I would support Standards Track.

I also support publishing this document in Standards Track.

> 
>     In addition, Alia and I have been speaking about another use case for
>     this draft.  In particular, I would like to see it extended to account
>     for identification of component-links inside ECMP and LAG's, which
>     should be a straightforward use case given what's already specified in
>     this draft.  This use case has become prevalent over the last several
>     years and will become even more so in the future.
> 
> 
> I believe that these cases can be handled by the router deciding which
> ifIndex or IP address to include.  For instance, a router might include the
> ifIndex of the member interface of a LAG.

I agree that the document is much more aligned with and structured
around solving the problem of identifying the incoming interface of an
undeliverable datagram, and that's a very useful troubleshooting tool.
It also cleaned some of the issues previously identified.

Please find a couple of comments: I think that the "Usage" section can
use some finer/stricter definition; the report of the "numberedness" of
the interface in question can also help (and is currently not directly
covered). In the bitfield definition of the C-Type, one bit can be saved
by merging together the IPv4 and IPv6 bits in a single field, since only
one is meaningful for a given ICMP. It may also help to discuss what a
NAT should do with extension fields containing addresses, if anything.
Finally, regarding ECMPs and LAGs, I think that the router behavior
should be deterministic in always including the same interface, (e.g.,
the LAG and not individual members), so that the receiving end can
interpret it a given way.

Thanks,

--Carlos.

>     -shane
>     >> On 5/15/07, *Alia Atlas* < [email-masked]
>     <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>
>     >>     On 5/14/07, *Pekka Savola* < [email-masked]
>     <mailto:[email-masked]>
>     >>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>
>     >> [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

---

From: Danny McPherson <[email-masked]>
Date: Sun, 30 Sep 2007 21:44:46 -0600

On Jul 25, 2007, at 11:51 AM, Mark Townsley wrote:

>
> Please also give us feedback on whether or not this document should  
> be published, and on what track. I am considering the Standards  
> Track, shepherded directly by either me or Jari.

I also believe Standards Track is appropriate.

I do have a couple of comments rather random comments
for the Alia and the rest of the authors.

-danny

-------
Section 4.1: Interface Role  Value 2-3 : "Undefined by this memo and
to be assigned by IANA" I think you mean "Reserved"?

Bits 4 & 5 of the Interface Information Object you say they MUST
be set to zero.  Why not SHOULD be, this will provide more flexibility
with deployment of new functions that might employ those bits?

In section 4 item "4." you say an interface name string of no more
than 31 bytes may be included.   In section 4.2 you say the interface
name Sub-Object must have a length that is a multiple of 4 bytes and
MUST NOT exceed 32 bytes.  Clarifying that a one octet "charset
type" is required, and that the entire field be aligned on 32-bit
boundaries, with trailing zero padding if necessary, would perhaps
remove any confusion.

Also, your use of "An interface name string" may introduce
confusion, you might consider rewording section 4 bullet
4. to something like this:

   4.  An Interface Name Sub-Object, a string of no more than
        31 bytes, MAY be included

"Figure 3" is the only diagram you seem to have labeled and
referenced.  Consistency with the others would be useful.

In the Security Considerations section tightening up the use
of "destination IP address" is important.  You should be very
clear about the ICMP message destination IP address versus
the triggering packets destination IP address.  Also, I think the
example should be that interface names and ifIndex values
should NOT be available outside of the local administrative
domain, while the IPv4 addresses may be.

Also, the fact that this could be used to identify egress
interfaces that may have drop by policy on ingress
(e.g., Dest Unreah, Admin Prohibit) should be strongly
considered, both from a descriptive and IP address
perspective.  I could see this information being exploit
for reconnaissance and other activities.

Providing a few tables for each object in the IANA
considerations section might make things more clear.
I'd tighten up the wording around the Interface Name
Sub-Object bits 4 & 5 as well, as mentioned above.
Same for values 2 & 3 if Interface role.

Given that this is Standards Track, perhaps something
besides FCFS for charset type allocation worthwhile?

I also have some concerns about there only being two
RSVD bits for included information, I suspect we could
very quickly exhaust that.  Any thoughts there?  I realize
we're bounded by C-Type Object subtype bit some other
encoding might be useful here?

I'm not sure why you have a reference to RFC 2328 in
the references section?

A general application of this as well may be to identify which
egress interface triggered a given function for the original
datagram.  For example, if an ACL drops the packet and
Dest Unreac/Admin Pro denies the packet, being able to
identify that might be useful.. Another example there would
be that of P MTU, to identify which egress interface can't
support a given MTU size - or to obtain a bit of intelligence
data from a given router on that front.  If you thought of
such an implementation on a firewall, for example, you
might drop and even provide corresponding policy numbers
on a trusted side, and nothing on an untrusted side, etc..

Your text here:

      Included Information: This 6-bit field [0:5] indicates what
                         information is included in the object.  The
                         information must be included in the same order
                         as the bits (from highest to lowest).

Might be better clarified by either using highest-order or
"leftmost", as opposed to "from highest to lowest".  Also,
why do you have this constraint?

Why is the interface name Sub-Object limited to 32 octets
total length?