Carlos, More answers & discussion inline.
On 10/8/07, Carlos Pignataro <[EMAIL PROTECTED]> wrote: > > > 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
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
