Where is the edge of the Internet? Re: no ip forged-source-address

Mailman List Mirror (Read Only)
1

> What about the other large isps? What would it take for you to do
> something? Chris is gracious enough to show up and participate, at
> least even if it does mean he has to wear nomex.

I'm in favor of source address filtering at the edges.

Here we agree, I believe the difference might be that you don't consider
the edge of your network to be the edge. If the edge only encompasses
where "Joe Bob" connects, then we have no belt and suspenders for when
things go wrong. It also allows the largest isps to continue doing
nothing or very little.

I'm opposed to some of the suggestions where to put source address
filters, especially placing them in "non-edge" locations. E.g. requiring
address filters at US border crossings is a *bad* idea, worthy of an
official visit from the bad idea fairy.

What is bad about filtering facing non-customers, if loose rpf is
used? I'm assuming this is what you mean by "border crossings" rather than
the literal.

Our networks, and our customer bases, are not identical. This is good
and bad. Not to make excuses, the ease with which this can technically be
done depends on your network and type of customer connections. Or more
precisely how you aggregate customer connections.

Is there anywhere you can apply rpf today, while working towards the rest
for tomorrow? I can't speak for everyone, but I like it when people
do what they can.

I don't personally have RPF deployed "everywhere" in the network I run,
but I am deploying it, piece by piece.

"Progress, not perfection" as the saying goes.

IMHO the edge is generally the best place to do source address filtering.
After traffic is aggregated its more difficult. Some folks have already
identified the technical limitations of some types equipment. And with
the market, we're going to be stuck with that equipment for a while. In
hindsight, if every provider and every equipment vendor did it from day 1,
we would be in great shape.

The only equipment I'm heard here which has serious issues related to
feature availability is the 12000 (which was never a particularly good
aggregation device to begin with). RPF works fine on 7200, 7500, and
6500, from my experience. I've not used 12000's for customer aggregation
since they historically haven't been designed for or adequate in that
respect.

As such, I can understand providers not being able to apply RPF immediately
on 12000's, at least unless they are acquiring E3 cards for new installs.

Does that mean I can wave my magic wand and fix everything tomorrow? No.

Can I work on standards, vendors and purchasing agents to change this over
time? Yes. Will yelling at me make it happen faster? I doubt it, but I
know you will anyway.

All I asked for in my last message was whether folks were making progress,
and if they weren't to point out the trouble areas so we could all pool
our collective resources to address the stoppage.
This doesn't mean full deployment must occur by tomorrow (I'ld fail), but
that it be something each network is working towards.

However, we never hear "we're working on deploying rpf, but having snags"
but hear instead "rpf won't work for us". The latter always feels
more philosophical than technical, even if there are real technical issues
at play. If there are technical issues, I want to help in getting them
addressed (short of buying folks gear appropriate for customer aggregation,
sorry I don't have money to donate).

So, in this vein, is there gear other than old 12000 linecards that
can't do RPF? Is anyone still using 2500's or 4500's?

What non-hardware reasons are there not to do some flavor of rpf? Is
there a situation where even loose rpf will not work?

2

The only equipment I'm heard here which has serious issues related to
feature availability is the 12000 (which was never a particularly good
aggregation device to begin with). RPF works fine on 7200, 7500, and
6500, from my experience. I've not used 12000's for customer aggregation
since they historically haven't been designed for or adequate in that
respect.

As such, I can understand providers not being able to apply RPF

immediately

on 12000's, at least unless they are acquiring E3 cards for new installs.

6500s can do it, but enabling it doubles the size of the FIB, and the FIB
can only hold 244,000 unicast entries. So, with RPF enabled on any
interface, your limit is now 122,000 routes. With a full BGP view, you're
probably dangerously close to this number.

You're supposed to be able to exceed that number and simply end up with some
networks being software switched, however, I've seen a number of 6509s
running native software either fall over or experience serious bugs (not
fixed as of 12.1(13)E) when exceeding this limit.

3

I'm opposed to some of the suggestions where to put source address
filters, especially placing them in "non-edge" locations. E.g. requiring
address filters at US border crossings is a *bad* idea, worthy of an
official visit from the bad idea fairy.

What is bad about filtering facing non-customers, if loose rpf is
used? I'm assuming this is what you mean by "border crossings" rather than
the literal.

--------->makes sense on the edge/aggregation but if you do it further up in
the network.....there maybe some cases where we have assymetric routing,
where the path of uplink is never the path the same as the downlink, and
infact the source network of the packet may never be present in the routing
table....(it is possible, after all its a packet switched network and the
routing is destination IP based) ...

4

$author = "alok" ;

makes sense on the edge/aggregation but if you do it further up in
the network.....there maybe some cases where we have assymetric routing,
where the path of uplink is never the path the same as the downlink

hence the suggestion of "reachable-via any" rather then "route to source IP
must be out the interface packet came in" in the scenario you paint. it's
hard to block spoofed source addresses that actually exist in the routing
table except at the "edges", hence the discussion about where the "edge"
is...

if you pick the right places to implement filtering there is no need to do
it to all routers.

infact the source network of the packet may never be present in the routing
table....(it is possible, after all its a packet switched network and the
routing is destination IP based) ...

ummmm, if the source address isn't in the routing table why would we bother
carrying the packet a single hop further?

marty

5

Hi

see inline :o),

