[92559] in North American Network Operators' Group
RE: New router feature - icmp error source-interface [was: icmp rpf]
daemon@ATHENA.MIT.EDU (David Temkin)
Mon Sep 25 19:32:39 2006
Date: Mon, 25 Sep 2006 16:33:18 -0700
In-Reply-To: <FE9252F8-8605-4EAC-8DCD-9F20F34A4C45@ianai.net>
From: "David Temkin" <dave@rightmedia.com>
To: <nanog@merit.edu>
Errors-To: owner-nanog@merit.edu
=20
> -----Original Message-----
> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On=20
> Behalf Of Patrick W. Gilmore
> Sent: Monday, September 25, 2006 5:31 PM
> To: nanog@merit.edu
> Cc: Patrick W. Gilmore
> Subject: Re: New router feature - icmp error source-interface=20
> [was: icmp rpf]
>=20
>=20
> On Sep 25, 2006, at 5:26 PM, Berkman, Scott wrote:
>=20
> > Might this not be a bad idea if the router has interfaces=20
> on multiple,=20
> > separate paths? Such a case may be where one customer or set of=20
> > traffic routes over a link to ISP A, and other traffic over=20
> a link to=20
> > ISP B, and not all related addresses are portable. In that=20
> case the=20
> > loopback address for the ICMP errors might show from an=20
> address that=20
> > seems to belong to a block from ISP A, but is really=20
> traffic that was=20
> > transported on ISP B.
> >
> > Just trying to come up with possible issues, not saying=20
> that's a best=20
> > practice or anything...
>=20
> I doubt it is possible to make a rule / knob / idea / feature=20
> / whatever that cannot be misused, or that is applicable to=20
> all corner cases.
>=20
> That's why it's a knob. :) If it is applicable to your=20
> situation, you should use it. If not, not.
>=20
> But if the knob has enough use in enough situations, then it=20
> is probably something we want to push the vendors to implement.
>=20
> --
> TTFN,
> patrick
>=20
>=20
> > -----Original Message-----
> > From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On =20
> > Behalf Of
> > Patrick W. Gilmore
> > Sent: Monday, September 25, 2006 9:23 AM
> > To: nanog@merit.edu
> > 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=20
> 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=20
> definition of)
> >> spoofing.
> >
> > Who thinks it would be a "good idea" to have a knob such that ICMP =20
> > 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=20
> messages from a
> > router would come from this address, regardless of the incoming or
> > outgoing interface. Things like PMTUD would still work,=20
> and your / =20
> > 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=20
> 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 =20
> > suggestion.
> >
> > (Unless, of course, I get 726384 "you are off-topic"=20
> 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. =20
http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1828/products
_configuration_guide_chapter09186a00800ca590.html#5406
-Dave
