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.
>
> 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 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?
> > 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
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