6

$author = "alok" ;

they will charge you a whooping sum for that "picking places" bit ;o)
... i agree that the best place to actually address such scenarios is the
"backbone"/"peering points"/"borders" where all traffic is seen..rather than
go around tinkering at all edges..but i dont know how RPF would address the
assymetry there.. but at the edges...depolyment costs is a problem..i
think...dont ask me if i have a better idea :o) i would be writing a paper
if i did.....

i'd disagree with your choice of places:

backbone - the core is the last place i'd be putting filtering

peering points / borders - the router needs a full table (asymmetry /
reachable-via any) and be beefy enough to handle the extra load of
filtering.

the places to go after are (IMHO in this order):

- routers immediately upstream of dial-in pools, cable headends etc.etc.
  (strict filtering)
- routers aggregating customer circuits (strict filtering)
- peering / transit circuits (loose filtering)

coz the destination network is there..... its still a viable config
isnt it..incase of assymetric uplinks and downlinks? ......wht stops u from
"not having a route to the source" as routing is destination IP based...
some particular network may be covered with 0.0.0.0/0 for example and you
may have no routing entry for it... or you could be having a customer who
uplinks a particular network segment via your ISP, but doesnt advertise his
network to you as he actually downlinks that network from somewhere
else...nothing to stop that topology either.........right?

a default route is still a route (may need configuring "allow-default").

i don't think you grasp the idea of "reachable-via any" which allows you to
filter only if there is no route for the source address in the entire table,
allowing for asymmetry in the network.

if the router can't return a response or icmp packet to the source, why
bother with the packet. if the router doesn't have a full table and no
default route then it just isn't a smart place to filter (and a very extreme
corner case).

marty

7

they will charge you a whooping sum for that "picking places" bit ;o)
... i agree that the best place to actually address such scenarios is the
"backbone"/"peering points"/"borders" where all traffic is seen..rather

than

go around tinkering at all edges..but i dont know how RPF would address

the

assymetry there.. but at the edges...depolyment costs is a problem..i
think...dont ask me if i have a better idea :o) i would be writing a paper
if i did.....

i'd disagree with your choice of places:

backbone - the core is the last place i'd be putting filtering

peering points / borders - the router needs a full table (asymmetry /
reachable-via any) and be beefy enough to handle the extra load of
filtering.

-----------> so its a hardware limitation?....bigger cores needed

the places to go after are (IMHO in this order):

- routers immediately upstream of dial-in pools, cable headends etc.etc.
  (strict filtering)
- routers aggregating customer circuits (strict filtering)
- peering / transit circuits (loose filtering)

----------> fair enuf...... 2 schools of thought, and ur idea makes sense
too... no denying that...but you have corner cases... which wont come up if
it could be in the core.....

coz the destination network is there..... its still a viable config
isnt it..incase of assymetric uplinks and downlinks? ......wht stops u

from

"not having a route to the source" as routing is destination IP based...
some particular network may be covered with 0.0.0.0/0 for example and you
may have no routing entry for it... or you could be having a customer who
uplinks a particular network segment via your ISP, but doesnt advertise

his

network to you as he actually downlinks that network from somewhere
else...nothing to stop that topology either.........right?

a default route is still a route (may need configuring "allow-default").

-----> well that covers everything doesnt it ;o)... even those not in ur
network..does it actually ping and check to see if its there?

i don't think you grasp the idea of "reachable-via any" which allows you to
filter only if there is no route for the source address in the entire table,
allowing for asymmetry in the network.

--------------> do u inject BGP into IGP? ....do all access boxes have the
entire BGP table/or know every address/network on the internet?

