The packet stream can be disrupted by the victim by 'pretending' to go offline to the protocol receiving the bandwidth from that particular attack. The rerouting of using available bandwidth to other protocols via an alternative port can remove the ramifications of the attack. Applying the aforementioned framework within the cloud environment offers an unprecedented level of security enabling the transmission and storage of information in an environment where DDoS is actively monitored and attacks are recognizable. The strategy of using the cloud ostensibly removes the bottleneck constriction due to the lack of physical infrastructure such as a server that purports a chokepoint should an attacker stream an abundance of packet information to the target server.

According to Koutepas, Stamatelopoulos, & Maglaris (2004), "Management-wise DDoS attacks present an interesting challenge since their nature makes them difficult to stop by the efforts of a single site. Factors that contribute to this are: (a) attackers most of the time spoof packet source IP's address; (b) the possibility of the attack initiating from a wide range of networks worldwide; and (c) the in ability of a domain to enforce incoming traffic shaping; detected malicious flows can be blocked locally but the assistance of the upstream network is still needed in order to free the resources occupied on the incoming link. (Koutepas, Stamatelopoulos, Maglaris, 2004)

When attempting to counter a DDoS, the specific attack characteristics have to be determined locally and communicated to networks on the attack path (possibly through attack-congested lines) in order to take appropriate measures. According to the site's security policies the typical reactions implemented usually consist of setting up tailor-made blocking or throttling filters on active network components. Still, no matter how effective this response will be, the bandwidth penalty is present on all the domains along the attack path. To alleviate the resulting congestion extra steps must be taken and contacts must be made between these networks. The further we move from the victim, the more dispersed this procedure becomes and there is less immediate interest from the domains to help." (Koutepas, Stamatelopoulos, Maglaris, 2004)

Security considerations, according to Koutepas, Stamatelopoulos, Maglaris (2004), include "An attacker orchestrating a DDoS attack could "tune into" the right Multicast group (the one used by the Entities) and listen for signs of detection and response communications. Knowing such information could make it possible to direct the hostile machines to new attack patterns so that the malicious traffic can elude any newly installed filters. Another concern is that fake alert messages describing nonexistent events could initiate Entity responses to hinder legitimate traffic." (Koutepas, Stamatelopoulos, Maglaris, 2003)

According to Fonseca (2001), "Asta Networks will unveil Vantage System, its new DDoS -- prevention offering, this month. Deployed at various points in an enterprise or service provider network, Vantage System is a hardware appliance that uses software to survey and "flag" traffic for known or unknown anomalies. The product features sensors, which direct suspicious activity, and the coordinator, which interfaces with a variety of sensors and reports back to the user. Devich says his defense system integrates with network management platforms through SNMP, as well as Cisco and Juniper routers. In the fight against DoS attacks, users may be able to deflect a deluge that could strike from any origination point through a managed service approach, says John Pescatore, vice president and research director of network security at Stamford, Conn.-based Gartner." (Fonseca, 2001)

According to Vijayan (2004), "The long-term answer to DDoS protection has to be in the [service provider] networks and backbones" said John Pescatore, an analyst at Stamford, Conn.-based Garnter, Inc. That's because upstream service providers are in a better position to detect and choke off traffic directed at a specific IP address, said Schneier. But putting in place extra server processing capacity to handle DDoS attacks can be expensive and is likely to make sense only for larger companies, Mockapetris said. "There's a bit of a digital divide when it comes to the ability of companies to defend themselves against these attacks," he said. As a result, it's a good idea to require service providers to offer some sort of guarantee against DDoS attacks, said Schneier. Gartner has in fact been advocating this for more than two years, urging users to include DDoS protection language in their service-level agreements with Internet service providers and data center hosting companies. But less than 1% of companies overall are buying such services, Pescatore said. "Most enterprises say, 'It isn't raining, so the roof isn't leaking. Why fix it?" he said." (Vijayan, 2004)

According to Gezelter (2000), "It has been reported that significant legal and technical hurdles prevent a quick, straightforward solution to DDoS attacks. It is often suggested that the anonymity offered by the Internet must be eliminated to prevent future attacks. Like a postcard, each message on the Internet, known...

