���������������� ��������������������������

�������������������������

������������� ��������� ��������

�

��������������������������������������������������������������������� �!����������� ��"�#"$""� �!��

�%�����������&�����������%�����������&������� �'������(���%������)*+#+�,�� �!��

SUMMARY

IP traceback is a technique to combat distributeddenial of service attacks. This technique can specify therouters in the path of the attack flow with forged sourceaddresses. Although several techniques have been proposedto solve this problem, a variety of problems arise whenoperating on the actual Internet. We proposed a hierarchicalarchitecture for IP traceback as a solution to these prob-lems. In this paper, we define each type of protocol, designarchitecture for a prototype implementation, and verify itsoperation. Based on the results, we found that a large-scalesimulation was needed. © 2004 Wiley Periodicals, Inc.Electron Comm Jpn Pt 1, 87(11): 49–56, 2004; Publishedonline in Wiley InterScience (www.interscience.wiley.com). DOI 10.1002/ecja.10202

������� ��� %�����-�%.���������-� �����������#

���������-�%.�)-��������/

1. Introduction

Distributed Denial of Service (DDoS) attacksthreaten the Internet. In February 2000, a distributed denialof service attack was launched against Yahoo! in the UnitedStates [1]. Due to this attack, Yahoo! was unable to providenetwork service, and damages reached several million dol-lars. A distributed denial of service attack floods packetsfrom the attack nodes distributed over the Internet to the

victim nodes to consume resources such as bandwidth anddisrupt the Internet services such as WWW, SMTP, andFTP.

Techniques to handle distributed denial of serviceattacks are preattack and postattack measures. A preattacktechnique prevents the installation of attack nodes andremoves them. The attack nodes are installed by unauthor-ized accesses exploiting system weaknesses and by Trojanhorses used by worms and viruses. Thus, prevention ispossible by fixing the vulnerabilities, and detecting andremoving the attack nodes. Although information abouthandling the vulnerability for each incident provided by, forexample, CERT is widely disseminated, system administra-tors may not respond adequately. Consequently, it is diffi-cult to eliminate distributed denial of service attacks byusing only preattack measures.

A postattack measure detects an attack node from thegenerated denial of service and prevents the transmissionof attack packets by disconnecting the node from the In-ternet or filtering the paths. One technique is IP tracebackexamined in this paper. The victim nodes can handle thedistributed denial of service attacks for a short period andminimize the damage.

The IP traceback can detect the transmission path ofthe attack packets with forged sources. The attacker fakesthe source address to make detecting the attack nodesdifficult. Therefore, tracking technique based on source IPaddress, such as traceroute and the routing information,becomes impossible. Today, the attack nodes are detectedby appropriately using the router filtering function or thedenial of service detection function. However, the Internet

0��++1�2����.��� �������%��/

3������������ ������������������� �!����.�������4��/�"5����/������++1'������� ������������ ����'�������6������7����������4��/� ")#8����/�"����(�����++*��!!/��1") 9�1,*

49

is an international communication infrastructure and con-nects organizations having various policies such as com-mercial Internet Service Providers (ISPs), businesses, andresearch and academic institutions. This manual tracking isexpensive and requires international cooperation whentracking across borders, and becomes a major obstacle inshortening the tracking period. The IP traceback automatesthis tracking process, reduces the costs needed for tracking,and shortens the time for handling distributed denial ofservice attacks.

In the IP traceback, the flow of attack packets sentfrom the attack node shown in Fig. 1 is called the attackflow, and the path passing this attack flow is called theattack path. The technique for identifying the attack pathcorresponding to this attack flow determines the IP trace-back.

In this research, we present an overview of our pro-posed hierarchical architecture for IP traceback and discussits ability to operate on the Internet. Then, we explain theimplemented architecture and various protocols of the pro-posed technique, and report the results of its verification.

Section 2 describes related research and the hierar-chical architecture for IP traceback. Section 3 explains theprotocol design and implementation architecture of theproposed technique. In Section 4, we consider the verifica-tion of the operation of this implementation and the practi-cal implementation. Section 5 presents a summary anddescribes future problems.

2. Related Research

In Ref. 2, we summarized a technical study of IPtracebacks and pointed out the problems of various pro-posed IP traceback techniques. We proposed hierarchicalIP traceback as a solution to these problems in Refs. 3 and4 and have worked on standardization [5].

This section briefly overviews existing IP tracebacktechniques and describes our proposal.

2.1. Existing IP traceback techniques

