private ip addresses from ISP

Joe Maimon jmaimon at ttec.com
Tue May 23 15:35:43 UTC 2006




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.




More information about the NANOG mailing list