if the router can't return a response or icmp packet to the source, why
bother with the packet. if the router doesn't have a full table and no
default route then it just isn't a smart place to filter (and a very extreme
corner case).

------> most access would be the corner cases... i have cases where tier-2
ISPs would simply take a 3 Mb uplink from 1 service provider and a fat
downlink from another (ISP-2) ...all the BGP routes/advertisements would be
in the 2nd ISPs networks, ISP 1 has no idea what this guys address range is
at the access is... this is a common mechanism lots of tier-2 ISPs would
apply......

okie...does RPF actually ping and check if there is "indeed" a way to get to
the destination purely via IGP (to indicate it is in the same AS as it is a
spoofed IP)?..again note, purely via IGP....not BGP..(again not a 0.0.0.0/0
crossing to another AS)

if you anyway knew the network so well, a better way would be to use route
filters in bgp (access list in) if u any way knew the customers network
range and for no BGP customers, simple filters at edge points without RPF
would put the same overhead i guess....

8

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So, in this vein, is there gear other than old 12000 linecards that
can't do RPF? Is anyone still using 2500's or 4500's?

What non-hardware reasons are there not to do some flavor of rpf? Is
there a situation where even loose rpf will not work?

SUNET has had a standing recommendation to its customers to enable RPF for
a couple of years now. Our customers come in two flavours, big and small.
The small ones get a FE, and there typically is marginal clue at the
customer site. For them we do "the long command" (ip verify unicast
reverse-path), as it has been known, in the access router, which in the
weird scale of a REN is a 12016 or a 12010 chock full with 8-port FE cards.
It keeps up with the load, and we've not seen any trouble so far.

The big customers are more interesting. They have redundant connections,
two 10720 routers on an OC48 SRP ring facing the backbone routers for that
city which are two 12408 or similar. There also is an AS transition on the
ring; nearly all our big customers have ASen and we speak BGP to them. This
setup of course means that traffic may enter via one of the routers and
exit via the other, leading to strangeness and confusion, especially when
the customer staff is less experienced in non-trivial routing.

In some cases we've helped them solve this by simple access lists, but that
is a bit too static to be really nice.

- --
M�ns Nilsson Systems Specialist
+46 70 681 7204 KTHNOC MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

9

$author = "alok" ;

so its a hardware limitation?....bigger cores needed

not necessarily. if you do the filtering in the right places you can leave
the core to do it's job of passing packets.

also, the idea of filtering at the edges is designed to reduce the distance
dud packets travel in your network, leaving your routers to worry about
passing legit packets.

fair enuf...... 2 schools of thought, and ur idea makes sense
too... no denying that...but you have corner cases... which wont come up if
it could be in the core.....

the idea behind the extended filtering capabilities in routing software /
OSes is to address the problems you describe.

well that covers everything doesnt it ;o)... even those not in ur
network..does it actually ping and check to see if its there?

no, a default route is a default route. it doesn't check the IP address, but
any packets to dud addresses will get dropped the second they hit a default
free zone (if there is no matching prefix) or the upstream router (addresses
covered by a prefix but not used).

do u inject BGP into IGP? ....do all access boxes have the
entire BGP table/or know every address/network on the internet?

i'd be running iBGP across the default free core and IGP to cover link state
of your core. i've seen BGP injected into IGP and it can end up ugly if your
not careful.

so yes, you'd have a subset of your routers with full tables. you can filter
on these routers using "reachable-via any" to address asymmetry. on routers
closer to the customer edge, you might not have a full table but you can
apply stricter filtering given that you should know what subnets are coming
in your customer facing interfaces.

most access would be the corner cases... i have cases where tier-2
ISPs would simply take a 3 Mb uplink from 1 service provider and a fat
downlink from another (ISP-2) ...all the BGP routes/advertisements would be
in the 2nd ISPs networks, ISP 1 has no idea what this guys address range is
at the access is... this is a common mechanism lots of tier-2 ISPs would
apply......

? ISP-1 can filter packets based on subnets known to be attached to the
customer circuit (your customer system does record IP addresses assigned to
customers or provider independent IP subnets that your customers have,
doesn't it?!?)...

ISP-2 would do the same for upstream traffic. downstream both ISPs could
apply whatever filtering is appropriate (loose / strict) given their network
structure.

we cud start a new topic...

"where is the core of the internet"?

coz assymetric routing messes up everything :o) even for those scenarios
on the core...

read up a little RPF and the difference between "strict" and "loose"...

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122yo/swcg/secure.htm#xtocid10