Existing IP traceback techniques can be divided intofour methods.

:�;�<���������(����� �

These methods use a filtering function in the routersto detect the attack flow [6]. Since tracking is performed byusing existing facilities, the investment cost is minimal.However, the problems are the flow can be tracked onlyduring the period when the attack flow is being generatedand the tracking time for manually tracking by hand isrequired.

:�;�.������ ����������� �

The information required by the routers to constructthe attack path is stored in a special IP packet (called thepassive detection packet). Then the attack path is con-structed from this information [7]. This method can beintroduced without affecting the existing backbone system.However, the problem is the increase in traffic on theInternet caused by the passive detection packets.

:*;�������(����� �

These methods specify the attack path by having eachrouter store the information required for the IP traceback inthe header [8, 9]. Additional traffic accompanying the IPtraceback is not generated at all, but when an attack nodegenerates a fake marking, the computational power re-quired to construct the attack path increases substantially.

:1;�=���#��� ����� �

These methods have highly efficient storage capacityby using a hash function and log the packets passingthrough the routers. These methods specify the attack pathby logging and recording the packets [10]. These methodscan track in one packet units, but each monitored interfaceneeds network bandwidth for sending the recorded data andstorage, and demand management costs.

From the above existing research, the following threeproblems occur when operating the IP traceback on theactual Internet.

(i) The current Internet independently manages andoperates each management unit of routing called anAutonomous System (AS). Therefore, the measures forhandling problems between the ASs must connect betweenthe ASs.

>�(/��/� ����������?��� ��������!���/

50

(ii) The operating cost of an IP traceback systemdiffers for each method. The IP traceback method must bemodified for all of the routers and the information for IPtraceback is an operating requirement, a method that mustoperate and maintain the system. Thus, an IP tracebackcorresponding to the ISP’s budget and operating scale mustbe operated.

(iii) When considering the current situation of theattack schemes, we expect the attacker develops attackschemes that analyze various IP traceback techniques andtarget their weaknesses. Consequently, to match this, the IPtraceback techniques must also improve and change.

Due to the above three points, one IP tracebacktechnique may be difficult to apply to the entire Internet.Therefore, the authors focused on the routing mechanismsin the Internet and designed an IP traceback architecturecapable of solving the problems described above.

Routing on the Internet is not performed by onerouting protocol, but has the two layers of the ExteriorGateway Protocol (EGP) and the Interior Gateway Protocol(IGP) to correspond to the network scale. EGP routesbetween large-scale networks known as Autonomous Sys-tems. Border Gateway Protocol (BGP) 4/4+ is an exampleof this protocol. On the other hand, the Open Shortest PathFirst (OSPF) and Intermediate System-to-IntermediateSystem (IS-IS) are the IGPs for internal AS. In EGP opera-tion, the ASs have exchanged through the interconnectionsbased on the contracts between the ASs.

The hierarchical IP traceback system applies the rout-ing mechanism to the traceback system as described above.

2.2. Hierarchical IP traceback system

This system consists of three elements: the ExteriorIP (eIP) traceback system, the Interior IP (iIP) tracebacksystem, and the IP Traceback Manager (ITM) network.Each control area of eIP and iIP traceback is the same aseach control area of EGP and IGP, which are the routingcontrol protocols shown in Fig. 2. An ITM network con-nects the eIP traceback and the iIP traceback.

The eIP traceback system identifies each AS that theattack flow passed. In this research, the objective was toidentify the attack path within 30 minutes from the start oftracking. This was decided based on the 30-minute comple-tion of the initial attack stage of a distributed denial ofservice attack in the CAIDA [11] report. However, sincecurrent research had not proposed an IP traceback methodthat can specify each AS that the attack flow passed, weproposed IP Option traceback for eIP traceback [3].

The iIP traceback system identifies the IP addressesof the routers passing the attack flow passing in the AS. Thedistributed denial of service attack is handled by the rela-

tionship between the eIP traceback identifying the AS ofthe attack node and the iIP traceback identifying the IPaddresses of the attack node.

Based on existing IP traceback studies, we deter-mined that three parameters were needed to interconnectthe eIP and the iIP tracebacks. These are the packet dumprecord of the attack flow, recorded time stamps, and re-corded node information (AS number/IP address). In thispaper, we operate the existing IP traceback technique as theiIP traceback and explain the extension required to makethe relationship between the eIP traceback and iIP trace-back.

An ITM network provides information exchange be-tween ASs applying eIP/iIP tracebacks. Each ITM intercon-nects with an ITM of the AS, which uses the ITM Protocol(ITMP) to perform BGP peering, and exchanges informa-tion.

Distributed denial of service attack handled accord-ing to this technique is the following process.

(1) Record the attack flow: The administrator of thevictim node requests a measure to handle the attack flow tothe administrator of the AS that belongs. The AS adminis-trator monitors and records the attack flow at the victimnode.

(2) Execute the eIP traceback: The attack path con-structed by the AS that the attack flow passed by the eIPtraceback is determined from the record.

(3) Execute the initial measure: ASs in the attack pathexecute filtering and bandwidth shaping for easing imme-diate damage at the victim node.

(4) Execute the iIP traceback: The iIP traceback isperformed on the ASs having an attack node, identifies theIP address of the attack node, and disconnects it from thenetwork.

(5) Attack convergence: By disconnecting the attacknode from the network, the attack flow converges, and thedistributed denial of service attack ends.

>�(/��/� ��������������%.��������������������/

51

An iIP traceback can be independently executed foreach AS. Consequently, AS can select IP traceback methodssuited to the operation style of each AS. And the AS canchange to another IP traceback method when vulnerabilityin the iIP traceback is discovered during operation or wheninappropriate for the operating scale.

2.3. The analysis of IP option traceback

Since the IP option traceback technique is a type oftracing packet scheme, the load on the network must beconsidered. In Ref. 12, we constructed a numerical modeland cleared the trade-off between the increase in networktraffic based on this solution and the time needed to con-struct the attack path. As a result, our target of identifyingthe attack path within 30 minutes is sufficient in the range(increase of 0.1% or less) having a small effect on the traffic.

Based on this solution, we designed and implementedthe architectures of hierarchical IP traceback and IP optiontraceback as the eIP traceback.

3. Prototype Implementation of theProposed Technique

In this section, we explain the prototype implemen-tation of the proposed method developed for FreeBSD 4.7and NetBSD 1.6 and the verification. We defined ITMP,which is a communication protocol between ITMs, anddefined the ITM API for information exchange for connect-ing eIP/iIP traceback and the ITMs through the design ofthe implemented architecture. And we designed their archi-tecture models. Next, based on the design, we implementedthe prototype and verified the operation.

3.1. IP option traceback configuration

In this section, we describe the configuration of IPoption traceback. IP option traceback was defined in Ref.3. However, in addition to the implementation and opera-tion, we proved that the architecture must have a higherlevel of independence between ITM and the proposed tech-nique. Then based on this, we updated the specification ofthe function part of IP option traceback. Since the algorithmspecifying the attack path is not changed, there is no effecton the result of simulation.

This method is constructed from two structures, thePacket Monitor (PM) and the Traceback Option Generator(TOG) (Fig. 3). The PM is present on the Border Router ofeach BGP boundary in an AS and monitors and samples theIP packets transiting out of the AS. The TOG manages thePM in each AS and generates and analyzes the tracingpackets using the IP option.

A PM is constructed from the following two func-tions.

(1) Packet selection: A packet is selected and copiedwith the probability P from each interface output of therouter.

(2) Cooperate with TOG: The PM sets the probabilityP in response to a request from the TOG and sends theselected packet to the TOG.

Next, we will describe the functions of TOG. TheTOG consists of five functions.

(1) Generation of the IP traceback option: The TOGgenerates the IP traceback option from the selected packetand the parameters (AS number, hash information for pre-venting forging).

(2) Option management: The TOG generates andmanages the pair keys, the AS message key X and the keyidentification number Z. The hash information is gener-ated by using the Keyed-Hash Message AuthenticationCode (HMAC) [13] from the key identification numberZ.

(3) Cooperate with PM: The TOG sends the prob-ability P for packet selection by a PM to each PM.

(4) Packet verification: The TOG verifies the HMACauthentication in the IP traceback option and builds theattack path.

(5) ITM interconnection: To construct the attack path,the TOG uses the ITM network to exchange that attack pathor the IP traceback option with neighboring TOGs.

In this method, by generating MAC data from the ASnumber with HMAC verification, the AS number will notbe saved as the clear text format in the traceback option.This solves the problem of the leaking of network topologi-cal information from the tracing packets having ICMPtraceback.

>�(/�*/� &�����������%.��!�������������������/

52

3.2. ITM API definition

We defined the ITM API to coordinate between theeIP and iIP tracebacks. The eIP/iIP tracebacks and the ITMmust exchange information for executing iIP tracebackthrough the API and information about eIP traceback re-sults. Figure 4 shows the eIP/iIP traceback system and theITM structure. Thus, the ITM API is used to communicateto the ITM, eIP and iIP traceback. The ITM of each ASinterconnects by using the ITMP.

The objective of the design of the ITM API in thisimplementation is for an actual implementation to connectas the iIP or eIP traceback module. The reference imple-mentation used PAFFI [14] implementing hash-based IPtraceback on a network processor (NP) as the iIP traceback,and the IP option traceback implementation we developedas the eIP traceback.

The API is constructed as follows.

• �.%�����@����(��(�%'�������������A�%'���.%���

�� �������!����� ����!�������������������������

�&� ������� ��� ���������� ������ �� � ��� ���#

����� ��� ��� ��!!��� � %.B�%.� ���������� ��

��(������(� %'��� ����� ��� ����� ����������(� �

���������/

• �����@����(��.%A�%.������������ ��������&

����@����(� ���������(���������%'�/�'��%'�

���������!�!����� ��������/

• '���������C������ ���!�����.%A�'�����.%����

���������������������%.�������������������������

�������(���C�����(���� ���!�� ��(��� �(����(

����������������/�.����� ��!�������������:���

����!���� ��&���������� �%.�� ���;������!��#

� � ��� �C���� %.� ��������� ���� ����� �.%/� ����

@��� �%.��������������� ����������.%����!���

�������������?������������/�

Each IP traceback can have independence withoutlosing cooperation between eIP and iIP by implementingeach IP traceback using the ITM API. Then the IP tracebackmodule of a neighboring AS can be linked through the ITM

network. Thus, the proposed method implements a protocoldesign of eIP traceback with the premise of connecting toeach AS by the ITM.

In this implementation, the IP option traceback im-plementation becomes available as the eIP traceback mod-ule by using the ITM API and connects to the neighboringAS to build the attack path on an ITM network platform.

3.3. ITMP

In this section, we explain ITMP which is used in dataexchange protocol between ITMs. The ITM network isconstructed with a peering connection of ITM to neighbor-ing ITMs as well as the peering of BGP. Thus, the topologyof the ITM network becomes equivalent to the topology ofthe AS network.

Figure 5 shows the state transitions in ITMP. ITMPhas an authentication phase and a connected phase. Theauthentication phase starts connecting to a neighboringITM with digest authentication. After authentication ends,neighbor information (AS number, availability of eIP trace-back and iIP traceback) is exchanged. After the authentica-tion phase ends, the connected phase is entered. In theconnected phase, each eIP/iIP traceback module is exe-cuted, or data are exchanged through the ITM networkbetween two IP traceback modules of neighboring ASs bythe ITM module.

3.4. Program code structure

This program code is divided into a part that modu-larizes the IP option traceback TOG and embeds it in ITMand a part of the IP option traceback PM that selects andsends the packets. The program is written in C and standard

>�(/�1/� �� ���������������%'�/ >�(/�$/� &��������������� ��(�������%'�./

53

libraries for portability. The libpcap library [15] is used asan external library in the IP option traceback PM part andthe libnet library [16] as the external library in the TOG part.At the writing of this paper, however, the part connected toPAFFI (iIP traceback) was designed and verified, but itsimplementation is not finished.

ITMP communication uses TCP/IP and enables con-necting by both IPv4 and IPv6. An independent ITM net-work can be constructing in IPv4 or IPv6. ITM in IPv6 orIPv4 and its traceback module group operate independentlyof each other.

The IP option traceback PM in the prototype imple-mentation monitors the traffic in the NICs and selects thepackets. Thus, the effect on the existing infrastructure mustcontinue to be minimized. Consequently, Ethernet hubscapable of port mirroring the routers’ NICs or the opticalsplitters must be connected and become an environmentable to monitor the traffic in the PM.

4. Verification of the Operation andDiscussion of the Practical Implementation

In this section, we discuss the verification environ-ment and the results.

4.1. Verification process of the proposedtechniques

To demonstrate the effectiveness of the proposedmethods on the Internet, we must verify the following steps.

(1) Design the architecture for implementing theproposed method and qualitatively discuss this design.

(2) Define the specification of the protocol based onthe architecture design and develop an implementation.

(3) Verify the operation of the eIP traceback (IPoption traceback) in the ITM network developed underabout ten ASs in a small-scale system.

(4) Verify the coordinated function, that is, the eIPtraceback in each ITM exchanges the IP traceback parame-ters with the iIP traceback via ITM network.

(5) Verify the operation of eIP traceback in the ITMnetwork at more than 100 ASs in a large-scale system.

(6) Operate on the Internet.

In Ref. 3, we completed item (1). In this paper, wefocus on carrying out items (2) and (3). The reason is theimplementation of the interface design to PAFFI is incom-plete, and we consider that the operation of IP tracebackwith PAFFI was finished. Then we discuss the importanceof verifying the connections between the ITM and eIP atthis time.

However, this verification is isolated from the per-spective of the actual Internet environment and scale.Therefore, we position this experiment within the frame-work of verifying the operation.

We believe that it is necessary to perform a large-scalesimulation in the verification in item (5) that considers theoperating scale of the actual Internet. We assume that thescale of the verification is based on the observations of theBGP peering in the Skitter project [17] of CAIDA.

Skitter defines the core AS group that is concentratingtraffic from BGP peering observations. The authors believethat a distributed attack flow must pass through these ASssimilar to normal traffic, and the ITM network must operatein the core ASs.

Although verification in the core AS is performed asitem (5), the operation must be directed toward operationin the actual Internet in item (6). We determined the testplan with the premise of installation to the Internet andsummarize the problems in the next section.

4.2. Verification of operation

The operation of the prototype implementation wasverified in the small-scale network test environment shownin Fig. 6. This environment consists of ten PCs, which arethe routers, an L2 switch (L2 Switching HUB, Extremenet-works Summit48) that connects these computers, a trafficgenerator (Traffic Generator, Agilent Router Tester), and acontroller (Ctrl. Unit) for varying the network configurationand controlling the traffic. Each PC has at least two networkinterface cards (NICs), and all of the NICs are connected tothe L2 switch. By setting up a virtual LAN of the L2 switchhub in the controller, a flexible topology can be designed

>�(/�)/� &��������������������������������/

54

without making physical changes. By combining the trafficgenerator with the virtual LAN, attack flows can be gener-ated from several dozen attack nodes and monitored.

Here, we assumed that each PC in the system was anindependent AS, and verified the implementation betweeneIP traceback and the ITM network. iIP traceback is exe-cuted in a closed environment independent from the eIPtraceback and the ITM network. As described earlier, sincethe implementation of the relationship iIP and ITM part isunfinished, the stub module only receives information foriIP traceback from the ITM.

With nine PCs as the ASs (AS1 to AS9 in Fig. 7) andone PC as the victim node (V in Fig. 7), we constructed thenetwork shown in Fig. 7 and verified the following points.(1) PM monitors the packets from the traffic generator andtransfers to the TOG according to the probability P. (2)Based on the packets transferred from the PM, the TOGgenerates and sends the IP option packet. (3) Verify thetransition phase from the authentication phase to the con-nected phase on ITMs. (4) The attack path can be con-structed from the IP option packet. From the above points,we verified that the prototype implementation operatedaccording to the design.

4.3. A discussion of the implementation

This section explains the possibility of realizing theproposed method.

We believe that the possibility of realizing ITM onthe actual Internet is high. The reason is it is extremelyimportant to minimize the damage to the customer’s site bya distributed denial of service attack in order to maintainservice quality and reliability. The ISP must have a remedyavailable in a short period of time. Then the ISP detects theattack path by IP traceback using the link testing method.Therefore, the ISPs emphasize the large expense, time, andthe use of human resources required to handle a distributeddenial of service attack.

The proposed method can reduce the costs needed forthe measures by integrating each IP traceback system basedon ITMs and automating the trace process between ITMs(between ASs). Furthermore, since each AS selects the IPtraceback method for the network scale and budget, the

proposed method enables implementation of a flexible IPtraceback system.

From the above, each AS has the advantage of ITMoperation, and this method is very practical.

��� ���������

As a solution to existing problems, the hierarchicalIP traceback architecture is an IP traceback system that isdivided into eIP traceback and iIP traceback in accordancewith EGP and IGP, which are the routing architectures inthe Internet.

Based on this proposal, we determined the ITM API(ITM information exchange API, data exchange API, trace-back request, and response API) because the existing tech-niques based on the analysis of existing IP tracebacksystems are used as the iIP traceback modules. The ITMPcommunication protocol was set to connect and controlamong the eIP and iIP tracebacks on the ITM network.

The prototype was developed based on the ITM APIand ITMP designs.

We explained the verification process based on theoperation of the proposed technique on the actual Internet.The position of the verification in this paper was to verifya traceback function for DDoS flows with eIP traceback inten ASs in a small-scale system and eIP traceback. Theresult clearly showed that the protocol design and imple-mentation of the proposed method could be simulated on alarge-scale system.

In the future, we plan a simulation that assumes thisimplementation in 500 physical nodes (5000 virtual nodes)on StarBED [18], which is an Internet simulator. In this test,the AS topology map based on Skitter will be constructedand the virtual attack flow generated by existing DDoStools. Then the operation of connecting the ITM and eIP/iIPtraceback will be tested. Performance such as the attackpath construction time and the network load will be clari-fied. On this basis, we would like to define the problems inthe operation of our proposed method on the Internet.

!"#"!"$ "%

�/ ����� /�>8%�������?���������D�������������/�E�#��

�32&�� ���!ABBF ��/���B��++#��#$�"*$,/�����

>�/��+++/

�/ ������ ��������� �/� %.� ��������� �����C��/�

%.& ��++�-1�A��5$9��"+/�:��� �!���;

*/ �� ��������������������(�����&/��������������

���������������%.���������/�%3%�3�'�����������

�++�- "$#8A�*�*9�*��/�:��� �!���;

1/ ������ ����������������(�����&/������!���#

������������������������%.��������������������/�.���

&�%�'G+*��>���� �/>�(/�5/� ��?������!���(�/

55

$/ ��/������������������������������%.���������/

.����$1���%3'>���!!��8�>������������ �!�������!ABB

�!���/����#����/��/H!B������B�����B�!!�#�����#���$1/

! ��� �����++�/

)/ &���� 7/� ����'����A� ��� %.� ������� ��?���� ���

�������(� ��&� ���� �/� .���� ,��� I&3�%J� &������

&��!������G++������/

5/ 8�������&���<�������'������'/�%��.���������

����(�/� %�����#������� ����#���#�����#+�/�@��

��/��++�/

"/ &���(�&��2��������������������� �����'/�.�����#

������?������!!��������%.���������/�.���������+++

&%6�������������!��,$9*+)��&��������/

,/ &��(����.���(��/�� ���� ��� ����������� ����#

��C�������%.���������/�.����%�>#����++�/

�+/ &��������� .����� (���� &������ <��� �����3�

'�����������>������&'��&�����2'/�=������� �%.

��������/�.����&%6����G+���&�����(�/�

��/ ��������4�����6���&���(�&/�%������(�%�����

����#��#��������������/�.�����+���I&3�%J�&��#

�����&��!������G+���2�����(�������/

��/ &�?����������%� ������� ����������/�.��������

���������� ��� �����# ������ %.� ��������/� .���

%�'G+*��'�����/

�*/ ���?�F���=��8���������������7/�=���A��� #

������(� ���� ����(� �������������/� 7>�� ��+1�

���!ABB???/���/��(B���B�����+1/�@����,,5/

�1/ ����(�?��3������������!/�.�>>%#.�����>�������

>%� �/� ���!ABB???/������/��/H!B!�� ����B.�>>%B�

�����++�/

�$/ '�.�I�./76/�'��<��!��!��������/����!ABB???/

��! ��!/��(

�)/ &��������� ��/� '�� <����� �������/� ���!ABB�����/

��������(/��

�5/ '�� ���!������ ������������ ���� %������ ����

��������� :��%��;/� &�����/� ���!ABB???/��� �/��(B

�����B��������B������B�� ����++�/

�"/ '����������������� ���������(���F��������

�!��� :'�;/� =�������� %'� �!�� ����������/

���!ABB???/��������#��/���/(�/H!B�(����B�� &!�/

�++�/

AUTHORS (from left to right)

Masafumi Oe (member) completed the doctoral program in information science at Nara Institute of Science andTechnology in 2003 and received a D.Eng. degree. He then became an assistant at the astronomical data analysis center of theNational Astronomical Observatory of Japan and JGN research fellow of the Telecommunications Advancement Organizationof Japan. He has performed research on IPv6 network security in the WIDE Project and the AI3 Project.

Youki Kadobayashi (member) entered the doctoral program at Osaka University in 1994 and received a D.Eng. degree.In 1996, he became a research assistant at the large-scale computer center. In 1999, he became a lecturer at Nara Institute ofScience and Technology, and has been an assistant professor of information science since 2000. His research interest is Internetarchitecture.

56