draft-iab-dos-02.txt   draft-iab-dos-03.txt 
Network Working Group M. Handley (ed) Network Working Group M. Handley (ed)
Internet-Draft UCL Internet-Draft UCL
Expires: January 21, 2006 E. Rescorla (ed) Expires: March 19, 2006 E. Rescorla (ed)
Network Resonance Network Resonance
July 20, 2005 September 15, 2005
Internet Denial of Service Considerations Internet Denial of Service Considerations
draft-iab-dos-02.txt draft-iab-dos-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 21, 2006. This Internet-Draft will expire on March 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document provides an overview of possible avenues for denial-of- This document provides an overview of possible avenues for denial-of-
service attack on Internet systems. The aim is to encourage protocol service attack on Internet systems. The aim is to encourage protocol
designers and network engineers towards designs that are more robust. designers and network engineers towards designs that are more robust.
skipping to change at page 2, line 21 skipping to change at page 2, line 21
2.1.2 Application Resource Exhaustion . . . . . . . . . . . 7 2.1.2 Application Resource Exhaustion . . . . . . . . . . . 7
2.1.3 Operating System Resource Exhaustion . . . . . . . . . 8 2.1.3 Operating System Resource Exhaustion . . . . . . . . . 8
2.1.4 Triggered Lockouts and Quota Exhaustion . . . . . . . 9 2.1.4 Triggered Lockouts and Quota Exhaustion . . . . . . . 9
2.2 DoS Attacks on Routers . . . . . . . . . . . . . . . . . . 9 2.2 DoS Attacks on Routers . . . . . . . . . . . . . . . . . . 9
2.2.1 Attacks on Routers through Routing Protocols . . . . . 10 2.2.1 Attacks on Routers through Routing Protocols . . . . . 10
2.2.2 IP Multicast-based DoS Attacks . . . . . . . . . . . . 11 2.2.2 IP Multicast-based DoS Attacks . . . . . . . . . . . . 11
2.2.3 Attacks on Router Forwarding Engines . . . . . . . . . 12 2.2.3 Attacks on Router Forwarding Engines . . . . . . . . . 12
2.3 Attacks on Ongoing Communications . . . . . . . . . . . . 13 2.3 Attacks on Ongoing Communications . . . . . . . . . . . . 13
2.4 Attacks using the Victim's Own Resources . . . . . . . . . 14 2.4 Attacks using the Victim's Own Resources . . . . . . . . . 14
2.5 DoS Attacks on Local Hosts or Infrastructure . . . . . . . 14 2.5 DoS Attacks on Local Hosts or Infrastructure . . . . . . . 14
2.6 DoS Attacks on Sites though DNS . . . . . . . . . . . . . 15 2.6 DoS Attacks on Sites though DNS . . . . . . . . . . . . . 16
2.7 DoS Attacks on Links . . . . . . . . . . . . . . . . . . . 17 2.7 DoS Attacks on Links . . . . . . . . . . . . . . . . . . . 17
2.8 DoS attacks on firewalls . . . . . . . . . . . . . . . . . 17 2.8 DoS attacks on firewalls . . . . . . . . . . . . . . . . . 18
2.9 DoS attacks on IDS systems . . . . . . . . . . . . . . . . 18 2.9 DoS attacks on IDS systems . . . . . . . . . . . . . . . . 19
2.10 DoS attacks on or via NTP . . . . . . . . . . . . . . . . 18 2.10 DoS attacks on or via NTP . . . . . . . . . . . . . . . . 19
2.11 Physical DoS . . . . . . . . . . . . . . . . . . . . . . . 19 2.11 Physical DoS . . . . . . . . . . . . . . . . . . . . . . . 20
2.12 Social Engineering DoS . . . . . . . . . . . . . . . . . . 19 2.12 Social Engineering DoS . . . . . . . . . . . . . . . . . . 20
2.13 Legal DoS . . . . . . . . . . . . . . . . . . . . . . . . 19 2.13 Legal DoS . . . . . . . . . . . . . . . . . . . . . . . . 20
2.14 Spam and Black-hole Lists . . . . . . . . . . . . . . . . 19 2.14 Spam and Black-hole Lists . . . . . . . . . . . . . . . . 20
3. Attack Amplifiers . . . . . . . . . . . . . . . . . . . . . . 21 3. Attack Amplifiers . . . . . . . . . . . . . . . . . . . . . . 22
3.1 Methods of Attack Amplification . . . . . . . . . . . . . 21 3.1 Methods of Attack Amplification . . . . . . . . . . . . . 22
3.2 Strategies to Mitigate Attack Amplification . . . . . . . 23 3.2 Strategies to Mitigate Attack Amplification . . . . . . . 24
4. DoS Mitigation Strategies . . . . . . . . . . . . . . . . . . 24 4. DoS Mitigation Strategies . . . . . . . . . . . . . . . . . . 25
4.1 Protocol Design . . . . . . . . . . . . . . . . . . . . . 24 4.1 Protocol Design . . . . . . . . . . . . . . . . . . . . . 25
4.1.1 Don't Hold State for Unverified Hosts . . . . . . . . 24 4.1.1 Don't Hold State for Unverified Hosts . . . . . . . . 25
4.1.2 Make it Hard to Simulate a Legitimate User . . . . . . 24 4.1.2 Make it Hard to Simulate a Legitimate User . . . . . . 25
4.1.3 Graceful Routing Degradation . . . . . . . . . . . . . 25 4.1.3 Graceful Routing Degradation . . . . . . . . . . . . . 26
4.1.4 Autoconfiguration and Authentication . . . . . . . . . 26 4.1.4 Autoconfiguration and Authentication . . . . . . . . . 27
4.1.5 Network Design and Configuration . . . . . . . . . . . 26 4.2 Network Design and Configuration . . . . . . . . . . . . . 27
4.1.6 Redundancy and Distributed Service . . . . . . . . . . 26 4.2.1 Redundancy and Distributed Service . . . . . . . . . . 28
4.1.7 Authenticate Routing Adjacencies . . . . . . . . . . . 26 4.2.2 Authenticate Routing Adjacencies . . . . . . . . . . . 28
4.1.8 Isolate Router-to-Router Traffic . . . . . . . . . . . 26 4.2.3 Isolate Router-to-Router Traffic . . . . . . . . . . . 28
4.2 Router Implementation Issues . . . . . . . . . . . . . . . 27 4.3 Router Implementation Issues . . . . . . . . . . . . . . . 28
4.3 End-System Implementation Issues . . . . . . . . . . . . . 27 4.3.1 Checking Protocol Syntax and Semantics . . . . . . . . 29
4.3.1 State Lookup Complexity . . . . . . . . . . . . . . . 27 4.3.2 Consistency Checks . . . . . . . . . . . . . . . . . . 29
4.3.2 Operational Issues . . . . . . . . . . . . . . . . . . 28 4.3.3 Enhance Router Robustness through Operational
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 29 Adjustments . . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 4.3.4 Proper Handling of Router Resource Exhaustion . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 4.4 End-System Implementation Issues . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.4.1 State Lookup Complexity . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35 4.4.2 Operational Issues . . . . . . . . . . . . . . . . . . 32
A. IAB Members at the time of this writing . . . . . . . . . . . 36 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . 37 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
A. IAB Members at the time of this writing . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . . 41
1. Introduction 1. Introduction
A Denial-of-Service (DoS) attack is an attack in which one or more A Denial-of-Service (DoS) attack is an attack in which one or more
machines target a victim and attempt to prevent the victim from doing machines target a victim and attempt to prevent the victim from doing
useful work. The victim can be a network server, client or router, a useful work. The victim can be a network server, client or router, a
network link or an entire network, an individual Internet user or a network link or an entire network, an individual Internet user or a
company doing business using the Internet, an Internet Service company doing business using the Internet, an Internet Service
Provider (ISP), country, or any combination of or variant on these. Provider (ISP), country, or any combination of or variant on these.
Denial of service attacks may involve gaining unauthorized access to Denial of service attacks may involve gaining unauthorized access to
skipping to change at page 10, line 32 skipping to change at page 10, line 32
with e.g., eBGP. with e.g., eBGP.
The simplest attack on a network of routers is to overload the The simplest attack on a network of routers is to overload the
routing table with sufficiently many routes that the router runs out routing table with sufficiently many routes that the router runs out
of memory, or the router has insufficient CPU power to process the of memory, or the router has insufficient CPU power to process the
routes [15]. We note that depending on the distribution and routes [15]. We note that depending on the distribution and
capacities of various routers around the network, such an attack capacities of various routers around the network, such an attack
might not overwhelm routers near to the attacking router, but might might not overwhelm routers near to the attacking router, but might
cause problems to show up elsewhere in the network. cause problems to show up elsewhere in the network.
Some routing protocols allow limits to be configured on the maximum Some routing protocol implementations allow limits to be configured
number of routes to be heard from a neighbor [17]. However, limits on the maximum number of routes to be heard from a neighbor [17].
often make the problem worse rather than better, by making it However, limits often make the problem worse rather than better, by
possible for the attacker to push out legitimate routes with spoofed making it possible for the attacker to push out legitimate routes
routes, thus creating an an easy form of DoS attack. with spoofed routes, thus creating an an easy form of DoS attack.
An alternative attack is to overload the routers on the network by An alternative attack is to overload the routers on the network by
creating sufficient routing table churn that routers are unable to creating sufficient routing table churn that routers are unable to
process the changes. Many routing protocols allow damping factors to process the changes. Many routing protocols allow damping factors to
be configured to avoid just such a problem. However, as with table be configured to avoid just such a problem. However, as with table
size, such a threshold applied inconsistently may allow the spoofed size, such a threshold applied inconsistently may allow the spoofed
routes to merge with legitimate routes before the mechanism is routes to merge with legitimate routes before the mechanism is
applied, causing legitimate routes to be damped. applied, causing legitimate routes to be damped.
The simplest routing attack on a specific destination is for an The simplest routing attack on a specific destination is for an
skipping to change at page 11, line 48 skipping to change at page 11, line 48
the group receivers and not to non-receivers. Thus ASM is the group receivers and not to non-receivers. Thus ASM is
particularly vulnerable to DoS attacks causing both multicast routing particularly vulnerable to DoS attacks causing both multicast routing
table explosion (and hence control processor memory exhaustion) and table explosion (and hence control processor memory exhaustion) and
multicast forwarding table exhaustion (and hence forwarding card multicast forwarding table exhaustion (and hence forwarding card
memory exhaustion or thrashing). memory exhaustion or thrashing).
ASM also permits an attacker to send traffic to the same group as ASM also permits an attacker to send traffic to the same group as
legitimate traffic, potentially causing network congestion and legitimate traffic, potentially causing network congestion and
denying service to the legitimate group. denying service to the legitimate group.
However, unlike unicast traffic, it is comparatively difficult to
spoof source addresses for IP multicast traffic. Most deployed IP
multicast routing protocols use reverse-path checks to build the
forwarding tree, and so multicast attackers are easily located. In
addition, multicast traffic will only continue to flow to a receiver
as long as the receiver joins the multicast group. Thus it may be
harder to use multicast traffic to cause a denial-of-service attack
on a destination - an attacker would need to be opportunistic,
sending traffic to a multicast group that is already being received
by the victim or another host located close to the victim.
SSM does not permit senders to send to arbitrary groups unless a SSM does not permit senders to send to arbitrary groups unless a
receiver has requested the traffic. Thus sender-based attacks on receiver has requested the traffic. Thus sender-based attacks on
multicast routing state are not possible with SSM. However, as with multicast routing state are not possible with SSM. However, as with
ASM, a receiver can still join a large number of multicast groups ASM, a receiver can still join a large number of multicast groups
causing routers to hold a large amount of multicast routing state, causing routers to hold a large amount of multicast routing state,
potentially causing memory exhaustion and hence denial-of-service to potentially causing memory exhaustion and hence denial-of-service to
legitimate traffic. legitimate traffic.
With IPv6, hosts are required to send ICMP Packet Too Big or With IPv6, hosts are required to send ICMP Packet Too Big or
Parameter Problem messages under certain circumstances, even if the Parameter Problem messages under certain circumstances, even if the
skipping to change at page 15, line 13 skipping to change at page 14, line 51
even simpler attack - simply send from the victim's MAC address, and even simpler attack - simply send from the victim's MAC address, and
the switch will redirect traffic destined for the victim to the the switch will redirect traffic destined for the victim to the
attacker's port. attacker's port.
It may be possible to cause broadcast storms [4] on a local LAN by It may be possible to cause broadcast storms [4] on a local LAN by
sending a stream of unicast IP packets to the broadcast MAC address - sending a stream of unicast IP packets to the broadcast MAC address -
some hosts on the LAN may then attempt to forward the packets to the some hosts on the LAN may then attempt to forward the packets to the
correct MAC address greatly amplifying the traffic on the LAN. correct MAC address greatly amplifying the traffic on the LAN.
802.11 wireless networks provide many opportunities to deny service 802.11 wireless networks provide many opportunities to deny service
to other users. Unless encryption is enabled, it is trivial to to other users. In some cases, the lack of defenses against DoS was
announce the presence of a basestation (or even of an ad-hoc mode a deliberate choice--because 802.11 operates on unlicensed spectrum
host) with the same network name (SSID) as the legitimate it was assumed that there would be sources of interference and that
basestation. Even adding authentication and encryption a la 802.1X producing intentional radio-level jamming would be trivial. Thus,
and 802.11i may not help much in this respect. The SSID space is the amount of DoS protection possible at higher levels was minimal.
unmanaged, so everyone's free to put anything they want in the SSID
field. Most host stacks don't deal gracefully with this. Nevertheless, some of the weaknesses of the protocols against more
sophisticated attacks are worth noting. The most prominent of these
is that association is unprotected, thus allowing rogue APs to
solicit notifications that would otherwise have gone to legitimate
APs.
The SSID field provides effectively no defense against this kind of
attacks. Unless encryption is enabled, it is trivial to announce the
presence of a base station (or even of an ad-hoc mode host) with the
same network name (SSID) as the legitimate basestation. Even adding
authentication and encryption a la 802.1X and 802.11i may not help
much in this respect. The SSID space is unmanaged, so everyone's
free to put anything they want in the SSID field. Most host stacks
don't deal gracefully with this. Moreover, SSIDs are very often set
to the manufacturer's default, making them highly predictable.
Some 802.11 basestations have limited memory for the number of Some 802.11 basestations have limited memory for the number of
associations they can support. If this is exceeded, they may drop associations they can support. If this is exceeded, they may drop
all associations. all associations. In an attempt to forestall this problem, some APs
advertise their load so as to enable stations to choose APs that are
less loaded. However, crude implementations of these algorithms can
result in instability.
Finally, as the authentication in 802.11 takes place at a Finally, as the authentication in 802.11 takes place at a
comparatively high level in the stack, it is possible to simply comparatively high level in the stack, it is possible to simply
deauthenticate or disassociate the victim from the basestation, even deauthenticate or disassociate the victim from the basestation, even
if WEP is in use [26]. Bellardo and Savage [3] describe some simple if WEP is in use [26]. Bellardo and Savage [3] describe some simple
remedies that reduce the effectiveness of such attacks. remedies that reduce the effectiveness of such attacks. While IEEE
802.11w will protect Deauthenticate or Disassociate frames, this
attack is still possible via forging of Association frames.
What all these attacks have in common is that they exploit What all these attacks have in common is that they exploit
vulnerabilities in the link auto-configuration mechanisms. Such vulnerabilities in the link auto-configuration mechanisms. In a
problems are hard to solve because the reason for the existence of wireless network it is necessary for a station to detect the presence
such autoconfiguration mechanisms is ease of use, and to secure them of APs in order to choose which one to connect to. In 802.11 this is
requires some form of authentication at a sufficiently early place in handled via the Beacon and Probe Request/Response mechanisms.
the autoconfiguration process.
The Beacon cannot easily be encrypted, because the station needs to
utilize them prior to authentication in order to discover which APs
it may wish to communicate with. Since authentication can only occur
after interpreting the Beacon, an encrypted Beacon would present a
chicken-egg problem: you can't obtain a key to decrypt the Beacon
until completing authentication, and you may not be able to figure
out which AP to authenticate with prior to decrypting the Beacon.
As a result, discussions of Beacon frame security have largely
focused on authentication of Beacon frames, not encryption. Even
here, solutions are difficult. While it may be possible to for a
station to validate a Beacon *after* authentication (either by
checking a MIC computed with the group key provided by the AP, or
verifying the Beacon parameters during the 4-way handshake), doing so
*before* authentication may require synchronization of keys between
APs within an SSID.
2.6 DoS Attacks on Sites though DNS 2.6 DoS Attacks on Sites though DNS
In today's Internet, DNS is of sufficient importance that if access In today's Internet, DNS is of sufficient importance that if access
to a site's DNS servers is denied, the site is effectively to a site's DNS servers is denied, the site is effectively
unreachable, even if there is no actual communication problem with unreachable, even if there is no actual communication problem with
the site itself. the site itself.
Many of the attacks on end-systems described above can be perpetrated Many of the attacks on end-systems described above can be perpetrated
on DNS servers. As servers go, DNS servers are not particularly on DNS servers. As servers go, DNS servers are not particularly
skipping to change at page 16, line 12 skipping to change at page 16, line 36
when the root nameservers were subjected to a very large DoS attack when the root nameservers were subjected to a very large DoS attack
[36]. A number of the root nameservers have since been replicated [36]. A number of the root nameservers have since been replicated
using anycast [1] to further improve their resistance to DoS. using anycast [1] to further improve their resistance to DoS.
However it is important for authoritative servers to have relaying However it is important for authoritative servers to have relaying
disabled, or it is possible for an attacker to force the DNS servers disabled, or it is possible for an attacker to force the DNS servers
to hold state [39]. to hold state [39].
Many of the routing attacks can also be used against DNS servers by Many of the routing attacks can also be used against DNS servers by
targeting the routing for the server. If the DNS server is co- targeting the routing for the server. If the DNS server is co-
located with the site for which is authoritative, then the fact that located with the site for which is authoritative, then the fact that
the DNS server is also unavailable of secondary importance. However, the DNS server is also unavailable is of secondary importance.
if all the DNS servers are made unavailable, this may cause email to However, if all the DNS servers are made unavailable, this may cause
that site to bounce rather than being stored while the mail servers email to that site to bounce rather than being stored while the mail
are unreachable, so distribution of DNS server locations is servers are unreachable, so distribution of DNS server locations is
important. important.
Causing network congestion on links to and from a DNS server can have Causing network congestion on links to and from a DNS server can have
similar effects to end-system attacks or routing attacks, causing DNS similar effects to end-system attacks or routing attacks, causing DNS
to fail to obtain an answer, and effectively denying access to the to fail to obtain an answer, and effectively denying access to the
site being served. site being served.
We note that if an attacker can deny external access to all the DNS We note that if an attacker can deny external access to all the DNS
for a site, this will not only cause email to that site to be for a site, this will not only cause email to that site to be
dropped, but will also cause email from that site to be dropped. dropped, but will also cause email from that site to be dropped.
This is because recent versions of mail transfer agents such as This is because recent versions of mail transfer agents such as
sendmail will drop email if the mail originates from a domain that sendmail will drop email if the mail originates from a domain that
does not exist. This is a classic example of unexpected does not exist. This is a classic example of unexpected
consequences. Sendmail performs this check as an anti-spam measure, consequences. Sendmail performs this check as an anti-spam measure,
and spam itself can be viewed as a form of DoS attack. Thus and spam itself can be viewed as a form of DoS attack. Thus
defending against one DoS attack opens up the vulnerability that defending against one DoS attack opens up the vulnerability that
allows another DoS attack. allows another DoS attack. If a receiving implmentation is using
DNS-based blackholing, an attacker can also mount a DoS attack by
attacking the blackhole server.
Finally, a data corruption attack is possible if a site's nameserver Finally, a data corruption attack is possible if a site's nameserver
is permitted to relay requests from untrusted third parties [39]. is permitted to relay requests from untrusted third parties [39].
The attacker issues a query for the data he wishes to corrupt, and The attacker issues a query for the data he wishes to corrupt, and
the victim's nameserver relays the request to the authoritative the victim's nameserver relays the request to the authoritative
nameserver. The request contains a 16-bit ID that is used to match nameserver. The request contains a 16-bit ID that is used to match
up the response with the request. If the attacker spoofs sufficient up the response with the request. If the attacker spoofs sufficient
response packets from the authoritative nameserver just before the response packets from the authoritative nameserver just before the
official response will arrive, each containing a forged response and official response will arrive, each containing a forged response and
a different DNS ID, then there is a reasonable chance that one of the a different DNS ID, then there is a reasonable chance that one of the
forged responses will have the correct DNS ID. The incorrect data forged responses will have the correct DNS ID. The incorrect data
will then be believed and cached by the victim's nameserver, so will then be believed and cached by the victim's nameserver, so
giving the incorrect response to future queries. The probability of giving the incorrect response to future queries. The probability of
the attack can further be increased if the attacker issues many the attack can further be increased if the attacker issues many
different requests for the same data with different DNS IDs, because different requests for the same data with different DNS IDs, because
many nameserver implementations will the issue relayed requests with many nameserver implementations will issue relayed requests with
different DNS IDs, and so the response only has to match any one of different DNS IDs, and so the response only has to match any one of
these request IDs [6] [33]. The use of anycast for DNS services these request IDs [6] [33].
makes it even more vulnerable to spoofing attacks. An attacker who
can convince the ISP to accept an anycast route to his fake DNS The use of anycast for DNS services makes it even more vulnerable to
server can arrange to receive requests and generate fake responses. spoofing attacks. An attacker who can convince the ISP to accept an
anycast route to his fake DNS server can arrange to receive requests
and generate fake responses. Anycast DNS also makes DoS attacks on
DNS easiet. The idea is to disable one of the DNS servers while
maintaining the BGP route to that server. This creates failures for
any client which is routed to the (now defunct) server.
2.7 DoS Attacks on Links 2.7 DoS Attacks on Links
The simplest DoS attack is to simply send enough non-congestion- The simplest DoS attack is to simply send enough non-congestion-
controlled traffic that a link becomes excessively congested, and controlled traffic that a link becomes excessively congested, and
legitimate traffic suffers unacceptably high packet loss. legitimate traffic suffers unacceptably high packet loss.
Under some circumstances the effect of such a link DoS can be much Under some circumstances the effect of such a link DoS can be much
more extensive. We have already discussed the effects of denying more extensive. We have already discussed the effects of denying
access to a DNS server. Congesting a link might also cause a routing access to a DNS server. Congesting a link might also cause a routing
skipping to change at page 17, line 41 skipping to change at page 18, line 23
that normal traffic is effectively excluded. This is however that normal traffic is effectively excluded. This is however
unlikely except on low bandwidth links. unlikely except on low bandwidth links.
Finally, it may be possible to an attacker to deny access to a link Finally, it may be possible to an attacker to deny access to a link
by causing the router to generate sufficient monitoring or report by causing the router to generate sufficient monitoring or report
traffic that the link is filled. SNMP traps are one possible vector traffic that the link is filled. SNMP traps are one possible vector
for such an attack, as they are not normally congestion controlled. for such an attack, as they are not normally congestion controlled.
Attackers with physical access to multiple access links can easily Attackers with physical access to multiple access links can easily
bring down the link. This is particularly easy to mount and bring down the link. This is particularly easy to mount and
difficult to counter with wireless networks [ difficult to counter with wireless networks.
2.8 DoS attacks on firewalls 2.8 DoS attacks on firewalls
Firewalls are intended to defend the systems behind them against Firewalls are intended to defend the systems behind them against
attack. In that they restrict the traffic that can reach those attack. In that they restrict the traffic that can reach those
systems, they may also aid in defending against denial-of-service systems, they may also aid in defending against denial-of-service
attacks. However, under some circumstances the firewall itself may attacks. However, under some circumstances the firewall itself may
also be used as a weapon in a DoS attack. also be used as a weapon in a DoS attack.
There are many different types of firewall, but generally speaking There are many different types of firewall, but generally speaking
they fall into stateful and stateless classes. The state here refers they fall into stateful and stateless classes. The state here refers
to whether the firewall holds state for the active flows traversing to whether the firewall holds state for the active flows traversing
the firewall. Stateless firewalls generally can only be attacked by the firewall. Stateless firewalls generally can only be attacked by
attempting to exhaust the processing resources of the firewall. attempting to exhaust the processing resources of the firewall.
Stateful firewalls can be attacked by sending traffic that causes the Stateful firewalls can be attacked by sending traffic that causes the
firewall to hold excessive state or state which has pathological firewall to hold excessive state or state which has pathological
structure. structure.
In the case of excessive state, the firewall simply runs out of In the case of excessive state, the firewall simply runs out of
memory, and can no longer instantiate the state required to pass memory, and can no longer instantiate the state required to pass
legitimate flows. Most firewalls will then fail closed, causing legitimate flows. Most firewalls will then fail disconnected,
denial-of-service to the systems behind the firewall. causing denial-of-service to the systems behind the firewall.
In the case of pathological structure, the attacker sends traffic In the case of pathological structure, the attacker sends traffic
that causes the firewall's data structures to exhibit worst case that causes the firewall's data structures to exhibit worst case
behaviour. An example of this would be when the firewall uses hash behaviour. An example of this would be when the firewall uses hash
tables to look up forwarding state, and the attacker can predict the tables to look up forwarding state, and the attacker can predict the
hash function used. The attacker may then be able to cause a large hash function used. The attacker may then be able to cause a large
amount of flow state to hash to the same bucket, which causes the amount of flow state to hash to the same bucket, which causes the
firewall's lookup performance to change from O(1) to O(n), where n is firewall's lookup performance to change from O(1) to O(n), where n is
the number of flows the attacker can instantiate [18]. Thus the the number of flows the attacker can instantiate [18]. Thus the
attacker can cause forwarding performance to degrade to the point attacker can cause forwarding performance to degrade to the point
skipping to change at page 19, line 28 skipping to change at page 20, line 12
resources such as encryption or authentication keys. This in turn resources such as encryption or authentication keys. This in turn
can prevent access to other more critical services. can prevent access to other more critical services.
2.11 Physical DoS 2.11 Physical DoS
The discussion thus far has centered on denial-of-service attacks The discussion thus far has centered on denial-of-service attacks
perpetrated using the network. However, computer systems are only as perpetrated using the network. However, computer systems are only as
resilient as the weakest link. It may be easier to deny service by resilient as the weakest link. It may be easier to deny service by
causing a power failure, by cutting network cables, or by simply causing a power failure, by cutting network cables, or by simply
switching a system off, and so physical security is at least as switching a system off, and so physical security is at least as
important as network security. important as network security. Physical attacks can also serve as
entry points for non-physical DoS, for instance by reducing the
resources available to deal with overcapacity.
2.12 Social Engineering DoS 2.12 Social Engineering DoS
The weakest link may also be human. In defending against DoS, the The weakest link may also be human. In defending against DoS, the
possibility of denial-of-service through social engineering should possibility of denial-of-service through social engineering should
not be neglected, such as convincing an employee to make a not be neglected, such as convincing an employee to make a
configuration change that prevents normal operation. configuration change that prevents normal operation.
2.13 Legal DoS 2.13 Legal DoS
skipping to change at page 20, line 18 skipping to change at page 20, line 52
addresses of dial-up ISPs or mail servers used to originate or relay addresses of dial-up ISPs or mail servers used to originate or relay
spam are added to black-hole lists. The recipients of mail choose to spam are added to black-hole lists. The recipients of mail choose to
consult these lists and reject spam if it originates or is relayed by consult these lists and reject spam if it originates or is relayed by
systems on the list. One significant problem with such lists is that systems on the list. One significant problem with such lists is that
it may be possible for an attacker to cause a victim to be black-hole it may be possible for an attacker to cause a victim to be black-hole
listed, even if the victim was not responsible for relaying spam. listed, even if the victim was not responsible for relaying spam.
Thus the black-hole list itself can be a mechanism for effecting a Thus the black-hole list itself can be a mechanism for effecting a
DoS attack. Note that every black-hole list has its own policy DoS attack. Note that every black-hole list has its own policy
regarding additions, and some are less susceptible to this DoS attack regarding additions, and some are less susceptible to this DoS attack
than others. Consumers of black-hole list technology are advised to than others. Consumers of black-hole list technology are advised to
investigate these policies before they subscribe. investigate these policies before they subscribe. Similar
considerations apply to feeds of bad BGP bad route advertisements.
3. Attack Amplifiers 3. Attack Amplifiers
Many of the attacks described above rely on sending sufficient Many of the attacks described above rely on sending sufficient
traffic to overwhelm the victim. Such attacks are made much easier traffic to overwhelm the victim. Such attacks are made much easier
by the existence of "attack amplifiers", where an attacker can send by the existence of "attack amplifiers", where an attacker can send
traffic from the spoofed source address of the victim and cause traffic from the spoofed source address of the victim and cause
larger responses to be returned to the victim. A detailed discussion larger responses to be returned to the victim. A detailed discussion
of such reflection attacks can be found in [31]. of such reflection attacks can be found in [31].
skipping to change at page 24, line 7 skipping to change at page 25, line 7
o Proxies should not arbitrarily relay requests to destinations o Proxies should not arbitrarily relay requests to destinations
chosen by a client. chosen by a client.
o Avoid signaling third-party connections. Any unavoidable third- o Avoid signaling third-party connections. Any unavoidable third-
party connections setup by a signaling protocol should incorporate party connections setup by a signaling protocol should incorporate
lightweight validation before sending significant data. lightweight validation before sending significant data.
4. DoS Mitigation Strategies 4. DoS Mitigation Strategies
NOTE: This section is incomplete
A general problem with DoS defense is that it is not in principle A general problem with DoS defense is that it is not in principle
possible to distinguish between a flash-crowd and a DoS attack. possible to distinguish between a flash-crowd and a DoS attack.
Indeed, having your site taken down by a flash crowd is probably a Indeed, having your site taken down by a flash crowd is probably a
more common experience than having it DoS-ed --- so common it's more common experience than having it DoS-ed --- so common it's
acquired its own names: being Slashdotted or Farked, after the web acquired its own names: being Slashdotted or Farked, after the web
sites that are common sources of flash crowds. Thus, the first line sites that are common sources of flash crowds. Thus, the first line
of defense against DoS attacks must be to provision your service so of defense against DoS attacks must be to provision your service so
that it can handle a foreseeable legitimate peak load. that it can handle a foreseeable legitimate peak load.
Underprovisioned sites are the easiest to take down. Underprovisioned sites are the easiest to take down.
skipping to change at page 26, line 12 skipping to change at page 27, line 12
precise details should clearly be left to implementors, the protocol precise details should clearly be left to implementors, the protocol
design needs to give them the capability to do their job properly. design needs to give them the capability to do their job properly.
4.1.4 Autoconfiguration and Authentication 4.1.4 Autoconfiguration and Authentication
Autoconfiguration mechanisms greatly ease deployment, and are Autoconfiguration mechanisms greatly ease deployment, and are
increasingly necessary as the number of networked devices grows increasingly necessary as the number of networked devices grows
beyond what can be managed manually. However, it should be beyond what can be managed manually. However, it should be
recognised that unauthenticated autoconfiguration opens up many recognised that unauthenticated autoconfiguration opens up many
avenues for attack. There is a clear tension between ease of avenues for attack. There is a clear tension between ease of
configuration and security of configuration. Future configuration and security of configuration, especially because there
are environments in which it is desirable for units to operate with
effectively no authentication (e.g., airport hotspots). Future
autoconfiguration protocols should consider the need to allow autoconfiguration protocols should consider the need to allow
different end-systems to operate at different points in this spectrum different end-systems to operate at different points in this spectrum
within the same autoconfiguration framework. within the same autoconfiguration framework. However, this also
implies that the network elements should avoid acting for
unauthenticated hosts, instead just letting them access the network
more or less directly.
4.1.5 Network Design and Configuration 4.2 Network Design and Configuration
4.1.6 Redundancy and Distributed Service In general, networks should be provisioned with private, out-of-band
access to console or control ports so that such control facilities
will be available in the face of a DoS attack launched against either
the control or data plane of the (in-band) network. Typically such
out-of-band networks are provisioned on a separate infrastructure for
exactly this purpose. Out-of-band access is a crucial capability for
DoS mitigation, since many of the typical redundancy and capacity
management techniques (such as prioritizing routing or network
management traffic) fail during such attacks. In addition, many
redundancy protocols such as VRRP [RFC3768] can fail during such
attacks as they may be unable to keep adjacencies alive.
There are several default configuration settings that can also be
exploited to generate several of the attacks outlined in this
document. For example, some vendors may have features such as IP
redirect, directed broadcast, and proxy ARP enabled by default.
Similar defaults, such as publicly readable SNMP [RFC3411]
communities (e.g., "public") can be used to reveal otherwise
confidential information to a prospective attacker. Finally, other
unauthenticated configuration management protocols such as TFTP
[RFC1350] should be avoided if possible; at the very least access to
TFTP configuration archives should be protected and TFTP should be
filtered at administrative boundaries. Finally, since many of the
password encryption techniques used by router vendors are reversible,
keeping such passwords on a configuration archive (as part of a
configuration file), even in the encrypted form written by the
router, can lead to unauthorized access if the archive is
compromized.
4.2.1 Redundancy and Distributed Service
A basic principle of designing systems to handle failure to have A basic principle of designing systems to handle failure to have
redundant servers which can take over when one fails. This is redundant servers which can take over when one fails. This is
equally true in the case of DoS attacks, which often focus on a given equally true in the case of DoS attacks, which often focus on a given
server and/or link. If service delivery points can be distributed server and/or link. If service delivery points can be distributed
across the network, then it becomes much harder to attack the entire across the network, then it becomes much harder to attack the entire
service. In particular, this makes attacks on a single network link service. In particular, this makes attacks on a single network link
more difficult. more difficult.
4.1.7 Authenticate Routing Adjacencies 4.2.2 Authenticate Routing Adjacencies
In general, cryptographic authentication mechanisms are too costly to In general, cryptographic authentication mechanisms are too costly to
form the main part in DoS prevention. However, routing adjacencies form the main part in DoS prevention. However, routing adjacencies
are too important to risk an attacker being able to inject bad are too important to risk an attacker being able to inject bad
routing information, which can affect more than the router in routing information, which can affect more than the router in
question. Additional non-cryptographic mechanisms should then be question. Additional non-cryptographic mechanisms should then be
used to avoid arbitrary end-systems being able to cause the router to used to avoid arbitrary end-systems being able to cause the router to
spend CPU cycles on validating authentication data. spend CPU cycles on validating authentication data.
For BGP, at the very least, this implies the use of TCP MD5 [24] or For BGP, at the very least, this implies the use of TCP MD5 [24] or
IPsec authentication, combined with the TTL 255 hack [23] to prevent IPsec authentication, combined with the GTSM [23] to prevent EBGP
EBGP association with non-immediate neighbours. In future, this will association with non-immediate neighbours. In future, this will
likely imply better authentication of the routing information itself. likely imply better authentication of the routing information itself.
4.1.8 Isolate Router-to-Router Traffic 4.2.3 Isolate Router-to-Router Traffic
As far as is feasible, router-to-router traffic should be isolated As far as is feasible, router-to-router traffic should be isolated
from data traffic. How this should be implemented depends on the from data traffic. How this should be implemented depends on the
precise technologies available, both in the router and at the link- precise technologies available, both in the router and at the link-
layer. The goal should be that failure of the link for data traffic layer. The goal should be that failure of the link for data traffic
should also cause failure for the routing traffic, but that an should also cause failure for the routing traffic, but that an
attacker cannot directly send packets to the control processor of the attacker cannot directly send packets to the control processor of the
routers. routers.
A downside of this is that some diagnostic techniques (such as A downside of this is that some diagnostic techniques (such as
pinging consecutive routers to find the source of a delay) may no pinging consecutive routers to find the source of a delay) may no
longer be possible. Ideally, alternative mechanisms (which do not longer be possible. Ideally, alternative mechanisms (which do not
open up additional avenues for DoS) should be designed to replace open up additional avenues for DoS) should be designed to replace
such lost techniques. such lost techniques.
4.2 Router Implementation Issues 4.3 Router Implementation Issues
4.3 End-System Implementation Issues Because a router can be considered as an end-system, it can
potentially benefit from all the prevention mechanisms prescribed for
end-system implementation. However one basic distinction between a
router and a host is that the former implements routing protocols and
forwards data, which in turn lead to additional router specific
implementation considerations. The issues described below are meant
to be illustrative and not exhaustive.
4.3.1 State Lookup Complexity 4.3.1 Checking Protocol Syntax and Semantics
Protocol syntax defines the formation of the protocol messages and
the rules of exchanges. The questions addressed by protocol syntax
checking includes, but is not limited to, the following:
1. Who sent the message?
2. Does the content conform to the protocol format?
3. Was the message sent with correct timing?
The first step in protocol syntax verification is to ensure that an
incoming message was sent by a legitimate party. There are multiple
ways to perform this check. One can verify the source IP address and
even the MAC address of the message. Utilizing the fact that eBGP
peers are normally directly connected, one can also check the TTL
value in a packet and discard any BGP updates packet whose TTL is
less than some maximum value (typically max TTL - 1) [23].
Cryptographic authentication should also be used whenever available
to verify that an incoming message is indeed from an expected sender.
For BGP, at the very least, this implies the use of TCP MD5 [24] or
IPsec authentication.
In addition to the sender verification, it is also important to check
the syntax of a received routing message, as opposed to assuming that
all messages came in a correct format. It happened in the past that
routers crashed upon receiving ill-formed routing messages. Such
faults will be prevented by performing rigorous syntax checking.
4.3.2 Consistency Checks
Protocol semantics defines the meaning of the message content, the
interpretation of the values, and the actions to be taken according
to the content. Here is a simple example of using semantic checking.
When a link failure causes a router in AS A to send a peer router B a
withdrawal message for prefix P, B should make sure that any
alternative path it finds to reach P does not go through A. This
simple check is shown to significantly improve BGP convergence time
in many cases [45].
Another example of using semantic checking against false routing
injection is described in [47]. The basic idea is to attach to the
route announcement for prefix P a list of the valid origin ASes. Due
to the rich connectivity in today's Internet topology, a remote AS
will receive routing updates from multiple different paths and can
check to see whether each update carries the identical origin AS
list. Although a false origin may announce reachability to P, or
alter the origin AS list, it would be difficult, if not impossible,
to block the correct updates from propagating out, thus remote ASes
can detect the existence of false updates by observing the
inconsistency of the received origin AS lists for P. Research studies
show that the "allowed origin list" test can effectively detect
majority of falsely originated updates.
Generally speaking, verifying the validity of BGP routes can be
challenging because BGP is policy driven and policies of individual
ISPs are not known in most cases. But assuming policies do not
change in short time scale, in principle one could verify new updates
against observed routes from recent past, which reflect the routing
policies in place. Research work is needed to explore this
direction.
Note that while the above steps are all fairly simple and don't
really "bullet-proof" the protocol, each adds some degree of
protection. As such, the combination of the above techniques can
result in an efffective reduction in the probability of undetected
faults.
4.3.3 Enhance Router Robustness through Operational Adjustments
There exist a number of configuration tunings that can enhance
robustness of BGP operations. One example is to let BGP peers
coordinate the setting of a limit on the number of prefixes which one
BGP speaker will send to its peer [46]. Although such check does not
validate the prefix owned by each peer, it can prevent false
announcements of large number of invalid routes. Had all BGP routers
been configured with this simple checking earlier, several large
scale routing outages in the past could have been prevented. Note,
however, that care must be taken with hard limits of this type
because they can be used to mount a DoS because implementations often
discard excess routes indiscriminately, thus potentially causing
black-holing of correct routes.
Another example of useful configuration tuning is to adjust the BGP's
KeepAlive and Hold Timer values to minimize BGP peering session
resets. Previous measurements show that heavy traffic load, such as
those caused by Worms, can cause BGP KeepAlive messages to be delayed
or dropped, which in turn cause BGP peering session break down. Such
load induced session breaks and re-establishments can lead to
excessive amount of BGP updates during the periods when stable
routing is mostly needed.
4.3.4 Proper Handling of Router Resource Exhaustion
In addition to the resource exhaustion problems that are generally
apply to all end systems, as described in Section 2, router
implementations must also take special care in handling resource
exhaustions when they occur in order to keep the router operating
despite the problem. For example under normal operations a router
does not require a large cache to hold outstanding ARP requests
because the replies are normally received within a few milliseconds.
However certain conditions can lead to ARP cache exhaustion, for
example during a virus attack where many packets are sent to non-
existing IP addresses, thus there are no ARP replies to the requests
for those addresses. Such phenomenon happened in the past and led to
routers stop packet forwarding.
Routers collectively operate as the brain of the Internet. Thus a
smooth functioning of all the routers is vitally important. Our goal
is to minimize routers' load on the control plane and maximize the
correctness of routing protocol operations.
4.4 End-System Implementation Issues
4.4.1 State Lookup Complexity
Any system that instantiates per-connection state should take great Any system that instantiates per-connection state should take great
care to implement the state-lookup mechanisms in such a way that care to implement the state-lookup mechanisms in such a way that
performance can not be controlled by the attacker. One way to performance can not be controlled by the attacker. One way to
achieve this is to use hash-tables where the hash mechanism is keyed achieve this is to use hash-tables where the hash mechanism is keyed
in such a way that the attacker cannot instantiate a large number of in such a way that the attacker cannot instantiate a large number of
flows in the same hash bucket. flows in the same hash bucket.
4.3.1.1 Avoid Livelock 4.4.1.1 Avoid Livelock
Most operating systems use network interrupts to receive data from Most operating systems use network interrupts to receive data from
the network, which is a good solution if the host spends only a small the network, which is a good solution if the host spends only a small
amount of its time handling network traffic. However, this leaves amount of its time handling network traffic. However, this leaves
the host open to livelock [29], where under heavy load the OS spends the host open to livelock [29], where under heavy load the OS spends
all its time handling interrupts and no time doing the work needed to all its time handling interrupts and no time doing the work needed to
handle the traffic at the application level. Server operating handle the traffic at the application level. Server operating
systems should consider using network polling at times of heavy load, systems should consider using network polling at times of heavy load,
rather that being interrupt-driven, and should be carefully rather that being interrupt-driven, and should be carefully
architected so that as far as reasonably possible, traffic received architected so that as far as reasonably possible, traffic received
by the OS is processed to completion, or very cheaply discarded. by the OS is processed to completion, or very cheaply discarded.
4.3.1.2 Use Unpredictable Values for Session IDs 4.4.1.2 Use Unpredictable Values for Session IDs
Most recent TCP implementations use fairly good random mechanisms for Most recent TCP implementations use fairly good random mechanisms for
allocating the TCP initial sequence numbers. In general, any allocating the TCP initial sequence numbers. In general, any
dynamically allocated value used purely to identify a communications dynamically allocated value used purely to identify a communications
session should be allocated using an unpredictable mechanism, as this session should be allocated using an unpredictable mechanism, as this
increases the search space for an attacker that wishes to disrupt increases the search space for an attacker that wishes to disrupt
ongoing communications. Thus the dynamically allocated port of the ongoing communications. Thus the dynamically allocated port of the
active end of a TCP connection might also be randomly allocated. active end of a TCP connection might also be randomly allocated.
With DNS, the ID which is used to match responses with requests With DNS, the ID which is used to match responses with requests
should also be randomly generated. However, as the ID field is only should also be randomly generated. However, as the ID field is only
16 bits, the protection is rather limited, especially in the face of 16 bits, the protection is rather limited, especially in the face of
birthday attacks. birthday attacks.
4.3.2 Operational Issues 4.4.2 Operational Issues
4.3.2.1 Eliminate Bad Traffic Early 4.4.2.1 Eliminate Bad Traffic Early
Many DoS attacks are generic bandwidth consumption attacks that Many DoS attacks are generic bandwidth consumption attacks that
operate by clogging the link that connects the victim server to the operate by clogging the link that connects the victim server to the
Internet. Filtering these attacks at the server does no good because Internet. Filtering these attacks at the server does no good because
the traffic has already traversed the link which is the scarce the traffic has already traversed the link which is the scarce
resource. Such flows need to be filtered at some point closer to the resource. Such flows need to be filtered at some point closer to the
attacker. Where possible, operators should filter out obviously bad attacker. Where possible, operators should filter out obviously bad
traffic. In particular, they should perform ingress filtering [22]. traffic. In particular, they should perform ingress filtering [22].
4.3.2.2 Establish a Monitoring Framework 4.4.2.2 Establish a Monitoring Framework
Network operators are strongly encouraged to establish a monitoring Network operators are strongly encouraged to establish a monitoring
framework to detect and log abnormal network activity. One can not framework to detect and log abnormal network activity. One can not
defend against an attack one doesn't detect or understand. Such defend against an attack one doesn't detect or understand. Such
monitoring tools can be used to set a baseline of "normal" traffic, monitoring tools can be used to set a baseline of "normal" traffic,
and can be used to determine: and can be used to determine:
o Aberrant flows. o Aberrant flows.
o Type and source of the aberrant flows o Type and source of the aberrant flows
skipping to change at page 33, line 34 skipping to change at page 37, line 34
[21] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. [21] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M.
Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol
Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification",
RFC 2362, June 1998. RFC 2362, June 1998.
[22] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating [22] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address Spoofing", Denial of Service Attacks which employ IP Source Address Spoofing",
RFC 2827, May 2000. RFC 2827, May 2000.
[23] V. Gill, J. Heasley, D. Meyer, "The BGP TTL Security Hack [23] V. Gill, J. Heasley, D. Meyer "The Generalized TTL Security
(BTSH)", draft-gill-btsh-02.txt (work in progress), 29-May-03. Mechanism (GTSM)", RFC 3682, February 2004.
[24] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 [24] A. Heffernan, "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[25] Laurent Joncheray, "Simple Active Attack Against TCP", 5th [25] Laurent Joncheray, "Simple Active Attack Against TCP", 5th
USENIX Security Symposium, 1995. USENIX Security Symposium, 1995.
[26] M. Lough, "A Taxonomy of Computer Attacks with Applications to [26] M. Lough, "A Taxonomy of Computer Attacks with Applications to
Wireless", PhD thesis, Virginia Polytechnic Institute, April 2001. Wireless", PhD thesis, Virginia Polytechnic Institute, April 2001.
skipping to change at page 35, line 5 skipping to change at page 38, line 52
[40] M. Zalewski, "Strange Attractors and TCP/IP Sequence Number [40] M. Zalewski, "Strange Attractors and TCP/IP Sequence Number
Analysis", http://razor.bindview.com/publish/papers/tcpseq.html Analysis", http://razor.bindview.com/publish/papers/tcpseq.html
[41] J. Bellardo and S. Savage, "802.11 Denial-of-Service Attacks: [41] J. Bellardo and S. Savage, "802.11 Denial-of-Service Attacks:
Real Vulnerabilities and Practical Solutions", Proceedings of the Real Vulnerabilities and Practical Solutions", Proceedings of the
12th USENIX Security Symposium, August 2003. 12th USENIX Security Symposium, August 2003.
[42] L. von Ahn, M. Blum, N. Hopper, and J. Langford. CAPTCHA: Using [42] L. von Ahn, M. Blum, N. Hopper, and J. Langford. CAPTCHA: Using
hard AI problems for security. In Proceedings of Eurocrypt, 2003. hard AI problems for security. In Proceedings of Eurocrypt, 2003.
[43] The whole world disappeared? http://www.merit.edu/mail.archives/
nanog/1998-04/msg00181.html, Apr 1998.
[44] Outage: MCI Worldcom nationwide ATM network.
http://www.merit.edu/ mail.archives/nanog/1999-02/msg00077.html, Feb
1999.
[45] D. Pei, X. Zhao, L. Wang, D. Massey, A. Mankin, F. S. Wu, and L.
Zhang. Improving BGP Conver-gence Through Assertions Approach. In
Proc. of IEEE INFOCOM, June 2002.
[46] Srikanth Chavali, Vasile Radoaca, Mo Miri, Luyuan Fang, and
Susan Hares. Peer prefix limits ex-change in bgp. http://
www.ietf.org/internet-drafts/draft-chavali-bgp-prefixlimit-01.txt,
April 2004.
[47] X. Zhao, D. Massey, A. Mankin, S.F. Wu, D. Pei, L. Wang, L.
Zhang, "BGP Multiple Origin AS (MOAS) Conflicts",
http://nanog.org/mtg-0110/lixia.html, 2001.
Authors' Addresses Authors' Addresses
Mark J. Handley (ed) Mark J. Handley (ed)
UCL UCL
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
UK UK
Email: M.Handley@cs.ucl.uk Email: M.Handley@cs.ucl.ac.uk
Eric Rescorla (ed) Eric Rescorla (ed)
Network Resonance Network Resonance
2483 E. Bayshore #212 2483 E. Bayshore #212
Palo Alto 94303 Palo Alto 94303
USA USA
Email: ekr@networkresonance.com Email: ekr@networkresonance.com
Appendix A. IAB Members at the time of this writing Appendix A. IAB Members at the time of this writing
 End of changes. 39 change blocks. 
102 lines changed or deleted 314 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/