Robert Bonomi wrote:

...

Date: Tue, 23 May 2006 11:14:53 -0400

"Translating" those addresses is a *BAD*IDEA*(TM). That obscures who the reporting machine was _if_ you have to actually communicate with that network operator.

These are the options: Construct the network so that icmp is never sourced from rfc1918 OR Do either of below: Filter icmp sourced from rfc1918 on egress Dont filter icmp sourced from rfc1918 on egress Translate icmp sourced from rfc1918 on egress Use some feature that translates/replaces rfc1918 sourced icmp with nonrfc1918 identifiable internally.

This is exactly why RFC1918 says that private-addrss source packets _should_ _not_ be passed across enterprise boundaries. It does _not_ say 'must not', because there *are* situations where it is necessary. This _is_ one of them. :)

You are in favor of: Dont filter icmp sourced from rfc1918 on egress However that leads to a significant hole in "anti spoofing defense sheild" of the net. So it becomes difficult to be in favor of this and also claim that liberal application of anti-spoofing/urpf will solve most of the abuses which depend on spoofing to be effective.

...

Understandably, translation on providers networks is not always feasible.

A feature on routers that sourced icmp packets to be told specificaly which address of the router to source it from would also help.

When the router has only RFC1918 addresses (totally internal to the network), it doesn't matter/help.

In this instance they would assign a single or more address nonrfc1918 to leverage this feature.

Also, the address to use as the source _is_ well-defined. it is the interface the packet came in on that triggered the ICMP message.

The proposed feature would make it configurable, perhaps on a per interface basis. The provider would keep an internal database. It need not even be routed. It would be nice if this was completely an icmp packet field value and not dependant on the ip header to identify the icmp generator.