$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.