As long as we're doing "Me Too"...
Savvis has had prefix:666 for around 18 months as well.
Alif Terranson
OpSec Engineering Manager
Operations Security Department
Savvis Communications Corporation
(314) 628-7602 Voice
(314) 208-2306 Pager
(618) 558-5854 Cell
Terranson, Alif wrote:
As long as we're doing "Me Too"...
Savvis has had prefix:666 for around 18 months as well.
Do you know if C&W does? Or will that wait until the integration?
This thread has caused me to add this as a requirement for a new gigabit ISP circuit I am ordering, as well as uRPF in the core, etc.
I've had two ISPs say "We don't do this yet, but based on the fact you are making it a requirement, we will role those functions out into our core."
Steve
Voting with his money for better net-security....
uRPF in the core seems like a bad plan, what with diverse routes and such.
Loose-mode might help SOME, but really spoofing is such a low priority
issue why make it a requirement? Customer triggered blackholing is a nice
feature though.
--Chris
(formerly chris@uu.net)
<snip>
uRPF in the core seems like a bad plan, what with diverse
routes and such.
Loose-mode might help SOME, but really spoofing is such a low
priority issue why make it a requirement? Customer triggered
blackholing is a nice feature though.
</snip>
Shared view,
mh (Teleglobe, btw)
Christopher L. Morrow wrote:
uRPF in the core seems like a bad plan, what with diverse routes and such.
Loose-mode might help SOME, but really spoofing is such a low priority
issue why make it a requirement? Customer triggered blackholing is a nice
feature though.
Obviously loose-mode. Spoofing may not be the current weapon of choice, but why not encourage the best net infrastructure?
Loose mode will not save you very much, many larger backbones route lots
of 'unused' or 'unallocated' ip space internally for various valid
reasons, some even related to security issues for their customers. So,
does stopping rfc-1918 (maybe) space help much? not really... atleast not
that I can see. Many flooding tools now flood from legittimate space, so
the ONLY way to limit this is by filtering as close to the device sourcing
the packets as possible. Nebulous filtering and dropping of miniscule
amounts of traffic in the core of a large network is just a waste of
effort and false panacea.
--Chris
(formerly chris@uu.net)
uunet does operate lots of dialup RAS though correct? any reason why urpf
is not reasonable there?
just because its not perfect and doesnt solve every problem doesnt mean
its useless.
miniscule amounts of traffic in uunet's core is still enough to ddos many
a victim into oblivion. anyone who has been ddos'd by uunet customers can
appreciate that.
-Dan
> the packets as possible. Nebulous filtering and dropping of miniscule
> amounts of traffic in the core of a large network is just a waste of
> effort and false panacea.uunet does operate lots of dialup RAS though correct? any reason why urpf
is not reasonable there?
For some sure, for others perhaps not 
We have some customers with
dedicated networks over dial, some with dial-backup and even some with dsl
backup.
just because its not perfect and doesnt solve every problem doesnt mean
its useless.
Sure, I'm just not really sure that the core is the right place to do
this... I agree that the edge is a fine place, I'd prefer not my edge 
but the edge is the right place. You can make all the decisions correctly
there, you can not in the core.
miniscule amounts of traffic in uunet's core is still enough to ddos many
a victim into oblivion. anyone who has been ddos'd by uunet customers can
appreciate that.
miniscule is enough to cause problems in anyone's network.... the point
here was: "Core isn't the right place for this" I wasn't really trying to
argue the 'urpf is good' or 'urpf is bad' arguement, just the placement.
Sorry if I made that confusing earlier.
--Chris
(formerly chris@uu.net)
Christopher L. Morrow wrote:
miniscule amounts of traffic in uunet's core is still enough to ddos many
a victim into oblivion. anyone who has been ddos'd by uunet customers can
appreciate that.
miniscule is enough to cause problems in anyone's network.... the point
here was: "Core isn't the right place for this" I wasn't really trying to
argue the 'urpf is good' or 'urpf is bad' arguement, just the placement.Sorry if I made that confusing earlier.
So we all agree that in the ideal world, everyone has anti-spoofing ACLs and route map filters and what not on every link into their network.
But in the real world...given that you are going to be peering with ISPs (or their upstreams) that do not do uRPF or anything at all on their edges, if you want to drop the patently bogus traffic, or your customers don't want to pay you for delivering it to them over links they don't want congested with it, what do you do?
I guess you can say "peering links are not core", and that's fine if you run loose-uRPF there, and can be assured that all access to your network has filters on all links. I was thinking of large peering routers as part of the core of an ISP, so loose-uRPF is sufficient on those routers, if edges are protected.
But if you are going to run loose-uRPF on your peering routers, why not run it on your core? Is there a technogical reason not to? Cisco OC48 line cards not support it (at least some do.), I'm almost sure Juniper does too. But I don't play in that area.
And given that there are ISP's running it in the core; that it will block some malicious traffic; and spoofed traffic may well be used as an attack vector again (sometime people are going to have to catch on and patch machines, or worms will patch them for them, and reduce the botnet farm size. Maybe not this year, but sometime...), I still don't see why you are against it.
I accept that filtering on all edges, including peering, is a better place to do it. So do you filter on, say, peering links to other tier 1's? Even so, why not have belt AND suspender, and run it in the core?
steve@expertcity.com (Steve Francis) writes:
...
But in the real world...given that you are going to be peering with ISPs
(or their upstreams) that do not do uRPF or anything at all on their
edges, ...
ok, i'll bite. why do we still do this? see the following from june 2001:
http://www.cctec.com/maillists/nanog/historical/0106/msg00681.html
(and according to that text, it was a 9-year-old idea at that time.)
it's now 2004. how much longer do we want to have this problem?
Source address validation (or Cisco's term uRPF) is perhaps more widely
deployed than people realize. Its not 100%, but what's interesting is
despite its use, it appears to have had very little impact on DDOS or
lots of other bad things.
Root and other DNS servers bear the brunt of misconfigured (not
necessarily malicious attack) devices. So some people's point of
view may be different. But relatively few DDOS attacks use spoofed
packets. If more did, they would be easier to deal with.
After all these years, perhaps its time to re-examine the assumptions.
Having had almost exactly that phrase in my peering contracts for
$n years, the answer is because if you are A, and peer is B,
if ( A>B )
your spoofed traffic comes (statistically) from elsewhere so you don't
notice. You are dealing with traffic from C, where C>>A
else
you've signed their peering agreement, and are 'peering' on their
terms instead. Was I going to pull peering with $tier1 from whom
the occasional DoS came? Nope.
The only way this was ever going to work was if the largest networks
cascaded the requirements down to the smallest. And the largest networks
were the ones for whom (quite understandably) rpf was most difficult.
DoS (read unpaid for, unwanted traffic) is one of the best arguments
against settlement-free peering (FX: ducks & runs).
Alex
Source address validation (or Cisco's term uRPF) is perhaps more widely
deployed than people realize. Its not 100%, but what's interesting is
despite its use, it appears to have had very little impact on DDOS or
lots of other bad things.
...
But relatively few DDOS attacks use spoofed
packets. If more did, they would be easier to deal with.
AIUI that's cause & effect: the gradual implementation of source-address
validation has made attacks dependent on spoofing less attractive to
perpetrators. Whereas the available of large pools of zombie machines
has made the use of source spoofing unnecessary. Cisco et al have shut
one door, but another one (some suggest labeled Microsoft) has opened.
Those with long memories might draw parallels with the evolution of
phreaking from abuse of the core, which became (reasonably) protected
to abuse of unprotected PABXen. As I think I said only a couple of days
ago, there is nothing new in the world.
Alex
Source address validation (or Cisco's term uRPF) is perhaps more widely
deployed than people realize. Its not 100%, but what's interesting is
despite its use, it appears to have had very little impact on DDOS or
lots of other bad things.
Try saying that after running a major DDoS target, with "HIT ME" your
forehead.
No offense Sean but I'd like you to back your claim up with some
impirical data first.
From experience the majority of TCP based denial of service attacks
(which usually seem to be balanced with UDP, but ICMP is not as frequent
as it once was), use spoofed sources.
Has the number of DDOS attacks increased or decreased in the last few
years has uRPF has become more widely deployed?
Do you have any evidence the number of attacks are decreasing?
sean@donelan.com (Sean Donelan) writes:
> Try saying that after running a major DDoS target, with "HIT ME" your
> forehead. No offense Sean but I'd like you to back your claim up with
> some impirical data first.Has the number of DDOS attacks increased or decreased in the last few
years has uRPF has become more widely deployed?
the number of spoofed-source attacks is down only-slightly.
Do you have any evidence the number of attacks are decreasing?
the overall number of attacks and their volume seems to be decreasing
ever-so-slightly, but the ferocity of the attacks that come through seems
to be increasing more-than-slightly.
and, when defending against one of these, every valid source address is
worth its figurative weight in gold, and constitutes a minor compromise
for the attacker, even if the host it helps to identify is disposable,
easily replaced, and difficult to repair.
[ of course, sean, i could just be making that part up. but since i keep
saying it and since i get attacked pretty frequently, i might be telling
the truth. it could be worth assuming a little credibility and seeing
where that leads you. (but, we digress.) ]
the % of spoofed and bogon traffic was measured recently at several of
the root nameservers. iirc it was suprisingly high.
-Dan
Without any data to back this up, I'm estimating based on the attacks
I've dealt with.
I don't believe the number have gone down at all. If it has, it's done
that for someone else, not me,
I don't have any evidence. Nor do I *believe* the number of attacks is
decreasing. If anything, its staying the same or going up, as more
people decide it's fun to take networks offline through the greater and
greater number of compromised hosts.
If you want to do a little test, try this:
In the last 5 years, compromised hosts have become a favourite for
launching DDoS attacks from. If the number of compromised hosts with
outbound Internet access has gone up, then either the frequency of
attacks, or the amplitude of said attacks, or both have gone UP.
We all know the number of compromised hosts continues to go up. The rest
is simple logic.
just a question
why is DDoS the only issue mentioned wrt source address validation?
i'm sure there's other reasons to make sure your customers can't send
spoofed packets. they might not always be as news-worthy, but i feel it's
a provider's duty to do this. it shouldn't be optional (talking
specifically about urpf on customer interfaces, loose where needed)
fingers wrote:
just a question
why is DDoS the only issue mentioned wrt source address validation?
i'm sure there's other reasons to make sure your customers can't send
spoofed packets. they might not always be as news-worthy, but i feel it's
a provider's duty to do this. it shouldn't be optional (talking
specifically about urpf on customer interfaces, loose where needed)
Because _Distributed_ is the hot buzzword of the day.
At least one of us thinks clean traffic is a Good Thing all the time.
Packets that can't possibley be used for anything ought to be dumped at
the earliest possible opportunity as soon as it is apparent (or could
be if anybody looked) that they are "from" addresses that can't be
reached or have any other obviously fatal defect.