INTERNET-DRAFT Kathleen M. Moriarty
draft-moriarty-ddos-rid-03.txt MIT Lincoln Laboratory
Expires: August 10, 2003 February 10, 2003
Distributed Denial of Service Incident Handling:
Real-Time Inter-Network Defense
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
One of the latest trends attacking Internet security is the
increasing prevalence of Denial of Service (DoS) attacks. DoS
attacks target system and/or network resources and seek to
prevent valid access by consuming resources. Network
Providers (NP) need to be equipped and ready to assist in
tracing security incidents with tools and procedures in place
before the occurrence of an attack. This paper proposes a
proactive inter-network communication method to integrate existing
tracing mechanisms across NP boundaries to identify the source(s)
of an attack. The various methods implemented to trace attacks must
be coordinated both on the NPs network as well as provide a
communication mechanism across network borders. It is imperative
that NPs have quick communication methods defined to enable
neighboring NPs to assist in tracking a security incident across
the Internet. This proposal makes use of current tracing practices
for traffic and performance management, which could be extended
for DoS incident handling. Policy guidelines for handling these
incidents are recommended and can be used by NPs and extended to
their clients in conjunction with the technical recommendations.
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
TABLE OF CONTENTS
Status of this Memo ................................................ 1
Abstract ........................................................... 1
1.0 Introduction ............................................... 3
1.1 Overview of Attack Types ................................... 4
2.0 Recommended Network Provider (NP) Technologies ............. 5
3.0 Characteristics of Attacks ................................. 6
3.1 Tracing a Single Source Attack with Filters ................ 8
3.2 Tracing a Distributed attack ............................... 9
3.3 Trace Approaches ........................................... 10
3.3.1 Trace approach via Traffic Flow Analysis ............. 10
3.3.2 Trace Approach via Hash-Based IP Traceback ........... 13
3.4 Correlating Collected Data ................................. 14
4.0 Communication Between Network Providers .................... 15
4.1 Inter-Network Provider RID-DoS Messaging ................... 17
4.2 Message Formats ............................................ 18
4.2.1 Trace Request ........................................ 18
4.2.2 Trace Authorization Message .......................... 19
4.2.3 Source Found Message ................................. 20
4.2.4 Example Upstream Trace ............................... 21
4.3 Message Structure: ......................................... 22
4.4 Message Delivery Protocol - Integrity and Authentication ... 24
4.4.1 Transport Communication .............................. 25
4.4.2 Authentication of RID-DoS protocol ................... 25
4.4.3 Authentication Considerations for a Multi-hop Trace Request 26
4.4.4 Privacy Concerns ..................................... 27
5.0 Security Considerations .................................... 28
6.0 Summary .................................................... 29
7.0 References ................................................. 30
8.1 Acknowledgements ........................................... 32
8.2 Author Information ......................................... 32
Moriarty Expires: August 10, 2003 [Page 2]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
1.0 Introduction
Incident handling involves the identification of the source of an
attack, whether it be a system compromise or a denial of service
attack. In order to identify the source of an attack, there must
be a way to trace the attack traffic iteratively upstream through
the network to the source. In cases where an active session
between the compromised system and the attacker or source system is
available, the source is easy to identify as in the case of attacks
where the source address was not spoofed and sufficient evidence is
left behind. The problem of tracing incidents becomes more
difficult when the source is obscured or spoofed, logs are deleted,
and the number of sources are overwhelming.
Current approaches to mitigating the effects of security incidents,
DoS, and DDoS attacks are aimed at identifying and filtering or
rate limiting packets from attackers who seek to hide the origin of
their attack by source address spoofing from multiple locations.
Measures can be taken at network provider (NP) border routers
providing ingress, egress, and broadcast filtering as a recommended
best practice in RFC2827. These filters ensure that traffic
leaving and entering client locations contains valid source and
destination addresses.
Network providers have devised solutions to trace attacks across
their backbone infrastructure to either identify the source on
their network or the next upstream network in the path to the
source. Many of the single network tracing mechanisms have been
developed as in-house solutions and are specific to the network
that is traced. Techniques such as collecting packets as traffic
traverses the network have been implemented to provide the
capability to trace attack traffic after an incident has occurred.
Other methods use flow based traffic analysis to trace traffic
across the network in real time. The single network trace
mechanisms use similar information across the individual networks
to trace traffic, but encounter problems when they attempt to have
a trace continued through the next upstream network.
In the case where the traffic traverses multiple networks, there is
currently no established communication mechanism to provide the
ability to continue the trace. If the next upstream network has
been identified, a phone call might be placed to contact the
network administrators in hopes to have them continue the trace.
A communication mechanism is needed to facilitate the transfer of
information needed in order to continue traces accurately and
efficiently to upstream networks. The communication mechanism
described in this paper takes into consideration the information
needed by various single network trace implementations and the
needs of network providers to have the ability to decide if a trace
request should be permitted to continue. Finally, methods are
incorporated into the communication system to indicate what actions
were taken to cease or mitigate the effects of the attack at hand.
Moriarty Expires: August 10, 2003 [Page 3]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
1.1 Overview of Attack Types
The CERT Coordination Center published a paper in October, 2001
entitled, "Trends in Denial of Service Attack Technology"[6]. The
paper outlined the behavior of Denial of Service attacks of both
single-source and multiple-source origins. Denial of Service (DoS)
attacks attempt to consume bandwidth, processing power, or system
resources for the purposes of denying use by normal users.
Bandwidth-based attacks flood systems with TCP, UDP or ICMP
packets. Bandwidth or processing power based attacks may use
variations on these packets, such as altering the source address,
port numbers, or TCP options.
Many attacks types including various DoS attacks and system
compromise use tactics such as altering port numbers to enable
packets to bypass packet filters. Other approaches are to use
packets, which are targeting valid services hosted by the network
since they must be permitted and the attack traffic cannot be
deciphered from valid network traffic.
In bandwidth based DoS attacks, tactics including altering the
source address as in the case of an ICMP attack where packets are
sent through a site with the IP direct broadcast option enabled on
the site's router. The IP directed broadcast would amplify the
number of packets sent to the victim, thus flooding the network and
consuming bandwidth.
Another type of DoS attack is aimed at consuming system resources,
as in the SYN flood attack. A SYN flood attack is a TCP attack
where the initiator of the attack begins the TCP handshake sequence
by sending a SYN packet to the destination server of the attack
with a spoofed source address. The server responds with an
acknowledgement of the SYN packet, but the response packet is sent
to the spoofed source address, which does not accept the unexpected
acknowledgment packet. This leaves the connection open on the
server and consumes system resources. There are a limited number
of connections a server can maintain, and once this limit is
reached, valid connections are denied. This is just one example of
a class of attacks targeting a single system or service to prevent
valid traffic from accessing the system.
DoS attacks are characterized by large amounts of traffic destined
for particular Internet locations and can originate from a single
or multiple sources. An attack from multiple sources is known as a
Distributed Denial of Service attack (DDoS). Because DDoS attacks
can originate from multiple sources, tracing such an attack can be
extremely difficult or nearly impossible. These attacks can be
launched from systems across the Internet unified in their efforts
or by compromised systems enlisted as 'zombies' that are controlled
by servers, thereby providing anonymity to the controlling server
Moriarty Expires: August 10, 2003 [Page 4]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
of the attack. DDoS attacks do not necessarily spoof the source of
an attack since there are a large number of source addresses, which
make it difficult to trace anyway. DDoS attacks can also originate
from a single system or a subset of systems that spoof the source
address in packet headers in order to mask the identity of the
attack source.
Compromising a system can be accomplished through one of many
attack vectors, using various techniques from a remote host or
through a local privilege escalation attempts. The attack may
exploit a system or application level vulnerability that may be the
result of a design flaw or a configuration issue. A compromised
system, as described above, can be used to later attack other
systems. The subsequent attacks may be targeted systems or an
attempt to recruit zombies to later be used in DoS or DDoS attacks.
Identifying the sources of system compromises may also be difficult
since an attacker may access the compromised system from various
sources. The attacker may also take measures to hide their tracks
by deleting log files or by accessing the system through a series
of compromised hosts.
2.0 Recommended Network Provider (NP) Technologies
For the purpose of this document, a network provider (NP) shall be
defined as a backbone infrastructure manager of a network. The
backbone may be that of an organization providing network (Internet
or private) access to commercial, personal, government, and
educational institutions or the backbone provider of the connected
network. The connected network provider is an extension meant to
include Intranet and Extranet providers as well as instances such
as a business or educational institute's, (etc.) private network.
NPs typically manage and monitor their networks through a
centralized network management system (NMS). This system usually
performs trend analysis for bandwidth utilization and reports
communication problems. As a part of the bandwidth trend analysis
performed, denial of service traffic or unusually unexpected
increases in bandwidth could also be reported. With the capability
of seeing the entire network under management, the NMS could be
utilized to trace to the origin of network traffic within its own
network. NPs could become proactive in handling denial of service
attacks through the use of tools already in existence on their
networks. If trend analysis is not already being performed for
bandwidth utilization, this may require the use of an additional
server to perform this function. Such a server would need to
account for traffic redirection events resulting in bandwidth
fluctuations due to networking problems in other areas of an NP's
backbone. Ideally, this system would have the ability to perform a
trend analysis on the network to determine if there was an
unusually large increase in traffic without explanation, such as a
network event elsewhere on the backbone. Client events, such as
the launch of a new web site or streaming video of a noteworthy
Moriarty Expires: August 10, 2003 [Page 5]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
news event should be programmable exceptions to the alert. Once it
can be determined that the event may be significant, a trace back
for the source of the increased traffic should be performed through
analysis on the neighboring connections on the network. If
possible, the trace may need to inspect packets to determine a
pattern, which could assist reverse path identification. This may
be accomplished by inspecting packet header information such as the
source and destination IP addresses, ports, and protocol flags to
determine if there is a way to distinguish them from other packets.
A description of the incident along with any available automated
trace data should trigger an alert to the NPs security team for
further investigation.
The proactive monitoring for bandwidth related attacks could use
trending analysis as a guideline to determine acceptable levels of
traffic across the network. Unexplained and extended spikes in
traffic would be a signal that a DoS attack may be in progress.
Resource related attacks would be more difficult to detect because
the effects of resource exhaustion are not readily apparent in
network traffic. Methods such as trending the packet size of
traffic to and from networks may be an indicator of this type of
attack. For example, if there is a large increase in small packets
sent to and from a network, that may be an indicator of a SYN flood
attack. TCP connections begin with small packets, but the session
data over the established connection may be a mixture of large and
small packets. A change in the size of packets to or from a
network or host may be an indicator of a DoS attack using different
types of traffic than normally seen in the monitored network.
3.0 Characteristics of Attacks
The goal of tracing a security incident may be to identify the
source or to find a point on the network as close to the origin of
the incident as possible. A security incident may be defined as a
system compromise, a worm or Trojan infection, or a single or
multiple source denial of service attack. Incident tracing can be
used to identify the source(s) of an attack in order to cease or
mitigate the undesired behavior. The communication system,
RID-DoS, described in this paper can be used to trace any type of
security incident and allows for actions to be taken when the
source of the attack or a point closer to the source has been
identified. The purpose of tracing an attack would be to cease or
mitigate the affects of the attack through methods such as
filtering or rate limiting the traffic close to the source or
by using methods such as taking the host or network offline.
Tracing security incidents can be a difficult task since attackers
go to great lengths to obscure their identity. In the case of a
security incident, the true source might be identified due to an
existing established connection to the attackers point of origin.
However, the attacker may not connect to the compromised system for
Moriarty Expires: August 10, 2003 [Page 6]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
a long period of time after the initial compromise or may access
the system through a series of compromised hosts spread across the
network. Other methods of obscuring the source may include
targeting the host with the same attack from multiple sources using
both valid and spoofed source addresses. This tactic can be used
to compromise a machine and leave a difficult task of locating the
true origin for the administrators. DDoS attacks are also
difficult or nearly impossible to trace because of the nature of
the attack. Some of the difficulties in tracing these attacks
include:
O the attack originates from multiple sources,
O the attack may include various types of traffic meant to consume
server resources, such as a SYN flood attack without a significant
increase in bandwidth utilization,
O the type of traffic could include valid destination services,
which cannot be blocked since they are essential services to
business, such as DNS servers at an NP or HTTP requests sent to an
organization connected to the Internet,
O the attack may utilize varying types of packets including TCP,
UDP, ICMP, or other IP protocols.
O the attack may use a very small number of packets from any
particular source, thus making a trace after the fact nearly
impossible.
If the source(s) of the attack cannot be determined from tracing
the increased bandwidth utilization, it may be possible to trace
the traffic based on the type of packets seen by the client. In
the case of packets with spoofed source addresses, it is no longer
a trivial task to identify the source of an attack. In the case of
an attack using valid source addresses, methods such as the
traceroute utility can be used to fairly accurately identify the
path of the traffic between the source and destination of an
attack. This paper discusses methods that can be used to trace
back to the source of an attack, in particular when the source
address has been spoofed. The methods include packet filtering,
packet hash comparisons, and packet flow analysis.
Moriarty Expires: August 10, 2003 [Page 7]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
3.1 Tracing a Single Source Attack with Filters
In 1997, the MCI Security team wrote DoSTrack [2], a program
used to trace back through a network in order to identify the
origin of a single-source DoS attack, such as the SYN flood attack.
The program started its tracing efforts at the NP border router for
a client under attack and determined if the neighboring router was
witnessing the attack. If the router was passing the attack
traffic, DoSTrack would then identify the interface on a Cisco
router from which the traffic was originating. Once the next hop
was identified, DosTrack would log into the next router in the
upstream path of the attack traffic and set a filter to monitor
for the traffic. If the router did not see the attack traffic,
DoSTrack would stop its tracing efforts at that router. If the
attack traffic were seen, it would continue tracing until the
source of the traffic or a bordering NP was identified. The
traces were performed through the use of access control filters
implemented on each router in the upstream path of the traffic.
The filters were used to permit the suspicious traffic and then log
the packet information, including the source interface on the
router that the packet used to identify the next hop. DoSTrack has
several drawbacks. Router access control lists and logging are
both resource intensive operations. The additional resources
required to implement filters across a network are not available
at many NPs. In many cases NPs maintain routers close to maximum
capacity for normal operation, making it unfeasible to implement
the type of filtering required by DoSTrack. CenterTrack [2] was
an improvement on DoSTrack eliminating the need for filtering in
the center of the network, however, it is still taxing on router
resources and lacks the ability for Inter-network communication.
This approach could help identify the source of an attack, but a
less resource intensive approach is needed for many NPs.
Several other limitations include:
O DosTrack was primarily used for tracing Denial of Service attacks
from a single-source, thus the solution would not scale to trace
a multiple-source attack.
O DosTrack was written specifically for Cisco routers. Other
vendors, for example high-end routers used in multi-gigabit
networks, may not even provide similar filtering options.
O The DoSTrack program can only be used within a single NP's
backbone because of access capabilities to neighboring network's
equipment.
A solution to address attacks of a distributed nature, crossing
multiple network backbones, and various network equipment is
needed. The approach should consider the resource limitations of
a wide range of Network Providers, with various types of equipment.
Moriarty Expires: August 10, 2003 [Page 8]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
3.2 Tracing a Distributed attack
Tracing a DDoS attack is a very difficult problem. Since DDoS
attacks may involve multiple sources with spoofed addresses, there
may only be a small amount of traffic from each of the originating
hosts. This makes it difficult to trace back to the sources. The
sources may also alternate the type of traffic and the master may
vary the sources from within the pool of sources launching the
attack. Because of the dynamic nature of the DDos attack,
immediate action would need to be taken to have any hope of
locating the origin(s) of the attack with a near real-time trace.
In order to identify a DoS attack or DDoS, a client may notify its
NP that it is currently under attack. Automated methods might
include statistical traffic analysis, which looks for
unexpected fluctuations in bandwidth or in the size and types of
packets sent between networks or hosts. There is
on-going research in the area of detecting DoS and DDoS, and any
effective techniques could be integrated with the tracing
techniques described in this paper. Current research approaches
range from methods that detect backscatter traffic [3], using
a data structure for bandwidth attack detection [4], and monitoring
congestion through packet retransmission information [5]. Another
detection method may include monitoring any changes in the size of
packets sent to and from a network. For example, if a site that
normally receives small packets and replies with large packets
experiences a change in traffic pattern such as the sending and
receiving of large amounts of either small or large packets, this
could indicate a DoS attack.
Once an attack has been detected through traffic analysis and
bandwidth usage statistics, traces would have to quickly identify
the various sources of the attack. Once an attack is detected, a
generalized approach to tracing back connections might include the
inspection of packet header information such as the destination IP
address and any distinguishing header values of the traffic seen
by the site during the attack.
If a trace can identify the sources of a distributed attack,
blocking the sources at the NP level close to the attacker could
be an immediate action to stopping the attack. In the case of a
DDoS attack, further information may be obtained from the attacking
computers as to the controller of the attack sending the 'zombies'
control information to carry out the attack. This additional trace
is beyond the scope of this paper, but may use additional tracing
mechanisms such as sniffing the network to locate the controllers
of the attack.
Finding a faster and more efficient way to trace multiple sources
of an attack is essential to combating DDoS attacks. The ability
to quickly relay and act upon the trace information gathered is
imperative to stopping DDoS attacks. Tracing multiple attack paths
Moriarty Expires: August 10, 2003 [Page 9]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
can also cause additional stress on the network and does not scale
well.
3.3 Trace Approaches
There have been many separate research initiatives to solve the
problem of tracing upstream packets to detect the true source of
attack traffic. Upstream packet tracing is currently confined to
the borders of a network or a NP's network. Traces require access
to network equipment and resources, which limit a trace to a
specific network. Once a trace reaches the boundaries of a
network, the network manager or NP adjacent in the upstream trace
must be contacted in order to continue the trace. NPs have been
working on individual solutions to accomplish upstream tracing
within their own network environment. The tracing mechanisms
implemented thus far have included proprietary solutions requiring
specific information such as IP packet header data or hash values
of the attack packets in the case of the 'Hash Based IP
Traceback'[8]. Other research solutions involve marking packets as
explained in 'ICMP Traceback Messages'[10] and 'Practical Support
for IP Traceback' [9]. The following sections outline some
available solutions for implementing traceback within the confines
of a network managed by a single entity. Later in the paper the
focus will be on the information needed to accomplish the trace and
to make possible the Inter-NP communication specified.
3.3.1 Trace approach via Traffic Flow Analysis
Traffic flow analysis is used to monitor individual network traffic
streams, such as a single TCP session beginning with the SYN packet
and ending with the final FIN ACK in a session. There have been a
few efforts to standardize flow analysis for network management,
one through the traffic flow management MIB and another through
Cisco's NetFlow. The 'Traffic Flow Management' RFC [RFC2720] was
Designed to provide management information such as behavior models,
Capacity planning, network performance, quality of service, and
Attribution of network usage to system administrators. NetFlow
from Cisco [7] provides similar capabilities to the traffic flow
mib, except that it is specific to IP traffic and has already been
implemented for traffic management in Cisco equipment. Although
NetFlow was developed by Cisco, it is also an open standard. The
flow analysis in both implementations can monitor with a capture
filter on source and destination addresses, the number of packets
and the count of bytes in each flow, the originating interface of
the traffic, and the upstream peer information. The upstream peer
information is essential to tracing a spoofed packet back to the
true origin. During a DoS, the destination IP address and port
information could be used to detect the event while the source
information could be used to trace the path to the origin of the
attack. The packet and byte count variables keep a count of the
packets in the bi-directional flow as well as the number of octets
in a flow. This information could be correlated and used in
Moriarty Expires: August 10, 2003 [Page 10]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
network analysis for attack detection.
There are several differences in the implementations and the
monitor and capture capabilities of the two flow analysis
implementations. NetFlow collects all packets and maintains the
following information on packet flows for later analysis:
O Source and destination IP address
O Source and destination TCP/User Datagram Protocol (UDP) ports
O Type of service (ToS)
O Packet and byte counts
O Start and end timestamps
O Input and output interface numbers
O TCP flags and encapsulated protocol (TCP/UDP)
O Routing information (next-hop address, source autonomous system
(AS) number, destination AS number, source prefix mask,
destination prefix mask)
The flow management in RFC2720 is based on an SNMP mib extension.
The monitoring device in the network uses a capture filter to
determine what packets should be buffered until retrieved by a
central monitoring system. The capture filter or monitoring
information can include source and destination information for
various protocols, a start and end time for the packet flows,
packet count and byte information for the flow, as well as detailed
address information for the source and destination of the flow.
RFC2720 has not been implemented widely and may not be a feasible
option for flow analysis at this point in time.
NetFlow is based specifically on IP flow analysis. In addition to
filtering on IP address information, NetFlow also looks into TCP
and UDP header for port and flag information, which
can be very useful in tracing attack traffic. NetFlow also
provides detailed peer information such as the source interface of
the flow through a router and routing information such as the next
hop and the Autonomous System (AS) peer information.
In either case, the structures defined for traffic flow management
could be extended for use in tracing DoS or DDoS incidents. The
traffic flow management information could first be used in trend
analysis of network behavior in order to detect anomalies such as
bandwidth fluctuations or variations in the types of packet flows.
An NP's central management station could be used to coordinate a
trace of suspicious network traffic and may also be responsible for
the traffic flow analysis of data gathered via devices on the
network running the traffic flow captures. The monitoring devices
could be existing network equipment or promiscuous listening
devices. In order to expedite the trace(s) of an attack, pre-
defined filters can be used to quickly trace traffic as described
in the traffic flow management specifications. A pre-defined
filter might generically capture all TCP port 23 traffic, but
Moriarty Expires: August 10, 2003 [Page 11]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
would require a custom filter to include destination address
information.
An SNMP approach using the Traffic Flow MIB or the NetFlow approach
to detect DDoS may help to reduce the necessary resources used by
network routers when compared to a filter based approach. The
traffic flow MIB was designed to be used for network performance
measurement and takes into consideration system resources in the
implementation. A coordinated SNMP approach can provide the
dynamic framework necessary for tracing attacks in near real-time
because a central management station would control trace attempts
and quickly move through the network identifying the source of an
attack. A similar system might be used to alter capture filters
through a network using NetFlow or a similar technology to trace
attack traffic. The design of NetFlow also sought to reduce the
necessary resources consumed in existing network equipment.
Options to offload the resources to promiscuous devices aids in the
reduction of resource utilization of backbone equipment. Flow
analysis for DDoS attacks would be performed on potentially
congested network segments where router resources may be
dangerously low. Using promiscuous devices may be the only
feasible answer without impacting the network further to perform a
trace.
NetFlow differs from the flow mib in its collection method.
NetFlow uses an export model to collect information from monitoring
devices. The devices periodically send flow information to a
predefined FlowCollector via UDP packets. The data is sent to the
FlowCollector when a flow has completed or when the flow continues
past a certain length of time. The communication mechanism between
NPs and their network management systems described later, provide
a framework for dynamically sending traces to bordering networks to
continue the search for the attack origins.
The 'Traffic Flow Measurement' RFCs RFC2720 and RFC2722 outline a
structure for monitoring flows in a network through the use of
capture filters deployed on network devices throughout the network.
In the case of NetFlow, flow collection is enabled for all traffic
on a specific device interface with all data sent to a
FlowCollector. The device could be a router or switch already in
the network or an appliance-like device promiscuously monitoring
the network using either flow analysis method on a broadcast
segment or a mirrored port on a switch to the router. Another
option would be a device used to promiscuously monitor all
interfaces of a router using network taps. The monitoring device
would use a network tap on each of the connections to the device
being monitored to ensure the capture of all data to and from the
router or switch. The information collected could then identify
the source interface of traffic flows.
The RFC2720 monitoring is performed by a network device with a
defined filter, which watches for a specific flow of traffic. The
Moriarty Expires: August 10, 2003 [Page 12]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
capture filter can be predefined on the devices and managed by a
central device collecting the data captured. A central network
management station taking periodic snapshots of the flows of
traffic through network devices could be extended for use in
detecting abnormal behavior on the network, such as the occurrence
of a denial of service attack. The NMS could also perform any
post-processing and analysis of the captured data. The filters
might be set to trace certain packets in the event of an attack or
set to monitor normal traffic flows with periodic collection for
trending analysis.
NetFlow could be used to send continuous flow data to a
FlowCollector for post-processing. The flow analysis could be used
to detect attacks or for tracing attack traffic after the flows
from particular sources have already completed.
The monitoring device would incur added overhead when monitoring a
flow, especially in the case of a high bandwidth network. Most
NPs seem to prefer using separate monitoring devices for any
approach to tracing attack traffic. Several NPs have already
implemented their own proprietary tracing mechanism.
In the case of large, and geographically diverse networks, traces
using various monitoring solutions across a single network may
present issues even with full control of the network. Approaches
to address this problem have included ideas such as dividing the
network into sections or regions as discussed in the Hash-based IP
Traceback solution. Other problems that large networks may
encounter would include and may not be limited to the ability to
monitor large network pipes and the number of points on the network
that would require monitoring. A passive monitoring solution might
not be feasible as a result of the number and size of the points
that would require monitoring on the network.
3.3.2 Trace Approach via Hash-Based IP Traceback
BBN implemented a trace back solution, which collects hashes of IP
packets across the network. The Hash-Based IP Traceback was
designed specifically to trace attack traffic and achieve the
following objectives
O trace attacks after specific flows of the attack have completed
O reduce storage requirements needed to save traceable packet data
O provide a secure method to store packet captures on the Internet
Hash-based IP traceback is another solution to provide the ability
to trace attack traffic. By capturing all packets across the
network and saving hash values for the IP header information that
does not get altered as it traverses the network, attacks can be
traced after the fact. Since hashes of IP header information are
stored instead of the actual header information, privacy
Moriarty Expires: August 10, 2003 [Page 13]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
concerns are no longer an issue as might be the case with packet
captures across the Internet. If a system used to store the
packet captures was compromised, the data could not be used to
identify which entities are 'talking' to each other on the
Internet.
BBN also considered how traces could be performed across a single
network, for example an NP's backbone. The solution divides the
network up into regions, each with its own collection station.
The trace might be initiated at a particular collection station
where data for a specific router is stored. When the collection
station traces through its database for the matches of particular
hashes of IP packets, it follows the trace through the network
equipment for its own region. The collection station then
determines which bordering region was the next upstream source of
the attack and the trace is continued at the next collection
agent. The trace continues until the source is identified or a
neighboring network is identified as the upstream source of the
attack. The upstream network must then be notified in some way in
order to continue the trace. The upstream network may require the
hash information if they use hash-based IP Traceback or they may
require IP header information if another solution is in use. The
upstream provider will want to look at its network and resources
and decide if it would like to initiate a trace across their
network. A possible solution for the upstream trace between
bordering networks is discussed later.
Hash-based tracing has some definite advantages over other
solutions, such as the ability to store a larger amount of packets
for a greater period of time by using 32-bit digests. However,
there are some disadvantages, as well. Additional equipment is
needed to capture and store the hashed-based IP header
information. Some NPs have made investments in their current
tracing capabilities and do not have the resources to deploy a new
solution.
3.4 Correlating Collected Data
Integrating this extended monitoring capability into the NMS would
allow for the formulation of network behavior statistics and thus
the detection of anomalous usage behavior. The network trend
analysis capability could be used to detect unexplained spikes in
bandwidth usage on the network as a whole, as well as, on specific
networks in an NP backbone or servers on a local network. The NMS
would be aware of network outages that may result in traffic being
redirected through alternate paths of the network, which would be
an example of an explained spike in bandwidth. A client connected
to an NP may be hosting an event, such as a web cast. An
abundance of valid connection attempts can also result in bringing
a web site down, exhausting either bandwidth or system resources.
If an NP was aware of such an event, it could set higher
Moriarty Expires: August 10, 2003 [Page 14]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
thresholds for bandwidth usage alerting during that period of time
to prevent false alarms.
The anomalies could be used as methods of detecting Denial of
Service attacks. Since a centralized server would be recording all
of the capture information from the network devices, it may be
easier to track the source of an attack. If the current capture
filters on the monitoring devices do not provide the necessary data
to trace the attack, pre-defined or new, filters could be set on
the monitoring devices to watch for the traffic flows known to be
part of the attack. The peer information could be used by the NMS
to dynamically set the new filters upstream in the reverse path of
the traffic flow until the central monitoring station discovers the
source. However, this may limit the trace to the boundaries of a
specific network. Since the trace may have begun on a specific
company's network, its border with the NP may be the boundary
where the tracking must then become the responsibility of the NP
because of access limitations. This would also be true in the case
of a boundary between NPs.
When tracing back an attack, the NP could elect to enable this
tracking feature, and then poll the routers on their network for
the types of traffic seen during the attack. In order for this
trace of traffic to be meaningful for a DDoS attack, the IP
header information or the IP hash values of the packet would be
necessary as the traffic is traced back through the network.
Using the traffic flow MIB the IP destination and possibly protocol
information could be set in the monitoring devices for tracking via
a filter, this may be a viable way to trace back traffic quickly
through a network.
DDoS attacks can have many origins. Traces such as described above
may lead back to a client that is only a very small part of the
attack. However, once a few clients are detected as being part of
the attack, methods could be used to determine the location of the
controller of the client to further trace the true source of the
attack. That trace may involve intrusion detection or monitoring on
the client and is beyond the scope of this paper.
4.0 Communication Between Network Providers
Expediting the communication between NPs is essential when
responding to a security related incident such as a Denial of
Service attack, which may cross network access points, (Internet
backbones) between providers. As a result of the urgency involved
in this inter-NP security incident communication, there must be an
effective system in place to facilitate the interaction. This
communication policy or system should involve multiple means of
communication to avoid a single point of failure. Email may be the
best way to transfer information about the incident, packet traces,
etc. However, email may not be received in a timely fashion or be
acted upon with the same urgency as a phone call.
Moriarty Expires: August 10, 2003 [Page 15]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
Each NP should dedicate a phone number to reach a member of their
security incident response team. The phone number could be
dedicated to inter-NP incident communications and must be a
hotline that provides a 24x7 live response. The phone line should
reach someone who would have either the authority and expertise or
the means to expedite the necessary action to investigate the
incident. This may be a difficult policy to establish at smaller
NPs due to resource limitations, so another solution may be
necessary. An outside group may be able to serve this function
given the necessary access to the NPs network. The outside
resource should be able to mitigate or alleviate the financial and
experience resource limitations.
A technical solution to trace traffic across a single NP may be to
implement traffic flow meters, as described in the 'Traffic Flow
Measurement: Architecture' document [RFC2722], that can be read by
other NPs or a neutral third party to facilitate the investigation
of a denial of service attack. Meters can be read by multiple
meter readers, which may limit the expense and provide the ability
for a quick response to an attack. The meter uses a single active
capture filter and the buffered data can be retrieved by any of the
configured meter readers. Each NP may want to maintain their own
management station used for network monitoring and analysis. A
neutral third party may have access to a specific group of capture
filters that can be implemented dynamically as an event is traced
beyond network borders. This could be a function of a central
organization operating as a computer response team for the Internet
as a whole.
An alternative to permitting access to other network's equipment
would be to create a standard messaging mechanism to enable NMS
systems to communicate trace information to neighboring networks'
Network Management Systems. The third party mentioned above may
be used in this technical solution to assist in facilitating traces
through smaller NPs. The messaging mechanism may be a logical or
physical out-of-band network to ensure the communication is secure
and unaffected by the state of the network under attack. The two
management methods would accommodate the needs of larger NPs to
maintain full management of their network and the third party
option could be available to smaller NPs who lack the necessary
human resources to perform a trace. The first method enables the
individual NPs to involve their network operations staff to
authorize the continuance of a trace through their network via a
notification and alerting system. The out-of-band logical solution
for messaging may be permanent virtual circuits configured with a
small amount of bandwidth dedicated to NMS communications between
NPs.
The network used for the communication, out-of-band or protected
channels discussed later, would be direct communication links to
relay RID-DoS messages, accepting only this messaging protocol.
The communication links would be direct connections between network
Moriarty Expires: August 10, 2003 [Page 16]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
peers, which would form a larger web or iterative network that
correlates to the paths available over the larger web of networks.
The maintenance of the individual links will be the responsibility
of the two network peers hosting the link. Further discussion is
beyond the scope of this document and may be more appropriately
handled in network peering agreements.
Procedures for incident handling need to be established and well
known by anyone that may be involved in incident response. The
procedures should also contain contact information for internal
escalation procedures, as well as external assistance groups such
as CERT, GIAC, and the FBI.
4.1 Inter-Network Provider RID-DoS Messaging
In order to implement a messaging mechanism between NMS systems, a
standard protocol and format is required to ensure inter-
operability between vendors. The messages would have several
requirements in order to be meaningful as they traversed multiple
networks. The Real-Time Inter-Network Defense against DoS
(RID DoS) provides the framework necessary for communication
between networks involved in the trace back and mitigation of a DoS
attack. There are several types of messages that would be needed
to facilitate a trace across multiple networks. A message sent
between NMS systems to request the continuance of a trace through a
bordering network would require the information enumerated below.
1. Enough information to enable the network administrators
to make a decision about the importance of continuing the trace.
2. The filter or IP packet hash information needed to carry out
the trace.
3. Contact information of the origin of the trace. The contact
information could be provided through the autonomous system
number [RFC1930] whois information listed in the American
Registry for Internet Numbers (ARIN) database.
4. Network path information to help prevent any routing loops
through the network from perpetuating a trace. If an NMS
receives a trace request containing its own information in the
path, the trace must cease and the NMS should generate an alert
to inform the network operations staff that a routing loop
exists.
5. A unique identifier for a single attack should be used to
correlate traces to multiple sources in a DDoS attack.
Use of the communication network and the RID-Dos protocol must be
for pre-approved, authorized purposes only. It is the
responsibility of each participating party to adhere to guidelines
set forth in both a global use policy for this system as well as
one established though the peering agreements for each bi-lateral
peer. The purpose of such policies are to avoid abuse of the
system and shall be developed by a consortium of participating
Moriarty Expires: August 10, 2003 [Page 17]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
entities. The global policy may be dependent on the domain in
which it operates under, for example, a government network or a
commercial network such as the Internet would adhere to different
guidelines to address the individual concerns. Privacy issues
must be considered in public networks such as the Internet.
4.2 Message Formats
The following section describes the four message types used to
facilitate the communication between NPs tracing an incident. The
messages would be generated and received on Network Management
Systems on the NPs network. The fields in the messages are
described following the message descriptions.
4.2.1 Trace Request
Description: This message is sent to the Network Management Station
next in the upstream trace.
Message Type 1
Time Stamp
Incident Identifier
ASN for originating NP
Incident number based on incremental tracking
Trace number - used for multiple traces of a single
incident
Confidence rating of detected Denial of Service attack (0-100)
Level Meaning
______________________
1 Low probability the detected attack occurred
100 High probability the detected attack occurred
Filter used to trace incident across meters in the network
Number of NMS in the path listed in message
(count of items in following list)
Path information of Network Management Systems used in the trace
Autonomous System Number and NMS IP address of Next Network
Autonomous System Number and NMS IP address Current Network
...
Autonomous System Number and NMS IP address of Originating
Network
Digital signature of 32-bit hash of packet filter from
initiating NMS, passed to all systems in upstream trace
A DDoS attack can have many sources resulting in multiple traces to
locate the sources of the attack. It may be valid to continue
multiple traces for a single attack. The path information would
enable the administrators to determine if the exact trace had
already passed through a single network.
Moriarty Expires: August 10, 2003 [Page 18]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
4.2.2 Trace Authorization Message
Description: This message is sent to the initiating NMS from the
next upstream NP's NMS to provide information on the trace status
in the current network.
Message Type 2
Time Stamp
Incident Identifier
ASN for originating NP
Incident number based on incremental tracking
Trace number - used for multiple traces of a single
incident
Confidence rating of detected Denial of Service attack (0-100)
Filter used to trace incident across meters in the network
Trace Status
0 Pending
1 Approved
2 Denied
Number of NMS in the path listed in message
(count of items in following list)
Path information of Network Management Systems used in the trace
Autonomous System Number and NMS IP address of Next Network
Autonomous System Number and NMS IP address Current Network
...
Autonomous System Number and NMS IP address of Originating
Network
A message is sent back to the NMS that initiated the trace as a
notification means. This message verifies that the next NMS in the
path has received the message from the previous NMS in the path.
This message also verifies that the trace is now continuing,
stopped or pending in the next upstream network in the path of the
trace. The pending status would be automatically generated after a
2-minute timeout without system predefined or administrator action
taken to approve or disapprove the trace continuance.
Moriarty Expires: August 10, 2003 [Page 19]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
4.2.3 Source Found Message
Description: This message indicates that the source of the attack
in this trace was located and is sent to the initiating NMS through
the network of out-of-band NMS systems in the path of the trace.
Message Type 3
Time Stamp
Incident Identifier
ASN for originating NP
Incident number based on incremental tracking
Trace number - used for multiple traces of a single
incident
Action Taken (multiple selections permitted)
Bit Meaning
______________________________________________
0 No action at this time
1 Filter at upstream peer ingress point
2 Network segment blocked
3 Host (IP Address) blocked from Internet access
4 Protocol port used in attack blocked
5 Alert generated
6 Site notified
7 Other
Number of contacts listed in packet
Value should always be 1 for this message type
Autonomous System Number and NMS IP address of the system, which
located the source of the trace
Digital signature of source NP for authenticity of source found
Message, signature of hash of all fields of message
Starting with the time stamp and including the AS number
and NMS IP address of the system sending the found message.
[True Source address information of attack]
[Text field for any additional information for the action taken]
A message sent back to initiating NMS to notify the originating
network administrators that the source has been located. The
actual source information may or may not be included depending on
the policy of the network in which the client or host is attached.
Any action taken by the NP to act upon the discovery of the source
of a trace should be included. The NP may be able to automate the
adjustment of filters at their border router to block outbound
access for the machine(s) discovered as a part of the attack. The
filters may be as comprehensive as to block all Internet access
until the host has taken the appropriate action to resolve any
security issues or to rate limit the ingress traffic as close to
the source as possible.
Security and privacy considerations discussed later must be taken
into account with source found messages.
Moriarty Expires: August 10, 2003 [Page 20]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
4.2.4 Example Upstream Trace
The diagram below outlines the RID-DOS communication between NMS
systems on different networks tracing an attack.
Attack Dest NP-1 NP-2 NP-3 Attack Src
1. Attack | Attack
reported | detected
2. Initiate trace
3. Locate origin
through
upstream NP.
4. o---Msg-Type-1------>
5. Trace
Initiated
6. <-----Msg-Type-2----o
7. Locate origin
through
upstream NP.
8. o---Msg-Type-1--->
9. Trace Initiated
10. <------------Msg-Type-2------------o
11. Locate attack
source on network X
12. <------------Msg-Type-3------------o
The NP who detected the attack initiates the trace. The attack
is traced to the source or the next upstream NP. This process
continues until the trace identifies the source of the attack. Any
type 2 and 3 messages must pass through all NMS systems in the path
back to the initiator of the trace because of the secure
connections established between NMS systems of border networks.
The involved systems in the path for type 2 and 3 messages would
then have the ability to see the acknowledge the trace status
before sending the messages back along the NMS path to the
originating NMS.
Before a trace can be initialized, the originating NMS must check
an internal database to determine if a trace to the same IP address
or network address has occurred within a specified period of time,
no less than 1 day. The trace may have also been initiated by the
same NMS or this NMS may have been in the path of the trace. The
previous filter must be maintained for a minimum of a one-week
period in order to retrieve the filter for comparison before
initiating a trace request or allowing a trace continuance to
occur. If the network administrator justifies a similar trace, a
note might be added to the text section of the packet to provide an
additional confidence indication to the upstream NPs in the path of
the trace.
Moriarty Expires: August 10, 2003 [Page 21]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
4.3 Message Structure:
The TCP protocol is a good candidate to provide a reliable
transport mechanism for the messages sent between network
management systems. RID-DoS would operate on a
port assigned by the Internet Assigned Numbers Authority (IANA).
The message structure for the data portion of the packet is
detailed below. Message types 1 and 2 share the same structure.
Message type 3 differs after the incident identifier. The first 88
bytes include the consistent fields used in each packet type:
-------------------------------------------------------------------
| Msg Type | Time Stamp | Incident Identifier |
-------------------------------------------------------------------
8-bit 32-bit 48-bit
Field 1: 8-bit field for Message Type containing the number
associated with the message type given in the above descriptions
Field 2: 32-bit field for Time Stamp containing the current time in
seconds since January 1,1970 Greenwich Mean Time from the sender of
the packet
Field 3: 48-bit field for Incident Identifier
16-bit field Autonomous System Number (ASN)
16-bit field for Incident number, rolls over to zero
16-bit field for Trace number, rolls over to zero
Field 4: 8-bit field depending on message type
Percentage for Confidence rating in message type 1 and 2
Bit set for Action taken (bit set to 1 if selected option) in
message type 3
Field 5: 424-bit field for Filter used in message type 1 and 2.
Note: This field is unnecessary in message type 3. Must include
space for all items listed below and unused items would be left
blank for specific filters. All non-changing fields of the IP
header are included as well as 8 bytes from the payload to meet the
needs of the Hash-based IP Traceback. The protocol and port
information is listed for flow analysis or filter based traces.
4-bit field for IP header version
4-bit field for the IP header length, usually 20 bytes
In Version 6 packets, this field is used for priority
16-bit field for size of datagram (IP header plus payload
listed in bytes)
field used for payload length in version 6 packets
16-bit field for identification to uniquely identify packets
Version 6 8-bit for next hop and 8-bit for hop limit
3-bit field for IP flags, pad unused fields
13-bit field for fragmentation offset, listed in bytes
8-bit field for protocol number
128-bit Destination Internet IP address given in IPv6 format
Moriarty Expires: August 10, 2003 [Page 22]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
128-bit Source Internet IP address given in IPv6 format
16-bit field for destination port
16-bit field for source port
64-bit field for 8 bytes of payload
Field 6: 2-bit field to indicate trace status in message type 2,
Followed by 6-bit of padding
Following 2 fields used in message type 1, 2, and 3:
Field 6 in Msg 1:
Field 7 in Msg 2:
Field 5 in Msg 3: 8-bit field Number of hops or contacts along the
path of the trace
Next Field 7, 8, or 6: 144-bit field for each identifier.
16-bit for AS number
128-bit for NMS IP address in IPv6 format
Note 1: If identifier is unavailable, the IPv6 formatted
address should be listed and the AS number field null terminated
and padded. The optional text box at the end of the packet
should be used to provide NP name and contact information.
Note 2: A maximum of 80 identifiers may be listed within the
size constraints of a TCP packet. 15 would be large enough
considering that this is a count of the NMS systems used to trace
the attack. If the number is exceeded, that may indicate a loop
or other problem with the trace. In the case were it is valid to
have more than 15 NMS systems listed, the originating NMS should
be left in the packet and the rollover should begin with the
second hop. Each NMS should also track the trace identifiers
that have already passed through their systems to prevent loops.
Following 2 fields for Message type 1:
Field 8: 8-bit for size of Digital Signature for message type 1
Field 9: Digital signature of 128-160-bit hash of filter
128-bit hash produced from MD5, 160-bit hash produced
from the SHA hash algorithm
Remaining Fields in Message Type 3:
Field 7: 8-bit for size of Digital Signature for message type 3
Field 8: Digital signature of 128-160-bit hash of message 3 contents
128-bit hash produced from MD5, 160-bit hash produced
from the SHA hash algorithm
Field 9: 128-bit field given for true source address of attack
Field 10: 8-bit field with size of optional text field or null.
Field 11: Optional Text Field
0-1420-byte text field used in message type 3 to provide
additional attack information or contact information, minus
the size of the digital signature.
0-1152-byte text field if the optional text field is used in
Moriarty Expires: August 10, 2003 [Page 23]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
message type 2 for NMS identification information.
The text field can extend to the end of the TCP packet data unit
size limit of 1460 bytes. The number of bytes used for the text
field is listed in the first 8-bits or a null character must be
used to indicate the text field was not used. The text field
must be terminated with a null character to signify the end of
the text portion of the packet.
Note: The text is in English and is represented using ASCII format.
A single language would reduce management complexity,
particularly in the case where the event spans NPs in multiple
countries.
Total size of Message Type 1 packet
(without IP and TCP headers) = 656 bits with 1 NMS listed,
2448-bits with 15 NMS listed
Total size of Message Type 2 packet is 8-bits larger than Message
Type 1
Message Type 3 size before the optional text field is 256-bit
4.4 Message Delivery Protocol - Integrity and Authentication
The RID-Dos protocol must be able to guarantee delivery and meet
the necessary security requirements of a state-of-the-art protocol.
In order to guarantee delivery, TCP should be considered as the
underlying protocol within the current network standard practices.
It may seem appropriate to use SNMP trap messages since Network
Management Systems already use this messaging structure. However,
RFC1215 discourages the use of traps for this type of application
and attempts to discourage the creation of new trap types. The
current trap messaging structure does not satisfy the information
requirements in order to successfully carry out a trace. Trap
messages are sent via UDP, which assist in the quick delivery of
packets, however they do not guarantee delivery as in TCP. The RID
DoS protocol for inter-NMS communication could provide the
transport mechanism for message delivery. Another protocol choice
that may seem appropriate is the IDMEF protocol used for Intrusion
Detection messaging. However, the design of the packets and
messages used for that system do not meet the needs of RID-DoS to
ensure all the necessary information is included in the messages
sent between network providers.
Security considerations must include the integrity, authentication,
and authorization of the messages sent between NMS systems. The
communication between NMS systems must be authenticated and
encrypted to ensure the integrity of the messages and the NMS
systems involved in the trace. Another concern that needs to be
addressed is authentication for a request that traverses multiple
Moriarty Expires: August 10, 2003 [Page 24]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
networks. In this scenario, systems in path of the multi-hop
trace request need to authorize a trace from not only their
neighbor network, but also from the initiating NMS. Several
methods can be used to ensure integrity of the communication.
4.4.1 Transport Communication
Out-of band communications dedicated to NP interaction for RID-DoS
messaging would provide additional security as well as guaranteed
bandwidth during a denial of service attack. This might be
accomplished through logical paths defined over the existing
network. Out-of-band communications may not be possible between
all network providers, but should be considered if feasible to
protect the network management systems used for RID-DoS messaging
on the network.
In order to address the integrity and authenticity of messages,
IPSec tunnels MUST be used to encrypt the traffic sent between
NMS systems with pre-defined trust relationships. Systems used
to send authenticated RID-DoS messages between networks MUST use
a dedicated and secured interface to connect to a border network
management system. If a single system is used to connect to
multiple network management systems, each connection must have a
dedicated interface and the security requirements MUST meet those
agreed upon through peering or service level agreements (SLA). The
NMS interface must only listen for and send RID-DoS messages over
an IPSec tunnel, using the Encryption Security Protocol and meeting
a minimum requirement of algorithms and keys established by the
peering or SLA agreement. IPSec transport mode using ESP is
preferred, however tunnel mode using filters to limit the
communication to the RID-DoS protocol is sufficient. Tunnel mode
is acceptable due to limitations in the availability of compatible
IPSec transport mode implementations. Transport Layer Security
(TLS) would be similar to IPSec Transport mode in that it is used
to wrap the specific protocol with encryption to provide transport
level security. The selected algorithm must have minimum security
levels of the times, 3DES or 128-bit AES are sufficient at the time
this draft was written.
4.4.2 Authentication of RID-DoS protocol
In order to insure the authenticity of the RID-DoS messages, a
message authentication scheme using a public key infrastructure
(PKI) must be inherent to the protocol. Public key certificates
and digital signatures issued by a trusted Certificate Authority
(CA) will be used to provide the necessary level of authentication
for the RID-DoS protocol. The trusted CA used for RID-DoS
messaging must be trusted by all involved parties and may take
advantage of similar efforts, such as the dot-root project
(http://dot-root.com). The PKI infrastructure used for
authentication would also provide the necessary certificates needed
Moriarty Expires: August 10, 2003 [Page 25]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
to establish the above mentioned IPSec tunnels.
Hosts receiving a RID-DoS message, such as a trace request, for
example, must be able to verify that the sender of the request is
valid and trusted. Using digital signatures on a hash of the
RID-DoS message with an X.509 version 3 certificate issued by a
trusted party can be used to authenticate the request. The X.509
version 3 specifications as well as the digital signature
specifications and Certificate Revocation List (CRL) Internet
standards set forth in RFC2459 must be followed in order to
interoperate with a PKI designed for similar Internet purposes. A
one-way certificate based authentication protocol as described in
the ISO Authentication Framework (ISO/IEC 9594/8) and cited in 24.9
of Applied Cryptography must be used. The ISO authentication
framework provides the authentication and integrity aspects
required for secure messaging between network providers.
An optional extension to the authentication scheme would be to
incorporate the use of attribute certificates to provide
authorization capabilities as described in RFC3281. This may be
useful as messages are sent from network peers to determine
authorization levels based on the attribute information in the
certificate, which could be used to determine priority of a trace
request. The attribute information might be used to determine if
a trace request should be processed automatically or if human
intervention is required.
4.4.3 Authentication Considerations for a Multi-hop Trace Request
Bi-lateral trust relations between network providers ensure the
authenticity of requests for trace requests from immediate peers
in the web of networks formed to provide the trace back
capability. A network provider several hops into the path of the
RID-DoS trace must trust the information from their peer as to the
confidence rating of the attack and the previous trust
relationships in the downstream path. In order to provide a
higher assurance level as to the authenticity of the trace request,
the originating NMS is included in the trace request along with
contact information as well as the information of all NMS systems
in the path the trace has taken.
A second measure must be taken to ensure the identity of the
originating NMS. The originating NMS, also listed as originator
of the request in the path information, must include a digital
signature in the trace request sent to all systems in the NMS
upstream path. The initiating NMS system is required to include
a digitally signed hash of the packet filter information, all
necessary fields of the IP header and 8 bytes of payload, in the
trace request. A second benefit to this requirement is that the
integrity of the filter used is ensured as it is passed to
subsequent NPs in the upstream trace of the packet. The trusted
PKI used to provide authentication listed in the authentication
Moriarty Expires: August 10, 2003 [Page 26]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
section will also provide the certificates used to digitally sign
the necessary information in the trace requests. Since the CA is
known and trusted by all parties, any host in the path of the
trace can verify the digital signature. The digitally signed hash
must be included in all upstream trace requests to allow
subsequent NPs to verify the authenticity of a trace request.
4.4.4 Privacy Concerns
RID-DoS is useful when trying to determine the true source of a
packet when it traverses multiple networks. In order to identify
the source and trace multiple networks, the packet header
information along with 8 bytes of payload are used in the packet
identification. The information obtained from the trace may result
in the identity of the source host or the network provider used by
the source of the traffic. The trace mechanism used across a
single network provider may also raise privacy concerns if the
provider uses a method, which involves storing packets for some
length of time in order to trace packets after the fact.
The identity of the true source of a packet could be protected
through service level agreements with network providers. In some
situations, systems used in attacks are compromised by an unknown
source and then in turn are used to attack other systems. In this
type of situation, the reputation of a business or organization may
be at stake and the action taken through RID-DoS would be to report
the action taken to the originating system. If the security
incident was a minor incident such a zombie system used in part of
a large-scale DDoS attack, ensuring the system is taken off the
network until it has been fixed may be sufficient. Local, state,
or national laws may dictate the appropriate reporting action for
specific security incidents.
The packet information is sent across multiple networks that happen
to be in the path of a trace. Another concern may be that an
attack occurred between a specific source and destination and every
network provider in the path of the trace is now aware that the
cyber attack occurred. In cases where compromised systems are
responsible for the attack, this may not raise privacy concerns.
However, in a targeted attack, where source addresses are spoofed,
it may not be desirable for the knowledge of two nation states
battling a cyber war to become general knowledge to all
intermediate parties. It is important to allow the traces to take
place in order to cease the activity since the health of the
networks in the path could also be at stake during the attack.
This provides a second argument for allowing the third message
type, source found to only include an action taken instead of
identity of the offending host. In some situations, all network
traffic of a nation may be granted through a single network
provider. In order to gain support for tracing mechanisms,
options must also include the ability to send a source found
message from the downstream peer of the network provider where the
Moriarty Expires: August 10, 2003 [Page 27]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
source was found to provide another layer of protection to the
attack source identity. Legal action may override this technical
decision after the trace has taken place, but that is out of the
technical scope of this document.
Finally, privacy concerns may also include the storage of packet
information that could be used for single network traces. RID-DoS
is designed to pass the information needed by any single network
trace mechanism used. The decision of what single trace mechanism
used by a provider may depend on resources, existing solutions, and
local legislation. Privacy concerns in regard to the single
network trace must be dealt with at the client to network provider
level and are out of the scope for RID-DoS messaging.
The ability to dynamically trace packets through packet flow data
could be used with malicious intent and reach beyond the intended
scope of this protocol. However, if using a valid source address,
RID-DoS traces would not be necessary since the true source
information would already be valid in the packet. Tools such as
traceroute can be used to identify path information, thus making
RID-DoS extraneous in such situations. If tools such as traceroute
do not provide the necessary path information in a security
incident, the trace request must note the use system to avoid
instances where the trace is providing information outside the
intended and agreed upon scope of the system. Appropriate system
use must be defined by the collaborative effort of the NPs
connected in a RID-DoS web.
5.0 Security Considerations
Communication between NP's NMSes must be protected. An out of band
network, either logical or physical would prevent outside attacks
against NMS communication. Authenticated encryption tunnels
between stations would protect the data in transit as well as
provide integrity of the data and must be used. Since the RID-DoS
network is a bilateral interconnection of adjacent peers, the NMSs
would permit messages between peering networks, which would relay
messages to upstream peers on behalf of the initiating network
peer.
The NMS should be configurable to either require user input or
automatically continue traces. This feature would enable a network
manager to assess the available resources before continuing a
trace. A trace may cause adverse affects on a network. If the
confidence rating is low it may not be in the Network Provider's
best interest to continue the trace. The confidence ratings must
adhere to the specifications for selecting the percentage used to
avoid abuse of the system. Trace requests must be issued by
authorized individuals from the initiating network, set forth in
policy guidelines established through peering or SLA agreements.
Policy between NPs must be established to provide guidelines for
Moriarty Expires: August 10, 2003 [Page 28]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
communication. The policy should include communication methods,
security, and fall-back procedures. The Policy should establish a
method to protect communications between NMS systems between all
bordering NPs. The trust relationships would have to extend to all
bordering NPs in order to be successful in tracing and stopping
attacks. A fully meshed communication ability would provide the
means for message type 3 (Source Found Message) to be sent to an
initiating NMS. If a fully meshed communication system is not
available, messages may have to traverse multiple systems to reach
the initiating NMS as a result of the linear trust relationships
established between management systems. Other policy
considerations include how the AS number and NMS IP address should
be shared. This should also be coupled with any necessary
pre-shared key or certificate (or trusted Security Authority)
stored in the NMS for encryption negotiation.
Note: The AS number and corresponding IP address for a network NMS
would be shared between cooperating networks via a predefined
table. This information may be stored locally on NMS systems or a
central database accessible on the secured network used for
inter-NP messaging on NMS. A Certificate Authority may be used to
establish security associations between NMS systems.
The method of passing the trace request to subsequent networks
eliminates the need for granting access to remote entities to
configure network equipment on border networks. Access to network
equipment to configure systems for trace continuance would remain
in the responsibility of the parties who own and manage the
equipment. This also prevents the need for sharing authentication
information to the devices outside of the network operation center
managing the device. Network administrators who have the ability
to base the decision on the available resources and other factors
of their network maintain control of the continuance of a trace.
6.0 Summary
Denials of service attacks have always been difficult to trace as a
result of the spoofed sources, resource limitations, and bandwidth
utilization problems. Methods to identify and trace attacks near
real time are essential to thwarting attack attempts. Network
Providers need automated methods as well as policies in place
in order to attempt to combat the hacker's efforts. Proactive
monitoring and alerting of backbone and client bandwidth with trend
analysis is an approach that can be used to help identify and trace
attacks quickly without resource intensive side effects.
Subsequent more detailed analysis could be used to complement the
bandwidth monitoring. Timely communication between NPs is
essential in incident handling.
Moriarty Expires: August 10, 2003 [Page 29]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
7.0 References
[ISO 9594/8] CCITT Rec. X.509 (1994) | ISO/IEC 9594-8:1994,
Information Technology - Open Systems Interconnection รป The
Directory: Authentication Framework
[RFC791] "Internet Protocol, DARPA Internet Program, Protocol
Specification". Information Sciences Institute, University of
Southern California. September 1981.
[RFC1213] "Management Information Base for Network Management of
TCP/IP-based Internets: MIB-II". K. McCloghrie, M . Rose. March
1991.
[RFC1215] "A Convention for Defining Traps for use with the SNMP".
M. Rose. March 1991.
[RFC1930] "Guidelines for creation, selection, and registration of
an Autonomous System (AS)". J. Hawkinson and T. Bates. March 1996.
[RFC2246] "The TLS Protocol". Dierks, T. and C. Allen.
January 1999.
[RFC2459] "Internet Public Key Infrastructure: Part I: X.509
Certificate and CRL Profile". Housley, R., Ford, W., Polk, W. and
D. Solo. January 1999.
[RFC2527] "Internet X.509 Public Key Infrastructure: Certificate
Policy and Certification Practices Framework". Chokhani, S.,
Ford, W. March 1999.
[RFC2528] "Internet X.509 Public Key Infrastructure:
Representation of Key Exchange Algorithm (KEA) Keys in Internet
X.509 Public Key Infrastructure Certificates". Housley, R., Polk,
W. March 1999.
[RFC2720] "Traffic Flow Measurement: Meter MIB". N. Brownlee.
October 1999.
[RFC2722]"Traffic Flow Measurement: Architecture". N. Brownlee, C.
Mills, G. Ruth. October 1999.
[RFC2723] "SRL: A Language for Describing Traffic Flows and
Specifying Actions for Flow Groups". N. Brownlee. October 1999.
[RFC2827] "Network Ingress Filtering: Defeating Denial of Service
Attacks Which Employ IP Source Address Spoofing". P. Ferguson and
D. Senie. May 2000.
[RFC3821] "An Internet Attribute Certificate Profile for
Authorization". Farrell, S., Housley, R. April 2002.
Moriarty Expires: August 10, 2003 [Page 30]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
[1] http://www.info-sec.com/denial/infosece.html-ssi
[2] `CenterTrack: An IP Overlay Network for Tracing DoS Floods'.
Robert Stone. 9th Usenix Security Symposium Proceedings, August
2000.
[3] 'Inferring Internet Denial of Service Activity`. David Moore,
Geoffrey M. Voelker and Stephan Savage. ;login. November 2001.
[4] 'MULTOPS: A Data-Structure For Bandwidth Attack Detection'.
Thomer M. Gil, Massimiliano Poletta. ;login. November 2001.
[5] 'Network Congestion Monitoring and Detection using the IMI
infrastructure'. Takeo Saitoh, Glenn Mansfield, and Norio
Shiratori. Graduate School of Information Sciences, Tohoku
University.
[6] 'Trends in Denial of Service Attack Technology`. Kevin J. Houle
and George M. Weaver. CERT Coordination Center. October 2001.
[7] http://www.cisco.com/go/netflow
[8] 'Hash Based IP Traceback'. A. Snoren, L. Sanchez, C. Jones,
F. Tchakountio, S. Kent, and W. Strayer. SIGCOMM'01. August 2001.
[9] 'Practical Network support for IP Traceback'. S.Savage, D.
Wetherall, A. Karlin and T. Anderson. SIGCOMM'00. August 2000.
[10] 'ICMP Traceback Messages'. S. M. Bellovin. Internet Draft:
draft-bellovin-itrace-00.txt, March 2000.
[11] PKCS 5 v2.0 Password-Based Cryptography Standard. RSA Security
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-5/index.html.
March 1999.
[12] PKCS 7 Cryptographic Message Syntax Standard. RSA Security.
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html.
May 1997.
[13] Applied Cryptography: Protocols, Algoritms, and Source Code
in C. Schneier, Bruce. Second edition. John Wiley & Sons. 1996.
Moriarty Expires: August 10, 2003 [Page 31]
Internet-Draft DDoS Incident Handling: RID-DoS February 10, 2003
8.1 Acknowledgements
Dr. Robert K. Cunningham, MIT Lincoln Laboratory
Cynthia D. McLain, MIT Lincoln Laboratory
Dr. William Streilein, MIT Lincoln Laboratory
Many thanks to the Internet community for reviewing and commenting
on the draft, most notably Jose Nazaro, Jean-Francois Morfin, Tony
Tauber, Steve Bellovin, Jeffrey Schiller, and Stephen Northcutt.
8.2 Author Information
Kathleen M. Moriarty
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Phone: 781-981-5500
Email: Moriarty@ll.mit.edu
This work was sponsored by the Air Force under Air Force
Contract Number F19628-00-C-0002.
"Opinions, interpretations, conclusions, and recommendations
are those of the author and are not necessarily endorsed
by the United States Government."
Moriarty Expires: August 10, 2003 [Page 32]