nanog mailing list archives
Re: New router feature - icmp error source-interface [was: icmp rpf]
From: Daniel Senie <dts () senie com>
Date: Mon, 25 Sep 2006 23:38:23 -0400
At 10:29 PM 9/25/2006, Chris L. Morrow wrote:
On Mon, 25 Sep 2006, Joseph S D Yao wrote: > > On Mon, Sep 25, 2006 at 09:22:34AM -0400, Patrick W. Gilmore wrote: > ... > > Who thinks it would be a "good idea" to have a knob such that ICMP > > error messages are always source from a certain IP address on a router? > ... > > > I've sometimes thought it would be useful when I wanted to hide a route. > But security via obscurity just makes it that much harder to fix I think in the original poster's scenario one network was looking to protect their resources/equipment from a majority of the network's ills. It's not unreasonable... atleast not in my mind. It's also not 'security through obscurity' since one of the parties is/was leaking their information OUT, just not 'in' :)
The issue is that the world has changed. Some networks actually expect not only the use of public addresses on router interfaces, but addresses from advertised blocks. Why has the world changed? Because not everyone is friendly on the Internet. There were issues raised in Mobile IP by the drafts that predated the publication of RFC 2267. Why? Well, Mobile IP WG had made the assumption that all IPv4 packet forwarding would be done, without filtering, based solely on the destination IP address. The down side was it made some of the traffic look spoofed. The world changed, people started abusing the Internet in new ways, and the old assumptions no longer held. Mobile IP WG adapted to the new reality that was coming. The longevity of the TCP/IP protocol suite is attributable to the continued effort of many people, not to savant qualities of those who first wrote specifications.
> something. Many more times than this would have been useful, I've been > able to identify at which router a problem was by a 'traceroute' that What's interesting is that today, in many networks, the usefulness of traceeroute has bee degraded by other non-ip issues (<cough>mpls</cough>) not in ALL cases, but certainly in many you are not seeing quite what you'd expect from the traceroute :(
There's no more degradation of usefulness from MPLS than there was from ATM or Frame Relay. Pick your poison for virtualized link layer, and you'll have some degree of difficulty determining and debugging the underlying network without tools to peer under the hood.
Current thread:
- RE: New router feature - icmp error source-interface [was: icmp rpf], (continued)
- RE: New router feature - icmp error source-interface [was: icmp rpf] David Temkin (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Richard A Steenbergen (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Richard A Steenbergen (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Patrick W. Gilmore (Sep 25)
- Comcast contact Anshuman Kanwar (Sep 25)
- Re: Comcast contact Peter Cohen (Sep 26)
- Re: New router feature - icmp error source-interface [was: icmp rpf] John Curran (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Richard A Steenbergen (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Joseph S D Yao (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Chris L. Morrow (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Daniel Senie (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Payam Tarverdyan Chychi (Sep 25)
- Re: icmp rpf Mark Kent (Sep 25)
- Re: icmp rpf Patrick W. Gilmore (Sep 25)
- Re: icmp rpf Patrick W. Gilmore (Sep 26)
- Re: icmp rpf Jared Mauch (Sep 26)