RE: no ip forged-source-address
A fundamental effect of spoofing addresses from your local subnet is that when the packets reach their target, the source addresses are meaningful. I realize that the traceability of these packets has already been mentioned, but I want to point out the profound difference between a DDoS attack with meaningful vs. meaningless source addresses. -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Hank Nussbacher Sent: Wednesday, October 30, 2002 2:27 PM To: variable@ednet.co.uk Cc: nanog@nanog.org Subject: Re: no ip forged-source-address On Wed, 30 Oct 2002 variable@ednet.co.uk wrote: If every router in the world did this I could still use spoofed IP addresses and DDOS someone. My little program could determine what subnet I am on, check what other hosts are alive on the subnet and then when it decides to attack, it would use some neighbor's IP. The subnet I am on is a /24 and there very well may be a few dozen hosts. I could be real sneaky and alter my IP randomly to be any of my neighbors for every packet I send out. Traceback would get me instantly back to the offending subnet but then it would take a bit of digging on the network admin to track me down and applying RPF checking won't help. RPF checking can only go so far. You would need RPF checking down to the host level and I haven't heard anyone discuss that yet. -Hank
Hi,
I've been following the discussion on DDoS attacks over the last few
and our network has also recently been the target of a sustained DDoS attack.I'm not alone in believing that source address filters are the simplest way to prevent the types of DDoS traffic that we have all been seeing with increasing regularity.Reading the comments on this list have lead me to believe that there is a lot of inertia involved in applying what appears to me as very simple filters.
As with the smurf attacks a few years ago, best practice documents and RFC's don't appear to be effective.I realise that configuring and applying a source address filter is trivial, but not enough network admins seem to be taking the time to lock this down.If the equipment had sensible defaults (with the option to bypass them if required), then perhaps this would be less of an issue.
Therefore, would it be a reasonable suggestion to ask router vendors to source address filtering in as an option[1] on the interface and then move it to being the default setting[2] after a period of time?This appeared to have some success with reducing the number of networks that forwarded broadcast packets (as with "no ip directed-broadcast").
Just my $0.02,
Richard Morrell edNET
[1] For example, an IOS config might be:
interface fastethernet 1/0 no ip forged-source-address
[2] Network admins would still have the option of turning it off, but
weeks this
would have to be explicitly configured.
On Wed, 30 Oct 2002, H. Michael Smith, Jr. wrote:
A fundamental effect of spoofing addresses from your local subnet is that when the packets reach their target, the source addresses are meaningful. I realize that the traceability of these packets has already been mentioned, but I want to point out the profound difference between a DDoS attack with meaningful vs. meaningless source addresses.
I'm confused.. its still a DoS attack, eh??
On Thu, 31 Oct 2002 06:21:00 GMT, "Christopher L. Morrow" said:
I'm confused.. its still a DoS attack, eh??
It's the difference between: A) Going out to your car at the end of a too-long day and finding a broken taillight. B) Going out to your car at the end of a too-long day and finding a broken taillight and a business card under the windshield wiper that has "Sorry - call me and I'll pay for it" written on the back.
On Thu, 31 Oct 2002 Valdis.Kletnieks@vt.edu wrote:
On Thu, 31 Oct 2002 06:21:00 GMT, "Christopher L. Morrow" said:
I'm confused.. its still a DoS attack, eh??
It's the difference between:
A) Going out to your car at the end of a too-long day and finding a broken taillight.
B) Going out to your car at the end of a too-long day and finding a broken taillight and a business card under the windshield wiper that has "Sorry - call me and I'll pay for it" written on the back.
I think the spoofed source filtering is more a red-herring than anything else. Its not the fix for anything related to this problem of attacks on the internet. Spoofed or non, I can forward 1,000,000pps at your network and it will die (most times). This is like trying to fix a rotten decayed tooth with trident.
analogy games are fun, but it boils down to this... If I know the real source of an attack, I can stop it within minutes. I'm sure that my customers appreciate that fact. Noone will ever completely stop attacks, the point is to minimize their impact. that is my concern as a service provider. also, from the victim's perspective, you have someone to hold accountable. Charles -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Christopher L. Morrow Sent: Wednesday, October 30, 2002 10:47 PM To: Valdis.Kletnieks@vt.edu Cc: Christopher L. Morrow; nanog@nanog.org Subject: Re: no ip forged-source-address On Thu, 31 Oct 2002 Valdis.Kletnieks@vt.edu wrote:
On Thu, 31 Oct 2002 06:21:00 GMT, "Christopher L. Morrow" said:
I'm confused.. its still a DoS attack, eh??
It's the difference between:
A) Going out to your car at the end of a too-long day and finding a broken taillight.
B) Going out to your car at the end of a too-long day and finding a broken taillight and a business card under the windshield wiper that has "Sorry - call me and I'll pay for it" written on the back.
I think the spoofed source filtering is more a red-herring than anything else. Its not the fix for anything related to this problem of attacks on the internet. Spoofed or non, I can forward 1,000,000pps at your network and it will die (most times). This is like trying to fix a rotten decayed tooth with trident.
On Wed, 30 Oct 2002, Charles D Hammonds wrote:
analogy games are fun, but it boils down to this... If I know the real source of an attack, I can stop it within minutes. I'm sure that my customers appreciate that fact. Noone will ever completely stop attacks, the point is to minimize their impact. that is my concern as a service provider. also, from the victim's perspective, you have someone to hold accountable.
again, spoofed or non, at the egress to the customer you just need to make the traffic stop. Whether they are spoofed isn't an issue.
Charles
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Christopher L. Morrow Sent: Wednesday, October 30, 2002 10:47 PM To: Valdis.Kletnieks@vt.edu Cc: Christopher L. Morrow; nanog@nanog.org Subject: Re: no ip forged-source-address
On Thu, 31 Oct 2002 Valdis.Kletnieks@vt.edu wrote:
On Thu, 31 Oct 2002 06:21:00 GMT, "Christopher L. Morrow" said:
I'm confused.. its still a DoS attack, eh??
It's the difference between:
A) Going out to your car at the end of a too-long day and finding a broken taillight.
B) Going out to your car at the end of a too-long day and finding a broken taillight and a business card under the windshield wiper that has "Sorry - call me and I'll pay for it" written on the back.
I think the spoofed source filtering is more a red-herring than anything else. Its not the fix for anything related to this problem of attacks on the internet. Spoofed or non, I can forward 1,000,000pps at your network and it will die (most times).
This is like trying to fix a rotten decayed tooth with trident.
On Wed, 30 Oct 2002, Charles D Hammonds wrote:
analogy games are fun, but it boils down to this... If I know the real source of an attack, I can stop it within minutes. I'm sure that my customers appreciate that fact. Noone will ever completely stop attacks, the point is to minimize their impact. that is my concern as a service provider. also, from the victim's perspective, you have someone to hold accountable.
again, spoofed or non, at the egress to the customer you just need to make the traffic stop. Whether they are spoofed isn't an issue.
It is a lot easier to stop when you know whom you have to stop. Why is uunet so opposed to uRPF? If performance concerns, what effort has been made to address them with the vendor? Why is it that others (I believe ATT was mentioned) can do it with no apparent performance impact? Is it philosophical, and nothing would get you to change? What about financial, more dos traffic equals more revenue and bad sources means complaints may go elsewhere deflecting cost from the abuse/security budget? Do you just not like us? Let's solve whatever issues you believe to exist, so we can do _something_ rather than sitting around not doing anything all the time. What would it take to get uunet to do something? 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.
On Mon, 4 Nov 2002 bdragon@gweep.net wrote:
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. 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. 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. 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. 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.
On Mon, 4 Nov 2002 bdragon@gweep.net wrote:
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?
On Mon, 4 Nov 2002 sean@donelan.com wrote:
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.
Ok, so I'll respond to one more of the messages I missed yesterday. On Mon, 4 Nov 2002, Matt Buford wrote:
On Mon, 4 Nov 2002 sean@donelan.com wrote:
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 :( 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 :(
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.
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
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 :( 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 :( 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. the punting never happens and the traffic isn't acl'd :(
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 :(
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 :( 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...
Ok, so I'll respond to one more of the messages I missed yesterday.
On Mon, 4 Nov 2002, Matt Buford wrote:
On Mon, 4 Nov 2002 sean@donelan.com wrote:
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.
The above was actually me, not Sean, iirc.
Alot of large providers have 'all 12000' or 'alot of 12000' devices, so this is a hint at the problem :( Most large, where large == continental, providers don't have very many 7200/6500 gear in their network.
Someone else just mentioned running RPF on 12000 without issue, except for SRP rings. I can't confirm that myself, as we avoided using 12000 for customer aggregation due to their poor performance in that arena. RPF on ubr7200, 7200vxr, 7500, and 6500 all seem to work fine.
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 :(
Definately understandable.
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 :( 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 :(
Yes, I meant Engine 3, which are the ISE cards. I don't yet have any, but I'ld be surprised if they don't support acls on subints. Perhaps you meant E1 and E2? Even if they don't support acls, I'ld be surprised if they didn't support RPF. <snip>
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 :(
Interesting, but shouldn't affect RPF, correct? <snip>
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) ...
$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 -- Skirwan - "And if pigs can fly, and I can ride one, and they fly me to hell, and it just froze over, and we all have ice cream..." [1] talonyx - "I really need to stop reading Slashdot while on codeine....." [2] [1] - http://slashdot.org/comments.pl?sid=28984&cid=3113144 [2] - http://slashdot.org/comments.pl?sid=28984&cid=3113355 [3] [3] - Yes, I corrected his spelling... ;)
Hi see inline :o), ----- Original Message ----- From: Martin <marty@supine.com> To: <nanog@nanog.org> Sent: Tuesday, November 05, 2002 12:59 PM Subject: Re: Where is the edge of the Internet? $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... =====> ..he does cover it in the cisco docs...but then that means only the edges..which means deployment problems and blah blah .... i was answering the question as to why not on the "non customer facing side"...... if you pick the right places to implement filtering there is no need to do it to all routers. ====> 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.....
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? =======> 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?
$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 -- I'm not here. This isn't happening. "How to Disappear Completely" - Radiohead
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
go around tinkering at all edges..but i dont know how RPF would address
than 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....
$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/secur... marty -- Can't buy what I want because it's free. Can't be what they want because I'm me. "Corduroy" - Pearl Jam
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.... ---------------
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?!?)... =====> 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 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"..... ...hmm but you could say that the tier-2 guy should do RPF too........that makes sense...."stringent laws" would help..... ---------------- ISP-2 would do the same for upstream traffic. downstream both ISPs could apply whatever filtering is appropriate (loose / strict) given their network structure. =====> loose/strict wont help if its 2 different ISPs..........and if u dont know what customer networks are uplinking via your own core.....
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/secur e.htm#xtocid10 ========> 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... 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... if u mean something else by "loose" then im sorry im not aware.. perhaps you could share some info... incase u think i am giving you too many corner cases.... its not "whine whine" its just exploring possibilites :o) ... -Alok
$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 -- You need only two tools, WD-40 and duct tape. If it doesn't move and it should, use the WD-40. If it moves and shouldn't, use the tape.
On Tue, 05 Nov 2002 13:26:04 +0530, alok <alok.dube@apara.com> said:
=======> 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?
And if the destination network isn't there, you send the ICMP Net Unreachable to where? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
???? u confused me with that question... who said the destn net was unreachable?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Monday, November 04, 2002 19:22:14 -0500 bdragon@gweep.net wrote:
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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE9x4ry02/pMZDM1cURAkFKAJ99xAl0kWLTK1DpVn1kSOTEHb5kUwCeIcNu C0fOzo0ekX7DFyOh/rmFEhc= =yCn8 -----END PGP SIGNATURE-----
Sean puts this very nicely... I was away today so I missed the rest of the traffic and looking it over alot of it was not relevant. I'll put in some comments here though. On Mon, 4 Nov 2002, Sean Donelan wrote:
On Mon, 4 Nov 2002 bdragon@gweep.net wrote:
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.
Sure, so are most operators, including me. Define the edge the right way, as Sean says, though. The edge is the customer CPE, or even the LAN router inside the customer network. As close as possible to actual hosts that can spoof.
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.
In general, knowing what ips a 'peer' is going to send you is very difficult. One would hope that all peers would have all customers implement filtering as close to their hosts as possible. This isn't a reality today :( Putting filtering, of any type, in a 'core' spot is asking for trouble. Doing much other than routing at the core is a bad plan. In the future perhaps filtering and other magic would be possible in the core, but in reality it will almost always be a tough thing to do. :(
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.
This is a good point. If you are aggregating customers on gear where the uRPF filtering is done in software you will severely impact performance with anything over oc3 rates :( Do not confuse acls with uRPF, acls on t1 aggragation isn't workable unless your 'network' lives in your basement. uRPF is only feasible in some small circumstances. Making the assumption that because your network works with uRPF and thus Sean's or Ryan's or Paul's will isn't really valid. I would like to believe that the majority of NSP/ISP operators have atleast considered uRPF, or some kind of mitigation techniques. We have, and for us the current possibilities aren't feasible :( for a number of technical reasons which the respective's vendors are aware.
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.
Yes, filter at the 'edge', where 'edge' == 'as close to the host as possible'. Possibly this could be accomplished by a config default in IOS/JunOS... something akin to 'no ip directed broadcast'... or atleast that possibility was raised at the NANOG Security BOF. This won't solve any problems in the short term, but it is a move in the right direction.
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.
This is the tact that we are taking inside UUNET today. We are trying to work on a consensus document for 'Network Equipment Requirements'. This effort is being headed up by Mr. George Jones, I believe this document is headed out for IETF work and possibly additions to BCP 38 ? Barry Greene is helping out on this along with some folks from Merit. The focus of this is to get everyone possible asking for the same thing from their vendors. For a long time every vendor through the door would say: "security what?", "Filtering what?", "You are the ONLY person asking for this capability." This was the response to: Radius authentication for management access, tacacs auth for management access, auth for management access, filtering, filtering at line rate, filtering on all interfaces... the list goes on of things that one would assume are 'standard' on any network gear. UUNET, atleast, has been asking all vendors we see/speak-with/test for the list of things in George's document for the last 2 years. -Chris "Nomex, whats that?" Morrow.
analogy games are fun, but it boils down to this... If I know the real source of an attack, I can stop it within minutes.
the real source of the attack is the skript kitty who zombied the 10,000 hosts which are sourcing packets at you. the intermediate sources are the 10,000 zombies, and trying to deal with them at the source just does not scale. though i sympathize with the frustration the attack victim feels, i find the net.vigilanteeism amusing at best and misdirecting of people's efforts at worst. the places where the counter-attack is scalable are at the real perp and at the attacked site. finding the former is still a matter of research. the known scalable counter to the latter is still <http://nanog.org/mtg-0102/bellovin.html>. randy
analogy games are fun, but it boils down to this... If I know the real source of an attack, I can stop it within minutes.
the real source of the attack is the skript kitty who zombied the 10,000 hosts which are sourcing packets at you. the intermediate sources are the 10,000 zombies, and trying to deal with them at the source just does not scale. really you only need four or five though - if you can monitor the tcp/ip
at Thursday, October 31, 2002 1:22 PM, Randy Bush <randy@psg.com> was seen to say: links each have, you should find a common node that is the control node (assuming the current situation where the bots remain connected during the attack; a simple change could alter this to disconnect immediately after orders are issued and not reconnect for a random time spanning hours or days, but even then, unless the kiddie wishes to discard his entire botnet after a single attack, they should eventually reconnect to a control channel (probably an irc channel or similar) - at least theoretically, an irc server network could be tapped to determine who is the controller in a bot room, or the bot room could be discontinued (which again, would only halt the current state of the art; the bots could easily have a different network or a distributed networking capability to recover the botnet after loss of a control room; actually, I would be surprised if bots didn't already have some similar provision now)
On Thu, 31 Oct 2002, Christopher L. Morrow wrote:
I think the spoofed source filtering is more a red-herring than anything else. Its not the fix for anything related to this problem of attacks on the internet. Spoofed or non, I can forward 1,000,000pps at your network and it will die (most times).
I agree, but
This is like trying to fix a rotten decayed tooth with trident.
Wouldn't you rather the dentist know which tooth to drill, instead of randomly drilling all of of your teeth hoping to get the cavity? I can pretty much predict, after source address validation becomes widely used someone will come up with the idea of blackholing attacking hosts. Of course, since many of these systems use DHCP, the zombies will just release and get new addresses.
At 01:36 AM 31-10-02 -0500, Valdis.Kletnieks@vt.edu wrote:
It's the difference between:
A) Going out to your car at the end of a too-long day and finding a broken taillight.
B) Going out to your car at the end of a too-long day and finding a broken taillight and a business card under the windshield wiper that has "Sorry - call me and I'll pay for it" written on the back.
It is better than not having it but we should not get our hopes up that DOS attacks would stop. Remember when 60% of the Internet mail servers were open mail relays? We all thought closing them up would stop spam. Today it is less than 1% but I would say that the amount of spam has not dropped proportionality. See: http://www.nwfusion.com/columnists/2002/1014buzz.html for reference. -Hank
participants (13)
-
alok -
bdragon＠gweep.net -
Charles D Hammonds -
Christopher L. Morrow -
David Howe -
H. Michael Smith, Jr. -
Hank Nussbacher -
marty＠supine.com -
Matt Buford -
Måns Nilsson -
Randy Bush -
Sean Donelan -
Valdis.Kletnieks＠vt.edu