private ip addresses from ISP

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


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. :slight_smile:

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.