Jari, Alia, Please find some comments and my 2ยข inline.
On 9/9/2008 8:11 PM, [EMAIL PROTECTED] said the following: > Jari, > >> -----Original Message----- >> From: Jari Arkko [mailto:[EMAIL PROTECTED] >> Sent: Saturday, September 06, 2008 5:52 AM >> To: Internet Area; >> [EMAIL PROTECTED]; >> [EMAIL PROTECTED] >> Subject: comments on draft-atlas-icmp-unnumbered >> >> Overall, this draft specifies a useful function and I believe >> it should move forward. +1 ! >> >> There are a number of details that need a bit of adjustment >> before the draft is ready, however. Please see details >> further down in this e-mail. >> >> There is one big question as well. There has been some >> discussion about the usefulness of next hop information and >> whether draft-watkins-icmptype11code0 should also move >> forward, or if the drafts should merge. Having read the two I think that in general, NH information is extremely useful even with a number of limitations (I'll reply to Naiming's posting regarding this). But I don't think that draft-watkins-icmptype11code0 should be merged. The main reason is that draft-atlas-icmp-unnumbered already supports providing next-hop information in a more generic way. It may need to add some clarifying text exemplifying how/when it may/should_not be used (as an applicability of the next-hop info), but encoding and support is there: Specifically, this extension contains the Interface-Role field that can take values for either incoming or outgoing interface (and outgoing may need to have more descriptions in presence of ECMPs, etc). I remember discussing it with Alia, along with outgoing mtu topics. The text says this already: Using the extension defined herein, an IP device can explicitly identify by the above the outgoing interface and next-hop over which a datagram would have been forwarded if that datagram had been deliverable. This can be used for creating a downstream map. And it says in the "Usage": In an ICMP message, more than one Interface Information Object with a given interface role MUST NOT be included. Multiple Interface Information Objects, each with a different interface role, MAY be included. This was included to allow for both incoming and outgoing information in the same message (i.e., which can be exemplified to saying that an ICMP response can include two extension objects): one for the incoming information and one for the outgoing information. Each of these two, in turn, can describe the respective interface by either (or a combo of) ifIndex, IP address, description. The definition in draft-atlas-icmp-unnumbered allows support for nh info for both IPv4 and IPv6. Additionally, the other generalization is that draft-watkins-icmptype11code0 seems to apply to timexceeded only, and not e.g., unreachables (and it's important in `traceroute -M`, etc). >> drafts together now, my opinion is that adding a flag and 2nd >> IP address for the next hop for an outgoing interface object >> seems like a good approach. This would allow reporting an >> outgoing interface AND its next hop information (where available). > > As you say, it is not difficult to add the next-hop information. > As I recall, we did discuss doing this. > The concern is that it adds substantially to the implementation > complexity to support this feature. Basically, that requires knowledge > of dynamic information beyond the local system and may not be easily > available. > Others may be able to comment more extensively on their concerns. > > Given that the outgoing interface's information is available, this is > an issue for non-point-to-point interface types. > > If we were to include the next-hop information, do we only care about > numbered next-hops (i.e., ignoring unnumbered point-to-point > interfaces)? > What if the next-hop information is not of the same IP version as the > packet? > Do we just not include it? > > As I said, the concern was with implementation complexity from the added > information and not, obviously, the details of encoding it in this > draft. If there is sufficient consensus to have this ability, then it > could be added. > >> Another interesting issue is treatment by NATs. Given that >> the information is primarily for debugging and that any >> modification or removal of this information by a NAT could >> interfere with that, my suggestion is that NAT devices SHOULD >> merely pass this extension along. > > The concern I've heard expressed is that this would interfere with the > hiding of the IP addresses inside the NATed region. > > The only way to resolve both concerns seems to be for the NAT to > allocate > a unique "ifIndex" for the interface info being hidden and report that? > > Is it better for a SHOULD to argue for less security in favor of > troubleshooting > or leave it up to the designer/customer as to which trade-off is > preferable. > >> Technical: >> >>> Extending ICMP to Identify the Receiving Interface Abstract >>> >>> This memo defines ICMP extensions, using ICMP multi-part messages, >>> through which a router or host can explicitly identify the >> interface >>> upon which an undeliverable datagram anrrived. >>> >>> ... >>> >>> Using the extension defined herein, an IP device can explicitly >>> identify the incoming interface by any or all of the following: >>> >>> o IPv4 address >>> o IPv6 address >>> o name >>> o ifIndex >>> >>> Using the extension defined herein, an IP device can explicitly >>> identify by the above the outgoing interface and next-hop >> over which a >>> datagram would have been forwarded if that datagram had been >>> deliverable. >>> >>> ... >>> >>> 3.2. Policy and MTU Detection >>> >>> A general application would be to identify which outgoing interface >>> triggered a given function for the original packet. >>> ... >>> 0 : This object describes the incoming interface. >>> 1 : This object describes the outgoing interface. >>> >> First, the title is misleading, and the abstract does not >> mention the ability to identify outgoing interfaces. Second, >> how does the identification of the outgoing interface follow >> from the identification of the incoming interface, given >> things like ECMP? > > Yes, the abstract and title need to be updated to reflect the > possibility > of outgoing interface information. > > Given things like ECMP, the device needs to do the ECMP algorithm based > upon > the packet and report where the packet would have gone. This requires > the > ability to either (ideally) get that information from the forwarding > path or > else to compute what the forwarding path would have decided. It is an > important > ability. > >> Since the draft does, after all, support identifying outgoing >> interfaces as well that fact should be better reflected in >> title, abstract, etc. >> >>> 3 : When set, this bit indicates the ifIndex of the interface is >>> included. When clear, the ifIndex is not included. >> Encoded how? How many bytes? > >>From Sec 4, " The ifIndex of the interface of interest MAY be included. > This > is the ifIndex assigned to the interface by the router in as > specified by the Interfaces Group MIB [RFC2863]." > I can specify it more clearly as being 4 octets written in big endian > order. > The MIB specifies it as an Integer32. > > >>> Another issue is when a device inside a private region generates an >>> ICMP message with some of these extensions and that ICMP >> message will >>> transit a NAT to reach its destination. A NAT may choose >> to remove or >>> overwrite the extensions. >> First, please clarify whether leaving the extension alone is >> also legal. >> This is obviously what a legacy NAT would do, of course, so I >> don't feel good about outlawing it. > > Yes, leaving the extension alone is legal. > >> Second, I think we need a stronger recommendation on what the >> NATs should do about this, so that the NAT vendors can do the >> right thing. >> However, its not entirely clear to me what the right thing >> is. In particular, even if this extension passes a NAT the >> optional addresses included in it may or may not still be >> valid on the other side of the NAT. And this has nothing to >> do with the type of the addresses (private or public), it has >> to do with the topology of the network -- and this may not be >> something that the NAT device understands. >> >> One approach would be to say that this information is for >> debugging only, and therefore SHOULD be left alone. Thoughts? > > The only concern with this is the desire to hide the addresses > entirely inside the NAT. It should be only for debugging, but > we don't want to introduce a new security concern. > > Carlos had some useful insights here; perhaps he will have time > to comment? In the presence of NATs, I think that the behavior can go from removing the extension (to avoid leaking info), re-writing it, to leave it alone (prioritizing troubleshooting). But the behavior could potentially be different for address versus non-address information. Specifically regarding the addresses, IMHO the case is conceptually similar to the NAT treatment of source IP addresses in ICMPs, and I think that the NAT should be asked to do the same that for router source addresses in draft-ietf-behave-nat-icmp. That is, request the NAT to treat the IP in the extension as it treats the "Router-x" address when "ICMP Error Packet Received from External Realm", and to treat the IP address in the extension as "Router-y" address in "ICMP Error Packet Received from Private Realm". I just found some text (on the possibilities, mostly without taking sides on the normativeness) that I'd sent to Alia on this, which might be totally outdated, but perhaps can serve as a starting point: <nat> 5. Network Address Translation Considerations [NAT-ICMP] encourages Traditional IP Network Address Translators (Traditional NATs, see [RFC3022]) to support ICMP extension objects. This document defines ICMP extensions that include IP addresses and therefore contain realm specific information, and consequently describes possible NAT behaviors in presence of these extensions. In the most general case, a NAT device may choose to remove or overwrite these extensions (see [Section Security]). The action may be different for the different fields: The ifIndex can either be transparently passed or removed, the Description can be transparently passed, removed or re-written (adding some text to the effect that a NAT was crossed and the description was removed, as a matter of policy or other), and IP addresses can either be removed or translated. When translating IP address-related fields of the extension defined in this document, the behavior should be equivalent to that of the treatment of Router-x and Router-y source IP address in Sections 4.2.1 and 4.2.2 of [NAT-ICMP] (respectively). That is: o For ICMP Error Packets received from an External Realm: IP Addresses included in this extension remain unchanged because they correspond to the external domain (e.g., correspond to a router that generated the ICMP in the external realm). o For ICMP Error Packets received from a Private Realm: This extension includes an IP address corresponding to the Private realm, let's refer to it as IP-Private, and its translation depends on whether Basic NAT or NAPT function ([RFC3022]) is enforced by the NAT: - Basic NAT: If the NAT has an active mapping for IP-Private, the NAT translate it within the extension with the IP-Public in said mapping. If not, the NAT translates the IP-Private address using its own IP address on the external domain. - NAPT: the NAT translates the IP-Private address in the extension to its own IP address on the external domain. Additional Informational References: [NAT-ICMP] draft-ietf-behave-nat-icmp [RFC3022] RFC3022 </nat> Unless it's desired to always let this extension through unchanged, this allows for troubleshooting while not leaking private-realm addresses outside. The Security Considerations section mentions possibilities, taking the extension as a monolith (not describing sub-TLV-specific behaviors): Another issue is when a device inside a private region generates an ICMP message with some of these extensions and that ICMP message will transit a NAT to reach its destination. A NAT may choose to remove or overwrite the extensions. One additional comment: The Security Considerations section mentions potential policy controls on reply to which sources to add the extension to. I wonder if it should point to draft-shen-udp-traceroute-ext to allow for a more dynamic or granular enforcement of this. Thanks, --Carlos. > >>> Interface Name Sub-Object >> Shouldn't there be some discussion about truncation in case >> the real name does not fit this object? > > True; truncation would give just the first 62 octets of the ifName. > I can specify this clearly. > >> Editorial: >> >>> upon which an undeliverable datagram anrrived. The incoming >> Typo > > will fix > >>> Bit 7 6 | 5 4 3 2 1 0 >>> >> +-------+-------+-------+-------+-------+-------+-------+-------+ >>> | Interface Role| Rsvd | Rsvd | index | IP | >> Rsvd | descr | >>> >>> +-------+-------+-------+-------+-------+-------+-------+-------+ >>> >> For what it is worth, I found this figure illustrative, but >> the text that accompanied it was confusing. For one thing, >> the text discusses two fields "Interface Role" and "Included >> Information" which are not shown here. For another, the bits >> are later referred to by their numbers, not names. I would >> suggest sticking to the names in the figure and removing the >> concept of the "Included Information" field. >> >>> The information/sub-objects MUST be sent and received inside the >>> Interface Information Object in the order that they are >> listed in the >>> final 6-bits included-information field. >> Just say: >> >> "The ifIndex, address, and name follow the C-type octet, in >> this order, if present." >> >> or something to that effect. Avoid referring to the confusing >> included-information field. Also, the ifIndex and address >> were by my understanding not proper objects, it was just >> bytes following the C field. > > This is true as far as it goes - but if the additional reserved flags > are > allocated, I'd expect them to follow the same restriction. That is > captured > in the existing language and not in your suggested text. > > The ifIndex and address are just bytes as you say and not sub-objects. > That's > why I specified information/sub-objects. > >>> 4.3. Interface Information Object Description >> Wouldn't this be better as "Examples"? > > Yes > >>> Figure 4 depicts the Interface Information Object, with two of the >>> valid permutations. >> Three, but who's counting :-) > > laziness in editing strikes again... > >>> o Bit 3: ifIndex include >> included > > will fix > > Thanks for the review, > Alia > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
