North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: New router feature - icmp error source-interface [was: icmp rpf]

  • From: David Temkin
  • Date: Mon Sep 25 19:34:14 2006

 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Patrick W. Gilmore
> Sent: Monday, September 25, 2006 5:31 PM
> To: [email protected]
> Cc: Patrick W. Gilmore
> Subject: Re: New router feature - icmp error source-interface 
> [was: icmp rpf]
> 
> 
> On Sep 25, 2006, at 5:26 PM, Berkman, Scott wrote:
> 
> > Might this not be a bad idea if the router has interfaces 
> on multiple, 
> > separate paths?  Such a case may be where one customer or set of 
> > traffic routes over a link to ISP A, and other traffic over 
> a link to 
> > ISP B, and not all related addresses are portable.  In that 
> case the 
> > loopback address for the ICMP errors might show from an 
> address that 
> > seems to belong to a block from ISP A, but is really 
> traffic that was 
> > transported on ISP B.
> >
> > 	Just trying to come up with possible issues, not saying 
> that's a best 
> > practice or anything...
> 
> I doubt it is possible to make a rule / knob / idea / feature 
> / whatever that cannot be misused, or that is applicable to 
> all corner cases.
> 
> That's why it's a knob. :)  If it is applicable to your 
> situation, you should use it.  If not, not.
> 
> But if the knob has enough use in enough situations, then it 
> is probably something we want to push the vendors to implement.
> 
> --
> TTFN,
> patrick
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On  
> > Behalf Of
> > Patrick W. Gilmore
> > Sent: Monday, September 25, 2006 9:23 AM
> > To: [email protected]
> > Cc: Patrick W. Gilmore
> > Subject: New router feature - icmp error source-interface [was: icmp
> > rpf]
> >
> >
> > On Sep 25, 2006, at 9:06 AM, Ian Mason wrote:
> >
> >> ICMP packets will, by design, originate from the incoming interface
> >> used by the packet that triggers the ICMP packet. Thus giving an
> >> interface an address is implicitly giving that interface 
> the ability
> >> to source packets with that address to potential anywhere in the
> >> Internet. If you don't legitimately announce address space then
> >> sourcing packets with addresses in that space is (one 
> definition of)
> >> spoofing.
> >
> > 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?
> >
> > For instance, you could have a "loopback99" which is in an announced
> > block, but filtered at all your borders.  Then set "ip icmp error
> > source-interface loopback99" or something.  All error 
> messages from a
> > router would come from this address, regardless of the incoming or
> > outgoing interface.  Things like PMTUD would still work, 
> and your /  
> > 30s
> > could be in private space or non-announced space or even
> > imaginary^Wv6 space. :)
> >
> > Note I said "error messages", so things like TTL Expired, Port
> > Unreachable, and Can't Fragment would come from here, but 
> things like
> > ICMP Echo Request / Reply pairs would not.  Perhaps that should be
> > considered as well, but it is not what I am suggesting here.
> >
> > Obviously there's lots of side effects, and probably unintended
> > consequences I have not considered, but I think the good might out-
> > weigh the bad.  Or not.  Which is why I'm offering it up for  
> > suggestion.
> >
> > (Unless, of course, I get 726384 "you are off-topic" 
> replies, in which
> > case I withdraw the suggestion.)
> >
> > --
> > TTFN,
> > patrick

C and J both already have a similar feature, however I'm not sure
whether or not they apply to ICMP.  They both support PBR for locally
originated packets - which, should include if the thought process is
correct, ICMP.  Perhaps someone with some time to waste can verify this
in a lab.  

http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1828/products
_configuration_guide_chapter09186a00800ca590.html#5406

-Dave