Internet DRAFT - draft-hazeyama-traceback-field-trial
draft-hazeyama-traceback-field-trial
Inetnet Engineering Task Force H. Hazeyama
Internet Draft NAIST
Intended status: Informational K. Wakasa
Expires: August 2010 JDCA
T. Takemori
KDDI R&D Lab.
February 28, 2010
A Field Trial of Inter-Domain Traceback Operation in Japan
draft-hazeyama-traceback-field-trial-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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
Hazeyama, et al. Expires August 28, 2010 [Page 1]
Internet-Draft Field Trial of Traceback in Japan February 2010
This Internet-Draft will expire on August 28, 2010.
Copyright and Licence Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
This memo reports a field trial of Inter-Domain Traceback Operation
in Japan as a proof of concept on IP packet traceback. This field
trial was carried out with 15 commercial ISPs and one traceback
control center which was a mediator among participated ISPs.
Table of Contents
1. Introduction................................................3
2. Operational Models and Configurations........................3
2.1. Operational and Legal Requirements for Traceback Systems.3
2.2. The Operational Model in this field trial...............5
2.3. The configurations of this field trial.................13
2.3.1. Participates......................................13
2.3.2. Traceback systems.................................13
3. The summary of the experiments.............................14
3.1. System Performance.....................................15
3.2. Validation of management system, and operational efficiency16
3.3. System Adaptability....................................18
4. Security Considerations.....................................19
5. IANA Considerations........................................19
6. Summary....................................................19
7. References.................................................20
7.1. Normative References...................................20
7.2. Informative References.................................20
8. Acknowledgments............................................21
Hazeyama, et al. Expires August 28, 2010 [Page 2]
Internet-Draft Field Trial of Traceback in Japan February 2010
1. Introduction
We had a field trial of inter-domain IP traceback operation with
fifteen ISPs in Japan with their real network environments, from May
to the end of August in 2009. In this memo, we briefly report this
field trial. The details of the evaluation results have been reported
in [Wakasa2010].
2. Operational Models and Configurations
While formulating an operation model of an inter-domain traceback, we
identified following 5 assumptions;
1) Establish a traceback control facility.
2) Collect traceback data at all times.
3) Operational costs are treated as something to be resolved
separately.
4) Legal charges are not expected to be initiated by the control
facility.
5) With respect to judging whether or not there is an attack, we
expect that judgment criteria will be created separately.
According to these assumptions, we designed traceback systems and
the operational model.
2.1. Operational and Legal Requirements for Traceback Systems
According to our survey of commercial ISPs regarding their legal
requirements, to operate in a legitimate manner an automatic
traceback is allowed to trace only packets necessary for an incident
response. Also, the requirements for implementing lawful traceback
have been identified through investigation of various countries'
related laws, and from the results of a survey of Japanese ISP's
opinions, these are summarized as follows;
(1) No destruction of data for communications, etc.
Traceback systems should have affinity for all kinds of packets.
Also, the deployment of a traceback system must not destruct some
kind of communication, cause an excessive increase in traffic or
cause damage to network equipment.
Hazeyama, et al. Expires August 28, 2010 [Page 3]
Internet-Draft Field Trial of Traceback in Japan February 2010
(2) Guaranteeing privacy of communications
To guarantee privacy of communications, acquired information for
tracing, such as an IP header or payload information must be
converted into hash values, with only those hash values to be
recorded or exchanged.
(3) Access restricted to only those conducting traces
Authentication must be carried out to ensure that the data
acquired for the purpose of tracking cannot be accessed by
individuals other than those responsible for conducting traces.
(4) Restriction of usages
Traceback system should be used as a supportive tool for incident
responses. As an incident response such as a DDoS attack, acts in
pursuit of lawful business must be applied, and a traceback
implemented.
(5) Protection of traceback data prior to the outbreak of an incident
Access to the traceback data acquired in advance for the purpose
of tracking must be restricted until the outbreak of a specific
incident.
(6) Obligation of confidentiality in the shared use of data
The shared use of the traceback data acquired for the purpose of
tracking must be limited to only those ISPs involved in the
coordination process.
(7) Information disclosure through appropriate methods
Details that can be disclosed from among the results of traceback
must be disclosed through the appropriate methods.
(8) Obligation of confidentiality for those conducting traces
Those conducting traces must accept obligations of
confidentiality with regard to the data acquired as a result of
traces.
Hazeyama, et al. Expires August 28, 2010 [Page 4]
Internet-Draft Field Trial of Traceback in Japan February 2010
(9) Development and application of security and privacy policies
The security policies and privacy policies of each ISP must be
developed and applied.
The details of these operational and legal requirements are written
in [Wakasa2009].
2.2. The Operational Model in this field trial
To satisfy these requirements, the process of carrying out traceback
is divided into automatic traceback phase and incident response phase,
shown in Figure 1 and Figure 2. In the automatic traceback phase, an
inter-domain traceback is carried out by traceback systems in second
order. On the other hand, in the incident response phase, the
operators of related ASs carry out an inter-domain traceback as a
part of an incident response in ten-minutes order.
The automatic traceback is composed of four components as follows;
(i) Attack detection
An Intrusion Detection System (IDS) is installed to detect attack
packets as shown in Figure 2. As described in Figure 2, Traceback
Client (TC) converts an alert from IDS to a traceback request
message. Each request message contains hash values of attack
packets upto 60 entries. Due to the legal requirement (2), the
packet information on a request message must be the hash value of
an issued packet. The hash encoding method in the field trial was
reported in [Kai2009].
(ii) Traceback System (TB System) to record AS communication packets
The TB systems in Figure 2 are based on hash-based traceback
scheme reported in [Kai2009]. Each TB system generates hash
values based on the header portion of packets that pass through
the boundaries linking ASs with other ASs, and temporarily stores
these hash values in memory.
(iii) Controller to identify the passage of attack packets
To exchange traceback information among ASs, we employed
InterTrack [InterTrack] as the controller component of the
Hazeyama, et al. Expires August 28, 2010 [Page 5]
Internet-Draft Field Trial of Traceback in Japan February 2010
automatic tracing. When the passage of an attack packet has been
confirmed, the ITM (Inter-domain Traceback Manager) requests
execution of a traceback recursively to an adjacent AS ITM, and
posts the traceback results to the database (TB event Database in
Figure 1.).
An end-to-end traceback result is summarized as full or partial
AS path(s) from source AS to Destination AS(s) and the status of
each AS. The variations of the status of an AS in this field
trial were follows;
``Destination'' :
The AS would be the destination of issued packets. Actually,
the issued packets were recorded in TB systems as the incoming
direction to the AS.
``Source'' :
The AS would be the source of issued packets. Actually, the
issued packets were recorded in TB systems as the outgoing
direction from the AS.
``Transit'' :
The AS would be located in the forwarding AS path of the
issued packets. Actually, the issued packets were recorded in
TB systems as both the incoming direction and outgoing
direction on the AS.
``Translated'' :
Some translation of the issued packets would be occurred in
the AS. In this field trial, ``Translated'' AS was the
reflection point of a DNS reflection attack. Actually,
``Translated'' status was given when the traceback system for
DNS reflection attacks returned hash value(s) of a DNS request
packet which were paired with the hash value of the issued DNS
reply packet.
``Unknown'' :
In this status, the issued packets were recorded on TB systems,
but, TB systems did not distinguish any direction of the
issued packets.
``Not Found''':
Hazeyama, et al. Expires August 28, 2010 [Page 6]
Internet-Draft Field Trial of Traceback in Japan February 2010
TB systems did not have any records about the issued packets.
The message forwarding strategy of an ITM on the field trial was
as follows; The ITM on the current AS forwards a request message
to only upstream adjacent ASs if the TB system on the current AS
distinguish the AS status except for ``Unknown'' and ``Not
Found''. When the TB system returns ``Unknown'' or ``Not
Found''status, the ITM executes a flooding routine, that is, the
ITM on the current AS forwards the request message to all
adjacent ASs except for the AS which forwarded the request
message to the current AS. Each request message has a unique
identifier. If an ITM receives a duplicated request message by
the flooding routine on other ASs, the ITM stops forwarding the
request message, and returns a reply message as ``reached''. Also,
a request message has ``Time To Live'' field, whose value is
decreased along with traversed AS hops. If the value of ``Time To
Live'' reaches to zero, an ITM stops further forwardings.
(iv) Database to store traceback results
End-to-end traceback results are managed in a database (TB event
Database in Figure 1). This database can be available by AS
operators through a trouble ticket system on the control facility
(TB control center). The TB control center is a mediator of the
incident response among ASs, managing the TB event Database and
the TB trouble ticket system, and playing the role of an agent to
notify incidents and response results to the related ASs.
Hazeyama, et al. Expires August 28, 2010 [Page 7]
Internet-Draft Field Trial of Traceback in Japan February 2010
+----------+ +----------+ +----------+
|Customer 1| |Customer 2| |Customer 3|
+----------+ +----------+ +----------+
| | |
Incident Incident Incident
Handling Handling Handling
| | |
+--------+ +--------+ +--------+
|Operator| |Operator| |Operator|
| (AS A) | | (AS B) | | (AS C) |
+--------+ +--------+ +--------+
| | |
+---- Incident Handling (VPN) ---+
|
|
+--------------------------+
| TB Trouble Ticket System | <Incident Handling>
+--------------------------+
------------| (TB Control Center) |---------------------
+--------------------------+
| TB Event DataBase | <Automatic Tracing>
+--------------------------+
^ ^ ^
| | |
+- summary -+ summary +- summary-+
| | |
(VPN) (VPN) (VPN)
| | |
+------+ +------+ +------+
| ITM | | ITM | | ITM |
|(AS A)| |(AS B)| |(AS C)|
+------+ +------+ +------+
| | |
+-------inter-AS tracing (VPN)--------+
Figure 1 The Operation Model in the field trial.
Hazeyama, et al. Expires August 28, 2010 [Page 8]
Internet-Draft Field Trial of Traceback in Japan February 2010
+------ Inter-AS tracing ---------+
| | |
| | |
+------+ | +------+ | +------+ |
| TB | | | TB | | | TB | |
|system| | |system| | |system| |
|(AS A)| | |(AS B)| | |(AS C)| |
+------+ | +------+ | +------+ |
| | | | | |
intra-AS | intra-AS | intra-AS |
tracing | tracing | tracing |
| | | | | |
+------+ +------+ +------+
| ITM | | ITM | | ITM |
|(AS A)| |(AS B)| |(AS C)|
+------+ +------+ +------+
^ ^ ^
| | |
request request request
| | |
+-----+ +------+ +-----+
| TC | | TC | | TC |
+-----+ +------+ +-----+
^ ^ ^
| | |
alert alert alert
| | |
+------------+ +------------+ +------------+
| IDS | | IDS | | IDS |
|(Customer 1)| |(Customer 2)| |(Customer 3)|
+------------+ +------------+ +------------+
Figure 2 The interaction among TB systems
In the automatic traceback phase, the trigger of an inter-domain
automatic tracback is an alert from the IDS on the victim AS or the
victim customer. From the alert, the Traceback Client (TC) generates
a request message and submits the request message to the ITM on the
victim AS. The inter-domain automatic tracback of a submitted request
is carried out according to the procedure drawn in Figure 3.
Hazeyama, et al. Expires August 28, 2010 [Page 9]
Internet-Draft Field Trial of Traceback in Japan February 2010
TC-1 ITM-A TB-A ITM-B TB-B TM-C TB-C EventDB
| | | | | | | |
|----->| | | | | | | 1. request
|<-----| | | | | | | 2. notify
| | | | | | | | the acceptance
| |----->| | | | | | 3. query to
| | | | | | | | the local TB
| |<-----| | | | | | 4. reply from
| | | | | | | | the local TB
| |------------->| | | | | 5. forwarding
| |--------------------------->| | | request to
| | | | | | | | neighbors
| | | |---->| |---->| | 6. query to
| | | | | | | | local TBs
| | | |<----| |<----| | 7. reply from
| | | | | | | | local TBs
| |<---------------------------| | | 8. reply to
| |<-------------| | | | | the issuer
| | | | | | | | 9. aggregate
| | | | | | | | replies
|<-----| | | | | | |10. reply result
| | | | | | | |
| |---------------------------------------->|11. report
| | | | | | | | summary
Figure 3 Flow chart of an automatic tracing
If some application layer traceback system is installed in related ASs,
the automatic traceback will be carried out along with the procedure in
Figure 4. An application traceback system replies the translated
information of a packet, for example, the reflection by a DNS query, the
address transition by NAT or NAPT, etc.. The application traceback
system also replies a hash value of the pre-translated packet.
Hazeyama, et al. Expires August 28, 2010 [Page 10]
Internet-Draft Field Trial of Traceback in Japan February 2010
TC-1 ITM-A TB-A ITM-B TB-B TB-B' ITM-C TB-C EventDB
|----->| | | | | | | | 1. request
|<-----| | | | | | | | 2. notify
| | | | | | | | | the acceptance
| |----->| | | | | | | 3. request to
| | | | | | | | | the local
| |<-----| | | | | | | 4. reply from
| | | | | | | | | the local TB
| |------------->| | | | | | 5. forwarding
| | | |---->| | | | | 6. request to
| | | |-------->| | | | local
| | | | | | | | |
| | | |<----| | | | | 6. reply
| | | | | | | | |
| | | |<========| | | | 7. reply with
| | | | | | | | | trans. Info.
| | | | | | | | |
| | | |====>| | | | | 8. request with
| | | |========>| | | | trans. Info.
| | | | | | | | |
| | | |<====| | | | | 9. reply
| | | |<========| | | |
| | | |=============>| | | 10.forwarding
| | | | | | | | | with trans.
| | | | | | | | | info.
| | | | | | |====>| | 11.request with
| | | | | | | | | trans. info.
| | | | | | |<====| | 12. reply
| | | |<=============| | | 13. reply
| |<=============| | | | | | 14. reply
| | | | | | | | | 15. aggregate
| | | | | | | | | replies
|<=====| | | | | | | | 16. reply
| |=======================================>| 17. report
| | | | | | | | | summary
Figure 4 Flow chart of an automatic tracing with an application
traceback
Hazeyama, et al. Expires August 28, 2010 [Page 11]
Internet-Draft Field Trial of Traceback in Japan February 2010
In the incident response phase, damage reports are submitted from the
operator of victim AS to the TB trouble ticket system on the TB
control center, and a request to confirm the circumstances of the
attack will submitted to the AS from which the attack originated
through the trouble ticket system. According to the opened ticket,
the TB Control Center mediates between the ``Source'' AS and
``Destionation'' AS. If the issued traceback result does not contain
``Source'' AS, the TB Control Center contacts to other related ASs
such as ``Transit'' ASs. The flow chart of the incident response
phase is show in Figure 5.
``Destination'' ``Source''
Customer-1 AS-A EventDB TBCC AS-B Customer-2
| | | | | |
|------->| | | | | 1. request an
| | | | | | incident
| | | | | | handling
| |<-------->| | | | 2. search trace
| | | | | | logs
| |---------------->| | | 3. subscribe
| | | | | | a new ticket
| | |<---->| | | 4. search trace
| | | | | | logs and
| | | | | | related ASs
| | | |---->| | 5. notify incident
| | | | |-------->| 6. notify incident
| | | | | | 7. handle incident
| | | | |<--------| 8. response
| | | |<----| | 9. response
| |<----------------| | | 10. confirm
|<-------| | | | | 11. confirm
|------->| | | | | 12. reply
| |---------------->| | | 13. request
| | | | | | closing
| |<----------------|---->| | 14. notify closing
| | | | |-------->| 16. notify closing
| | | | | | 15. close
| | | | | | the ticket
Figure 5 Flow chart of an incident handling
Hazeyama, et al. Expires August 28, 2010 [Page 12]
Internet-Draft Field Trial of Traceback in Japan February 2010
2.3. The configurations of this field trial
In this section, we describe the configurations of this field trial.
2.3.1. Participates
With the cooperation of fifteen ISPs and three research centers, we
conducted this field trial. The fifteen ISPs were located in
different prefecture across Japan: Hokkaido, Tohoku, Hokuriku, Kanto,
Kansai, Chugoku, Shikoku, Kyusyu, and Okinawa. The EventDB and the
ticket system were hosted in another data center. The TB control
center was located in Tokyo. The three research centers participated
as customers.
2.3.2. Traceback systems
At each ISP we installed one controller device, multiple probes, one
PC for accessing the database and one attack simulation server. In
total, we placed 35 probes in ISPs environments. The number of probes
in each ISP was between one and four, and included the environment at
the AS borders of each AS on IPv4 networks.
A controller device contained an ITM daemon of InterTrack
[InterTrack] and a TB probe manager daemon [Kai2009]. ITM daemons and
TB probe manager daemons exchanged traceback information in several
XML messages. The XML messages were defined in InterTrackMessage.xsd
[InterTrackSource]. A TB probe manager daemon and TB probes exchanged
traceback information in an original protocol.
The TB probes were an enhanced hash-based IP traceback system
[Kai2009], and an application layer traceback system to cover DNS
reflection attack scenarios. One of enhanced hash-based IP traceback
probes was hardware based probe catching up with 10 Gbps Ethernet.
Others were software based probes which can make hash values of
packets upto 300 Mbps.
To keep anonymity of each packet, the packet information was hash
values of packets. The hash function we employed was an enhanced
bloom filter described in [Kai2009]. A hash table on each TB probe
was refreshed in 4.0 seconds interval. The false positive rate was
0.083 in 20 bit-length hash values on 890 Mbps traffic as a measured
Hazeyama, et al. Expires August 28, 2010 [Page 13]
Internet-Draft Field Trial of Traceback in Japan February 2010
value. The false positive rate can be reduced by employing more
longer hash values, for example, the false positive rate was
0.00000578 in 26 bit-length hash values on 445 Mbps traffic as a
measured value.
Each attack simulation server had TC daemon of InterTrack
[InterTrack], Snort IDS daemon [Snort], simulative attack tools based
on libnet [libnet]. The attack simulation servers were used either a
victim host or an attacker host. The TC on each attack simulation
server requested with 20 bit length hash values of 60 different
packets in every 2 seconds, if the Snort captured attack packets.
This request interval was derived from the performance of the EventDB
server. In DNS reflection attack scenarios, a bind 9 daemon and an
application traceback daemon ran on the attack simulation servers.
The controller, TB probes and the attack simulation server in each
ISP were inter-connected on an isolated layer 2 network. All
controllers and EventDB established TCP connections over another VPN.
We tested several variations of the peering topology among ITMs: a
cascade topology, a full-mesh topology, a partial-mesh topology along
with the BGP peering topology. The message forwarding strategy was a
hybrid strategy. On the hybrid strategy, an ITM forwards a request to
only upstream neighbors when the TB system distinguished the upstream
neighbors, in other cases, the ITM floods requests to all neighbors
except for the issuer neighbor.
To cover the communication overhead through the trouble ticket system,
a live chat system was settled in the TB control center. We applied
an access control rule to the live chat system as same as that of the
TB trouble ticket system. Through the live chat system, operators
actively confirm the current status of an incident response.
3. The summary of the experiments
Here, we report the summury of the experiments on this field trial.
The field trial was carried out from May to the end of August in 2010.
Totally, we had 13 times of demonstration experiments of incident
responses with traceback along with 9 attack scenarios. The details
of the experiments are described in [Wakasa2010].
Hazeyama, et al. Expires August 28, 2010 [Page 14]
Internet-Draft Field Trial of Traceback in Japan February 2010
3.1. System Performance
Results of the field trial confirmed the performance of the traceback
system, including information about processing time and fault
detection rates that can be expected in the real Internet environment
of fifteen ISPs. We used 20 bit-length hash values. With more ISPs
and larger scale Internet environment, the performance of the
traceback system would still be only a few seconds of processing time,
and the detection failure rate under 1 %. The reasons of detection
failure were, i) the recording loss caused by high traffic load on an
ISP where a software-based TB system was deloplyed, ii) the issued
packets were forwarded through an AS border where A TB system was not
deployed due to the limitation of the facility of an ISP.
Here, we summarize the processing time for each automatic tracing. In
the full mesh topology among ITMs, all automatic traceback trials
were completed in less than 1 second. Also, we measured such round
trip time of an automatic traceback trial in the 13 hops cascade
topology. In the casucade topology, most automatic tracback trials
were finished in 3 seconds, the maximum was 4 seconds.
Also, we measured the time spent for an incident response, that is,
the actual consumed time for the flow chart of Figure 5. We had 13
demonstration experiments of the traceback operation along with 9
attack scenarios, which included a sigle simlulated DoS attack,
multiple simulated DDoS attacks, a simulated DNS reflection attack,
actual attacks reported by a honeypot system, and so on. The details
of attack scenarios were described in [Wakasa2010]. The average time
to spend an incident handling, from receiving a damage report of a
customer to the closing of the ticket, was about 40 minutes, the
minimum was 11 minutes, the maximum was about 1 hour.
The demonstration experiments in the field trial identified the
following three issues about traceback systems:
i) How to cooperate with different traceback systems?
We tried to cooperate between traceback systems with slightly
different technologies, but failed to trace simulated attacks
because of differences in system parameters, operational rules,
and network environments. In future, we should consider what is
necessary to achieve automatic cooperation among multiple
traceback groups, or cooperation among traceback systems based on
different technologies.
Hazeyama, et al. Expires August 28, 2010 [Page 15]
Internet-Draft Field Trial of Traceback in Japan February 2010
ii) How to decide the best values of system parameters?
The best values of following many parameters must be agreed for
each traceback system:
a) Type of topology and mode of traceback request transmission in
InterTrack.
b) Hash parameters in the probe, and where to install each
software probe or hardware probe in the ISP environment.
c) Upper limit of fault detection rate and packet loss rate.
d) Transmission rate to send the traceback request.
We should analyze the relationship among each parameter to be
able to make the best decision about the target network
environments.
iii) How to design the topology of InterTrack.
Because there were very few adjacent ASs among the fifteen ISPs
participating in the demonstration experiments, we designed the
topology of InterTrack as connecting each ISP completely, and
the traceback requests were sent to all other ISP as same as
broadcast. We should design future traceback systems so ISPs are
independently able to update InterTrack and other parameters,
this may achieve fairness, greater efficiency and widespread
adoption of traceback systems.
3.2. Validation of management system, and operational efficiency
We examined traceback operation considering the following two factors.
The first factor is the validation of the management system, which is
required to follow legal requirements. The second factor is the
efficiency of traceback operation from view point of ISPs operators.
i) Validation of management system
The management system for the demonstration experiments was
required to have many check points for each process to satisfy
Hazeyama, et al. Expires August 28, 2010 [Page 16]
Internet-Draft Field Trial of Traceback in Japan February 2010
legal requirements, and the traceback operation is controlled on
a step-by-step basis, traceback operators are required to record
every operation on a check sheet. We analyzed the operational
records from the viewpoint of following factors, and confirmed
the validation of the management system.
a) Only few complex operational processes spent too much time and
negatively impacted some experiments.
b) Even during exception handling, there were only a few
instances when operational time increased for both the victim
and attack ISP.
c) Operation time increased only occasionally when incidents
occurred.
d) The time taken for operations in all situations was consistent
across all the participating ISPs.
ii) Operation efficiency from view point of ISPs operators
Operators need to be aware that they may need to stop current
operations and quickly switch attention to a higher priority
incident. Some operators found it difficult to make the right
decision in such situations because of lack of experience or
skills. The traceback operation must provide support for such
situations.
We analyzed the operation record from the view point of following
factors, and confirmed the operational efficiency from view point
of ISPs operators.
a) Our results showed that operation time was consistent among
ISPs.
b) Among different experiments, operation time was exceeded when
an ISP requested many operations simultaneously.
c) When high priority incident occurred, an ISP stopped the
traceback operation. After the incident finished, the operator
Hazeyama, et al. Expires August 28, 2010 [Page 17]
Internet-Draft Field Trial of Traceback in Japan February 2010
was successfully able to continue the traceback operation after
restart.
d) The traceback control center sent almost 60 messages to each
ISP for help during the experiments, and ISPs reacted to these
messages on and average of 20 occasions
3.3. System Adaptability
In a large-scale environment, it is not possible to avoid many types
of incomplete situation when conducting a trace. In the demonstration
experiments the following examples of incomplete situations were
recognized.
i) The traceback operation was stopped by a higher priority
incident.
ii) Experiments to cooperate with other traceback systems were
conducted without detailed prior discussion.
iii) Could not install probes to all links of some ISPs.
iv) Could not make hash completely in probes at some ISPs because of
the too much traffic.
v) Could not send traceback requests over 60 times in a 2 second
period because of system restrictions.
vi) Could not install the traceback system to all ISPs.
The traceback system and operation were able to adapt to these
incomplete situations to some extent. About issue i), prior training
of ISPs operators and good operation procedures, documentation and
check sheets were found to be good solutions. About issues iv) and v),
the new search engine has provided a solution, searching multiple
hash values with one click. About issues iii) and vi), general
improvements to the traceback operation provide a solution.
Hazeyama, et al. Expires August 28, 2010 [Page 18]
Internet-Draft Field Trial of Traceback in Japan February 2010
4. Security Considerations
When the widely adaption of the inter-domain traceback or the
standardization of the inter-domain traceback, we should consider the
following items;
(i) The traceability of the inter-domain messaging
(ii) Authenticaion and Authorization among ITMs
(iii) Encryption of the communication channel among ITMs
(iv) policy enforcement scheme
(v) Abuse of the inter-domain traceback
This memo is just an informational draft to report the result of a
field trial of an inter-domain traceback operation. The discussion
of each security issue is out of scope on this memo.
5. IANA Considerations
This document does not require any IANA action.
6. Summary
In this memo, we introduced the results of a field trial of an inter-
domain packet traceback operation conducted with fifteen ISPs in
Japan in 2009 using simulated and real attacks.
Through the results of this field trial we have gained a great deal
of knowledge about following three factors. i) traceback system
performance. ii) traceback operational efficiency and the management
system's validation. iii) traceback system's adaptability against
incomplete situations. And we have been able to begin to identify
issue that will help to achieve widespread adaption.
When the traceback system achieves widespread adoption, a larger
scale traceback control center and more efficient management system
will be required. When the traceback system achieves widespread
adoption in a real network environment, 24 hours/7days operation will
be necessary, and updates of the management system would be required.
For the operational efficiency, problems with the traceback system or
mistakes by operators should be minimized by steady efforts on a day-
by-day basis. Strengthen of monitoring and redundancies of the
traceback system and promoting automatic operation will be necessary.
Hazeyama, et al. Expires August 28, 2010 [Page 19]
Internet-Draft Field Trial of Traceback in Japan February 2010
We should find a solution to tracing attacks with large scale ISPs in
Japan and overseas. To install the traceback system into lager ISPs
we must resolve the problems of cost. Because overseas ISPs would
very likely install different types of traceback system, we must
resolve how to cooperate with different technical and operational
systems. Practically we must resolve how to trace attacks where few
ISPs have installed the same traceback system, and many other ISPs
have not installed any traceback system.
7. References
7.1. Normative References
7.2. Informative References
[Snoren2001]
A. Snoren, L. Sanchez, C. Jones, F. Tchakountio, S. Kent,
and W. Strayer. ``Hash Based IP Traceback.'' SIGCOMM'01.
August 2001.
[Wakasa2009]
K. Wakasa, K. Takemori, and M. Kimura ``Traceback
Coordination Model with Legal Requirements against Source
Address Attacks'', In proceeding of 2009 IEEE Pacific Rim
Conference on Communications, Computers and Signal
Processing, August 2009.
[Wakasa2010]
K. Wakasa, H. Hazeyama, T. Kai, A. Hashiguchi, M. Yamagata,
M. Fujinaga, R. Ohshima, and T. Shintani. ``Large Scale
Demonstration Experiments Towards Achieving Practical
Traceback on the Internet'', In Proceedings of Fourth
International Workshop on Advances in Information Security
(WAIS 2010), February 2010.
[Hazeyama2006]
H. Hazeyama, Y. Kadobayashi, D. Miyamoto, and M. Oe. ``An
autonomous architecture for inter-domain traceback across
the borders of network operation'', In Proceedings of 11th
IEEE Symposium on Computers and Communications (ISCC '06),
pp. 378-385, June 2006.
[Kai2009]
Hazeyama, et al. Expires August 28, 2010 [Page 20]
Internet-Draft Field Trial of Traceback in Japan February 2010
T. Kai, A. Hashiguchi, H. Nakatani, ``Proposal for and
Evaluation of Improved Method of Hash-Based IP Traceback
System'', In Proceedings of The 2009 International Workshop
on Forensics for Future Generation Communication
environments (F2GC 2009), December, 2009.
[ID-RID]
Kathleen M. Moriarty, ``Real-time Inter-network Defense'',
draft-moriarty-post-inch-rid-10.txt, February, 2010.
[InterTrackSource]
http://intertrack.naist.jp/intertrack-0.1.4.tar.gz
[Snort]
http://www.snort.org/
[libnet]
http://libnet.sourceforge.net/
8. Acknowledgments
This research is a part of "Research and Development into Traceback
technology on the Internet" sponsored by the National Institute of
Information and Communications Technology since Fiscal 2005. Finally,
we would like to express our deep gratitude to many ISPs and research
centers that provide active cooperation with our field trial.
This document was prepared using 2-Word-v2.0.template.dot.
Hazeyama, et al. Expires August 28, 2010 [Page 21]
Internet-Draft Field Trial of Traceback in Japan February 2010
Authors' Addresses
Hiroaki Hazeyama
Nara Institute of Science and Technology
Takayama 8916-5, Ikoma, Nara, Japan
Phone: +81-743-72-5216
Email: hiroa-ha@is.naist.jp
Ken Wakasa
Japan Data Communication Association
Minato-ku, Tokyo, Japan
Phone:
Email: secretariat@telecom-isac.jp
Keisuke Takemori
KDDI R&D Laboratories
Fujimino-city, Saitama, Japan
Phone:
Email: takemori@kddilabs.jp
Hazeyama, et al. Expires August 28, 2010 [Page 22]
