Extended Incident Handling Working Group Kathleen M. Moriarty
draft-moriarty-ddos-rid-06.txt MIT Lincoln Laboratory
Expires: August 28, 2004 February 28, 2004
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
Network security incidents such as Denial of Service (DoS), system
compromises, worms, and viruses typically result in the loss of
service, data, and resources both human and system. Security
incidents can be detrimental to the health of the network as a
whole. 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 detect and trace
attacks must be coordinated 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 integrates current incident detection
and tracing practices for network traffic, which could be extended
for security incident handling. Policy guidelines for handling
incidents are recommended and can be agreed upon by a consortium
using the defined protocol and extended to each NP's clients.
Internet-Draft February 28, 2004
TABLE OF CONTENTS
Status of this Memo ................................................ 1
Abstract ........................................................... 1
1. Introduction .................................................... 4
1.1 Overview of Attack Types ................................... 5
2. Recommended Network Provider (NP) Technologies .................. 7
3. Characteristics of Attacks ...................................... 8
3.1 Tracing a Distributed attack ............................... 10
3.1.1 Tracing Security Incidents ........................... 10
3.2 Trace Approaches ........................................... 11
3.2.1 Trace approach via Traffic Flow Analysis ............. 11
3.2.2 Trace Approach via Hash-Based IP Traceback ........... 12
3.2.3 IP Marking ........................................... 13
3.3 Correlating Collected Data ................................. 14
4. Communication Between Network Providers ......................... 14
4.1 Inter-Network Provider RID Messaging ....................... 16
4. RID Network Topology ............................................ 18
4.2 Message Formats ............................................ 19
4.2.1 RID Messages using SOAP and Web Services Security Model 20
4.2.2 RID Data Types ....................................... 20
4.2.4 IODEF-Document ...................................... 21
4.2.5 IODEF-Document Extensions ............................ 21
4.2.5.2 NPPath Extension ............................... 25
4.2.5.3 TraceStatus Extension ......................... 26
4.3 RID Documents Defined by Message Type Derived from IODEF ... 27
4.3.1 Trace Request ........................................ 29
4.3.2 Trace Authorization Message .......................... 30
4.3.3 Source Found Message ................................. 31
4.3.4 Relay Message Request ................................ 32
4.3.5 Example Upstream Trace ............................... 34
4.3.6 RID Trace Request Example ............................ 35
5. RID IODEF Extension Document Type Definition .................... 37
6. Message Transport ............................................... 40
6.1 Message Delivery Protocol - Integrity and Authentication ... 40
6.2 Transport Communication .................................... 41
6.3 Authentication of RID Protocol ............................. 41
6.4 Authentication Considerations for a Multi-hop Trace Request 42
6.4.1 Public Key Infrastructures and Consortiums ........... 43
6.5 Privacy Concerns and System Use Guidelines ................. 44
7. Security Considerations ......................................... 47
Moriarty Expires: August 28, 2004 [Page 2]
Internet-Draft February 28, 2004
8. Summary ......................................................... 49
9. References ...................................................... 50
9.1 Acknowledgements ........................................... 53
9.2 Author Information ......................................... 53
Moriarty Expires: August 28, 2004 [Page 3]
Internet-Draft February 28, 2004
1. 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 or packet marking techniques. The
single network trace mechanisms use similar information across the
individual networks to trace traffic. Problems are encountered
when an attempt is made to have a trace continued through the next
upstream network since the trace mechanism and management may be
different.
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, Real-time Inter-network Defense (RID),
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
Moriarty Expires: August 28, 2004 [Page 4]
Internet-Draft February 28, 2004
to continue. The data in RID messages will be represented in an
Extensible Markup Language (XML) document and is an extension of
the Incident Data Exchange Format (IODEF) model. By following this
model, integration with other aspects of the network for incident
handling is simplified. Finally, methods are incorporated into the
communication system to indicate what actions were taken closest to
the source in order to cease or mitigate the effects of the attack
at hand. RID is intended to provide a method to communicate the
relevant information between NPs while being compatible with a
variety of existing and possible future detection and tracing
approaches.
Security and privacy considerations are of high concern since
potentially sensitive information may be passed through RID
messages. RID messaging will take advantage of XML security, web
services security model, and will wrap RID messages in the Simple
Object Access Protocol (SOAP) to use the authentication, integrity,
and authorization features each has to offer to achieve the level
of security that is necessary. SOAP and WS-Security provide the
necessary security for a protool like RID, but may cost too much
in terms of overhead. BEEP, XML SNMP, and other transport methods
are also under consideration.
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
Moriarty Expires: August 28, 2004 [Page 5]
Internet-Draft February 28, 2004
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
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.
System compromises may occur from valid source addresses, which may
also be the case for other security incidents such as worms,
Trojans, or viruses. It is often the case that an incident goes
unreported even if valid source address information is available.
Incident handling is a difficult task for a NP and even at some
client locations due to the size of a network and resource
limitations.
Moriarty Expires: August 28, 2004 [Page 6]
Internet-Draft February 28, 2004
2. 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 or the
network provider's Computer Security Incident Response Team
(CSIRT). 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). The acronym NMS will
be used to generically represent management servers on a network
used for the management of network resources and the integration of
RID messaging with other components of the network. This system
usually performs trend analysis for bandwidth utilization and
report communication problems and in this case may also trigger a
trace across the network or communicate with a system that can
initiate a trace. 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
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
Moriarty Expires: August 28, 2004 [Page 7]
Internet-Draft February 28, 2004
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.
Intrusion detection system (IDS) may also be integrated to create
IODEF documents or RID messages to facilitate security incident
handling. IDS monitor network traffic analyzing packets to
determine if traffic might be classified as malicious. If an IDS
detects malicious traffic, an analyst might determine the validity
and severity of the attack traffic and determine if a trace is
necessary. If the analyst determines a trace should be initiated,
an IODEF document with RID extensions might be created or the
necessary information sent to the RID messing system in order to
create and track the RID message.
The detection of other security incidents may rely more on
reporting rather than automated detection tools, except perhaps in
the case of some worms, which can result in large increases of
traffic. Detection of a security incident is outside the scope of
this paper, however it should be possible to integrate detection
methods with RID messaging.
3. 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, 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.
Care must also be taken to ensure the system is not abused and to
use proper analysis in determining if attack traffic is in fact
attack traffic at each NP along the path of a trace.
Moriarty Expires: August 28, 2004 [Page 8]
Internet-Draft February 28, 2004
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
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 IP address
information or 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. If the true source has been identified,
actions should be taken to cease or mitigate the effects of the
attack by reporting the incident to the NP or the upstream NP
closest to the source. In the case of spoofed source address other
methods can be used to trace back to the source of an attack. The
methods include packet filtering, packet hash comparisons, IP
Marking techniques, ICMP Traceback, and packet flow analysis. As
in the case of attack detection, tracing traffic across a single
network is a function that can be used with RID in order to provide
the networked ability to trace spoofed traffic to the source, while
Moriarty Expires: August 28, 2004 [Page 9]
Internet-Draft February 28, 2004
RID provides all the necessary information to accommodate the
approach used on any single network to accomplish this task. RID
can also be used to report attack traffic close to the source where
the IP address used was determined to be valid.
3.1 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, hosts, or an IDS. 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. Some research approaches
include 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.
3.1.1 Tracing Security Incidents
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 stop 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. A similar example of
attack traffic with the possibility of multiple traces required
Moriarty Expires: August 28, 2004 [Page 10]
Internet-Draft February 28, 2004
would be one in which an attacker compromised a series of systems
and accomplished hiding their source by logging into a string of
systems to launch 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 attack traffic. Tracing multiple attack
paths can also cause additional stress on the network and does not
scale well.
A CSIRT report might be generated in the form an of IODEF document
and then fed into a RID message or document to facilitate a trace
of attack traffic.
3.2 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 or custom solutions
requiring specific information such as IP packet header data, hash
values of the attack packets, or marked packets. Hash values are
used to compare a packet against a database of packets that have
passed through the network in the case of 'Hash Based IP
Traceback'[8]. Other research solutions involve marking packets as
explained in 'ICMP Traceback Messages'[10], 'Practical Support for
IP Traceback' [9], and *** IP Marking []***. 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.2.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
NetFlow. The 'Traffic Flow Management' RFC [RFC2720] was
Designed to provide management information such as behavior models,
Moriarty Expires: August 28, 2004 [Page 11]
Internet-Draft February 28, 2004
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.
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)
Based on the information listed above, a spoofed packet can be
traced upstream through a network to either identify the true
source or the upstream peer. Various flow based solutions have
been developed and implemented for use on a single backbone based
on flow analysis and the RID messaging described later must be able
to support existing and future solutions to trace attacks across
multiple networks. The AS number listed associated with a source
IP address is only valid if the source IP address is valid. The AS
number in this case cannot be trusted, however it may be trusted in
the iterative trace and from the actual address information
gathered from that trace.
3.2.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
Moriarty Expires: August 28, 2004 [Page 12]
Internet-Draft February 28, 2004
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
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 will require the
IP packet information in order to continue the trace. 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 limited number of packets can be stored based on
resources and network traffic loads. A possible solution for
communicating the upstream trace request between bordering networks
is discussed later with the RID protocol.
The trace solution implemented across the single network is
independent of the messaging system and would have a greater
impact on the effectiveness and efficiency of a trace across the
network.
3.2.3 IP Marking
IP Marking is another technique that can be used to trace attacks
in which the source address has been spoofed in a more efficient
manner than iterative trace mechanisms. This technique has been
proposed specifically in terms of tracing DoS attacks across a
network. All information is correlated at the end node or the
target where the packets received would have been marked
probabilistically along the path of the traffic. This method
requires that routers and other infrastructure equipment have the
ability to mark packets so that the path they tool can be derived
at the destination address for the packets. Since all packets are
not marked, depending on the IP Marking scheme used, a number of
Moriarty Expires: August 28, 2004 [Page 13]
Internet-Draft February 28, 2004
similar packets would have to be sent from a single source in order
for it to be identified. IP Marking alone may not be a complete
answer for tracing traffic, since an attacker could switch their
methods to send very little data from any one host used in a DDoS
attack, thus making it unlikely that enough packets will be marked
to find the source of each stream. Integrating IP Marking with
other techniques may be the best answer to ensure the efficiency
and robustness of the system as a whole.
In terms of integrating the IP Marking approach with RID there are
several ways in which it may be useful. IP Marking may be used to
gather information about the path of the trace up to an including
identifying the actual source. A peer closer to the source might
be identified if the IP Marking technique were not able to fully
reconstruct the path of the trace. In this instance, the trace
information could be sent to the closest point identified in the
path from the IP Marking technique, thus shortening the length of
time required to trace the traffic through the network. If a
source was identified, a ID Relay request might be used in order to
trigger a specific action to take place close to the source to
mitigate or stop the affects of the attack.
3.3 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
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, worms or other security
incidents. IDS systems may detect attacks and redistribute
information into an NMS or RID messaging system to facilitate an
attack traffic trace in order to mitigate or stop the traffic.
4. Communication Between Network Providers
Expediting the communication between NPs is essential when
responding to a security related incident, 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
Moriarty Expires: August 28, 2004 [Page 14]
Internet-Draft February 28, 2004
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 or other communication system.
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
include home grown or commercial systems in which RID messaging
must accommodate the input requirements. The network management
systems used on the NPs backbone to coordinate the trace across the
single network requires a method to accept and process RID messages
and relay trace requests to the system as well as wait for
responses from the system to continue the RID request process as
appropriate. In this scenario, each NP would maintain their own
RID system and integrate with a management station used for network
monitoring and analysis. An alternative for NPs lacking sufficient
resources may be to have a neutral third party with access to the
NPs network resources that could be used to perform the trace
functions. This could be a function of a central organization
operating as a computer response team for the Internet as a whole
or within a consortium that may be able to provide centralized
resources. Consortiums would consist of a group of NPs that agree
to participate in the RID communication protocol with an agreed
upon communication protocol facilitating the secure transport of
RID XML documents via the Simple Object Access Protocol (SOAP).
The first method described prevents the need to permit access to
other network's equipment through the use of a standard messaging
mechanism to enable RID or NMS's to communicate trace information
to other networks in a consortium or in neighboring networks. 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
Moriarty Expires: August 28, 2004 [Page 15]
Internet-Draft February 28, 2004
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 messages, accepting only this messaging protocol.
The communication links would be direct connections between network
peers who have agreed upon use and abuse policies through the use
of a consortium. Consortiums might be linked through policy
comparisons and additional agreements to form a larger web or
iterative network of peers that correlates to the traffic 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. Within a consortium, a web of connections
might be formed in order to facilitate fast communications for
relay messages described later for the RID protocol. Contact
information, IP addresses of network management systems and other
information must be coordinated between by a consortium and may use
existing databases, such as the Routing Arbitor, as with any changes
to the involved systems. The security, configuration, and
confidence rating schemes of the peering NMSs for RID messaging
peers must be negotiated by peers and must meet certain overall
requirements of the fully connected network, (Internet, government,
education, etc.) through the peering and/or a consortium based
agreement.
RID messaging established with clients of an NP may be negotiated
in a contract as part of a value added service or through a service
level agreements. Further discussion is beyond the scope of this
document and may be more appropriately handled in network peering
or service level 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 a CSIRT, CCCERT, GIAC, and the FBI.
4.1 Inter-Network Provider RID Messaging
In order to implement a messaging mechanism between RID
communication or NMS systems, a standard protocol and format is
required to ensure inter-operability between vendors. The messages
would have to meet several requirements in order to be meaningful
as they traversed multiple networks. The Real-Time Inter-Network
Defense (RID) provides the framework necessary for communication
between networks involved in the trace back and mitigation of a DoS
attack or security incident. There are several types of messages
Moriarty Expires: August 28, 2004 [Page 16]
Internet-Draft February 28, 2004
that are needed to facilitate a trace across multiple networks.
The message types include a Trace Request, Trace Authorization,
Source Found, and a Relay Request. A Trace Request message can be
used when the source of the traffic may have been spoofed, which
may require each network provider in the upstream path to receive a
trace request and issue a trace across their network in order to
determine the upstream source of the traffic. The Trace
Authorization and Source Found messages are used to communicate the
status and result of a trace as it traverses potentially several
networks. The last message type would be used to leverage the
bi-lateral relationships or a consortium's interconnections to
relay a request in order to mitigate or stop potentially malicious
or spurious valid traffic close to the source. This request
type (4), called a Relay Request, would only involve the RID
communication systems along the path to the source of the traffic
and not involve the use of single network trace systems. Routes
would determine the fastest path to a known source IP address in
the case of a relay request or type four message. A message sent
between RID or NMS systems to request the continuance of a trace or
to relay a request to stop traffic at the source 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] or NIC handle information listed in the
Registry for Internet Numbers or other Internet databases.
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 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 bilateral
peer or agreed upon consortium guidelines. The purpose of such
policies are to avoid abuse of the system and shall be developed by
a consortium of participating 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. Privacy issues are discussed later in the
Moriarty Expires: August 28, 2004 [Page 17]
Internet-Draft February 28, 2004
security section along with other requirements that must be agreed
upon by participating entities.
Traces must be legitimate security related incidents and not used
for purposes such as sabotage or censorship. An example of such
abuse of the system would include a request to rate limit
legitimate traffic to prevent information from being shared between
users on the Internet (restricting access to online versions of
papers) or restricting access from a competitor's product in order
to sabotage a business.
The RID system 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.
4. RID Network Topology
The most basic topology for RID systems that communicate with each
other would be a direct connection or a bi-lateral relationship as
illustrated below.
__________ __________
| | | |
| RID |__________-------------___________| RID |
|_________| | NP Border | |________|
-------------
Figure 1: Direct Peer Topology
Within the consortium model, several topologies might be agreed
upon and used. One would leverage bi-lateral network peering
relationships of the members of the consortium. The peers for RID
would match that of routing peers and the logical network borders
would be used. This approach may be necessary for an iterative
trace where the source is unknown. The model would look like the
above diagram, however there may be an extensive number of inter-
connections of bi-lateral relationships formed. Also within a
consortium model, it may be useful to establish an integrated mesh
of networks to pass RID messages. This may be beneficial where the
source address is known and an interconnection may provide a faster
route to reach the closest upstream peer to the source of the
attack traffic. A possible example is illustrated below.
Moriarty Expires: August 28, 2004 [Page 18]
Internet-Draft February 28, 2004
_______ _______ ______
| | | | | |
__| RID |____-------------____| RID |____-------------____| RID |__
|_____| | NP Border | |_____| | NP Border | |_____|
| ------------- ------------- |
|_______________________________________________________|
Direct connection to network that is not an immediate network peer
Figure 2: Mesh Peer Topology
By using a fully meshed model that may occur in a consortium,
broadcasting RID requests would be possible, but not advisable. By
broadcasting a request, RID peers that may not have had the attack
traffic appear on their network would be asked to perform a trace
in order to possibly speed the time in which the true source was
identified. The initiating network would not have first performed
a trace on their own network to identify the next upstream peer or
if the source of the traffic was actually on their own network. If
the source was later to be found on the same network as the
initiating peer, unnecessary resources would have been utilized for
this unnecessary trace request(s).
4.2 Message Formats
The following section describes the four message types used to
facilitate the communication between NPs tracing an incident based
on the IODEF model. The messages would be generated and received
on RID communication systems or NMSs on the NPs network. The
messages may originate from other IODEF messages from intrusion
detection servers, CSIRTS, etc.. A RID message uses the IODEF
framework which is encapsulated in a SOAP wrapper to enable the
parsing of the various types of RID messages and IODEF extensions
for RID through the use of the AdditionalData class in the IODEF
model. Each type of RID message is described in the following
sections along with an example using the IODEF format and
extensions.
SOAP and the Web Services Security Model [19,20] are used to take
advantage of existing standards for ease of implementation and
integration of RID systems. Transport Layer Security (TLS)
provides the necessary level of encryption for the transport RID
messages. The Web Services WS-Security, WS-Policy, WS-Trust, and
WS-Privacy specifications provide the standards based methods to
encrypt and digitally sign SOAP messages, provide system use and
privacy guidelines, authentication and authorization, encryption,
as well as the method to establish trust between members of a RID
consortium or a peering consortium. The Web Services Security
Model will be used to provide the necessary security levels between
peers on the RID network, whereas XML security functions like the
digital signature and encryption can be used within the contents of
the message for privacy and security in cases where certain
elements must remain encrypted or signed as they traverse the PATH
Moriarty Expires: August 28, 2004 [Page 19]
Internet-Draft February 28, 2004
of a trace. One example of this is the digital signature on the
originatorÆs packet used for the trace request to provide a way to
verify the identify the originator of the trace.
The Web Services Security Model in relation to RID messaging will
be expanded upon further with more specific detail in an upcoming
draft release.
4.2.1 RID Messages using SOAP and Web Services Security Model
Four RID message types are defined in this document to facilitate
communications between CSIRTs or NPs. The message types include:
Trace Request, Trace Authorization, Source Found, and Relay
Request.
1. Trace Request. This message is sent to the Network Management
Station next in the upstream trace. It may be used to initiate a
trace request or to continue a trace request to an upstream network
closer to the source of the origin of the security incident.
2. Trace Authorization. This message is sent to the initiating NMS
from each of the upstream NP's NMS to provide information on the
trace status in the current network.
3. Source Found. 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 NMS systems in the path of the trace.
4. Relay Request. This message type is used when the source of the
traffic is believed to be valid. The purpose of the relay message
request is to leverage the existing peer relationships in order to
notify the network provider closest to the source of the valid
traffic of some event that has occurred, which may be a security
related incident.
When a system receives a RID message, it must be able to
first determine the type of message it is and then parse it
accordingly. SOAP and the WS-Security model will be used for this
purpose and will be discussed further in an upcoming version of
this draft.
4.2.2 RID Data Types
RID is derived from the IODEF data model and inherits all of the
data types defined in the IODEF model. With the exception of
representing packet data, no other additional data types are
required for RID extensions. The extension for RID containing the
packet contents will be represented in a hexadecimal format for
easier use by single network trace systems and integration with
other aspects of the network. Hexadecimal data is defined in XML
as the datatype:
Moriarty Expires: August 28, 2004 [Page 20]
Internet-Draft February 28, 2004
xs:hexBinary
Hexadecimal attributes are represented by the hexBinary data type.
The hexBinary data type allows you to code binary content as a
character string by translating the value of each binary octet into
two hexadecimal digits.
4.2.4 IODEF-Document
The IODEF model will be followed as specified in RFCXXXX (the RFC
number will replace the XXXX when a number has been assigned for
the document) for each of the RID message types. The
AdditionalData element will be used to define extensions to the
IODEF-Document in order to facilitate RID communications. Each
message type varies slightly in format and purpose; hence the
requirements vary and will be specified for each. All classes,
elements, attributes, etc. that are defined in the IODEF-Document
are valid in the context of a RID-Document, however certain
classes, attributes, elements, etc. will be required for each
message type and the rest are optional when sending a RID request
and will be defined in sections 4.1.3. The IODEF model MUST be
fully implemented to ensure proper parsing of all RID messages.
Since RID documents are IODEF-Document with extensions, all
RID documents contain the IODEF Document class, the IODEF model,
and the IODEF DTD. The incident class is required for an
IODEF-Document and in turn for a RID-Document. The AdditionalData
attribute defined in the Incident class will be used to define the
RID extensions for the IODEF model that are included in some RID
messages.
Please see RFCxxxx for specific information on the IODEF-Document
requirements. (The RFC number will be defined when the document
becomes an RFC).
4.2.5 IODEF-Document Extensions
There are three extensions required to facilitate RID
communications within the IODEF data model. The first extension is
used to represent the data used in tracing an incident, the second
is used to list out the path a trace has taken at the NMS or NP
level, and the third is used to indicate the approval status of a
trace or relay request.
In order for network traffic to be traced across a network, an
example packet from the attack must be sent along with trace or
relay requests. All of the non-changing fields of an IP header
along with 8 bytes of payload are required to provide enough
information to uniquely trace the path of a packet. The non-
changing fields of the packet header and the 8 bytes of payload are
the superset of data required by most single network tracing
systems used and prevent the need for sharing potentially sensitive
Moriarty Expires: August 28, 2004 [Page 21]
Internet-Draft February 28, 2004
information that may be contained in the data portion of a packet.
The AdditionalData will be used to create an extension of the IODEF
model to include a hexadecimal formatted packet including all
packet header information plus 8 bytes of payload. RID requires
the first 28 bytes of an IP v4 packet in order to perform a trace.
The required number of bytes provides the IP header in an IP V4
packet, which is 10 bytes long, the TCP/UDP/ICMP header is also 10
bytes long, plus an additional 8 bytes of payload to distinguish
the packet for tracing purposes. RID requires 48 bytes for an IP
V6 packet in order to distinguish the packet in a trace. The input
mechanism should be flexible enough to allow intrusion detection
systems or packet sniffers to be the source of the information.
The system creating the RID message should also use the packet
information to populate the Incident class information in order to
avoid human error, but also allow a system administrator to
override the automatically populated information.
As required for an IODEF extension in (IODEF Section 4.2), the
parameter entities for extensions to the IODEF model are defined
here to allow for proper parsing of the required extensions to the
IODEF model used in RID messages or documents. The definition
contains the location of the extension DTD and references the
entities:
%x-IPPacket;
%x-NPPath;
%x-TraceStatus; ]>
The AdditionalData class from the IODEF model is extended to
facilitate RID communications as follows:
+------------------+
| AdditionalData |
+------------------+
| ANY |
| |<>---(0..*)----[ IPPacket ]
| ENUM restriction |
| ENUM type |<>---{1..*}----[ NPPath ]
| STRING meaning |
| |<>---(0..1)----[ TraceStatus ]
+------------------+
Figure 3: the AdditionalData class extension
The aggregate classes that constitute the RID extensions for the
AdditionalData class are:
Moriarty Expires: August 28, 2004 [Page 22]
Internet-Draft February 28, 2004
IPPacket
Zero or many. The IP Packet that will be used to trace to the
source of a security incident reported through RID.
NPPath
One or many. The contact information for the NPs involved in a
trace, which includes information on the actual RID or NMS
systems involved in the trace.
TraceStatus
Zero or One. This is used only in Type 2, Authorization Status
messages to report back to the originating RID system if the
trace will be continued by each NMS or RID system that received
a trace request in the path to the source of the traffic.
The attributes of the AdditionalData class as defined in the IODEF
model. Specific meanings have been added for use as strings in the
meaning attribute.
restriction
optional. Defined in section 3.2 of the IODEF model.
Type
Required. ENUM. The data type of the element content. The
permitted values for this attribute are in the IODEF document.
The default value is "string", and MUST be set to "xml" for all
extensions to the IODEF model as stated in the IODEF Data Model
(Section 4.2).
Meaning
Mandatory. STRING. An identifier used to determine which
extension of the AdditionalData attribute is used. In the
context of RID, the following identifiers are valid:
1. RID-IPPacket. The packet information used to trace attack
traffic used for RID incident response.
2. RID-NPPath. The Network Providers in the path of a trace that
was either the origin of the request or an NMS in the path
of the trace.
3. RID-TraceStatus. Trace Status is used in the Type 2 message.
It lists the response from the upstream provider that received
either a Trace request (Type 1) or a Relay request (Type 4)
message and notifies the originator of a request along with
all NPs in the downstream path if the trace will continue in
the current network that has received the request.
4.2.5.1 IPPacket Extension
The IPPacket information will be represented through the
AdditionalData class extension of IODEF.
Moriarty Expires: August 28, 2004 [Page 23]
Internet-Draft February 28, 2004
+-----------------------+
| IPPacket |
+-----------------------+
| ENUM restriction |<>-----------[ IPVersion ]
| |
| |<>-----------[ HexPacket ]
| |
| |<>---(0..*)--[ IPPacket ]
+-----------------------+
Figure 4: the IPPacket class
The aggregate classes that constitute the NPPath class are:
IPVersion.
One or Many. STRING. The IP version of the packet used in the
trace.
1. IPv4
2. IPv6
HexPacket. HexBinary. A packet in hexadecimal format using the
xs:hexBinary XML data type.
28 bytes for an IPv4 packet.
48 bytes for an IPv6 packet.
IPPacket
Zero or many. Recursive definition of IPPacket, allowing for
grouping of data. This may be used if more than one example
packet will be sent in a single trace or relay request.
Moriarty Expires: August 28, 2004 [Page 24]
Internet-Draft February 28, 2004
4.2.5.2 NPPath Extension
The path information will also be an extension of the
AdditionalData class.
+------------------+
| NPPath |
+------------------+
| ENUM restriction |<>---{0..1}----[ name ]
| |
| |<>---{0..*}----[ RegistryHandle ]
| |
| |<>-------------[ Node ]
| |
| |<>---{0..*}----[ Email ]
| |
| |<>---{0..*}----[ Telephone ]
| |
| |<>---{0..1}----[ Fax ]
| |
| |<>---{0..1}----[ Timezone ]
| |
| |<>---{1..*}----[ NPPath ]
+------------------+
Figure 5: the NPPath class
The aggregate classes that constitute the NPPath class are:
name
Zero or one. NAME. The name of the contact. The contact may
either be an organization or a person. The type attribute
dictates the semantics (organization or person).
RegistryHandle
Zero or many. The handle name in a registry. Care must be taken
to ensure that a handle is meaningful to the recipient.
Intra-organizational handles are of not much use for
extra-organizational communication.
Node
One. The Node class is used to identify a host or network
device, in this case to identify the system communicating RID
messages or the NPÆs NMS.
The base definition of the class is reused from the IDMEF
specification, see Section 4.2.7.1 of [7] in the IODEF
specification IODEF 3.18.
Email
Zero or many. EMAIL. The email address of the contact formatted
according to Section 2.2.12.
Moriarty Expires: August 28, 2004 [Page 25]
Internet-Draft February 28, 2004
Telephone
Zero or many. PHONE. The telephone number of the contact
formatted according to documentation in Section 5.21 of RFC2256.
Fax
Zero or one. PHONE. The facsimile telephone number of the
contact formatted according to documentation in Section 5.21 of
RFC2256.
Timezone
Zero or one. STRING. The timezone in which the contact resides.
NPPath
One or many. Recursive definition of NPPath, allowing for
grouping of data. This is necessary in order to provide the
complete list of systems communicating in the RID trace or relay
request. The first NPPath definition is used for the originating
host and NP information, the second listing is for the first NP
that receives a request. All subsequent entries are used to list
the information for each RID system for the NPs involved in the
trace that a request has been sent to.
4.2.5.3 TraceStatus Extension
The TraceStatus information will also use AdditionalData.
+-------------------+
| TraceStatus |
+-------------------+
| |
| ENUM restriction |<>-------[ AuthorizationStatus ]
| |
+-------------------+
Figure 6: the TraceStatus class
The aggregate elements that constitute the TraceStatus class are:
AuthorizationStatus
Required. ENUM. The listed values are used to provide a response
to the requesting CSIRT of the status of a trace request in the
current network.
1. Approved. The trace was approved and will begin in the current
NP.
2. Denied. The trace was denied in the current NP. The next
closest NP can use this message to filter traffic from the
upstream NP using the example packet to help mitigate the
effects of the attack as close to the source as possible. The
Type 2 message must be passed back to the originator and a Type
3 used from the closest NP to the source to indicate actions
Moriarty Expires: August 28, 2004 [Page 26]
Internet-Draft February 28, 2004
taken.
3. Pending. Awaiting approval and a time-out period has been
reached which resulted in this pending status and Type 2
message being generated.
4.3 RID Documents Defined by Message Type Derived from IODEF
This section includes the mandatory IODEF information used in all
RID messages. Since RID is a wrapper for an IODEF document, the
full IODEF specifications should be implemented, but the following
section identifies the IODEF fields that must be filled in when
generating a RID message or document. Other fields may optionally
be filled in to provide further information to an incident handler
and thus must be implemented for proper parsing of a RID message
wrapping an IODEF document. This section will reference the IODEF
model and the sections of the IODEF RFC where each IODEF class can
be located.
Incident Class (IODEF 3.2)
Purpose: The Purpose will always be 1. Handling for RID messages
Restriction: Sender can select from the IODEF specifications for
this value and fill in as appropriate
IncidentID (IODEF 3.3)
GUID: Name of CSIRT or NP that created the document
Alternate ID (IODEF 3.4)
This incident ID is one set by another CSIRT that is tracking the
same or a similar incident. This value should not be set in the
initial request, but may be set in a request passed forward by an
NP in the path of a trace.
Related Activity Class (IODEF 3.5)
This class is optional if an AlternateID is specified, otherwise
it is unnecessary.
IncidentData Class (IODEF 3.7)
Description: Text description of the incident - Mandatory for RID
Assessment: Characterization of the impact - Mandatory for RID,
(reference IODEF section 3.12)
Impact aggregate class (IODEF 3.12.1) MUST be used along with
the Confidence class (IODEF 3.12.5) in the Assessment Class.
The other impact classes are optional and may depend on the
Incident type to determine if the additional classes are
appropriate.
Method: Techniques used in attack - Optional for RID (IODEF 3.11)
DetectTime: Mandatory for RID (Time Class - IODEF 2.26 and 3.9)
StartTime: Mandatory for RID (Time Class - IODEF 2.26 and 3.9)
EndTime: Optional for RID, incident may still be in process in
which no end time can be listed (Time Class - IODEF 2.26, 3.9)
ReportTime: Mandatory for RID (Time Class - IODEF 2.26 and 3.9)
Moriarty Expires: August 28, 2004 [Page 27]
Internet-Draft February 28, 2004
Contact: Mandatory for RID (IODEF 3.8)
The required aggregate classes for the contact class in RID
messages include:
Name, RegistryHandle (IODEF 3.8.1), Email, Telephone
The attributes in the contact class are required in the IODEF
document and thus are required in RID messages and include:
Restriction, Role, and Type
Expectation: Mandatory for RID (IODEF 3.10)
The following attributes are required in RID messages:
Priority and Category
Note: Although Category is required in a request, the NP
closest to the source of the attack decides upon the
ultimate response.
History: Required for upstream trace relays or requests, but not
For the original request, (IODEF 3.13). May also be used to
Further describe actions taken along the NP Path of a trace.
EventData: Required for RID (IODEF 3.14 - 3.16)
Much of the EventData Class is a duplicate for the aggregate
IncidentData class and the proper uses of this class are defined
in the IODEF RFC.
System class (IODEF 3.17)
The System class is required and the information listed in this
class can be automatically entered into this class from the
packet used in the incident trace by the RID implementation.
Information must be reviewed by the submitter and the additional
required classes and attributes filled in for proper processing
of a request. The system class MUST be used to list the
source and the target or intermediate system(s) and MUST note if
the system was spoofed through the use of the Node class (IODEF
3.18). A separate instance of the System class (and Node Class)
is used for each type of system listed in the document. The
spoof section MUST be used in the System EventData Class of all
RID messages and is set to the value of spoofed for all requests
(Type 1) that require an actual trace of network traffic. In a
Type 4 Relay Request, the source is believed to be valid. All
other classes of the System Class are optional as in the IODEF
document.
AdditionalData: RID messages require that the NP Path and the
IPPacket extensions are used to provide adequate information for
an upstream peer to perform a trace. The information contained
in the NPPath and IPPacket extensions must remain and be
maintained in each RID message type document. The TraceStatus
extension is used in message type 2 alone since it's purpose is
to let the downstream NP know if the trace was approved and will
begin in the next upstream network.
IPPacket (IP version of packet to be traced)
NPPath (Original Request should contain originator plus the
next peer in the upstream request, the host that is receiving
the request)
Moriarty Expires: August 28, 2004 [Page 28]
Internet-Draft February 28, 2004
TraceStatus (Approval status for the trace in the current
network)
Restriction
Optional. ENUM. The IODEF restriction should be used in
addition to the RID privacy and security guidelines since this
is optional on the part of the receiving end of an IODEF
message and is not enforced.
Note: The implementation of the RID system may obtain some of the
information needed to fill in the content required for each message
type automatically from packet input to the system or default
information such as that used in the NPPath extension.
4.3.1 Trace Request
Description: This message or document is sent to the Network
Management Station next in the upstream trace once the upstream
Source of the traffic has been identified.
The following information is required for message type 1 and will
be provided through:
RID Wrapper identifying Message Type 1
Time Stamps (DectectTime, StartTime, EndTime, ReportTime)
Incident Identifier (Incidnent Class, IncidentID)
Trace number - used for multiple traces of a single
Incident, must be noted
Confidence rating of Security Incident (Impact and Confidence
Class)
System Class is used to list both the Source and Destination
Information used in the attack and must note if the traffic
is spoofed, thus requiring an upstream trace request in RID
Packet used to trace incident across the network
IPPacket extension for RID
Path information of Network Management Systems used in the trace
NPPath extension for RID
[Free form test area for any additional information on
justification for relay message request, IODEF IncidentData
Description]
Digital signature from initiating NMS, passed to all systems in
upstream trace using XML digital signature
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. The incident identifier
must also be used to identify multiple trace requests from a
single incident.
Moriarty Expires: August 28, 2004 [Page 29]
Internet-Draft February 28, 2004
4.3.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.
The following information is required for Message Type 2 and will be
provided through:
RID Wrapper identifying Message Type 2
Time Stamps (DectectTime, StartTime, EndTime, ReportTime)
Incident Identifier (Incidnent Class, IncidentID)
Trace number - used for multiple traces of a single
Incident, must be noted
Confidence rating of Security Incident (Impact and Confidence
Class)
Status of trace request
TraceStatus extension for RID
Packet used to trace incident across the network
IPPacket extension for RID
Path information of Network Management Systems used in the trace
NPPath extension for RID
The last NP listed is the NP sending this Type 2 message.
All previous NPs listed in the NPPath must be retained.
Digital signature of responding NP for authenticity of Trace
Status Message, from the NP creating this message using
XML digital signature
[Additional free form text information on the attack,
History Class]
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 28, 2004 [Page 30]
Internet-Draft February 28, 2004
4.3.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.
The following information is required for Message Type 3 and will
be provided through:
RID Wrapper identifying Message Type 3
Time Stamps (DectectTime, StartTime, EndTime, ReportTime)
Incident Identifier (Incidnent Class, IncidentID)
Trace number - used for multiple traces of a single
Incident, must be noted
Confidence rating of Security Incident (Impact and Confidence
Class)
Action Taken (Expectation and Category Class)
Packet used to trace incident across the network
IPPacket extension for RID
Path information of Network Management Systems used in the trace
NPPath extension for RID
The last NP listed is the NP, which located the source of
the traffic (the NP sending the Type 3 message)
[Free form test area for any additional information on
The identified source of the attack traffic, IODEF
Description, Incident Class]
Digital signature of source NP for authenticity of source found
Message, the NP creating this message using XML digital
signature
[True Source address and other information on the attack,
History Class]
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.
Note: The Category Class may be expanded in IODEF at a later date
Moriarty Expires: August 28, 2004 [Page 31]
Internet-Draft February 28, 2004
to accommodate all of the possible actions taken as a result of a
RID trace or relay request. Until that time occurs, the History
class should be used to note all actions taken close to the source
of a trace. The additional options include, but may not be limited
to:
Action Taken (multiple selections permitted)
______________________________________________
No action at this time
Filter at upstream peer ingress point
Rate Limit attack traffic
Network segment blocked
Host (IP Address) blocked from Internet access
Protocol port used in attack blocked
Alert generated
Site notified
Other
4.3.4 Relay Message Request
Description: This message type is used when the source of the
traffic is believed to be valid. The purpose of the relay message
request is to leverage the existing bi-lateral peer relationships
in order to notify the network provider closest to the source of
the valid traffic of some event that has occurred, which may be a
security related incident.
The following information is required for Message Type 4 and will
Be provided through:
RID Wrapper identifying Message Type 4
Time Stamps (DectectTime, StartTime, EndTime, ReportTime)
Incident Identifier (Incidnent Class, IncidentID)
Trace number - used for multiple traces of a single
Incident, must be noted
Confidence rating of Security Incident (Impact and Confidence
Class)
Packet used to trace incident across the network
IPPacket extension for RID
Path information of Network Management Systems used in the trace
NPPath extension for RID
[Free form test area for any additional information on
justification for relay message request, IODEF Description]
Digital signature from initiating NMS, passed to all systems in
upstream trace using XML digital signature
Security considerations would include the ability to encrypt the
contents of the relay message request using the public key of the
destination network provider. The incident number would increase
as if it were a trace request message in order to ensure
Moriarty Expires: August 28, 2004 [Page 32]
Internet-Draft February 28, 2004
uniqueness within the system. The relaying peers would also
append their AS information as the request message was relayed
along the web of network providers so that the source found
message could utilize the same path as set of trust relationships
for the return message, which would indicate any actions taken.
The request would also be recorded in both the state table of the
initiating and destination NP NMS. The destination NP would be
responsible for any actions taken as a result of the request in
adherence to any service level agreements or internal policies.
The NP should confirm the traffic actually originated from the
suspected system before taking any action and confirm the reason
for the request.
Note: The AS number of the source IP address is listed as the
first AS in the path information for the NMSs. The last relay
packet sent to the source AS will include the same path
information twice. The AS information is necessary in order to
direct the message appropriately to the closest NP to the source
of the traffic. In the case of message type 4, the filter
information may be encrypted, so the relaying NMSs may have no
other way to determine how to direct the packets.
Moriarty Expires: August 28, 2004 [Page 33]
Internet-Draft February 28, 2004
4.3.5 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
Figure 7: RID Communication Flow
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 Description element of the document to
provide an additional confidence indication to the upstream NPs in
Moriarty Expires: August 28, 2004 [Page 34]
Internet-Draft February 28, 2004
the path of the trace.
A single trace may be limited in time by factors determined by the
single network trace system used by the NPs in the path of the
trace. The single trace system may either trace a packet
dynamically or search through stored packet data for evidence that
the packet had traversed the network. In the case of a dynamic
trace, the traffic would need to be active on the network for the
trace to be successful or the trace would cease and a message would
be sent to indicate the status that the trace cannot continue to
the originating NMS through the consortiumÆs or bilateral trust
relationships formed by the RID or NMS systems in the path of the
trace. The packet trace may also be limited due to the storage
space on networks, which save traffic data. A trace status message
would be sent in this case as well to provide the path information
up to the point in which the trace could no longer be continued to
the originator of the trace through the RID systems in the path of
the trace. This information could also be used to block or
mitigate the traffic at the participating NP closest to the source.
4.3.6 RID Trace Request Example
The example listed is of a trace request, based on the incident
report example from the IODEF document. The AdditionalData
extensions were added as appropriate for a Trace Request message
using the IPPacket and NPPath classes. The example given is that
of a CSIRT reporting a DoS attack in progress to the upstream NP.
The request asks the next NP to continue the trace and have the
traffic mitigated closer to the source of the traffic.
CERT-FOR-OUR-DOMAIN#207-1
Host involved in DOS attack2004-02-02T22:19:24+00:002004-02-02T22:49:24+00:002004-02-02T23:20:24+00:00Rate limit traffic close to
sourceCSIRT-FOR-OUR-DOMAINcsirt-for-our-domain@ourdomain
Moriarty Expires: August 28, 2004 [Page 35]
Internet-Draft February 28, 2004
Constituency-contact for 10.1.1.2Constituency-contact@10.1.1.2CSIRT-FOR-OUR-DOMAIN#207-1
CERT-FOR-OUR-DOMAIN
Notification sent to next upstream NP
closer to 10.1.1.22001-09-14T08:19:01+00:0038765
10.1.1.2
80
192.168.1.2
xmlns:RID="http://www.ietf.org/iodef/RID-IPPacket.html"
xmlns="http://www.ietf.org/iodef/RID-IPPacket.html">
IPv4(Hex Binary of Packet contents)
xmlns:RID="http://www.ietf.org/iodef/RID-NPPath.html"
xmlns="http://www.ietf.org/iodef/RID-NPPath.html">
CSIRT-FOR-OUR-DOMAINCSIRT123csirt-for-our-domain@ourdomain
Moriarty Expires: August 28, 2004 [Page 36]
Internet-Draft February 28, 2004
172.17.1.2
CSIRT-FOR-UPSTREAM-NPCSIRT345csirt-for-upstream-np@ourdomain
172.20.1.2
<-- Digital Signature applied to the packet using the XML Digital
Signature W3C Recommendations. This will be fixed to provide
a proper example in the upcoming draft release.
(
()?
)+
()?
(
-->
5. RID IODEF Extension Document Type Definition
Moriarty Expires: August 28, 2004 [Page 39]
Internet-Draft February 28, 2004
6. Message Transport
RID messages or documents can be transported over existing
protocols since the messages are in an XML format using the IODEF
model. The privacy and security considerations are such that a
means to encrypt and sign the data must be provided. Encrypting or
signing the documents may be done within the capabilities of XML,
as defined in the IODEF specification. The use of transport
protocols to encrypt data such as S/MIME and HTTPS are encouraged
to provide an additional level of security, integrity, and
authentication. The encryption requirements and considerations for
RID are discussed in the Security section of this document.
6.1 Message Delivery Protocol - Integrity and Authentication
The RID 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
protocol for inter-NMS communication could provide the
transport mechanism for message delivery.
Security considerations must include the integrity, authentication,
privacy, and authorization of the messages sent between RID
communication or NMS systems. The communication between RID
systems must be authenticated and encrypted to ensure the integrity
of the messages and the RID systems involved in the trace. Another
concern that needs to be addressed is authentication for a request
that traverses multiple 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 and privacy of the
communication.
The transport mechanism selected (S/MIME, HTTP, HTTPS, etc.) may be
agreed upon by a consortium using the RID protocol to ensure
consistency among the peers. Consortiums may vary their selected
transport mechanisms and thus must decide up on a mutual protocol
to use for transport when communicating with peers in a neighboring
consortium using RID. RID systems MUST support both the S/MIME and
HTTPS protocols and properly integrate with a public key
infrastructure (PKI) managed by the consortium, other protocols are
optional for implementation. Consortiums are discussed later in
the paper.
Moriarty Expires: August 28, 2004 [Page 40]
Internet-Draft February 28, 2004
6.2 Transport Communication
Out-of band communications dedicated to NP interaction for RID
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 messaging
on the network.
In order to address the integrity and authenticity of messages,
transport encryption MUST be used to secure the traffic sent
between RID or NMS systems with pre-defined trust relationships.
Systems with predefined relationships for RID would include those
who peer in a consortium with agreed upon appropriate use
regulations and for peering consortiums to link together a larger
group of networks.
Systems used to send authenticated RID messages between networks
MUST use a dedicated and secured interface to connect to a border
Network's RID system. If a single system is used to connect to
multiple RID systems or NMS(s), each connection must have a
dedicated interface and the security requirements MUST meet those
agreed upon through the consortium regulations, peering, or service
level agreements (SLA). The NMS interface must only listen for and
send RID messages over an encrypted tunnel and meeting a minimum
requirement of algorithms and keys established by the consortium,
peering, or SLA agreement. Transport Layer Security (TLS) or
Secure MIME are appropriate protocols to provide the necessary
level of security and are established standards. 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. The
encryption strength must adhere to import and export regulations of
the involved countries of a data exchange.
6.3 Authentication of RID Protocol
In order to insure the authenticity of the RID messages, a
message authentication scheme using a public key infrastructure
(PKI) must be inherent to the protocol. SOAP tied together with
WS-Security requires a trust center such as a PKI or Kerberos key
distribution center for the distribution of credentials to provide
the necessary levels of security for this protocol. Public key
certificates pairs issued by a trusted Certificate Authority
(CA) will be used to provide the necessary level of authentication
and encryption for the RID protocol. The CA used for RID
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
for encryption via either Transport Layer Security (TLS) used in
Moriarty Expires: August 28, 2004 [Page 41]
Internet-Draft February 28, 2004
the HTTPS protocol or Secure MIME (S/MIME).
Hosts receiving a RID 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 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.
The IODEF specification must be followed for digital signatures to
provide the authentication and integrity aspects required for
secure messaging between network providers. The use of digital
signatures in RID XML messages MUST follow the World Wide Web
Consortium (W3C) recommendations for signature syntax and
Processing when either the XML encryption or digital signature are
used within a document. Web Services Security (WS-Security) MUST
be followed for encryption and digital signatures on the SOAP
messaging.
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. The WS-Policy specifications will be
used for the policy verification, which may determine if a trace
will be continued.
6.4 Authentication Considerations for a Multi-hop Trace Request
Bilateral 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 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
Moriarty Expires: August 28, 2004 [Page 42]
Internet-Draft February 28, 2004
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. This digital signature from the originating RID or
NMS system is performed on the IPPacket class of the RID extension
to the IODEF model in the AdditionalData class following the XML
digital Signature specifications from W3C [17]. The signature MUST
be passed to all parties that receive a trace request and each
party MUST be able to validate the digital signature. In order to
accommodate that requirement, the element HexPacket that MUST also
remain unchanged as a request is passed along between providers is
the only element for which the signature is applied. 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 section will also
provide the certificates used to digitally sign the necessary
information in the trace requests to meet the requirement of
authenticating the original request. 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 of the
packet MUST be included in all upstream trace requests to allow
subsequent NPs to verify the authenticity of a trace request.
6.4.1 Public Key Infrastructures and Consortiums
Consortiums of NPs are an ideal way to establish a communication
web of trust for RID messaging. The consortium could provide
centralized resources, such as a PKI, and established guidelines
for use of the RID protocol. The consortium would also assist in
establishing trust relationships between the participating NPs to
achieve the necessary level of cooperation and experience sharing
among the consortium entities. The consortium may also be used for
other purposes to better facilitate communication among NPs in a
common area (Internet, region, government, education, private
networks, etc.).
Using a PKI to distribute certificates used by RID systems provides
an already established method to link trust relationships between
NPs of consortiums that would peer with NPs belonging to a separate
consortium. In other words, consortiums could peer with other
consortiums to enable communication of RID messages between the
participating NPs. The PKI along with Memorandum of Agreements
could be used to link border directories to share public key
information in a bridge, hierarchy, or a single cross certification
relationship.
Consortiums also need to establish guidelines for each
participating NP to adhere to. The guidelines MUST include:
O Physical and practices to protect RID systems
O Network and application layer protection for RID systems and
communications
Moriarty Expires: August 28, 2004 [Page 43]
Internet-Draft February 28, 2004
O Proper use guidelines for RID systems, messages, and requests
O A PKI to provide authentication, integrity, and privacy
6.5 Privacy Concerns and System Use Guidelines
Privacy issues raise many concerns when information sharing is
required to achieve the goal of stopping or mitigating the affects
of a security incident. The Web Services Security Model,
specifically the WS-Policy and WS-Privacy specifications will be
used to automate the enforcement of the privacy concerns listed
within this document. The privacy and system use concerns that
MUST be addressed in the RID system and other integrated components
include:
o Privacy of data monitored and/or stored on IDS for attack
detection
o Privacy of data monitored and stored on systems used to trace
traffic across a single network
o Privacy of the identity of a host used in an attack
o Privacy of information such as the source and destination used
for communication purposes over the monitored or RID connected
network(s)
o Protection of data from being viewed by intermediate parties
in the path of a relay request MUST be considered
o System use restricted to security incident handling within the
local regionÆs definitions of appropriate traffic for the network
monitored and linked via RID in a single consortium also abiding
by the consortiums use guidelines
o System use prohibiting the consortiumÆs participating NPs from
inappropriately tracing non attack traffic to locate sources or
mitigate traffic unlawfully within the jurisdiction or region
o System use between peering consortiums MUST also adhere to any
government communication regulations that apply between those two
regions, such as encryption export and import restrictions
o System use between consortiums MUST not request traffic traces
and actions beyond the scope intended and permitted by law or
inter-consortium agreements
o System use between consortiums MUST respect national boundary
issues and limit requests to appropriate system use and not to
achieve their own agenda to limit or restrict traffic that is
otherwise permitted within the country in which the peering
consortium resides
RID is useful when trying to determine the true source of a
packet when it traverses multiple networks or to provide a means to
communicate security incidents and a way to automate the response.
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 determine the identity of the source host or the network
provider used by the source of the traffic. It should be noted
that the trace mechanism used across a single network provider may
Moriarty Expires: August 28, 2004 [Page 44]
Internet-Draft February 28, 2004
also raise privacy concerns for the clients of the network.
Methods that may raise concern include those which involve storing
packets for some length of time in order to trace packets after the
fact. Monitoring networks for intrusions and for tracing
capabilities also raise concerns for potentially sensitive valid
traffic that may be traversing the monitored network. IDS and
single network tracing is outside of the scope of this document,
but the concern should be noted and addressed within the use
guidelines of the network. Some IDS and single network trace
mechanisms attempt to properly address these issues. RID 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 messaging.
The identity of the true source of an attack packet being traced
trough RID could be sensitive. The true identity listed in a type
3 or source found message could be protected through the use of
encryption on the fields containing the identity for the
originating NP to decrypt or depending on SLAs, the action taken
may be listed without the identity being revealed to the
originating NP. The ultimate goal of the RID communication system
is to stop or mitigate attack traffic and not to ensure the
identity of the attack traffic is known to all involved parties
including the site under attack. The NP that identifies the source
would need to deal directly with the involved parties and proper
authorities in order to determine the guidelines for the release of
such information if it was regarded as sensitive. 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 listed in the RID message may be
the only additional information reported in the source found
message 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. The textual descriptions should
include details of the incident in order to protect the reputation
of the unknowing attacker and prevent the need for additional
investigation where applicable. 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 could be seen as sensitive to the
parties involved. A specific example of this concern may be that
an attack occurred between a specific source and destination and
every network provider in the path of the trace would now be aware
that the cyber attack occurred. In cases where compromised systems
are responsible for the attack, this may not raise privacy
Moriarty Expires: August 28, 2004 [Page 45]
Internet-Draft February 28, 2004
concerns. However, in a targeted attack it may not be desirable
for the knowledge of two nation states battling a cyber war to
become general knowledge to all intermediate parties. However, 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 and not the identity of the offending host.
In the case of a relay request, where the originating NP is aware
of the NP that will receive the request for processing, the free
form text areas of the document could be encrypted using the public
key of the destination NP to ensure that no other NP in the path
can read the contents. The encryption would be accomplished
through the W3C specifications for encrypting an element.
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 source was found to provide another layer of
protection to the attack source identity. This provides an
additional level of abstraction to hide the identity and the NP of
the identified source of the traffic. Legal action may override
this technical decision after the trace has taken place, but that
is out of the technical scope of this document.
Privacy concerns when using message type 4 to request action close
to the source of valid attack traffic needs to be considered.
Although the intermediate NPs would relay the request to the
closest NP to the source, the intermediate NPs would not require
the ability to see the contents of the packet or the text
Description field(s) in the request. This message type does not
require any action by the intermediate RID systems, except to relay
the packet to the next NP in the path. Therefore, the contents of
the request may be encrypted. The intermediate NPs would only need
to know how to direct the request to the manager of the AS number
in which the source IP address belongs.
Traces must be legitimate security related incidents and not used
for purposes such as sabotage or censorship. An example of such
abuse of the system would include a request to block or rate limit
legitimate traffic to prevent information from being shared between
users on the Internet (restricting access to online versions of
papers) or restricting access from a competitor's product in order
to sabotage a business.
Inter-consortium RID communications raise additional issues
especially where the peering consortiums reside in different
regions or nations. Trace requests and requested actions to
mitigate traffic must adhere to the appropriate use guidelines and
yet prevent abuse of the system. First, the peering consortiums
MUST identify the types of traffic that can be traced between the
Moriarty Expires: August 28, 2004 [Page 46]
Internet-Draft February 28, 2004
borders of the participating NPs of each consortium. The traffic
traced should be limited to security incident related traffic.
Second, the traces permitted within one consortium if passed to a
peering consortium may infringe upon the peering consortiumÆs
freedom of information laws. An example of this would be that a
consortium in China may permit a trace of spam containing
objectionable material, outlawed within the country. The RID trace
may be a valid use of the system within the confines of the network
border, but MUST not be permitted to continue across network
boundaries where such content is permitted under law and could have
the effect of restricting access to data unnecessarily. A
continued trace into another country may break the laws and
regulations of that nation. Any such traces MUST cease at the
country's border.
The privacy concerns listed in this section have addressed issues
of privacy among the trusted parties involved in a trace within an
NP, a RID consortium, and peering RID consortiums. Data
used for RID communications must also be protected from parties
that are not trusted. This protection is provided though the
authentication and encryption of documents as they traverse the
path of trusted servers. Each RID system MUST perform a
bi-directional authentication when sending a RID message and use
the public encryption key of the upstream or downstream peer to
send a message or document over the network. This means that the
document is decrypted and re-encrypted at each RID system either
via S/MIME or TLS over HTTPS. The RID messages must be decrypted
at each RID system in order to properly process the request or
relay the information. Today's processing power is more than
sufficient to handle the minimal burden of encrypting and
decrypting relatively small typical RID message.
7. Security Considerations
Communication between NP's RID or NMS systems must be protected.
An out of band network, either logical or physical would prevent
outside attacks against NMS communication. An out of band
connection would be ideal, but not necessarily practical. By using
authenticated encryption tunnels between RID systems the data in
transit would be protected as well as to ensure the integrity of
the data and MUST be used. In the case where the RID network forms
a bilateral interconnection of adjacent peers, the RID systems
would permit messages between peering networks, which would relay
messages to upstream peers on behalf of the initiating network
peer. The trust would be based on consortiums and established
trust relationships of PKI cross certifications of consortiums.
By using SOAP, Web Services Security Model, Transport Layer
Security, and the XML security features of encryption and digital
signatures, RID takes advantage of existing security standards.
The standards provide clear methods to ensure messages are secure,
authenticated, authorized, meet policy and privacy guidelines, and
Moriarty Expires: August 28, 2004 [Page 47]
Internet-Draft February 28, 2004
integrity is maintained.
Policies between NPs must be established to provide guidelines for
communication. The policy should include communication methods,
security, and fall-back procedures. The Policy should establish a
method to protect communications of RID 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 directly
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 RegistryHandle 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, where the PKI is a
potential solution.
Note: The contact information and corresponding IP address for a
network RID system would be shared between cooperating networks via
a predefined table. This information may be stored locally on RID
systems or a central database, X.500, or LDAP server accessible on
the secured network used for inter-NP messaging on NMS. The
repository would also be used as the border directory to other
consortiums for sharing public key information necessary to
establish and protect communications.
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.
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 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 and/or the
relay message could be used for notification purposes to the NP
closest to the source to allow for an automated response and action
to mitigate the effects of the attack traffic. If tools such as
traceroute do not provide the necessary path information in a
security incident, the trace request MUST note the system use to
avoid instances where the trace is providing information outside
Moriarty Expires: August 28, 2004 [Page 48]
Internet-Draft February 28, 2004
the intended and agreed upon scope of the system.
8. Summary
Denial of service attacks and other security incidents have always
been difficult to trace as a result of the spoofed sources,
resource limitations, and bandwidth utilization problems.
Incident response is often slow as well even when the valid address
is known because of the resources required to notify the
responsible party of the attack and then to stop or mitigate the
attack traffic. 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 and
other attack detection techniques need to be integrated into the
network to provide automated response capabilities. The automated
response capabilities need to identify and trace attacks quickly
without resource intensive side effects. Integration with a
centralized communication system to coordinate the detection,
tracing, and identification of attack sources on a single network
are essential. RID provides a way to integrate a network providers
resources with their network components for each aspect of
detection and identification and extends the communication
capabilities where an attack source may have originated on another
network. This is accomplished through the flexible IODEF XML based
documents that may originate on an IDS system, trigger a network
trace, communicate a trace request to an upstream provider and
result in an action to stop or mitigate the attack traffic. The
messages are communicated between peers using the SOAP protocol and
security considerations are provided through existing standards
such as the Web Security Model and XML encryption and digital
signatures. RID provides the timely communication between NPs,
which is essential in incident handling.
Moriarty Expires: August 28, 2004 [Page 49]
Internet-Draft February 28, 2004
9. 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.
[RFC2256] "A Summary of the X.500(96) User Schema for use with
LDAPv3", Wahl, M., December 1997.
[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.
Moriarty Expires: August 28, 2004 [Page 50]
Internet-Draft February 28, 2004
[RFC3821] "An Internet Attribute Certificate Profile for
Authorization". Farrell, S., Housley, R. April 2002.
[RFCXXXX] ôThe Incident Data Exchange Format Data Model and XML
Implementationö. J. Meijer, R. Danyliw, Y. Demchenko. September
2003.
http://www.ietf.org/internet-drafts/draft-ietf-inch-iodef-02.txt
[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. Published in proceedings
of the 2001 USENIX Security Symposium.
[4] 'MULTOPS: A Data-Structure For Bandwidth Attack Detection'.
Thomer M. Gil, Massimiliano Poletta. Published in proceedings of
the 2001 USENIX Security Symposium.
[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 Houle,
George Weaver, Neil Long, and Rob Thomas. 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 28, 2004 [Page 51]
Internet-Draft February 28, 2004
[14] Advanced and Authenticated Marking Schemes for IP Traceback.
D. Song and A. Perrig. IEEE INFOCOM 2001.
[15] XML Schema. Eric Van der Vlist. OÆReilly. 2002.
[16] Extensible Markup Language (XML) 1.0 (Second Edition). W3C
Recommendation. T. Bray, E. Maler, J. Paoli, C. M. Sperberg-
McQueen. October 2000.
http://www.w3.org/TR/2000/REC-xml-20001006
[17] XML-Signature Syntax and Processing. W3C Recommendation.
M. Bartel, J. Boyer, B. Fox, B. LaMacchia , E. Simon. February
2002. http://www.w3.org/TR/xmldsig-core/#sec-Design
[18] XML Encryption Syntax and Processing, W3C Recommendation.
Imamura, T., Dillaway, B. and E. Simon, "", December 2002.
http://www.w3.org/TR/xmlenc-core/
[19] Security Architecture for Open Agent Systems. Vrije
Universiteit. Y. Demchenko, B. Overiender, H. M. Boonstra.
http://carol.science.uva.nl/~demch/worksinprogress/
draft-saas-paper03.pdf
[20] ôSecurity in a Web Services World: A Proposed Architecture
and Roadmapö. IBM and Microsoft. April 2002.
http://www-106.ibm.com/developerworks/webservices/library/ws-secmap
Moriarty Expires: August 28, 2004 [Page 52]
Internet-Draft February 28, 2004
9.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 as well as providing recommendations to simplify and
secure the protocol: Iljitsch van Beijnum, Steve Bellovin, Yuri
Demchenko, Jean-Francois Morfin, Jose Nazaro, Stephen Northcutt,
Jeffrey Schiller, and Tony Tauber.
9.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 28, 2004 [Page 53]