North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: private ip addresses from ISP
Robert Bonomi wrote: Date: Tue, 23 May 2006 11:14:53 -0400 These are the options:"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. 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. You are in favor of: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. :) 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. In this instance they would assign a single or more address nonrfc1918 to leverage this feature.Understandably, translation on providers networks is not always feasible. The proposed feature would make it configurable, perhaps on a per interface basis.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 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.
|