marty

10

inline....

$author = "alok" ;

so its a hardware limitation?....bigger cores needed

not necessarily. if you do the filtering in the right places you can leave
the core to do it's job of passing packets.

also, the idea of filtering at the edges is designed to reduce the distance
dud packets travel in your network, leaving your routers to worry about
passing legit packets.

=====> yup, but its fine if they reach the core as long as they dont go out
of it onto some WAN ($$) link (surely u have enuf on ethernet and pretty
much dont care whats there),... its still not hogging away bandwdith....but
its the ideal point to know "everything" passing around..... :o)..specially
Area -0 in OSPF.....

fair enuf...... 2 schools of thought, and ur idea makes sense
too... no denying that...but you have corner cases... which wont come up

if

it could be in the core.....

the idea behind the extended filtering capabilities in routing software /
OSes is to address the problems you describe.

well that covers everything doesnt it ;o)... even those not in ur
network..does it actually ping and check to see if its there?

no, a default route is a default route. it doesn't check the IP address, but
any packets to dud addresses will get dropped the second they hit a default
free zone (if there is no matching prefix) or the upstream router (addresses
covered by a prefix but not used).

======> I may have to stop aggregation/default routing , on certain points
where i may have to go "loose"........
...unless ..if its "right at the edge" , where you know customer
interfaces..as you have been saying..but still nothing can be put on the non
customer facing side....

do u inject BGP into IGP? ....do all access boxes have the
entire BGP table/or know every address/network on the internet?

i'd be running iBGP across the default free core and IGP to cover link state
of your core. i've seen BGP injected into IGP and it can end up ugly if your
not careful.

so yes, you'd have a subset of your routers with full tables. you can filter
on these routers using "reachable-via any" to address asymmetry. on routers
closer to the customer edge, you might not have a full table but you can
apply stricter filtering given that you should know what subnets are coming
in your customer facing interfaces.

=========> you wudnt want to put this on any iBGP routers with "loose", as
they will anyway "know too many networks" .....u cudnt do it for multihomed
guys, not sure how u say u can.....unless you filter out his entire
range....

11

$author = "alok" ;

yup, but its fine if they reach the core as long as they dont go out
of it onto some WAN ($$) link (surely u have enuf on ethernet and pretty
much dont care whats there),... its still not hogging away bandwdith....but
its the ideal point to know "everything" passing around..... :o)..specially
Area -0 in OSPF.....

but you loose some of the chances to do strict filtering if you leave the
filtering to the core.

I may have to stop aggregation/default routing , on certain points
where i may have to go "loose"........
...unless ..if its "right at the edge" , where you know customer
interfaces..as you have been saying..but still nothing can be put on the non
customer facing side....

the idea is that packets towards the customer were checked asap, preferably
at the point of ingress, and therefore no need to apply any filters on the
upstream interface. but the only check you can do is "loose" if you are
multihomed.

you wudnt want to put this on any iBGP routers with "loose", as
they will anyway "know too many networks" .....u cudnt do it for multihomed
guys, not sure how u say u can.....unless you filter out his entire
range....

you can apply "loose" on these routers which will cut 1918 and other bogus
source addresses. that doesn't prevent spoofing as much as it reduces the
work your network does carrying dud packets.

wont work if the customer has his own AS else ill need to filter
"all" of the addresses...... ***there is no rule which needs me to tell the
peering provider what I am uplinking via his pipe**.......** I could still
DDOS with all the IPs belonging to the tier-2 ISP and get enuf traffic
generated...right?**

you could with your IPs, but you'd find yourself no longer a customer in a
hurry. putting myself in the shoes of your hypothetical "tier-2" i'd want to
know what prefixes the customer was intending to hang off the circuit
regardless of whether they wanted to use us for uplink, downlink or both.

your going out of your way to paint yourself into a corner without employing
rigorous methods of doing things "the right way"...

you might also say "okie now i know this AS was the source" but then that
hardly helps you obviously cant ban the whole AS's IP range.. u need to
track the "user".....

reducing the likelihood that the attack packets have a spoofed source
address allows "the user" to be tracked more effectively.

...hmm but you could say that the tier-2 guy should do RPF too........that
makes sense...."stringent laws" would help.....

eliminating the possibility of spoofed source addresses requires everyone to
implement strict RPF at the edges, loose RPF at peering / transit points.
getting 100% compliance is unlikely, hence my choice of the word "reducing"
rather then "eliminating".

