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

On 10/1/2007 9:23 PM, Alia Atlas said the following

I would welcome discussion on what a NAT should do. I can see a couple possibilities and I'm sure there are more. One possibility that would expose that there are different paths would be for the NAT to replace an IP address with a "fake ifindex" or a "description" that indicates the external (address, port) or something along those lines. I.e., the NAT doesn't try to hide the multiplicity of paths behind it; I can see usage cases where this would be very helpful for trouble-shooting.

This is when the ICMP originates on the private side and traverses the NAT, correct?

Yes, I think that is the case of concern. If the ICMP originates on the public side, I don't see any work to be done.

The second option would be to remove the IP address and ifindex info and overwrite the description with something indicating the address of the NAT that did so (or the authority or something) or just remove the object.

Let me know what you'd prefer - or if we should define both for policy-based behavior - or if you see another option.

I'm not sure what a NAT should do, although it might need different behavior for the different fields (IP Address, ifIndex and Description)? one further option for the IP address is a similar to the Router-x|y source IP address treatment in Section 4.2.1 and 4.2.2 (respectively) of draft-ietf-behave-nat-icmp-05, that is depending on external/private network. draft-ietf-behave-nat-icmp-05 says:
   In addition, if the ICMP Error payload contains ICMP extensions
   ([ICMP-EXT]), the NATs are encouraged to support ICMP extension
   objects. At the time of this writing, the authors are not aware
   of any standard ICMP extension objects containing realm

   specific information.
And revision -03 explored something like that. But it could treat the IP address in the object similarly than the source IP address in those sections (they might be the same). This could be coupled, as you say, with an option (or even a default?) to remove the extension (or overwrite it with a description). The other aspect of extension-NAT interaction is the risk when the ICMP is generated from the private network sent outside, to leak "internal information". This risk may fall under the existing text:
   It may be
   desirable to provide this information to a particular network's
   operators and not to others.
Although it might help to call it out separately.

In the Security Considerations, I've just added

"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."

I don't feel that this fully addresses the concern. There should be a bit more guidance.
Perhaps we can talk about this at the upcoming IETF - and get the authors of draft-ietf-behave-nat-icmp-05 involved?

As for the LAG, this is a real problem that exists in networks today. I don't want to lose the ability to solve that problem due to a desire for determinism. An ifindex has meaning that is router-specific already; wouldn't the description provide the necessary information for a clearer interpretation?

I agree it is a real problem. My comment is that if someone sources a traceroute and receives an interface extension object, it should be clear if it is reporting a member or the LAG. Agreed, the ifIndex can be used for identification, but that would typically need an extra (offline) query step; the Description might help, if included.

I would assume, though not require, that the description be included...

Are you picturing something more sophisticated than a traceroute output? Given the desire to preserve the ability to tell the member of a LAG taken, what would you suggest? Are we onto another sub-object?

Or a new "Interface Role" / C-type. Currently, only one incoming interface object can be included, the question I think is how can the receiving end know it points to a member interface.

Sure, I'll use up another "Interface Role" - it does leave us with only 1 free, but this does seem like a useful clarification. For the name of the role would "Incoming Interface - Sub-IP Member" be a good description?

Thanks,
Alia

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

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.