On Jul 24, 2007, at 11:01 AM, Joe Greco wrote:
Since what I'm talking about is mainly IDS-style inspection of packets, combined with optional redirection of candidate hosts to a local "cleanser" IRCD, the only real problem is dumping outbound packets somewhere where the /32 routing loop would be avoided.
On a large network, particularly a network which hasn't already deployed a sinkhole/re-injection system which covers all the relevant portions of this topology, that's a lot of work. Transit networks are probably more likely than broadband access networks to've done so, IMHO (I've no knowledge of whether any of the relevant SPs have or haven't done so, that's just a general observation).
Presumably it isn't a substantial challenge for a network engineer to implement a policy route for packets from that box to the closest transit (even if it isn't an optimal path). It's only IRC, after all. ;-)
But we're talking about multiple destination points, and the static nature of [Cisco, at least] PBR doesn't always lend itself well to that kind of model. Multipoint GRE potentially does, but again, that's more infrastructure to plan and deploy.
Similar in complexity, just without the networking angle.
In much the same way that flying an airplane is similar to driving a car, just without the 35,000-feet-in-the-air angle. ;>
I don't see how what I suggest could be anything other than a benefit to the Internet community, when considering this situation.
I think sinkholing and re-injection is a very useful technique, and constantly exhort operators who haven't done so to implement it. My point was that if one hasn't implemented it, there's a substantial effort involved, one that's more complex than implementing DNS poisoning.
If your network is generating a gigabit of traffic towards an IRC server, and is forced to run it through an IDS that only has 100Mbps ports, then you've decreased the attack by 90%.
And one may've backhauled a gig of traffic across a portion of one's topology which can ill-afford it, causing collateral damage. Always a concern with any kind of redirection technology, it's important to monitor.
Your local clients break, because they're suddenly seeing 90% packet loss to the IRC server, and you now have a better incentive to fix the attack sources.
There are other incentives which are less traumatic, one hopes. ;>
Am I missing some angle there? I haven't spent a lot of time considering it.
See above. ;>
Yes, there is some truth there, especially in networks made up of independent autonomous systems. DNS redirection to a host would favor port redirection, so an undesirable side effect would be that all Cox customers connecting to irc.vel.net would have appeared to be coming from the same host. It is less effort, but more invasive.
Yes - sometimes more invasive methods are necessary, depending upon one's goal.
The point is that there are other ways to conduct such an exercise. In particular, I firmly believe that any time there is a decision to break legitimate services on the net, that we have an obligation to seriously consider the alternatives and the consequences.
Yes, but it's also very easy to second-guess what others are doing when not in full possession of the facts. None of us are, so it's probably a bit premature to speculate about someone else's chain of reasoning and then attack his logic, in the absence of any concrete information regarding same. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice Culture eats strategy for breakfast. -- Ford Motor Company