icmp rpf

virendra rode wrote:
>> This is yet another reason one shouldn't rely on
pings & traceroutes to
>> perform reachability analysis.

So, you're in the "traceroute is not important"
camp?
(you'll note that in my email I did ask whether we think 
traceroute is important)

Mark Smith wrote:
>> The non-announcers, because they're also breaking
PMTUD.

Really?   How?   Remember, we're not talking about RFC1918
space,
where there is a BCP that says we should filter it at the
edge.
We're talking about public IP space, that just doesn't
happen to be
announced outside of a particular AS.

Thanks,
-mark

On Sep 24, 2006, at 4:33 PM, Mark Kent wrote:

> Remember, we're not talking about RFC1918 space,
> where there is a BCP that says we should filter it at
the edge.
> We're talking about public IP space, that just
doesn't happen to be
> announced outside of a particular AS.

If the intent is to prevent folks from reaching out and
touching  
random network infrastructure devices directly whilst still
allowing  
traceroute to work, iACLs and/or using IS-IS as one's IGP
and null- 
routing the infrastructure blocks at one's various edges
achieves the  
same effect with less potential for breakage:

http://ww
w.nanog.org/mtg-0405/mcdowell.html

Note that a good infrastructure addressing plan is a
prerequisite for  
both of these methods.

------------------------------------------------------------
-----------
Roland Dobbins <rdobbinscisco.com> //
408.527.6376 voice

Any information security mechanism, process, or procedure
which can
be consistently defeated by the successful application of a
single
class of attacks must be considered fatally flawed.

     -- The Lucy Van Pelt Principle of Secure Systems Design

Hi Mark,

On Sun, 24 Sep 2006 16:33:30 -0700 (PDT)
Mark Kent <marknoc.mainstreet.net> wrote:

> Mark Smith wrote:
> >> The non-announcers, because they're also
breaking PMTUD.
> 
> Really?   How?   Remember, we're not talking about
RFC1918 space,
> where there is a BCP that says we should filter it at
the edge.
> We're talking about public IP space, that just
doesn't happen to be
> announced outside of a particular AS.
> 

When a router that can't shove a DF'd packet down a link
because the
MTU is too small needs to create a ICMP Destination
Unreachable, Packet
Too Big, Fragmentation Required, it needs to pick a source
IP address
to use for that ICMP packet, which will be one of those
assigned to the
router with the MTU problem (I'm fairly sure it's the IP
address assigned to the outgoing interface for this ICMP
packet,
although I don't think it probably matters much). If an
upstream
router, i.e. on the way back to the sender who needs to
resend with a
smaller packet, is dropping these packets because they fail
RPF, then
PMTUD breaks. The result might be connection timeouts at the
sender, or
possibly after quite a while the sender might try smaller
packets and
eventually they'll get through (I think Windows might do
this). Either
way, bad end-user experience.

PMTUD as it currently works isn't ideal, as of course there
isn't any
guarantee that these ICMP Dest Unreachables will get there
even in a
"good" network. However, most of the time it
works, where as in the
scenario you're presenting, it definately won't.

Regards,
Mark.

-- 

        "Sheep are slow and tasty, and therefore must
remain constantly
         alert."
                                   - Bruce Schneier,
"Beyond Fear"

In response to this:
> Mark Smith wrote:
> >> The non-announcers, because they're also
breaking PMTUD.
> 
> Really?   How? 

Mark Smith replied with two paragraphs, but it's not 100%
clear to me
that he got the reason why I asked.   I asked because his
initial statement
boiled down to "numbering on un-announced space breaks
PMTUD"...
but it doesn't, not by itself (which he later expanded).

It only does so in the presence of filtering.

I think this is an important point to make because of my
interaction
with small.net.  When I pointed out the timeouts they said
that it was
because they don't announce the router IP addresses, which
is true but
not the whole story.  I mentioned that some providers in the
past
numbered on rfc1918 space and traceroute still worked, so
that alone
was not enough.

Then they said "it's because of the asymmetric
path," and that also is
true, but again not enough.  A large proportion of traffic
is
asymmetric, but traceroute still works.

Then they gave me an explanation that rested on the fact
that the
routers will not respond to pings because they are
unannounced outside
of their world.  That too is true, but irrelevant and I told
them how
Jacobson's traceroute works and told them that *someone*
was
dropping/filtering the return packets and I'ld like to know
who/why.

They somewhat implied that it was my fault, and this
situation was
unique to my net, so I used the big.net looking glass to
show how the
same things happens from space not associated with my
network.
(Yes, I should have done this from the outset.)

With that they asked big.net, and big.net said they
filtered, 
and that's where we are.  

My point here is that it took me ten (10) emails with
small.net to get
this information partly because the small.net support staff
had notions
in their head premised on too simplistic statements like
"numbering on
un-announced space breaks PMTUD."  

I wanted to clear this up because this list is likely read
by support
people at various networks, and it's pretty clear that not
all of them
are well versed even on something as thoroughly discussed
over the ages
as traceroute.

Thanks,
-mark