loose/strict wont help if its 2 different ISPs..........and if u
dont know what customer networks are uplinking via your own core.....

again, most upstreams want to know what prefixes you intend to hang off a
circuit. it allows them to protect themselves and you from doing something
funky like offering to transit for half the internet across your T1.

loose is essentally "exist -only" i hope thats what u
mean?........it doesnt check the "interface" being a possible point of
entry, just that the network is known via the routing table......thats what
your refering to I guess...??..for BGP peered networks... cant say
much....its upto him what he advertises to you...

"exist only" is required to allow filtering in the presence of routing
asymmetry. i'd rather filter on "exists" then the only alternative of not
filtering source addresses at all for traffic directed at your prefixes or
transiting your network.

but for customers whose networks are present in you IGP, it does make
sense.....strict on all access devices, loose on all the major points where
one cant tell the interfaces....but you still need to know where he uplinks
and downlinks from...."so its sort of same as acls but yeah, its
automated".......wondering if all this effort can be put onto the core...

wrong. you don't need to know uplink/downlink if you a thorough enough to
obtain information from the customer prior to bringing up their circuit.
if you don't obtain this information then you can't apply proper ACLs on
their BGP feed or implement the appropriate static / IGP routes. there is
nothing for the customer to gain by not notifying the IAP about all
prefixes...

incase u think i am giving you too many corner cases.... its not "whine
whine" its just exploring possibilites :o) ...

you need to keep a focus on what RPF is hoping to achieve and the associated
need by IAPs to be rigorous in their methods of handling customers...

marty

12

And if the destination network isn't there, you send the ICMP Net Unreachable
to where?

13

???
u confused me with that question… who said the destn net was unreachable?

14

Ok, so I'll respond to one more of the messages I missed yesterday.

> The only equipment I'm heard here which has serious issues related to
> feature availability is the 12000 (which was never a particularly good
> aggregation device to begin with). RPF works fine on 7200, 7500, and
> 6500, from my experience. I've not used 12000's for customer aggregation
> since they historically haven't been designed for or adequate in that
> respect.

Alot of large providers have 'all 12000' or 'alot of 12000' devices, so
this is a hint at the problem :frowning: Most large, where large == continental,
providers don't have very many 7200/6500 gear in their network.

Keep in mind that sometimes what platform you choose 12 months ago you may
get stuck with in a longer term than originally anticipated. That platform
may have been chosen because it was the only viable platform at the
initial buy time :frowning:

>
> As such, I can understand providers not being able to apply RPF
immediately
> on 12000's, at least unless they are acquiring E3 cards for new installs.

Wow, by E3 I assume you mean: Engine 3... This is a VERY BAD PLAN, if my
experience with them is anything to judge from. Both E2 and E3 cards have
some serious limitations when it comes to access lists and uRPF. For
instance, I've been in config mode where:

int blah1/0.123
ip access<tab>

yields nothing... in other words, 'ip access-group 123 out' is not even in
the valid config for these cards :frowning: even more depressing is the hope that
it'll work and the unfortunate reality that it'll apply to the interface
and never access list any traffic at all :frowning:

To Cisco's credit they are now addressing the intricacies of the 12000
platform, the combinations of linecard, IOS, config bits, routing
situations... This is a complex beast, and its not known anywhere near as
well as it should be.

From what I've heard, I haven't yet tested these, the E4+ cards are

supposed to answer alot of the existing acl issues. One thing to keep in
mind is that your FIB is limited to ~225k prefixes if you want to use PSA
acls (hardware acls)on a 12000... Supposedly, if you remove PSA acl
functionality you can punt the acl work to the linecard CPU, in reality
the punting never happens and the traffic isn't acl'd :frowning:

6500s can do it, but enabling it doubles the size of the FIB, and the FIB
can only hold 244,000 unicast entries. So, with RPF enabled on any
interface, your limit is now 122,000 routes. With a full BGP view, you're
probably dangerously close to this number.

This seems like the same issue as the FIB limits on the 12000 linecards :frowning:

You're supposed to be able to exceed that number and simply end up with some
networks being software switched, however, I've seen a number of 6509s
running native software either fall over or experience serious bugs (not
fixed as of 12.1(13)E) when exceeding this limit.

On the 12000, the routes are just lost... and magically the attack
'stops', so does traffic to some randomly large number of destinations too
:frowning: So this is 'suboptimal' to say the least.

BTW, Cisco has been made aware of these issues so its again, on deck for a
fix in the e5/6/7 linecard...