Reports of recent DDoS attacks indicate that the sender's address, referred to as the originator, or source, address, has often been forged -- a process known as IP spoofing. Forging an originator address serves to confuse the trail leading back to the computer that sent the packets." (Gezelter, 2000)
Additionally, according to Gezelter (2000), "Stopping spoofed packets does not eliminate the potential for DDoS attacks, but it makes it much harder to covertly stage such an attack. It makes it easier and faster for law enforcement and service providers to track and cut off the source of the attack. Traceability and accountability are productive ways to deal with many hazards. If ISPs reject all packets with obviously fake originator addresses, the process of identifying the source of the attack is accelerated. The scale of the attacks would also be reduced." (Gezelter, 2000)

According to Tsukioka (2005), "NIT Communications has announced that it will run a trial on a state-of -- the-art security system to protect NIT Com Global IP Network against distributed denial-of-services (DDoS) attacks. The DDoS attacks cause the denial of service for users of a targeted system by flooding the system with incoming messages to cause it to shut down." (Tsukioka, 2010) Again, this does point to the flooding of the path with packets of information or messages intended to restrict the ability of the network to process data at a reasonable rate.

According to Malliga (2008), "An integrated defense solution, implemented in a distributed manner throughout the network to prevent, detect, filter and rate limited is essential. Such a distributed system requires integration of various components to perform the aforementioned tasks. This paper advocates a distributed architecture of heterogeneous entities, placed at various points of a network working co-operatively to yield an effective defense against the attacks." (Malliga, 2008)

Strategies to mitigate the DDoS attacks, according to Liu (2009), include "Attacker identification applies trace-back techniques to identify the attacker's perpetrator. Attack packets usually have spoofed IP addresses and could ths derive from many IP addresses, so it's difficult to trace back to their source. If we can identify the attackers, it's easier to filter out their traffic." (Liu, 2009)

According to Messmer (2002), "Mazu Networks, which makes equipment to stop distributed denial-of-service-attacks, last week said it has added a way to determine what legitimate traffic is being filtered out in the process. Mazu has also added a way to filter out attacks with dangerous payloads, such as the Nimda and Code Red viruses, which attempt to install a Trojan horse during the course of scanning attacks." (Messmer, 2002) However, the idea is that in the cloud, the ability to attach a Trojan horse to a payload and corrupt the data is unfounded.

References

Attacks test firms' internet defenses; inside PayPal's war room, engineers face chess match with WikiLeaks-inspired hackers. (2010, Wall Street Journal (Online), pp. n/a. Retrieved from http://search.proquest.com/docview/816948344?accountid=13044

Connolly, P.J. (2001). Fight DDoS attacks with intelligence. InfoWorld, 23(39), 58. Retrieved from http://search.proquest.com/docview/194345351?accountid=13044

Fonseca, B. (2001). Warning: DDoS attacks on the rise. InfoWorld, 23(22), 49. Retrieved from http://search.proquest.com/docview/194357031?accountid=13044

Gezelter, R. (2000). Stopping spoofed packets can cut down DDoS attacks. Network World, 17(33), 53. Retrieved from http://search.proquest.com/docview/215970452?accountid=13044

Koutepas, G., Stamatelopoulos, F., & Maglaris, B. (2004). Distributed management architecture for cooperative detection and reaction to DDoS attacks. Journal of Network and Systems Management, 12(1), 73. Retrieved from http://search.proquest.com/docview/201343592?accountid=13044

Liu, S. (2009, Surviving distributed denial-of-service attacks. It Professional Magazine, 11(5), 51. Retrieved from http://search.proquest.com/docview/206372139?accountid=13044

Lynn, S. (2009). In the ring: Microsoft office web apps vs. google docs. CRNtech, (33), 36. Retrieved from http://search.proquest.com/docview/215878625?accountid=13044

Malliga, S., & Tamilarasi, a. (2008). A distributed defensive architecture for DoS/DDoS attacks. Journal of Information Privacy & Security, 4(4), 21. Retrieved from http://search.proquest.com/docview/203667163?accountid=13044

Messmer, E. (2002). Weapons emerge to fend off DDoS attacks. Network World, 19(13), 12. Retrieved from http://search.proquest.com/docview/215955530?accountid=13044

Moss, H., & Zierick, J. (2011). Cloud providers will be better at security than you can ever be. Network World, 28(4), 27. Retrieved from http://search.proquest.com/docview/854279445?accountid=13044

Top 10 security predictions for 2011. (2011). Informationweek - Online,, n/a. Retrieved from http://search.proquest.com/docview/840658432?accountid=13044

Tsukioka, a. (2005). NTT com to…