Once upon a time, Mark Kent <marknoc.mainstreet.net>
said:
> I think this is an important point to make because of
my interaction
> with small.net.  When I pointed out the timeouts they
said that it was
> because they don't announce the router IP addresses,
which is true but
> not the whole story.  I mentioned that some providers
in the past
> numbered on rfc1918 space and traceroute still worked,
so that alone
> was not enough.

Not announcing their router interface IP space is not any
type of
security.  Anyone directly connected to them (customer or
peer) could if
they wish statically route that IP space, and any such
security would be
gone.  Unless it is otherwise filtered, any customer with a
default
route can reach their routers.
-- 
Chris Adams <cmadamshiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough
trouble.

On Mon, 25 Sep 2006, Chris Adams wrote:

> Once upon a time, Mark Kent <marknoc.mainstreet.net> said:
>> I think this is an important point to make because
of my interaction
>> with small.net.  When I pointed out the timeouts
they said that it was
>> because they don't announce the router IP
addresses, which is true but
>> not the whole story.  I mentioned that some
providers in the past
>> numbered on rfc1918 space and traceroute still
worked, so that alone
>> was not enough.
>
> Not announcing their router interface IP space is not
any type of
> security.  Anyone directly connected to them (customer
or peer) could if
> they wish statically route that IP space, and any such
security would be
> gone.  Unless it is otherwise filtered, any customer
with a default
> route can reach their routers.

Nevertheless putting router interface ip address for your
network
in one specific block is very effective as way to quickly
get rid
of DoS attack on the router - you simply stop announcing
that 
block but everything else on the network still works. And
doing
tricks like having primary ip address which not important at
all
(except for logging traffic actually destined to it) while
secondary
ip on the same interface is really the one used for
inter-connection
also works quite well.

-- 
William Leibzon
Elan Networks
williamelan.net

On Monday, 2006-09-25 at 10:09 MST, Mark Kent <marknoc.mainstreet.net> 
wrote:
> Mark Smith replied with two paragraphs, but it's not
100% clear to me
> that he got the reason why I asked.   I asked because
his initial 
statement
> boiled down to "numbering on un-announced space
breaks PMTUD"...
> but it doesn't, not by itself (which he later
expanded).
> 
> It only does so in the presence of filtering.

Which is exactly what one might expect to happen.  At least
it seems to me 
that RFC 3704 (BCP 84, http://www.ietf.o
rg/rfc/rfc3704.txt) applies.

When your traffic is sourced with dubious addresses, you
should expect 
much of it to disappear.  And when this happens, you're
hurting your 
customers and your customers' customers (okay, sometimes
it's "just" your 
peer's customers - still a concern in my opinion).

--
Tony Rall

On Tue, Sep 26, 2006 at 12:17:27AM -0700, Tony Rall wrote:
> 
> On Monday, 2006-09-25 at 10:09 MST, Mark Kent
<marknoc.mainstreet.net> 
> wrote:
> > Mark Smith replied with two paragraphs, but it's
not 100% clear to me
> > that he got the reason why I asked.   I asked
because his initial 
> statement
> > boiled down to "numbering on un-announced
space breaks PMTUD"...
> > but it doesn't, not by itself (which he later
expanded).
> > 
> > It only does so in the presence of filtering.
> 
> Which is exactly what one might expect to happen.  At
least it seems to me 
> that RFC 3704 (BCP 84, http://www.ietf.o
rg/rfc/rfc3704.txt) applies.
> 
> When your traffic is sourced with dubious addresses,
you should expect 
> much of it to disappear.  And when this happens, you're
hurting your 
> customers and your customers' customers (okay,
sometimes it's "just" your 
> peer's customers - still a concern in my opinion).

	I think this is the critical point, dubious ip sources have
been
used/abused in the past and those at "big.net"
that have done something
to mitigate the risk to the world from their customers and
their customers
from the world are doing a "community service"
imnsho ;).

	I don't see anyone here really advocating spoofed sources
(except for perhaps the mobile-ip users out there ;)

	How many people here have rpf enabled by default on their
customer CPE devices they ship?  (in your template or
whatnot)

	Do you u-rpf your dsl/cable/dial/fract-t1/t1 customers that
are not doing bgp?  It's hard to get this implemented across
an
entire network.  At one time I seem to recall someone saying
that 7018 was fully bcp-38 compliant, but I could be wrong.

	While doing u-rpf on your customers won't mitigate attacks
against them, it will help mitigate the costs of tracking
spoofed
attacks across your network infrastructure (which is harder
if you're
doing mpls) that you incur.

	Now, i'm guessing i may be the one responsible for the
practices of "big.net", but i do encourage other
big.nets
to enable u-rpf strict or loose wherever possible based on
their
equipment capabilities.  Every little bit will help.

	- jared

-- 
Jared Mauch  | pgp key available via finger from jaredpuck.nether.net
clue++;      | http://puck.nether.net
/~jared/  My statements are only mine.

Possible approach for small.net - ok, you know that big.net
will drop
any packets sourced from x.x.x.x if there's no route there
(loose uRPF
for downstream ISPs like small.net, strict uRPF for
end-users.)  So
give them a route.  Either give them a route on one of your
direct
interfaces to them, and then get rid of the packets by ACL
or by
null-routing it, or if that causes too much trouble, get
yourself a
56kbps line from a spare router and advertise it from
there.