日本ソフトウェア科学会
研究会資料シリーズ No.85
ISSN 1341-870X

Proceedings ofInternet Conference 2018
Sponsored by

JSPS 163rd Committee on Internet Technology (ITRC)

Co-sponsored by

WIDE Project (WIDE)

Technically cosponsored by

Japan Society for Software Science and Technology SIG on Internet Technology (JSSST/ITECH)

In-cooperation with

ACM SIGUCCS Tokyo Chapter
IEEE Communications Society Japan Chapter
the Internet Society Japan Chapter (ISOC-JP)
Qshu-Bone Project (QBP)
Kyushu Giga POP Project (QGPOP)
Cyber Kansai Project (CKP)
IEICE Chugoku Chapter
IEICE Kansai Chapter
IPSJ Chugoku Chapter
IPSJ Kansai Chapter
IPSJ Special Interest Group on High Performance Computing (HPC)
IPSJ Special Interest Group on Internet and Operation Technology (IOT)
IPSJ Special Interest Group on system software and Operating System (OS)IPSJ Special Interest Group on Distributed Processing System (DPS)IPSJ Special Interest Group on UBIquitous computing systems (UBI)IEICE Technical Committee on Internet Architecture (IA)IEICE Technical Committee on Network Systems (NS)Japan UNIX Society (JUS)

26th, 27th November, 2018
Akihabara Convention Hall, Tokyo, Japan発行日

2018年11月26日

発行者

インターネットコンファレンス2018 実行委員会

日本学術振興会産学協力研究委員会インターネット技術第163委員会
WIDEプロジェクト

日本ソフトウェア科学会事務局〒113-0032 東京都文京区弥生 2-4-16 学会センタービル内
日本ソフトウェア科学会

電話 03-5802-2060

FAX 03-5802-3007

無断転載・複製を禁じます日本ソフトウェア科学会
研究会資料シリーズ No.85
ISSN 1341-870X

Proceedings ofInternet Conference 2018
Sponsored by

JSPS 163rd Committee on Internet Technology (ITRC)

Co-sponsored by

WIDE Project (WIDE)

Technically cosponsored by

Japan Society for Software Science and Technology SIG on Internet Technology (JSSST/ITECH)

In-cooperation with

ACM SIGUCCS Tokyo Chapter
IEEE Communications Society Japan Chapter
the Internet Society Japan Chapter (ISOC-JP)
Qshu-Bone Project (QBP)
Kyushu Giga POP Project (QGPOP)
Cyber Kansai Project (CKP)
IEICE Chugoku Chapter
IEICE Kansai Chapter
IPSJ Chugoku Chapter
IPSJ Kansai Chapter
IPSJ Special Interest Group on High Performance Computing (HPC)
IPSJ Special Interest Group on Internet and Operation Technology (IOT)
IPSJ Special Interest Group on system software and Operating System (OS)IPSJ Special Interest Group on Distributed Processing System (DPS)IPSJ Special Interest Group on UBIquitous computing systems (UBI)IEICE Technical Committee on Internet Architecture (IA)IEICE Technical Committee on Network Systems (NS)Japan UNIX Society (JUS)

26th, 27th November, 2018
Akihabara Convention Hall, Tokyo, Japan

1

2

Internet Conference 2018

Program Committee and Organization Committee

Program Committee Chair
Teruaki Yokoyama (Kobe Institute of Computing / National Institute of Information andCommunications Technology)

Program Committee
Yasuhiro Ohara (NTT Communications)Katsushi Kobayashi (The University of Tokyo)
Nobuo Okashiwa (Kyoei Gakuen University)
Motoyuki Ohmori (Tottori University)
Keiichi Shima (IIJ Innovation Institute)

Organization Committee Chair
Hiroshi Mano (Koden Techno & Info)

Organization Committee
Motoyuki Ohmori (Tottori University)
Ismail Arai (Nara Institute of Science and Technology)
Minoru Ikebe (Oita University)
Yoshihisa Kawamoto (Osaka Gakuin University)
Katsushi Kobayashi (The University of Tokyo)
Toru Kondoh (Hiroshima University)
Yasuhiro Ohara (NTT communications)Yasuo Okabe (Kyoto University)
Koji Okamura (Kyushu University)
Toshihiko Shimokawa (Kyushu Sangyou University)
Naomi Terada (National Institute of Information and Communications Technology)
Seiichi Yamamoto (The University of Tokyo)
Teruaki Yokoyama (Kobe Institute of Computing / National Institute of Information andCommunications Technology)

3Internet Conference 2018

TechnicalProgram Committee

Technical Program Committee Chair
Ohara Yasuhiro (NTT Communications)Technical Program Committee
Hirochika Asai (Preferred Networks, inc.)
Rei Atarashi (IIJ Innovation Institute)
Razvan Beuran (Japan Advanced Institute of Science and Technology)
Romain Fontugne (IIJ Innovation Institute)Kensuke Fukuda (National Institute of Informatics)
Hiroaki Harai (National Institute of Information and Communications Technology)
Tatsuya Jinmei (Infoblox)
Katsushi Kobayashi (The University of Tokyo)
Aya Matsui (IBM Japan)
Hiroki Matsutani (Keio University)
Rodney Van Meter (Keio University)
Yoshifumi Nishida (GE Global Research)
Masafumi Oe (National Astronomical Observatory of Japan)
Nobuo Ogashiwa (Kyoai Gakuen University)
Yasuhiro Ohara (NTT Communications Corporation)
Motoyuki Ohmori (Tottori University)
Kazunori Sugiura (Keio University)
Yojiro Uo (IIJ Innovation Institute)
Seiichi Yamamoto (The University of Tokyo)
Teruaki Yokoyama (Kobe Institute of Computing / National Institute of Information andCommunications Technology)

4Internet Conference 2018

Program
26th November 2018: 1st day
9:00-10:00

Invited Talk (1)Internet Civilization
Jun Murai (Keio University)

10:00-10:15

Break

10:15-11:15

Invited Talk (2)Designing the quantum Internet
Rodney Van Meter (Keio University)

11:15-12:45

Lunch

12:45-13:15

Paper Presentation (1)
サイバー演習の防御演習時におけるシナリオ進行の自動化システムの提案
井上 拓哉 (北陸先端科学技術大学院大学)

Razvan Beuran (北陸先端科学技術大学院大学)
13:15-13:45

Poster Lightening Talk (1)13:45-14:45

Invited Talk (2)Beyond Internet Research: By Systemy!
Michio Honda (NEC Labs Europe)

14:45-15:15

Break

15:15-15:45

Research Topic Exchange (1)Traﬀy Waste - a smarter way to collect and management waste collection
Wasan Pattara-atikom (NECTEC)

15:45-16:45

Poster Lightening Talk (2)16:45-17:30

Poster and Demonstration

5

Internet Conference 2018

27th November 2018: 2nd day
9:30-10:30
Invited Talk (4)Internet Measurement, how to get the relativities right at scale
George Michaelson (APNIC Labs)
10:30-10:45

Break

10:45-11:45 Invited Talk (5)Past, Present, and Future of DNS Resolution
Paul Vixie (Farsight Security)
11:45-13:15

Lunch break

13:15-13:45 Paper presentation (2)Kamuee: An IP Packet Forwarding Engine for Multi-Hundred-Gigabit Software-based
Networks
Yasuhiro Oharaa (NTT Communications Corporation)
Hiroki Shirokuraa (NTT Communications Corporation)
Abhik Datta Banika (NTT Communications Corporation)
Yudai Yamagishia (NTT Communications Corporation)
Kim Kyunghwan (Independent Engineer)
13:45-14:15 Research Topics Exchange (2)The Cameroon Internet Shutdowns-Technological Framework
Ndenge Godden Zama (BlackedOut Africa)
14:15-15:15 Invited Talk (6)Challenges and opportunities from large scale Internet measurement infrastructures
Emile Aben (RIPE NCC)
15:15-15:45

Break

15:45-16:45 Invited Talk (7)Creating interactive experiences with Mixed Reality
Kelvin Cheng (Rakuten, Inc.)
16:45-17:15 Research Topics Exchange (3)SmartSantander: an IoT-based Smart City Testbed
Juan Ramón Santana (University of Cantabria)
17:15-18:00

Poster and Demonstration

18:15-18:30

Closing6

Internet Conference 2018

Table of Contents
Invited Talk
Internet Civilization
Jun Murai (Keio University)…………………………………………………………………

11

Designing the quantum Internet
Rodney Van Meter (Keio University) ………………………….……………………………… 12
Beyond Internet Research: Be Systemy!
Michio Honda (NEC Labs Europe)………………………………………………………… 13

Internet Measurement, how to get the relativities right at scale
George Michaelson (APNIC Labs) ………………………….……………………………… 14
Past, Present, and Future of DNS Resolution
Paul Vixie (Farsight Security, Inc.)………………………….……………………………… 15
Challenges and opportunities from large scale Internet measurement infrastructures
Emile Aben (RIPE NCC) Mr. Emile Aben………………………………………………… 16
Creating interactive experiences with Mixed Reality
Kelvin Cheng (Rakuten Institute of Technology, Rakuten, Inc.)……………………… 17

Research Topic ExchangeTraﬀy Waste - a smarter way to collect and management waste collection
Wasan Pattara-atikom (NECTEC)………………………………………………………… 19
The Cameroon Internet Shutdowns-Technological Framework
Ndenge Godden Zama (BlackedOut Africa) ………………………………………………… 20
SmartSantander: an IoT-based Smart City Testbed
Juan Ramón Santana (University of Cantabria)

7………………………………………… 21

Internet Conference 2018

Table of Contents
Paper Presentation
サイバー演習の防御演習時におけるシナリオ進行の自動化システムの提案
井上 拓哉 (北陸先端科学技術大学院大学)

Razvan Beuran (北陸先端科学技術大学院大学)………………………………………… 24

Kamuee: An IP Packet Forwarding Engine for Multi-Hundred-Gigabit Software-based Networks
Yasuhiro Oharaa (NTT Communications Corporation)
Hiroki Shirokuraa (NTT Communications Corporation)
Abhik Datta Banika (NTT Communications Corporation)
Yudai Yamagishia (NTT Communications Corporation)
Kim Kyunghwan (Independent Engineer)………………………………………………… 33

PosterLightweight Packet Loss Detection and Multicast Delivery Tree Recovery in SDN
Siva Sairam Prasad Kodali (Indian Institute of Technology Hyderabad)
Kotaro Kataoka (Indian Institute of Technology Hyderabad) ………………………………… 44
Trust Management in Multi-Domain SDN Networks Using Blockchain
Prashanth Podili (Indian Institute of Technology Hyderabad)
Kotaro Kataoka (Indian Institute of Technology Hyderabad) ………………………………… 45
On Accurate Packet Loss Estimation for Networks without Traﬃc Models
Masahiro Terauchi (Nagaoka University of Technology)
Kohei Watabe (Nagaoka University of Technology)
Kenji Nakagawa (Nagaoka University of Technology)………………………………… 46
An Ocean Target Detection Mechanism in IoT Environment
Yaqiang Zhang (Ritsumeikan University, China University of Geosciences)
Xiangbo Kong (Ritsumeikan University)
Lin Meng (Ritsumeikan University)
Zhangbing Zhou (China University of Geosciences)
Hiroyuki Tomiyama (Ritsumeikan University) ………………………………………………… 47
e-Learning System for Cryptography on Moodle
Tatsuki Miyamoto (Osaka Electro-Communication University)
Shogo Shimura (Shinshu University)
Tatsuki Watanabe (Osaka Electro-Communication University)
Hiroyuki Okazaki (Shinshu University)
Yuichi Futa (Tokyo University of Technology)
Yasuyuki Murakami (Osaka Electro-Communication University)……………………… 48

VISIBLE: Application for Vehicle Visibility and Incident Reporting in Real-Time
Mehul Sharma (Indian Institute of Technology Hyderabad)
Suhel Magdum (Indian Institute of Technology Hyderabad)
Antony Franklin A (Indian Institute of Technology Hyderabad)
Bheemarjuna Reddy Tamma (Indian Institute of Technology Hyderabad)
Digvijay S. Pawar (Indian Institute of Technology Hyderabad)……………………… 49

8

Internet Conference 2018

An evaluation of method for zero-day malicious email detection using email header
information analqaysis (EHIA) and deep-learning approach
Sanouphab Phomkeona (Kyushu University)
Koji Okamura (Kyushu University) ………………………………………………………… 50
How Japan's Approach Towards Cybersecurity has Changed: Quantitative Content Analysis of
Cybersecurity Strategy from 2013 to 2018
Piyush Ghasiya (Kyushu University)
Koji Okamura (Kyushu University) ………………………………………………………… 51
A Design of Failure Injection Testing considering Edge Computing Environment
Kenta Hayashi (Hiroshima City University)
Kaori Maeda (Hiroshima City University)
Tohru Kondo (Hiroshima University) ………………………………………………………… 52
Counting Passengers from Images of Drive Recorder Inside Buses by Using Background
Subtraction and OpenPose
Hayato Nakashima (Nara Institute of Science and Technology)
Ismail Arai (Nara Institute of Science and Technology)
Kazutoshi Fujikawa (Nara Institute of Science and Technology)……………………… 53
Intrusion Detection in the CAN bus using Statistical Analysis and Neural Networks
Araya Kibrom Desta (Nara Institute of Science and Technology)
Ismail Arai (Nara Institute of Science and Technology)
Kazutoshi Fujikawa (Nara Institute of Science and Technology)……………………… 54
Approach to Better Log Template Generation (awarded)
Yuya Yamashiro (︎︎The University of Tokyo)
Satoru Kobayashi (National Institute of Informatics)
Kensuke Fukuda (National Institute of Informatics)
Hiroshi Esaki (︎︎The University of Tokyo)………………………………………………… 55
A method of creating experimental network with routing between virtual hosts
Seiichi Yamamoto (National Institute of Information and Communications Technology,
The University of Tokyo)
Eiji Kawai (National Institute of Information and Communications Technology)……… 56
Dynamic Adaptation of Cooldown Period for Auto Scaling of VNF's
Mohit Kumar Singh (Indian Institute of Technology Hyderabad)
Gaurav Garg (Indian Institute of Technology Hyderabad)
Tulja Vamshi Kiran Buyakar (Indian Institute of Technology Hyderabad)
Venkatarami Reddy (Indian Institute of Technology Hyderabad)
Antony Franklin A (Indian Institute of Technology Hyderabad)
Bheemarjuna Reddy Tamma (Indian Institute of Technology Hyderabad) ……………… 57
Collecting a large number of active IPv6 addresses (awarded)
Yudai Aratsu (︎︎The University of Tokyo)
Satoru Kobayashi (National Institute of Informatics)
Kensuke Fukuda (National Institute of Informatics)
Hiroshi Esaki (︎︎The University of Tokyo)………………………………………………… 58
Fast Logging in Time Series for a Computer Security Incident Response
Motoyuki Ohmori (Tottori University) ………………………………………………………… 59
Development of Local cloud environment in the user vicinity
Tomohiro Yoshida (Kobe Institute of Computing)Randrianarivony Nirinarisantatra (Kobe Institute of Computing)
Teruaki Yokoyama (National Research and Development Institute of Information
and Communications Technology) ………………………………………………… 60

9Internet Conference 201810

Internet Conference 2018

Invited Talk (1)Speaker: Jun Murai (Keio University)
Title: Internet Civilization
Abstract: Some goals of the Internet design have been achieved; suchas a global digital space, easy to access, wired and unwired andbroadband.
A lot of not yet achieved; such as truly for everyone, full coverage,
latency sensitivity, sophisticated distributed processing, things to beconnected and eternal preservation of data.
When we define the world today as the `Internet Civilization', what weshould work for some essential elements of the Civilization including thearchitecture of the Internet, coming and expecting technologies andsocial design would be discussed.
Biography: He received his Ph.D. in Computer Science, Keio University in
1987, majored in Computer Science, Computer Network and Computer Communication. He
developed the Japan University UNIX Network (JUNET) in 1984, established WIDE Project in
1988, aiming to research and develop the computer networks.
He is a member of the Strategic Headquarters for the Promotion of an Advanced Information andTelecommunications Network Society (IT Strategic Headquarters), a member of the Cyber
Security Policy Council, National center of Incident readiness and Strategy for
Cybersecurity(NISC), Cabinet Secretariat, chairs and serves on many other governmental
committees, and is active in numerous international scientific associations. He is known as the"Internet samurai" and, in Japan has also been called "the father of the Internet in Japan".
He was a Member of Internet Architecture Board (IAB) from 1993-1995, Board of trustee ofInternet Society (ISOC) from 1997-2000, Board of Director of the Internet Corporation for
Assigned Names and Numbers (ICANN) from1998-2000. He was inducted into The 2013 Internet
Hall of Fame (Pioneer)/ 2011 IEEE Internet Award / 2005 Jonathan B. Postel Service Award.

11

Internet Conference 2018

Invited Talk (2)Speaker: Rodney Van Meter (Keio University)
Title: Designing the quantum Internet
Abstract: The coming Quantum Internet will bring us new capabilities:
advanced cryptographic functions, high-precision sensor networks foruses such as high-resolution astronomy, and secure distributed
quantum computing. Experimental progress on the components forquantum repeaters is moving at a dizzying rate, and theorists haveproposed various approaches to managing errors to create high-fidelity
quantum entanglement. Building quantum networks presents diﬀerent
challenges from building quantum links. I will give an overview of theseissues, then discuss the even more daunting challenge of creating a
network of networks -- an internetwork -- and show how our simulations
are guiding the design of a true quantum Internet.
Biography: Rodney Van Meter received a B.S. in engineering and applied science from the
California Institute of Technology in 1986, an M.S. in computer engineering from the University ofSouthern California in 1991, and a Ph.D. in computer science from Keio University in 2006. His
current research centers on quantum computer architecture and quantum networking. Other
research interests include storage systems, networking, and post-Moore's Law computerarchitecture. He is now an Associate Professor of Environment and Information Studies at Keio
University's Shonan Fujisawa Campus. He is the Vice Dean of the Graduate School of Media andGovernance, and the Vice Center Chair of Keio's new Quantum Computing Center. Dr. Van Meter
is a member of AAAS, ACM and IEEE.

12

Internet Conference 2018

Invited Talk (3)Speaker: Michio Honda (NEC Labs Europe)
Title: Beyond Internet Research: Be Systemy!
Abstract: Research on the Internet has been a good topic for the last
three decades, thereby having produced a lot of PhDs. Examples of thework include "new" architectures, measurement and various protocol
extensions, such as mobility or multipath support, faster, flexible orsecure signaling and better data multiplexing, to name but a few. As itturns out, the Internet has demonstrated its superior scalability, but notextensibility, resulting in ossification phrased as "HTTP as a narrow waistof the Internet", "IP options are not an option" and "Is it still possible to extend TCP?".
In this talk I suggest not to do research on the Internet itself anymore, and discuss possible
interesting topics surrounding it. For example, its core technology could be a basis of solving
general networking problems. Further, unlike phone lines, the Internet is still in use, introducing a
lot of interesting workloads that stress various system components. I will review several topics
which do or do not follow this line, and introduce some of our recent and ongoing work, including
network stack, load balancer and storage stack.
Biography: Michio Honda is a senior researcher at NEC Labs Europe in Heidelberg, Germany.
Before that, he was a software engineer at NetApp in Munich. He received his phd degree in 2012at Keio University in Japan. He has worked on transport protocols, congestion control,
middleboxes, network stacks, scalable software switch, and network/storage stack co-design for
persistent memory. He has published in venues including USENIX NSDI and ATC, and ACM
HotNets, SOSR, IMC, CCR and SoCC. He received IRTF/ISOC Applied Networking ResearchPrize in 2011, and best paper award at SOSR'15. He has served as a TPC member of several
conferences, including USENIX ATC, and ACM SOSR and ANCS. He has been a contributer tothe netmap framework, bringing the research results into the real world and making them available
to everybody.

13

Internet Conference 2018

Invited Talk (4)Speaker: George Michaelson (APNIC Labs)
Title: Internet Measurement, how to get the relativities right at scale
Abstract: APNIC is now eight years into a continuous measurement of
IPv6 and DNS, based on web and in-game advertising, which cruciallydepends on random placement. We are increasingly aware of aworldwide problem establishing "ground truth" for the relative amountsof data seen from diﬀerent Origin-AS. The talk explores our
methodology and dimensions of concern for this question.
Biography: George Michaelson is currently APNIC's senior R&D scientist. Recently, he has beenworking on long-baseline DNS statistics, services logging, audit and analysis, and design andimplementation of the Internet Number Resource Certification framework. George is a member ofthe BCS, and a founder member of the Australian chapter of the Internet Society. He participates
regularly in IETF standardization meetings, and co-authors Request For Comment (RFC)
documents, technical drafts, and conference and peer-review papers. George graduated fromYork University in 1982 with a BSc in Computer Science. His career in the United Kingdom andAustralia has pursued research and development in computer science, networking, and systems
administration.

14

Internet Conference 2018

Invited Talk (5)Speaker: Paul Vixie (Farsight Security, Inc.)
Title: Past, Present, and Future of DNS Resolution
Abstract: The Domain Name System has been a critical enabler ofInternet growth since its inception in 1987. In the decades since then,the DNS _resolution_ process has evolved from the LAN to the WAN,
and to Anycast; it now includes DNSSEC _validation_, Extended DNS(EDNS) Client Subnet, larger message sizes, and I18N. The resolution
processs has also been abused for surveillance, advertising insertion,and exfiltration. Today the DNS resolution process is poorly understood,and yet under forced revision. The trend is for DNS to be carried inside
HTTPS where it cannot be monitored or controlled except by servers
and clients themselves, and the dangers this will yield must be studied and discussed while thefuture remains flexible. Dr. Vixie (Keio, 2012) will describe the past and present of DNS, anddiscuss its likely near term future.
Biography: Paul Vixie was responsible for BIND from 1989 to 1999, and is the author of a dozen
or so IETF RFC documents about DNS. He also started the first anti-spam company (MAPS), andwas the founder and later president of the first U.S.-based commercial Internet Exchange (PAIX).
Today he serves as CEO of Farsight Security, home of the Security Information Exchange (SIE)and the world's leading Passive DNS database (DNSDB). He managed the F-root DNS server
from 1996 to 2012, and wrote the Cron software used on all UNIX-type computers today. He is
also co-inventor of the DNS Response Rate Limiting (RRL) and Response Policy Zone (RPZ)
feature-sets now in wide use to protect the operational Internet Domain Name System against
online attacks. He received his Ph.D. from Keio University in 2011, and was inducted into theInternet Hall of Fame in 2014.

15

Internet Conference 2018

Invited Talk (6)Speaker: Emile Aben (RIPE NCC)
Title: Challenges and opportunities from large scale Internet
measurement infrastructures
Abstract: The RIPE NCC runs 2 large scale Internet measurement
infrastructures, RIPE Atlas and RIPE RIS. In this presentation we'll dig
deeper into these infrastructures, challenges in running them andanalysing the data coming oﬀ of them.
Biography: I'm a system architect/research coordinator at the RIPE
NCC, where I work in the science group. I'm a chemist by training, but have been working since1998 on Internet related things, as a sysadmin, security consultant, web developer andresearcher. I am interested in technology changes (like IPv6 deployment), Internet measurement,
data analysis, data visualisation, sustainability and security. I'd like to bring research andoperations closer together, ie. do research that is operationally relevant. When I'm not working I
like to make music (electric guitar, bass and drums), do sports (swimming, (inline) skating,bouldering, soccer), and try to be a good parent.

16Internet Conference 2018

Invited Talk (7)Speaker: Kelvin Cheng (Rakuten Institute of Technology, Rakuten, Inc.)
Title: Creating interactive experiences with Mixed Reality
Abstract: The ubiquity of personal mobile devices enables users accessto a wealth of online information and services at their fingertips.
However, in terms of the interactive experience, there is still a distinct
gap between what users physically see and touch at the physicallocation and the digital content that they are interacting on their mobile
device. With the use of Mixed Reality (MR), physical and digital
information spaces can be merged, in which digital content can beaccessible directly on the physical objects. In this way, MR has thepotential to enable a more immersive experience. In this talk, we explore
how MR can enhance our daily experience in terms of shopping and exhibitions, and discusses
the future of MR and the factors that need to be considered when designing Mixed Reality
experiences going forward.
Biography: Dr Kelvin Cheng is currently a Research Scientist at Rakuten Institute of Technology,
the R&D lab of Rakuten, Inc. He received his PhD in Computer Science from The University ofSydney. His previous aﬃliations were Keio-NUS CUTE Center, National University of Singapore,
and CSIRO ICT Centre, Australia. He has extensive experience and expertise in the domain ofinteracting with large surfaces and multi-display environments using bare-hand interaction, andmulti-touch devices, and more recently involved in use of augmented and mixed reality platforms
to increase consumer experiences. He has previously lectured at the National University ofSingapore on Mobile Interaction Design, as well as the use of interactive technologies such as
iBeacons and Microsoft Kinect. At Rakuten, he has been involved in projects related to mixed
reality shopping, FC Barcelona uniform collection exhibition, and 5G trial demonstrations.

17Internet Conference 201818

Internet Conference 2018

Research Topic Exchange (1)Speaker: Wasan Pattara-atikom (NECTEC)
Title:Traﬀy Waste - a smarter way to collect and management waste
collection
Abstract: The logistics of waste collecting in Thailand is mostly
performed manually with traditional route management without the helpof information technology or IoT. Although tracking device are installed
in some of the waste collecting vehicles, the tracked data were used forreal-time location but the fleeting activities and performance were not
yet analyzed and understood.
In this project, we proposed system where the trucks are equipped with a high frequency and highaccuracy GNSS-sensor. With this sensors, we can achieve fours key objectives. The first objective
is to provide real-time location and detailed activities of the waste collecting logistics such ascollecting, in-a-traﬃc-jammed, or at-terminal. The second objective is to provide performance
analytics of the collecting logistics such as truck utilization, the number of and duration of pickups per trip, and route trajectory. The third objectives is provide more eﬀecient route
recommendation to reduce fuel and operational costs. The location of waste pick-up are identified
and extracted automatically using machine learning. The fourth objective is provide two-way
communications with citizen using mobile application. Mobile application can be applied toenable the request-for-pick-up with a notification when the vehicle is near the requested pick-up
location. This system can improve vehicle utilization, reduce operating cost, make the city cleaner.
Biography: Wasan Pattara-atikom is currently the Head of the Intelligent Transportation Systems
Laboratory and Principal Researcher at NECTEC. He earned two Master degrees in
Telecommunications and Business Administration, and a Doctor of Philosophy in Information
Science from the University of Pittsburgh. His research interest focus on the area of Intelligent
Transportation Systems (ITS) and Data Analytics Visualization.
He was responsible for the Traﬃc Information Dissemination Project (Traﬀy) which was selected
as an outstanding project by the National Science and Technology Development Agency and theMinistry of Science and Technology in 2008 and 2009. Dr. Pattara-atikom published over 80 peer
reviewed articles, submitted 7 patents.. He was recently listed on top scientists in Thai Institutions
according to their Google Scholar Profiles. He also served in the oﬃce the Ministry of Science andTechnology in 2012, and in the oﬃce of the Deputy Prime Minister in 2013.

19

Internet Conference 2018

Research Topic Exchange (2)Speaker: Ndenge Godden Zama (BlackedOut Africa)
Title: The Cameroon Internet Shutdowns-Technological Framework
Abstract: Research shows that one of the following techniques, DNSbased blocking, IP address blocking, URL-Based blocking, SearchEngine platform censoring, and Deep packet inspection based blocking
have been used in the past to block or filter content by governments in Africa. The Cameroon
internet shutdown was a total black out. This paper seeks for illustrate how it was done and theimpact on innovation and development.
Biography: Ndenge Godden Zama is a Data and Internet Freedom Activist and the founder ofBlackedOut Africa. BlackedOut Africa is a organization that fosters policy and advocates for a
free, open and accessible internet in Africa. The organization has engaged the private sector andgovernments all over Africa to keep an open access to the internet as a key catalyst for growthand development. Zama has a BSc in Management and an MA in ICT in Education. He is also
research fellow at the African Center for Research, Development and Climate Change

20Internet Conference 2018

Research Topic Exchange (3)Speaker: Juan Ramón Santana (University of Cantabria)
Title: SmartSantander: an IoT-based Smart City Testbed
Abstract: SmartSantander testbed is an urban deployment of Internet ofThings (IoT) devices in the city of Santander. Such massive deployment
has a two-fold approach. On the one hand, it allows to the scientificcommunity to experiment with IoT technologies and Smart City services,
including prototyping deployments in a real urban scenario. On the other
hand, it also provides a set of services to the citizens, including parking
management or environmental monitoring, among others. During thepresentation, the SmartSantander testbed will be described, including the architecture andcommunication technologies used in the testbed. Furthermore, the presentation will also include
the current eﬀorts to federate testbeds from Europe and the rest of the world, and the movement
to implement open standards for the Smart City through FIWARE.
Biography: Juan Ramón Santana obtained his MSc in Telecommunication Engineering at the
University of Cantabria in 2010. He is currently working as research fellow in the Network Planningand Mobile Communications Laboratory, a telecommunication research group from the same
university. Prior to his current occupation, he stayed for six months in the Silent Herdsman startup
company (formerly known as Embedded Technology Solutions), a spin-oﬀ from the University ofStrathclyde in Glasgow, working on IoT solutions for the cattle industry. Since then, he has been
involved in several Smart City international projects, from which we can highlight SmartSantander,
working on tasks such as the integration and deployment of the SmartSantander communication
infrastructure; Over the Air firmware update implementation; and the testbed platform
development.
Beyond SmartSantander, he has been also working in other EU projects, such as EAR-IT, FIESTAIoT or FESTIVAL, an EU-Japan collaborative project, working on platforms to federateinternational testbeds. Finally, it is worth mentioning that he has collaborated in more than 20
publications, including conferences, journals and book chapters.

21

Internet Conference 201822

Internet Conference 2018

Paper Presentation

23

Internet Conference 2018αΠόʔԋशͷ๷‫ޚ‬ԋश࣌ʹ͓͚ΔγφϦΦਐߦͷࣗಈԽγεςϜͷఏҊҪ্ɹ୓࠸ 1 , Razvan Beuran1

AbstractαΠόʔਓࡐͷҭ੒͚ͩͰͳ͘ɼଟ͘ͷਓʹαΠόʔۭؒͷ‫ڴ‬Җʹ͍ͭͯ஌ͬͯ΋Β͏ͨΊʹ΋αΠόʔԋश͕ඞཁͱͳΔɻͦͷதͰ΋ɼ‫ڴ‬Җͷೝ͓ࣝΑͼରॲͷͨΊɼαΠόʔ߈ܸʹର͢Δ๷‫ޚ‬ԋश͕ॏཁͰ͋Δɻ͔͠͠ɼ‫ط‬ଘͷ๷‫ޚ‬ԋशʹ͸‫ڭ‬ҭʹؔ͢Δ‫ػ‬ೳ͕͚͍ܽͯΔɻຊߘͰ͸ɼ๷‫ޚ‬ԋशʹΑΔηΩϡϦςΟ‫ڭ‬ҭΛී‫ͤ͞ٴ‬ΔͨΊɼ๷‫ޚ‬ԋशͷਐߦͱࢦಋΛࣗಈԽ͢ΔͨΊͷγεςϜ”DeTMan”ΛఏҊ͢Δɻ·ͣ͸‫ط‬ଘͷ๷‫ޚ‬ԋशʹ͍ͭͯߟ࡯͠ɼ‫ڭ‬ҭγεςϜͱͯ͠༻͍Δʹ͋ͨΓඞཁͳ‫ػ‬ೳʹ͍ͭͯ‫ݕ‬౼͢Δɻ࣍ʹɼ‫ݕ‬౼͞Εͨ‫ػ‬ೳΛ͍͔ʹ࣮ͯ͠૷͢Δ͔‫ݕ‬౼͠ɼ֓೦࣮૷Λߦ͏ɻ࠷‫ʹޙ‬ɼ࣮૷ͨ͠ DeTMan ʹ͍ͭͯɼ‫ڭ‬ҭγεςϜͱͯ͠ͷ๷‫ޚ‬ԋशͷ‫͔఺؍‬Β‫͢ূݕ‬Δɻ

Keywords: αΠόʔηΩϡϦςΟ, αΠόʔԋश, ๷‫ޚ‬ԋश, αΠόʔϨϯδ
1. ͸͡Ίʹ

2. ‫ط‬ଘͷ๷‫ޚ‬ԋश‫ڭ‬ҭͱͯ͠ͷ๷‫ޚ‬ԋशΛఏ‫͢ڙ‬Δʹ͋ͨΓɼ‫ط‬ଘͷ๷‫ޚ‬ԋशͰ͋Δ Hardening ͱ Micro Hardening Λྫʹߟ࡯͢Δɻ

‫ࡏݱ‬ɼٕज़ͷൃలʹ൐͍ɼ‫ͯͬͱʹۀا‬΋‫ݸ‬ਓʹͱͬͯ΋ηΩϡϦςΟϦεΫ͸ਂࠁͳ΋ͷͱͳͬͯ
͍Δɻ͔͠͠ɼIT ٕज़Λద੾ʹѻ͏ͨΊͷ‫ڭ‬ҭ͕ൃలʹ௥͍͍͍ͭͯͳ͍ɻηΩϡϦςΟਓࡐͷෆ଍ [1]΍ɼࣾձͷηΩϡϦςΟʹؔ͢Δҙࣝ [2] ͕େ͖ͳ໰୊ͱͳ͍ͬͯΔɻͦͷͨΊɼຊߘͰ͸ɼηΩϡϦςΟਓࡐͷҭ੒ʹେ͖ͳ໾ׂΛՌ͍ͨͯ͠Δ๷‫ޚ‬ԋशʹ஫໨ͨ͠ɻ๷‫ޚ‬ԋशͰ͸ɼडߨऀ͸༩͑ΒΕͨ‫ʹڥ؀‬ର࣮͠ߦ͞ΕΔ߈ܸʹରॲ͢Δ͜ͱͰɼαΠόʔ߈ܸͷ‫ڴ‬Җͱରࡦʹֶ͍ͭͯͿɻ

2.1. Hardening ͷ঺հHardening ͱ ͸ ɼWeb Application Security Forum(WASForum) ͕ओ࠵͢ΔηΩϡϦςΟ‫ݎ‬࿚Խͷ‫ٕڝ‬େձͰ͋ΔɻHardening Ͱ͸ɼ੬ऑੑΛ࣋ͭ EC
αΠτͷӡӦͯ͠ɼνʔϜର߅ͰചΓ্͛Λ‫͏ڝ‬ɻHardening ʹ͓͚ΔചΓ্͛ͱ͸ɼΫϩʔϥʔʹΑ
Δ EC αΠτͰͷࣗಈߪೖʹΑͬͯ੒ཱ͢ΔɻӡӦଆ͔Βͷ߈ܸʹରͯ͠ɼࢀՃऀ͸γεςϜΛ‫ݎ‬࿚Խ͢Δ͜ͱͰαʔϏεΛҡ࣋͠ɼചΓ্͛ͷ࠷େԽΛ໨ࢦ͢ɻ๷‫ޚ‬ԋशͷ։࠵ʹ͸ɼਤ 1 ʹࣔ͢ 3 ͭͷεςοϓ
͕ඞཁͱͳΔɻ૝ఆ͢Δ߈ܸऀͷߦಈ΍߈ܸύλʔϯͳͲΛࡦఆ͢Δ (1) ๷‫ޚ‬ԋशγφϦΦͷ࡞੒ɼγφϦΦʹԊͬͨ๷‫ޚ‬ԋशͷ‫ڥ؀‬Λߏங͢Δ (2) ๷‫ޚ‬ԋश‫ڥ؀‬ͷߏஙɼࢀՃऀʹ߈ܸΛ༩͑Δ (3) ๷‫ޚ‬ԋशͷ࣮ࢪͰ͋Δɻ๷‫ޚ‬ԋशγφϦΦͷ࡞੒͸ɼ๷‫ޚ‬ԋशʹ͓͍ͯ࠷΋ॏཁͳ෦෼Ͱ͋ΔɻͲͷΑ͏ͳԋशΛߦ͏ͷ͔ɼͲͷΑ͏ͳ߈ܸΛߦ͏ͷ͔ (ͲͷΑ͏ͳ੬ऑੑΛຒΊࠐΉͷ͔)ɼͲͷΑ͏ʹਐߦ͢Δͷ͔ʹ͍ܾͭͯఆ͢Δɻ
Hardening Ͱ͸༷ʑͳ෼໺ͷઐ໳Ո͕ू·ΓɼԋशγφϦΦΛ࡞੒͢Δɻ๷‫ޚ‬ԋश‫ڥ؀‬ͷߏஙͰ͸ɼ࡞੒ͨ͠๷‫ޚ‬ԋशγφϦΦʹ‫͍ͯͮج‬ԋश‫ڥ؀‬Λ࡞੒͢Δɻ๷‫ޚ‬ԋशͰ͸࣮ࡍʹ߈ܸ͢ΔͨΊɼԾ૝‫Ͱڥ؀‬ԋशΛ࣮ࢪ͢Δඞ

ແྉͰࢀՃՄೳͳ๷‫ޚ‬ԋशͱͯ͠ɼHardening[3]ͱ Micro Hardening[4] ͕͋Δɻ๷‫ޚ‬ԋशͷ։࠵ʹ͸ɼηΩϡϦςΟʹؔ͢Δߴ౓ͳઐ໳஌͕ࣝඞཁͱͳΔɻͦͷͨΊɼ‫ࡏݱ‬ͷओྲྀͳ๷‫ޚ‬ԋश͸ɼಛఆͷਓ෺΍ஂମʹΑͬͯӡӦ͞ΕΔʹཹ·͍ͬͯΔɻ݁Ռͱ͠
ͯɼ๷‫ޚ‬ԋशͷ‫ػ‬ձ͸‫ݶ‬ΒΕͯ͠·͍ɼधཁΛຬ͍ͨͤͯͳ͍ɻ๷‫ޚ‬ԋशΛී‫ʹٴ‬͸ɼΑΓ؆୯ʹ։࠵
Ͱ͖Δ͜ͱ͕ॏཁͰ͋Δɻ·ͨɼ‫ࡏݱ‬ͷ๷‫ޚ‬ԋश͸ԋशʹΑΔ‫܇‬࿅ʹॏ͖͕ஔ͔Ε͓ͯΓɼԋशͷࢀՃऀʹର͢ΔࢦಋͳͲ΋ఏ‫͞ڙ‬ΕΔɻ
ຊߘͰ͸ɼHardening ͱ Micro Hardening Λࢀߟͱͯ͠๷‫ޚ‬ԋशʹΑΔ‫ڭ‬ҭγεςϜʹ͍ͭͯߟ࡯͢Δɻ
ͦͯ͠ɼ‫ڭ‬ҭͱͯ͠ͷ๷‫ޚ‬ԋशΛఏ‫͢ڙ‬ΔαΠόʔ๷‫ޚ‬ԋशਐߦ؅ཧγεςϜ”DeTMan”ΛఏҊ͢Δɻ

1 ๺཮ઌ୺Պֶٕज़େֶӃେֶPreprint submitted to Internet Conference 2018

November 16, 201824

Internet Conference 2018͍ͯௐࠪ͠ɼ࣍ͷηοτͰରࡦΛࢪ͢ͱ͍ͬͨࢼߦ
ࡨ‫ޡ‬Λɼ1 ౓ͷԋशͷதͰ‫܁‬Γฦ͢͜ͱ͕Ͱ͖Δɻ

3. ‫ط‬ଘͷ๷‫ޚ‬ԋश͕࣋ͭ‫ڭ‬ҭ্ͷ՝୊
3.1. ։࠵ͷࠔ೉͞γφϦΦͷ࡞੒͸ԋशʹ͓͍ͯɼ࠷΋ॏཁͳεςοϓͰ͋ΔɻγφϦΦ͸ɼԋशͷ໨తʹԠͯ͡‫ݕ‬౼͢
Δඞཁ͕͋ΔɻͦͷͨΊɼઐ໳Ոͷ஌‫ݟ‬Λ‫ͯ͠༻׆‬࡞੒͢Δɻ·ͨɼ࡞੒ͨ͠γφϦΦ͸ɼԋशͷ໨త͕ಉ͡Ͱ͋Ε͹࠶ར༻͕ՄೳͰ͋Δɻԋश‫ڥ؀‬ͷߏஙʹ͸ɼCyRIS[6] ͳͲͷαΠόʔϨϯδߏஙπʔϧ΍ɼAnsible ͳͲͷߏ੒؅ཧπʔϧΛ༻͍Δ͜ͱΛਪ঑͢Δɻ‫ڥ؀‬ͷߏங͕؆୯ʹͳΔͩ
͚Ͱͳ͘ɼಉ͡ԋशΛ։࠵͢Δ৔߹ʹԋश‫ڥ؀‬Λ؆୯ʹߏஙͰ͖ΔͨΊͰ͋Δɻ্‫ه‬ͷπʔϧ‫܈‬͸ɼԋ‫ڥ؀‬ͷߏஙʹઃఆϑΝΠϧΛ༻͍ΔɻઃఆϑΝΠϧͷ࠶ར༻ʹΑΓɼԿ౓Ͱ΋ಉ͡ԋश‫ڥ؀‬Λ࡞੒͢Δ
͜ͱ͕Ͱ͖Δɻԋशʹ͓͍࣮ͯߦ͞ΕΔ߈ܸ͸ଟछଟ༷Ͱ͋Δͨ
Ίɼ༷ʑͳ෼໺ͷٕज़ऀ͕ඞཁͱͳΔɻ·ͨɼԋशͷࢀՃऀ͸ɼӡӦଆͷਓ਺ΑΓ΋ଟ͍ɻͦͷͨΊɼखಈͰ߈ܸ͢Δ৔߹ʹ͸ӡӦଆʹॏ͍ෛ୲͕͔͔Δɻ‫ڭ‬ҭͷҰ‫ͯ͠ͱ؀‬๷‫ޚ‬ԋशΛී‫ͤ͞ٴ‬ΔͨΊʹ͸ɼಛผͳਓࡐ͕ඞཁͰ͋Δ͜ͱ΍ӡӦଆʹॏ͍ෛ୲Λ‫ڧ‬͍Δ͜ͱ͸໰୊Ͱ͋Δɻ
γφϦΦͱԋश‫ڥ؀‬ͷߏங͸࠶ར༻͕ՄೳͰ͋Δɻ
͔͠͠ɼԋशͷ࣮ࢪ͸࠶ར༻͕Ͱ͖ͳ͍ɻͦͷͨΊɼ๷‫ޚ‬ԋशʹ͓͍ͯԋशͷ࣮ࢪ͕ෛ୲ͱͳ͍ͬͯΔɻ
Micro Hardening ͸ɼԋशͷਐߦΛࣗಈԽ͢Δ͜ͱʹΑΓͨͬͨ 1 ਓͰ΋։࠵ՄೳͰ͋ΔɻͦͷͨΊɼ๷‫ޚ‬ԋशΛ‫ڭ‬ҭͱͯ͠ఏ‫͢ڙ‬Δ৔߹ʹ͸ࣗಈԽʹΑΔ
ෛ୲ܰ‫͕ݮ‬ඞཁͰ͋Δɻਤ 1: ๷‫ޚ‬ԋशͷ 3 εςοϓཁ͕͋ΔɻHardening ʹ͓͚Δԋश‫ڥ؀‬͸ɼAlfons[5]ͱ‫ݺ‬͹ΕΔ‫ߏڥ؀‬ஙγεςϜΛ༻͍ͯԋश‫ڥ؀‬Λߏங͍ͯ͠Δɻ
࠷‫ʹޙ‬ɼ࣮ࡍʹԋशΛ࣮ࢪ͢ΔɻHardening Ͱ͸ɼӡӦଆͷ߈ܸ͸͢΂ͯखಈͰ࣮ߦ͞ΕΔɻӡӦଆ͸ձ৔ʹઃஔ͞ΕͨΧϝϥͰࢀՃऀͷ༷ࢠΛ֬ೝ͠ͳ͕Β߈ܸ͢ΔͨΊɼνʔϜʹ߹Θͤͯ߈ܸΛௐ੔͢
Δ͜ͱ͕Ͱ͖ΔɻͦͷͨΊɼॱௐʹਐΜͰ͍ΔνʔϜʹ͸ΑΓߴ౓ͳ߈ܸΛɼ௿ௐͳνʔϜʹ͸߈ܸΛ͠ͳ͍ͱ͍ͬͨɼॊೈͳਐߦ͕ՄೳͰ͋Δɻ
·ͨɼHardening Ͱ͸࣮‫ڥ؀‬Λ૝ఆͨ͠Ծ૝ωοτϫʔΫΛ࢖༻͢Δ͚ͩͰͳ͘ɼ‫ސ‬٬ରԠ΍্໾΁ͷใࠂɼ͞Βʹ͸ϚʔέοτϓϨΠεͱ‫ݺ‬͹ΕΔ‫ۀا‬ͷαʔϏεಋೖͳͲ΋‫ٕڝ‬ͷதͰߦΘΕΔɻٕज़͚ͩͳ͘ɼαΠόʔηΩϡϦςΟʹ‫ܞ‬ΘΔ্Ͱඞཁʹ
ͳΔͱߟ͑ΒΕΔ༷ʑͳ஌ࣝ΍εΩϧΛֶͿ͜ͱ͕ՄೳͰ͋Δɻ

2.2. Micro Hardening

3.2. डߨऀʹԠͨ͡ԋशͷਐߦ

Micro Hardening ͸‫ࣜג‬ձࣾ઒‫ޱ‬ઃ‫ܭ‬ͷ઒‫ޱ‬༸ࢯʹΑͬͯఏ‫͞ڙ‬ΕΔ‫ࣜܗٕڝ‬ͷษ‫ڧ‬ձͰ͋ΔɻHardening Project ͷαϒϓϩδΣΫτͱͯ͠஀ੜͨ͠ɻ
Hardening ͱൺֱͯ͠ɼΧδϡΞϧͳԋशʹͳ͍ͬͯΔɻ‫ٕؒ࣌ڝ‬͸ 1 ηοτ 45 ෼Ͱ͋Γɼ1 ౓ͷԋशͰɼ
3 ηοτҎ্ಉ͡಺༰Λ‫܁‬Γฦ͢ɻ؆ૉԽͷͨΊʹɼ‫ސ‬٬ରԠ΍্໾΁ͷใࠂͱ͍ͬͨɼٕज़తͳରࡦҎ֎ͷཁૉ͸ল͔Ε͍ͯΔɻ
Micro Hardening ͸๷‫ޚ‬ԋश‫ڥ؀‬ͷߏங͔Β߈ܸͷ࣮ߦ·ͰɼશͯࣗಈԽ͞Ε͍ͯΔɻͦͷͨΊɼ઒‫ޱ‬
ࢯ 1 ਓ͚ͩͰ΋ӡӦ͕ՄೳͰ͋ΓɼMicro Hardening͸೔ຊ֤஍Ͱසൟʹ։࠵͞Ε͍ͯΔɻ
Micro Hardening Ͱ͸ɼ߈ܸͷ࣮ߦ͸࣌ؒʹΑͬͯಈ࡞͢ΔλΠϜυϦϒϯํࣜʹΑΓࣗಈԽ͞Ε͍ͯΔɻͦͷͨΊɼ͢΂ͯͷηοτʹ͓͍ͯಉ͡λΠϛϯάͰಉ͡߈ܸ͕࣮ߦ͞ΕΔɻࢀՃऀ͸ɼ߈ܸʹͭ

Micro Hardening ͸λΠϜυϦϒϯํࣜʹΑΓࣗಈԽ͞Ε͍ͯΔɻ͔͠͠ɼλΠϜυϦϒϯํࣜͰ͸डߨऀશһʹಉ͡಺༰ͷԋशΛఏ‫͢ڙ‬Δ͜ͱʹͳΔɻͦͷͨΊɼԋश͕‫ج‬४ͱ͍ͯ͠ΔϨϕϧ͔Β཭Ε͍ͯ
Δਓ͸ର৅֎ͱͳͬͯ͠·͏ɻ‫ڭ‬ҭͱͯ͠ͷ๷‫ޚ‬ԋशͰ͸ɼHardening ͷΑ͏ʹडߨऀͦΕͧΕͷঢ়‫߹ʹگ‬ΘͤͯԋशΛࣗಈͰਐߦ͞
ͤΔඞཁ͕͋Δɻ
3.3. डߨऀʹର͢Δࢦಋͷෆ଍
DoS ߈ܸͷΑ͏ͳྫ֎Λআ͖ɼαΠόʔ߈ܸͱ͸ίϯϐϡʔλͷॴ༗ऀʹ‫͔෇ؾ‬Εͳ͍Α͏ʹ࣮ߦ͞
ΕΔɻHardening ΍ Micro Hardening ͸ɼ࣮ࡍͷ‫ڥ؀‬ʹ͍ۙ‫ͨ͏ߦͰܗ‬Ίɼ߈ܸ͞Εͨ͜ͱʹ‫ͱ͘͜෇ؾ‬΋·ͨɼԋशͷҰ෦Ͱ͋ΔɻͦͷͨΊɼ߈ܸʹ‫෇ؾ‬

25

Internet Conference 2018• ਐߦͷಠཱ

͘͜ͱͳ͘ԋश͕ऴྃ͢Δࣄଶ΋े෼ʹ૝ఆ͞ΕΔɻ͜Ε͸ɼ‫ڭ‬ҭͱͯ͠͸໰୊Ͱ͋Δɻ
จ෦Պֶলͷߴ౳ֶߍֶशཁ߲ [7] ʹ͓͍ͯɼʮ‫ج‬ૅతɾ‫ج‬ຊతͳ஌ࣝ‫ٕͼٴ‬ೳΛ࣮֬ʹशಘͤ͞ɼ͜
ΕΒΛ‫ͯ͠༻׆‬՝୊Λղܾ͢ΔͨΊʹඞཁͳࢥߟྗɼ
൑அྗɼද‫ͦྗݱ‬ͷଞͷೳྗΛ͸͙͘Ήͱͱ΋ʹɼओମతʹֶशʹऔΓ૊Ήଶ౓Λཆ͍ɼ‫ݸ‬ੑΛੜ͔͢‫ڭ‬ҭͷॆ࣮ʹ౒Ίͳ͚Ε͹ͳΒͳ͍ʯͱ‫͞ࡌه‬Ε͍ͯΔɻ·ͨɼʮ‫ݸ‬ʑͷੜెͷಛੑ౳ͷత֬ͳ೺Ѳʹ౒Ίɼͦͷ৳௕ΛਤΔ͜ͱʯͱ‫͞ࡌه‬Ε͍ͯΔɻͭ·Γɼ‫ڭ‬ҭͱͯ͠๷‫ޚ‬ԋशΛߦ͏ʹ͸ɼडߨऀͷਐ௙ʹԠͯ͡ɼηΩϡϦςΟʹ͍࣮ͭͯ֬ʹशಘͤ͞Δ͜ͱ͕
ඞཁͰ͋Δɻ
Hardening ΍ Micro Hardening Ͱ͸ԋश‫ޙ‬ͷղઆʹΑΓɼͲͷΑ͏ͳ߈ܸ͞Εͨͷ͔ʹ͍ͭͯ͸஌Δ͜
ͱ͕Ͱ͖Δɻ͔͠͠ɼԋश‫ޙ‬ͷղઆͰ͸͍ͭɾͲͷΑ͏ʹ߈ܸ͞Εͨͷ͔͸Θ͔Βͳ͍ɻͦͷͨΊɼ߈ܸ͞Εͨࡍʹίϯϐϡʔλ͸ͲͷΑ͏ͳ൓ԠΛࣔ͢ͷ͔ɼ஌Δ͜ͱ͕Ͱ͖ͳ͍ɻ‫ڭ‬ҭͱͯ͠͸ɼԋशதʹࢦಋ͢Δඞཁ͕͋Δɻ
·ͨɼ߈ܸʹ͍ͭͯ‫͑ڭ‬Δ͚ͩͰ͸ෆे෼Ͱ͋Δɻྫ͑͹ɼडߨऀ͕ͲͷϩάϑΝΠϧΛ֬ೝ͢Δ΂͖ͳͷ͔஌Βͳ͚Ε͹ͦΕҎ্ͷ৘ใʹ͍ͭͯௐࠪͰ
͖ͳ͍ɻՃ͑ͯɼϩάอଘͷઃఆ͕ద੾Ͱͳ͚Ε͹ɼͦ΋ͦ΋֬ೝ͢ΔͨΊͷ৘ใ͕ଘࡏ͠ͳ͍ɻ
๷‫ޚ‬ԋशʹ͓͚ΔࢦಋͰ͸ɼԋशதʹɼͲͷΑ͏ͳ߈ܸ͔͚ͩͰͳ͘ɼ‫ݕ‬஌ํ๏΍ରࡦ·Ͱࢦಋ͢Δ
ඞཁ͕͋Δɻ• ਐߦͷ෼‫ذ‬• ࢮ‫ػࢹ؂׆‬ೳ• ΠϕϯτυϦϒϯํࣜʹΑΔਐߦ‫ػ‬ೳ
4.1.1. ਐߦͷಠཱडߨऀͷঢ়‫ʹگ‬Ԡͯ͡ਐߦͤ͞ΔͨΊʹ͸ɼԋशͷਐߦΛडߨऀ͝ͱʹಠཱͤ͞ͳ͚Ε͹ͳΒͳ͍ɻਐߦΛಠཱͤ͞Δ͜ͱʹΑΓɼଞͷडߨऀʹΑΔӨ‫ڹ‬Λड͚Δ͜ͱͳࣗ͘෼ͰϖʔεͰਐߦՄೳʹͳΔɻ
4.1.2. ਐߦͷ෼‫ذ‬डߨऀͷঢ়‫گ‬͸ɼνʔϜ͝ͱʹҟͳΔɻडߨऀʹԠͨ͡ਐߦʹ͸ɼॱௐͳडߨऀʹ͸ΑΓߴ౓ͳ߈ܸ
Λɼ௿ௐͳडߨऀʹ͸؆୯ͳ߈ܸ΍๷‫ࣦʹޚ‬ഊͨ͠߈ܸΛ‫܁‬Γฦ͢ͱ͍ͬͨਐߦ͕ඞཁͰ͋ΔɻͦͷͨΊɼԋशͷਐߦΛ෼‫ͤ͞ذ‬Δඞཁ͕͋Δɻ
4.1.3. ࢮ‫ػࢹ؂׆‬ೳडߨऀ͕؅ཧ͢ΔωοτϫʔΫʹ͓͍ͯαʔϏε͕ఀࢭ͍ͯ͠Δ৔߹͸ɼԿΒ͔ͷΞΫγσϯτ͕ൃ
ੜ͍ͯ͠Δͱߟ͑ΒΕΔɻͦͷͨΊɼαʔϏε͕ఀࢭ͍ͯ͠Δ৔߹͸߈ܸΛ͢Δ΂͖Ͱ͸ͳ͍ɻ
4.1.4. ΠϕϯτυϦϒϯํࣜʹΑΔਐߦ‫ػ‬ೳࢮ‫ػࢹ؂׆‬ೳ͚ͩͰ͸ɼडߨऀ͕‫ٸۓ‬ͷॲஔͱͯ͠αʔϏεΛ࠶‫ى‬ಈΛ͚ͨͩ͠ͷ৔߹Ͱ΋߈ܸΛ࠶։͢Δɻ߈ܸʹର͢Δௐࠪ͢Δ࣌ؒΛ֬อ͢ΔͨΊʹ΋ɼࢮ‫ػࢹ؂׆‬ೳҎ֎ʹ΋߈ܸΛ଴‫͢ػ‬Δ‫ػ‬ೳ͕ඞཁʹͳΔɻ
ΠϕϯτυϦϒϯํࣜΛ༻͍Δ͜ͱʹΑΓɼಛఆͷΠϕϯτ͕ൃੜ͢Δ·ͰɼਐߦΛ଴‫ͤ͞ػ‬Δ͜ͱ
͕ՄೳͰ͋Δɻ

4. ‫ڭ‬ҭͱͯ͠ͷ๷‫ޚ‬ԋशͷͨΊͷࣗಈԽγεςϜ๷‫ޚ‬ԋशΛ‫ڭ‬ҭͱͯ͠ී‫ͤ͞ٴ‬Δ৔߹ʹ͸ɼӡӦͷෛ୲Λܰ͘͢ΔͨΊʹਐߦͷࣗಈԽ͕ॏཁͰ͋Δɻ
͔͠͠ɼ‫ط‬ଘͷࣗಈԽ͞Εͨ๷‫ޚ‬ԋशͰ͋Δ Micro
Hardening ͸ɼHardening ʹ͋ͬͨॊೈ͕ࣦ͞ΘΕ͍ͯΔɻ·ͨɼ‫ط‬ଘͷ๷‫ޚ‬ԋश͸‫ڭ‬ҭతͳࢦಋ͕ෆ଍
͍ͯ͠ΔɻͦͷͨΊɼ‫ڭ‬ҭͱͯ͠ͷ๷‫ޚ‬ԋशʹ͸ҎԼͷ఺͕ॏཁʹͳΔɻ

4.2. ࢦಋํ๏
ԋशʹΑΔηΩϡϦςΟ‫ڭ‬ҭͱͯ͠ҎԼͷ 3 ఺͕ඞཁͩͱߟ͑ΒΕΔɻ

• डߨऀͷঢ়‫ʹگ‬Ԡͨ͡ਐߦΛͲͷΑ͏ʹࣗಈԽ͢Δ͔• ஈ֊తͳ߈ܸͷ௨஌• ͲͷΑ͏ʹࢦಋ͢Δ͔• डߨऀͷཧղΛ֬ೝ• ͲͷΑ͏ͳৼΓฦΓΛఏ‫͢ڙ‬Δ͔• ԋशͷৼΓฦΓ

4.1. डߨऀͷঢ়‫ʹگ‬Ԡͨ͡ਐߦ

4.2.1. ஈ֊తͳ߈ܸͷ௨஌ຊߘͷ໨త͸ɼԋशʹΑΔ‫ڭ‬ҭͰ͋Δɻ1 ౓ʹ߈ܸʹؔ͢Δ͢΂ͯͷ৘ใΛ௨஌ͯ͠͸डߨऀࣗΒ͕
ߟ͑Δ‫ػ‬ձ͕ࣦΘΕͯ͠·͏ɻͦͷͨΊɼҟৗͷൃੜɾௐࠪ͢΂͖ϑΝΠϧɾ࣮ߦ͞Εͨ߈ܸɾରࡦํ
๏ͱஈ֊తʹडߨऀʹ௨஌͢Δ‫ػ‬ೳ͕ඞཁͰ͋Δɻडߨऀͷਐ௙ʹ߹ΘͤΔͨΊʹ͸ɼडߨऀ͕߈ܸʹରॲ͢Δ·Ͱ଴‫͢ػ‬Δ͜ͱͱɼडߨऀͷঢ়‫ʹگ‬Ԡͯ͡ҟͳΔ߈ܸΛ࣮ߦ͢Δ͜ͱ͕ඞཁʹͳΔɻ߈ܸΛ଴‫ͤ͞ػ‬ΔγεςϜ͸ɼҎԼͷ 4 ͭͷ‫ػ‬ೳʹΑΓ࣮૷Ͱ͖Δͱߟ͑ΒΕΔɻ

26

Internet Conference 2018

ਤ 2: DeTMan ͷ֓ཁਤ 3: DeTMan ͷಈ࡞

4.2.2. डߨऀͷཧղΛ֬ೝγεςϜʹ‫ݴ‬ΘΕΔ͕··ʹɼԿ΋ཧղͤͣԋशΛਐΊΔΑ͏ͳࣄଶ͸ආ͚ͳ͚Ε͹ͳΒͳ͍ɻडߨ
ऀͷཧղঢ়‫گ‬Λ֬ೝ͢Δ‫ػ‬ೳ͕ඞཁͰ͋Δɻ

DeTMan ͸ԋशͷਐߦΛಠཱͤ͞ΔͨΊʹɼडߨऀ਺ (༻ҙ͞Εͨԋश‫ͱ )਺ڥ؀‬ಉ਺ͷࢠϓϩηεΛ
ੜ੒͢Δɻԋशͷਐߦ͸ࢠϓϩηε͕୲͏ɻ1 ͭͷ‫؀‬‫͍ͯͭʹڥ‬ɼ1 ͭͷࢠϓϩηεΛׂΓ౰ͯΔ͜ͱʹΑΓɼਐߦͷಠཱʹ੒ޭͨ͠ɻ
DeTMan ͷಈ࡞Λਤ 3 ʹࣔ͢ɻDeTMan ͷ֤ಈ࡞ʹ͓͍ͯɼॳ‫ظ‬ઃఆҎ֎͸ࢠϓϩηε͕୲౰͢ΔɻҎ߱ͷ߲ʹ͓͍ͯɼDeTMan ͷ֤ಈ࡞ʹ͍ͭͯઆ໌
͢Δɻ

4.2.3. ԋशͷৼΓฦΓ߈ܸʹ͍ͭͯௐࠪ͢Δʹ͸ҎԼͷ৘ใ͕ඞཁʹͳΔɻ
• ͍ͭ߈ܸͨ͠ͷ͔• ͲͷΑ͏ͳ߈ܸΛͨ͠ͷ͔

5.2. DeTMan ͷಈ࡞• ݁Ռ͸Ͳ͏ͩͬͨͷ͔

5.2.1. ॳ‫ظ‬ઃఆ
DeTMan Ͱ͸νʔϜϑΝΠϧͱγφϦΦϑΝΠϧ
ͱ͍͏ 2 ͭͷઃఆϑΝΠϧΛ࢖༻͢ΔɻνʔϜϑΝΠϧʹ͸डߨऀ໊ (νʔϜ໊) ͱ߈ܸର৅ͱͳΔαʔόʹ͍ͭͯ‫ه‬ड़͢ΔɻγφϦΦϑΝΠϧʹ͸ԋशͷ۩ମతͳྲྀΕʹ͍ͭͯ‫ه‬ड़͢ΔɻγφϦΦϑΝΠϧ
ͷαϯϓϧΛਤ 4 ʹࣔ͢ɻ
DeTMan ʹ͓͍ͯɼγφϦΦϑΝΠϧ಺ͷ 1 ͭͷ·ͱ·ΓΛεςοϓͱ‫Ϳݺ‬ɻͭ·ΓɼγφϦΦϑΝ
Πϧͱ͸εςοϓͷू߹ମͰ͋Δɻ
DeTMan ͸ΞΫγϣϯͷ੒൱ʹԠͯ͡ಈ࡞ΛมԽ͞
ͤΔ͜ͱ͕ՄೳͰ͋ΔɻγφϦΦϑΝΠϧͷ successͱ failure ʹ͸ɼΞΫγϣϯ͕੒ޭ·ͨ͸ࣦഊͨ͠৔
߹ʹ͍ͭͯ‫ه‬ड़͞Ε͍ͯΔɻ·ͨɼDeTMan ʹ͸๷‫ޚ‬ԋशʹ‫ٕڝ‬ཁૉͷ࣋ͪࠐΈΛՄೳͱ͢ΔͨΊɼϙΠϯτ‫ػ‬ೳ͕͋Δɻsuccess ͱ failure ʹ͸ɼnext ʹ࣍ͷεςοϓΛɼpoint ʹΞΫγϣϯऴྃ‫ʹޙ‬Ճ‫͞ࢉݮ‬ΕΔϙΠϯτΛ‫ه‬ड़͢Δɻॳ‫ظ‬ઃఆͰ͸ɼ·ͣɼ2 ͭͷઃఆϑΝΠϧΛಡΈࠐΉɻγφϦΦϑΝΠϧͰ͸ɼtriggerɼsuccessɼfailure͸লུՄೳͰ͋ΔɻϑΝΠϧͷಡΈࠐΈ‫ޙ‬ɼলུ͞Εͨ෦෼Λิ‫͠׬‬ɼDeTMan ༻ʹ࠶ߏ੒͢Δɻ࣍ʹɼσʔλϕʔεʹؔ͢ΔઃఆΛߦ͏ɻ๷‫ޚ‬ԋशͷਐߦ߈ܸͷλΠϛϯάʹؔ͢Δ৘ใʹΑΓɼ֤छͷϩάΛௐࠪ͢Δࡍʹɼௐࠪ͢ΔൣғΛ‫ݶ‬ఆ͢Δ͜ͱ͕
ՄೳͰ͋Δɻ࣮ߦ͞Εͨ߈ܸͷछྨʹΑΔ৘ใʹΑΓɼԿΛௐࠪ͢Δ΂͖͔ಛఆՄೳͰ͋Δɻ߈ܸͷ੒൱ʹؔ͢Δ৘ใʹΑΓɼडߨऀͷࢪͨ͠ରࡦͷޮՌΛ஌Δ͜ͱ͕ՄೳͰ͋Δɻ
·ͨɼ߈ܸʹؔͯ͠೚ҙʹௐࠪՄೳʹ͢ΔͨΊɼडߨऀ͕೚ҙͷλΠϛϯάͰ͜ΕΒͷ৘ใΛ֬ೝͰ͖Δඞཁ͕͋Δɻ

5. ఏҊγεςϜ DeTMan
4 ষͰ͸ɼ๷‫ޚ‬ԋशʹΑΔ‫ڭ‬ҭγεςϜ͕࣋ͭ΂͖‫ػ‬ೳ͕໌Β͔ͱͳͬͨɻຊষͰ͸ɼ๷‫ޚ‬ԋशࣗಈਐߦ؅ཧγεςϜ DeTMan(Defense Training progress
Management system) ͷ֓೦࣮૷Λߦ͏ɻ
5.1. DeTMan ͷ֓ཁ
DeTMan ͷ֓ཁΛਤ 2 ʹࣔ͢ɻDeTMan ͸ɼ߈ܸͱࢦಋΛ͢΂ͯࣗಈͰ࣮ߦ͢ΔɻͦͷͨΊɼԋशͷ࣮ࢪʹ͓͍ͯɼӡӦଆʹਓΛඞཁͱ͠ͳ͍ɻ

27

Internet Conference 2018ঢ়‫گ‬Λɼ֎෦͔ΒࢀরՄೳͱ͢ΔͨΊʹσʔλϕʔ
εΛ༻͍Δɻσʔλϕʔεʹ͸ɼҎԼͷ 4 ͭͷςʔϒϧΛ࡞੒͢Δɻ• ԋश‫ؔ͢ʹڥ؀‬Δ৘ใΛอ؅͢Δ state ςʔϒϧ• ‫ߦ࣮ࡏݱ‬தͷεςοϓͱϙΠϯτͷ৘ใΛอ؅
͢Δ progress ςʔϒϧ• ΞΫγϣϯͷ࣮ߦ݁Ռʹؔ͢Δ৘ใΛอ؅͢Δlog ςʔϒϧ• γφϦΦʹؔ͢Δ৘ใΛอ؅͢Δ scenario ςʔϒϧ• डߨऀ΁ͷࢦಋʹؔ͢Δ৘ใΛอ؅͢Δ boardςʔϒϧ࠷‫ʹޙ‬ɼࢠϓϩηεΛੜ੒͢ΔɻҎ߱͸ɼࢠϓϩηεͷऴྃΛ଴‫͢ػ‬Δɻ

5.2.2. ࢮ‫ࢹ؂׆‬
DeTMan ͸ɼ௨ৗ͸ ping Λ༻͍ͨωοτϫʔΫͷૄ௨֬ೝʹΑΓࢮ‫ࢹ؂׆‬Λߦ͏ɻ͔͠͠ɼωοτϫʔΫͷૄ௨৘ใͷΈͰ͸ɼ߈ܸΛ଴‫͢ػ‬Δ͔ͷ൑அʹ͸ෆे෼Ͱ͋ΔɻͦͷͨΊɼνʔϜϑΝΠϧʹ‫͞ه‬Εͨԋश‫͍͓ͯʹڥ؀‬ɼαʔό໊ʹ web ͱ͍͏୯‫͕ޠ‬‫·ؚ‬Ε͍ͯͨ৔߹ʹɼHTTP ϦΫΤετʹΑΔ HTTPαʔόͷಈ࡞֬ೝΛߦ͏ɻࠓ‫ޙ‬ɼಈ࡞֬ೝΛߦ͏αʔϏεΛ௥Ճ͢Δɻࢮ‫ࢹ؂׆‬ͷ݁ՌΛ state ςʔϒϧʹॻ͖ࠐΉɻૄ௨֬ೝ·ͨ͸ಈ࡞֬ೝ͕ࣦഊͨ͠৔߹ɼ
ࢮ‫͕ࢹ؂׆‬੒ޭ͢Δ·Ͱ߈ܸΛ଴‫͢ػ‬Δɻ
ࢮ‫ࢹ؂׆‬͸ɼτϦΨʔલͱɼΞΫγϣϯલʹ࣮ߦ͢Δɻ͜ΕʹΑΓɼτϦΨʔͱΞΫγϣϯͷࡍʹ͸ɼԋश‫͕ڥ؀‬ਖ਼ৗʹಈ࡞͍ͯ͠Δ͜ͱ͕อূ͞ΕΔɻ
5.2.3. τϦΨʔ
DeTMan Ͱ͸ɼΠϕϯτυϦϒϯํࣜʹ͓͚ΔΠ
ϕϯτΛτϦΨʔͱ‫Ϳݺ‬ɻ‫ݱ‬εςοϓͷ trigger ʹ‫ه‬͞ΕͨϞδϡʔϧ͕࣮ߦ͞ΕɼτϦΨʔ͕ൃੜ͢Δ·Ͱಈ࡞Λ଴‫͢ػ‬Δɻ
DeTMan ͸ɼ߈ܸΛ଴‫͢ػ‬ΔͨΊͷ‫ػ‬ೳͱͯ͠ΠϕϯτυϦϒϯํࣜΛ࠾༻ͨ͠ɻ͔͠͠ɼඇಉ‫ ظ‬I/OΛ࠾༻͢Δͱಉ࣌ʹෳ਺ͷ߈ܸʹରॲ͠ͳ͚Ε͹ͳΒͳ͍ࣄଶ͕૝ఆ͞ΕΔɻͦͷͨΊɼ1 ౓ʹ 1 ͭͷτϦΨʔͷΈΛ଴‫͢ػ‬ΔɻϑΟογϯά΍ϦόʔεγΣϧͷΑ͏ͳϚϧ΢ΣΞΛ༻͍Δԋश͸ࠔ೉ʹͳ
Δ͕ɼDeTMan Ͱ͸ରԠ͠ͳ͍ɻ

ਤ 4: γφϦΦϑΝΠϧͷαϯϓϧ

5.2.4. ΞΫγϣϯ
ΞΫγϣϯʹ͓͍ͯɼDeTMan ͸डߨऀʹରͯ͠ೳಈతʹಈ࡞͢Δɻ‫ݱ‬εςοϓͷ action ʹ‫͞ه‬ΕͨϞδϡʔϧ͕࣮ߦ͞ΕΔɻओͳΞΫγϣϯͱͯ͠ɼ߈

28

Internet Conference 2018ܸͷ࣮ߦΛ૝ఆ͍ͯ͠Δɻଞʹ΋ɼϝʔϧͷૹ৴ͳͲ΋૝ఆ͍ͯ͠Δɻ
ΞΫγϣϯ͸ɼ࣮ߦͷ݁ՌͱίϝϯτΛ໭Γ஋ͱͯ͠ฦ͢ɻ࣮ߦͷ݁Ռ͸ɼΞΫγϣϯͷ੒൱Ͱ͋Γɼ
success ·ͨ͸ failure Ͱ͋Δɻ͔͠͠ɼྫ͑͹ɼΞΫγϣϯͱ࣮ͯ͠ߦ͞Εͨ߈ܸͷ੒ޭͱɼϝʔϧૹ৴ͷ੒ޭ͸ҙຯ͕൓ରͰ͋Δɻ߈ܸ͕੒ޭͨ͠৔߹͸ɼडߨऀʹ๷‫ޚ‬Λͤ͞ΔͨΊʹɼ࣍ͷ߈ܸʹ͸ਐ·ͳ͍ɻϝʔϧૹ৴͕੒ޭͨ͠৔߹͸ɼ࣍ͷ߈ܸʹਐΉɻ࣍અͰઆ໌͢ΔϩΪϯά͞ΕͨσʔλΛडߨऀ͕‫ݟ‬ͨ৔߹ʹࠞཚ͢ΔɻͦͷͨΊɼίϝϯτͱͯ͠डߨ
ऀ͔Β‫ࡍͨݟ‬ͷ݁Ռʹ͍ͭͯฦ͢͜ͱʹΑΓɼࠞཚΛ๷͙ɻ·ͨɼԋशதͷࢦಋ΋ΞΫγϣϯͱͯ͠ߦ͏ɻDeTMan ͸ΞΫγϣϯͷ੒൱ʹΑΓਐߦΛ෼‫͢ذ‬ΔɻͦͷͨΊɼ߈ܸ͕੒ޭͨ͠৔߹ʹͷΈʹ࣮ߦ͢ΔΞΫγϣϯͱͯ͠ɼࢦಋ͕ՄೳͰ͋Δɻ
DeTMan Ͱ͸ɼࢦಋͷͨΊͷΞΫγϣϯͱͯ͠ hintͱ question Λ༻ҙͨ͠ɻhint Ͱ͸ɼboard ςʔϒϧʹ৘ใΛ֨ೲ͢Δɻਤ 4 Λࢀߟʹઆ໌͢ΔɻຊγφϦΦͰ͸ɼhint1ɼhint2ɼhint3 ͷ 3 ͭͷώϯτ͕‫ه‬ड़͞Ε͍ͯΔɻDeTMan ͸ɼεςοϓ hint1 ͕ 1 ౓໨ʹ࣮ߦ͞Εͨ৔߹ɼhint1 Λ֨ೲ͢Δɻ2 ౓໨ʹ࣮ߦ͞Εͨ৔߹ʹ͸ hint2 Λɼ3 ౓໨Ҏ߱͸ hint3 Λ֨ೲ͢Δɻ͜ΕʹΑΓɼஈ֊తʹडߨऀʹରͯ͠৘ใ͕ఏࣔ͢
Δ͜ͱ͕ՄೳͰ͋Δɻ
question ΋ಉ༷ʹɼboard ςʔϒϧʹ৘ใΛ֨ೲ͢ΔɻຊγφϦΦͰ͸ɼquestion1ɼquestion2 ͷ 2 ͭͷ࣭໰͕‫ه‬ड़͞Ε͍ͯΔɻhint ͱ͸ҟͳΓɼ͢΂ͯͷ৘ใ͕ಉ࣌ʹ֨ೲ͞ΕΔɻboard ςʔϒϧʹ͸ɼhint΍ question ͳͲΛ۠ผՄೳͳ৘ใ΋֨ೲ͞ΕΔͨΊɼ۠ผՄೳͰ͋Δɻද 1: ๷‫ޚ‬ԋशͷൺֱHardeningԋशͷ༻్ਐߦͷॊೈ͞
։࠵೉қ౓
ϦΞϦςΟ

‫܇‬࿅
˕
ʷ
˕

Micro
Hardening
‫܇‬࿅
ʷ
˕
̋

DeTMan‫ڭ‬ҭ˓˓ʷ

5.2.6. ෼‫ذ‬ΞΫγϣϯͷ੒൱ʹԠͯ͡ɼ࣮ߦεςοϓΛมߋ
͢Δɻ࣮ߦεςοϓ͕ qed Ͱ͋ͬͨ৔߹͸ԋशΛऴྃ͠ɼͦ͏Ͱͳ͚Ε͹ࢮ‫ࢹ؂׆‬Λߦ͏ɻͦͯ͠ɼ࣮
ߦεςοϓ͕ qed ͱͳΔ·Ͱɼ‫܁‬Γฦ͢ɻ
5.3. WEB UIσʔλϕʔε಺ͷσʔλΛՄࢹԽ͢ΔͨΊʹ WEB
UI Λ༻͍Δɻ͜ΕʹΑΓɼडߨऀͷঢ়‫گ‬Λ֬ೝՄೳͰ͋Δɻ·ͨɼboard ςʔϒϧͷσʔλ΋ՄࢹԽ͢ΔͨΊɼࢦಋʹ΋ WEB UI Λ༻͍ΔɻσʔλΛՄࢹԽ͢Δ͚ͩ
Ͱͳ͘ɼະղ౴ͷ question ͕͋ͬͨ৔߹͸ղ౴ϑΥʔϜ΋࡞੒͢Δɻ͜ͷղ౴ϑΥʔϜΛ༻͍Δ͜ͱʹΑΓ question ʹରͯ͠ղ౴͕ՄೳͰ͋Δɻ

5.4. ‫ط‬ଘͷ๷‫ޚ‬ԋशͱͷҧ͍
ද 1 ʹɼHardeningɼMicro HardeningɼDeTMan ͷҧ͍Λ·ͱΊΔɻ‫ط‬ଘͷ๷‫ޚ‬ԋशͱ DeTMan ͷ࠷େͷҧ͍͸ɼԋशͷ༻్Ͱ͋Δɻ‫ط‬ଘͷ๷‫ޚ‬ԋश͸εΩϧΞοϓΛ໨తͱͯ͠։࠵͞ΕΔ͕ɼDeTMan ͸‫ڭ‬ҭΛ໨తͱ͢ΔɻͦͷͨΊɼDeTMan ͸‫ط‬ଘͷ๷‫ޚ‬ԋशʹ͸ͳ͔ͬͨ‫ڭ‬ҭ༻ͷ‫ػ‬ೳΛෳ਺࣋ͭɻ
DeTMan ͸؆୯ʹॊೈͳԋशΛ࣮ࢪՄೳ͕ͩɼԋशதʹࢦಋΛߦ͏ͨΊϦΞϦςΟ͸ଛͳΘΕ͍ͯΔɻ
࣮ࡍͷΠϯγσϯτ͸ɼDeTMan ͷΑ͏ʹ߈ܸʹ͍ͭͯ‫ͯ͑͘ڭ‬ΕΔ͜ͱ͸ͳ͍ɻͦͷͨΊɼDeTMan
͸ॳ৺ऀΛର৅ͱ͢Δɻ

5.2.5. ϩΪϯάDeTMan ͸ɼ࣮ߦͨ͠ΞΫγϣϯʹؔ͢Δ৘ใΛ
log ςʔϒϧʹ֨ೲ͢ΔɻϙΠϯτ͸ϩΪϯάͷࡍʹ‫͞ࢉܭ‬ΕΔɻ֨ೲ͞ΕΔ৘ใ͸ҎԼͷ 4 ͭͰ͋Δɻ• ‫ࡏݱ‬ͷ࣌ؒ• νʔϜ໊

6. ࣗಈԽ͞Εͨԋशਐߦ͓Αͼ‫ڭ‬ҭͷ࣮ূ࣮‫ݧ‬• ࣮ߦ͞Εͨεςοϓͷ step

6.1. ࣮ূ࣮‫ݧ‬ͷ֓ཁ
ਤ 4 ʹࣔ͢γφϦΦϑΝΠϧΛ༻͍ͯ DeTMan ͷ࣮ূ࣮‫ݧ‬Λߦ͏ɻγφϦΦͷϑϩʔΛɼਤ 5 ʹࣔ͢ɻຊγφϦΦͰ͸߈ܸ attack1 Λ࣮ߦ͠ɼ๷‫ʹޚ‬੒ޭͨ͠৔߹ɼattack1 ʹؔͯ͠डߨऀʹ࣭໰͢Δɻ߈ܸ
attack1 ͷ๷‫ࣦʹޚ‬ഊͨ͠৔߹͸ώϯτΛදࣔ͠ɼड
ߨऀʹ࣭໰͢Δɻडߨऀ͕ਖ਼͘͠ղ౴ͨ͠৔߹͸ԋशΛऴྃ͠ɼ‫ޡ‬౴ͨ͠৔߹͸΋͏ 1 ౓߈ܸΛ࣮ߦ͢Δɻ• ΞΫγϣϯͷίϝϯτ
• ΞΫγϣϯ࣮ߦ‫ޙ‬ͷϙΠϯτ
·ͨɼԋशऴྃ‫ʹޙ‬͸ log ςʔϒϧͷσʔλΛ csv
ϑΝΠϧ‫ʹࣜܗ‬ΑΓग़ྗ͢Δ͜ͱ͕Ͱ͖Δɻ

29

Internet Conference 2018

ද 2: ֤νʔϜʹ͓͚ΔԋशͷਐߦνʔϜ
Team ATeam B
Team Cਐߦ
1 ౓໨ʹ๷‫ޚ‬੒ޭ
2 ౓໨ʹ๷‫ޚ‬੒ޭ
5 ౓໨ʹ๷‫ޚ‬੒ޭਤ 7: progress ςʔϒϧͷൈਮਤ 5: ԋशϑϩʔਤ 8ɼਤ 9 ʹɼlog ςʔϒϧ͔Β Team AɼTeam Bʹؔͯ͠ൈਮͨ͠΋ͷΛࣔ͢ɻTeam A ʹؔ͢Δ log ςʔϒϧ಺ͷ৘ใΑΓɼTeamA ͸ 1 ౓໨͔Β߈ܸ attack1 ͷ๷‫ʹޚ‬੒ޭͨͨ͠Ίɼhint ͸࣮ߦ͞Ε͍ͯͳ͍͜ͱ͕෼͔Δɻ·ͨɼquestion1 ʹ΋ 1 ౓Ͱਖ਼౴ͨͨ͠Ίɼͦͷ··ԋश͕ऴྃ
ͨ͠ɻTeam B ʹؔ͢Δ log ςʔϒϧ಺ͷ৘ใΑΓɼ
Team B ͸ 1 ౓໨ͷ߈ܸ attack1 ͷ๷‫ࣦʹޚ‬ഊͨͨ͠Ίɼ࣍ʹ hint1 ͕࣮ߦ͞Ε͍ͯΔ͜ͱ͕෼͔Δɻ·ͨɼ
1 ౓໨ͷ question1 ʹ‫ޡ‬౴ͨͨ͠Ίɼattack1 ͕࠶౓࣮ߦ͞Ε͍ͯΔɻ2 ౓໨ͷ attack1 ͸๷‫ʹޚ‬੒ޭͨͨ͠
Ίɼhint1 ͸ 1 ౓͔࣮͠ߦ͞Ε͍ͯͳ͍ɻDeTMan ͸ɼडߨऀͷਐ௙ʹԠͯ͡ਐߦΛมԽͤͯ͞Δ͜ͱ͕֬ೝͰ͖ͨɻ·ͨɼTeam B ʹؔ͢Δ log ςʔϒϧ಺ͷ৘ใΑΓɼ
2 ౓໨ͷ attack1 ͸γφϦΦ௨ΓͳΒ͹ question1 ͷ
10 ඵ‫͞ߦ࣮ʹޙ‬ΕΔ͸ͣͰ͋Δ͕࣮ߦ͞Ε͍ͯͳ͍͜ͱ͕෼͔Δɻ͔͠͠ɼϩάʹ͸ Unavailable ͱ‫͞ه‬Εɼattack1 ͸γφϦΦ௨Γʹ࣮ߦ͞Ε͍ͯͳ͍ɻ
͜ͷ࣌ͷՄࢹԽ͞Εͨ state ςʔϒϧ͔Β Team Bʹؔͯ͠ൈਮͨ͠΋ͷΛਤ 10 ʹࣔ͢ɻTeam B Ͱ͸question1 ͷ‫ ʹޙ‬HTTP αʔό͕ఀࢭͨͨ͠ΊɼDeTMan ͸ HTTP αʔό͕࠶‫ى‬ಈ͞ΕΔ·Ͱ߈ܸΛ଴‫ػ‬ͨ͠ɻਤ 6: ԋश‫ڥ؀‬·ͨɼຊ࣮‫ݧ‬͸ɼਤ 6 ʹࣔ͢ԋश‫ͨ͠ࢪ࣮Ͱڥ؀‬ɻ
DeTMan ͸ 3 νʔϜ͕؅ཧ͢Δ߹‫ ܭ‬3 ୆ͷαʔόʹରͯ͠߈ܸ͢Δɻ
Team A ͸্‫ऀڃ‬ɼTeam B ͸த‫ऀڃ‬ɼTeam C ͸ॳ৺ऀͱ͠ɼද 2 ͷΑ͏ʹਐߦ͢Δͱఆٛ͢Δɻ࣭໰ʹ͸ɼ๷‫ʹޚ‬੒ޭͨ͠৔߹ʹਖ਼౴͢Δɻྫͱͯ͠ɼ
Team B ͸ 2 ౓໨ʹ๷‫ʹޚ‬੒ޭ͢ΔͨΊɼ࣭໰ʹ 1 ౓໨͸‫ޡ‬౴͠ɼ2 ౓໨ʹਖ਼౴͢Δɻ·ͨɼTeam B ͸ 2
౓໨ͷ attack1 ʹ͓͚ΔτϦΨʔ଴‫ػ‬தʹ HTTP αʔό͕ఀࢭ͠ɼTeam C ͷԋशऴྃ‫ى࠶ʹޙ‬ಈ͢Δɻ

6.2. डߨऀͷঢ়‫ʹگ‬Ԡͨ͡ਐߦ
ԋशதͷ͋Δॠؒʹ͓͍ͯɼWEB UI ʹΑΓՄࢹԽͨ͠ progress ςʔϒϧͷҰ෦Λਤ 7 ʹࣔ͢ɻprogressςʔϒϧΑΓɼνʔϜ͝ͱʹҟͳΔਐߦΛ͍ͯ͠Δ
͜ͱ͕෼͔Δɻਤ 8: log ςʔϒϧͷ Team A ʹؔ͢Δൈਮ

30

Internet Conference 2018

ਤ 9: log ςʔϒϧͷ Team B ʹؔ͢Δൈਮਤ 10: state ςʔϒϧͷ Team B ʹؔ͢ΔൈਮҎ্ͷ఺ΑΓɼDeTMan ͸ɼडߨऀͷঢ়‫ʹگ‬Ԡͯ͡ԋशΛਐߦ͍ͤͯ͞Δ͜ͱ͕֬ೝͰ͖ͨɻ

6.3. डߨऀʹର͢Δࢦಋਤ 11: board ςʔϒϧͷ Team C ʹؔ͢Δൈਮ

ਤ 11 ʹɼWEB UI ʹΑΓՄࢹԽͨ͠ board ςʔϒϧ͔Β Team C ʹؔͯ͠ൈਮͨ͠΋ͷͷҰ෦Λࣔ͢ɻ·ͨɼਤ 12 ʹ WEB UI ͷղ౴ϑΥʔϜΛࣔ͢ɻWEB
UI Ͱ͸ɼର࿩తͰ͋Δ͜ͱΛ‫ڧ‬ௐ͢ΔͨΊɼSNS ϥΠΫʹදࣔ͢Δɻ྘ͷίϝϯτ͕ώϯτɼ੺ͷίϝϯτ͕࣭໰ɼᒵ৭ͷίϝϯτ͸डߨऀͷղ౴Ͱ͋Δɻ
ਤ 11 ʹ͓͍ͯɼhint1 ͕Կ౓໨ͷ࣮ߦ͔ʹΑΓɼදࣔ͞ΕΔώϯτ͕มԽ͍ͯ͠Δ͜ͱ͕֬ೝͰ͖Δɻ
DeTMan Ͱ͸ɼର࿩తʹडߨऀʹରͯ͠ࢦಋՄೳ
Ͱ͋Δ͜ͱ͕֬ೝͰ͖ͨɻ

6.4. ԋशͷৼΓฦΓ
ਤ 7 ΍ਤ 10 ͸ԋशதʹࡱӨͨ͠΋ͷͰ͋Δɻͭ·Γɼԋशதʹडߨऀ͸ WEB UI ʹΑΓɼ‫ߦ࣮ࡏݱ‬͞Ε͍ͯΔεςοϓ΍ԋश‫ڥ؀‬ͷՔಇঢ়‫͍ͯͭʹگ‬
஌Δ͜ͱ͕Ͱ͖Δɻա‫͞ߦ࣮ʹڈ‬Εͨ߈ܸʹ͍ͭͯ΋ɼਤ 8 ΍ਤ 9 ͷΑ͏ʹࢀরՄೳͰ͋Δɻडߨऀ͸ɼ
WEB UI ʹදࣔ͞ΕΔ৘ใΛࢀߟʹԋश‫ڥ؀‬ͷௐࠪΛߦ͏ɻ·ͨɼ͜ΕΒͷ৘ใ͸σʔλϕʔεʹอ؅͞Εͯ
͍ΔͨΊɼԋश‫ʹޙ‬΋࢒ΔɻDeTMan ͸ log ςʔϒϧͷ಺༰ΛνʔϜผʹϨϙʔτͱͯ͠ग़ྗ͢Δ‫ػ‬ೳΛ࣋ͭͨΊɼԋश‫ޙ‬΋ৼΓฦΓ͕ՄೳͰ͋Δɻਤ 12: board ςʔϒϧͷղ౴ϑΥʔϜ

31

Internet Conference 2018

7. CyRIS ͱͷ࿈‫ܞ‬

8.3. WEB UI ͷΞΫηε੍‫ݶ‬‫ࡏݱ‬ͷ WEB UI Ͱ͸ɼWEB UI ʹΞΫηεͨ͢͠΂ͯͷਓ෺͕ɼ͢΂ͯͷ৘ใʹΞΫηεՄೳͰ͋ΔɻͦͷͨΊɼਐߦʹؔ͢Δ৘ใ͕ଞͷडߨऀʹެ։͞
ΕΔ͚ͩͰͳ͘ɼBoard ϖʔδͰผͷडߨऀʹର͢Δ࣭໰ʹղ౴͢Δ͜ͱ΋ՄೳͰ͋ΔɻԿΒ͔ͷ‫Ͱܗ‬ΞΫηεΛ੍‫͢ݶ‬Δ͜ͱʹΑΓɼଞͷडߨऀʹؔ͢Δ৘ใΛӾཡͰ͖ͳ͍Α͏ʹ͢Δඞཁ͕͋Δɻ

զʑͷϓϩδΣΫτͰ͸αΠόʔԋश౷߹ϑϨʔϜϫʔΫ CyTRON[8] Λ։ൃ͍ͯ͠ΔɻͦͷதʹαΠόʔϨϯδΛ࡞੒͢ΔπʔϧɼCyRIS ͕‫·ؚ‬Ε͍ͯ
ΔɻCyRIS ʹ͓͍ͯɼडߨऀͦΕͧΕʹׂΓ౰ͯΒΕ
Δԋश‫ڥ؀‬ΛΠϯελϯεͱ‫Ϳݺ‬ɻCyRIS ͸ɼKVM
Λ༻͍ͯ࡞੒͞Εͨ‫ج‬ຊͱͳΔΠϯελϯεΛඞཁͳ͚ͩෳ੡͠ɼαΠόʔϨϯδΛ࡞੒͢Δɻਤ 13 ʹ
CyRIS ͱ DeTMan ͷ࿈‫͍ࣔͯͭ͢ʹܞ‬ɻ

9. ͍͞͝ʹຊߘͰ͸ɼ‫ط‬ଘͷ๷‫ޚ‬ԋशͰ͋Δ Hardenig ͱ Micro
Hardening Λࢀߟʹɼ‫ڭ‬ҭͱͯ͠ͷ๷‫ޚ‬ԋशʹ͍ͭͯߟ࡯ͨ͠ɻߟ࡯Λ‫ʹݩ‬ɼ‫ڭ‬ҭͱͯ͠ͷ๷‫ޚ‬ԋशʹඞཁͳ‫ػ‬ೳΛͲͷΑ͏ʹ࣮૷͢Δ͔‫ݕ‬౼ͨ͠ɻͦ͠
ͯɼࣗಈͰ๷‫ޚ‬ԋशͷਐߦͱ‫ڭ‬ҭΛ͢ΔͨΊͷγεςϜ”DeTMan”Λ࣮૷ͨ͠ɻDeTMan ͕ɼ‫ڭ‬ҭͱͯ͠ͷ๷‫ޚ‬ԋशʹඞཁͳ‫ػ‬ೳΛຬ͍ͨͯ͠Δ͔‫ͨ͠ূݕ‬ɻࠓ‫ޙ‬͸ɼDeTMan ͷ‫׬‬੒౓ΛߴΊɼ࣮ࡍʹԋशΛ࣮ࢪ͢Δ͜ͱʹΑΓ‫ূݕ‬Λ‫ܧ‬ଓ͢Δɻँࣙਤ 13: CyRIS ͱͷ࿈‫ܞ‬ຊ‫ڀݚ‬͸ JSPS Պ‫ݚ‬අ 17K00478 ͷॿ੒Λड͚ͨ΋ͷͰ͢ɻCyRIS ͸ɼ࡞੒ͨ͠Ծ૝ϚγϯʹҰఆͷϧʔϧʹ‫ ͍ͯͮج‬IP ΞυϨεΛׂΓৼΓɼαΠόʔϨϯδͷ‫ڥ؀‬৘ใ͕‫ه‬ड़͞Εͨ yaml ϑΝΠϧΛग़ྗ͢Δɻ͜
ͷϑΝΠϧʹ͸ɼDeTMan ͷνʔϜϑΝΠϧʹඞཁ
ͱͳΔɼ߈ܸର৅ͷ IP ΞυϨεͳͲͷ৘ใ͕֨ೲ͞
Ε͓ͯΓɼDeTMan ͸νʔϜϑΝΠϧͷ୅ΘΓʹ͜ͷ yaml ϑΝΠϧΛར༻ՄೳͰ͋Δɻຊ‫ػ‬ೳʹΑΓɼCyRIS Λ༻͍ͯԋश‫ڥ؀‬Λ࡞੒ͨ͠৔߹͸ɼνʔϜϑΝΠϧΛ࡞੒͢ΔखؒΛলུͰ͖Δɻࢀߟจ‫ݙ‬[1] ‫ ۀ ࢈ ࡁ ܦ‬ল.
IT ਓ ࡐ ͷ ࠷ ৽ ಈ ޲ ͱ ক དྷ ਪ ‫ ͢ ؔ ʹ ܭ‬Δௐ ࠪ ݁ Ռ.
<http://www.meti.go.jp/press/2016/06/
20160610002/20160610002-7.pdf>.
[2] ਡ๚ത඙, ‫ݡݪ‬, ؔྑ໌. ৘ใηΩϡϦςΟߦಈϞσϧͷߏஙʕਓ͸ͳͥηΩϡϦςΟߦಈΛ͠ͳ͍ͷ͔. ৘ใॲཧֶձ࿦
จࢽ, Vol. 53, No. 9, pp. 2204–2212, September 2012.
[3] Hardening
project.
<http://wasforum.jp/
hardening-project/>.
[4] ઒‫ ޱ‬༸. <https://microhardening.connpass.com>.
[5] ҆ాਅ‫ޛ‬. Alfons: A mimetic network environment construction system. In 11th EAI International Conference on Testbeds
and Research Infrastructures for the Development of Networks &Communities, Jun 2016.
[6] Razvan Beuran, Pham Cuong, Tang Thanh Dat, Ken ichi Chinen, Yasuo Tan, and Yoichi Shinoda. Cybersecurity educationand training support system: Cyris. IEICE Transactions on Information and Systems, Vol. E101-D, No. 3, pp. 740–749, March2018.
[7] จ෦Պֶল. ߴ౳ֶߍֶशࢦಋཁྖ. <http://www.mext.
go.jp/component/a_menu/education/micro_detail/__
icsFiles/afieldfile/2011/03/30/1304427_002.pdf>.
[8] Razvan Beuran, Tang Thanh Dat, Pham Cuong, Ken ichi Chinen, Yasuo Tan, and Yoichi Shinoda. Integrated framework forhands-on cybersecurity training: Cytrone. In Elsevier Computers& Security, Vol. 78C, pp. 43–59, June 2018.

8. ࠓ‫ޙ‬ͷ՝୊
8.1. ߈ܸଆͷ IP ΞυϨε͕‫ݻ‬ఆ‫ࡏݱ‬ͷ DeTMan ʹ͸ɼ߈ܸଆͷ IP ΞυϨεΛมߋ͢Δ‫ػ‬ೳ͕ͳ͍ͨΊɼडߨऀͷϑΝΠΞ΢ΥʔϧʹΑΔରࡦʹΑΓɼ߈ܸ͕͢΂ͯ๷͕Εͯ͠·͏ɻ ͦͷͨΊɼ߈ܸऀͷ IP ΞυϨεΛϥϯμϜͰมߋ͢Δ‫ػ‬ೳ͕ඞཁͰ͋Δɻ

8.2. εςοϓؒͷ࿈‫ܞ‬‫ࡏݱ‬ͷ DeTMan ͸ 1 ͭ 1 ͭεςοϓ͕ಠཱͯͨ͠
Ίɼ͋ΔεςοϓʹΑΓ৘ใΛୣऔͯ͠΋ɼผͷεςοϓͰ͸ͦͷ৘ใΛ‫͍ͳ͖Ͱ͕ͱ͔͜͢׆‬ɻͦͷͨΊɼεςοϓಉ࢜Λ࿈‫ͤ͞ܞ‬ΔͨΊʹɼ߈ܸʹΑͬͯಘΒΕͨ৘ใΛอ؅͢ΔͨΊͷखஈ͕ඞཁʹͳΔɻ

32

Internet Conference 2018

Kamuee: An IP Packet Forwarding Engine forMulti-Hundred-Gigabit Software-based Networks
Yasuhiro Oharaa , Hiroki Shirokuraa , Abhik Datta Banika , Yudai Yamagishia , Kim Kyunghwanb
a NTT Communications Corporationb Independent Engineer

Abstract
In Software Defined Network (SDN) and Network Function Virtualization (NFV) era, extensible, flexible, and yethigh-performance software packet forwarding capability is desirable, as the core functionality of the future Internet. In
this paper we present Kamuee: a software IP packet forwarding engine, and its core router version that builds only oncommodity hardware. By scaling the number of forwarding CPU cores, Kamuee supports multiple 100GbE interfaces,with near wire-rate traffic. In our benchmarks that use two Intel Xeon Platinum 8180 processors, Kamuee could
forward 349.60 Gbps 512B-sized random destination traffic in a BGP full route environment. Further intralaboratory
evaluation resulted in 292.17 Mpps 64B forwarding capability, showing the potential of very high-speed software
router.
Keywords: NFV, SDN, Software Router, DPDK
1. Introduction

network functions to run on commodity o↵-the-shelf(COTS) hardware.
Therefore, software-defined networking is not only
good for the network, but for the business as well.
With SDN, the network can be made programmable. A
deeper look into network programmability reveals thatit involves both the control plane and the data plane andthat both are valuable in containing costs and enabling
business growth. Data path programmability o↵ers aplatform for rapidly deploying a new service or modifying an existing one. This is particularly important toservice providers in fields like security, for example, tomitigate a massive DDoS attack a↵ecting hundreds ofvulnerable servers across the globe.
Today, both control and data plane programmability provided by software-based solutions are the desirable characteristics of network services and devices.
An integral part of this is software based processing ofdata packets. But without high performance, software
packet processing cannot leverage the potential benefitsof SDN and NFV. Recent unprecedented leaps in NFVwith performance reaching up to 100 Gbps [1, 2], makethe need for software routers supporting speeds above
100 Gbps even more imperative. Keeping this in mind,
we endeavored to develop a high performance software
IP packet forwarding engine called Kamuee with comprehensive Layer 3 (routing) functionalities. Kamuee

The rapid emergence of services based on technologies such as cloud computing and AI-driven robotics,
underlines the desperate requirement for next generation networks, which are more flexible and able to keep
pace with changes in usage and capacity. Softwaredefined networking (SDN), network functions virtualization (NFV), and network virtualization (NV) are
the solutions which address this requirement and provide novel methodologies to design, build and operate
next generation networks. Thanks to the recent breakthroughs like o↵-the-shelf hardware or whitebox networking, a massive paradigm shift in networking technology finally took place by decoupling software fromthe hardware, so that it is no longer constrained by thebox that delivers it. SDN and NFV have become indispensable for all telecommunication service providers to(1) Drive Innovation by creating new types of applications, on-demand services and business models (2)Deliver Agility and Flexibility by enabling rapid deployment of new applications, services and infrastructure to quickly fulfill their changing requirements (3)Reduce OpEX by enabling automation and algorithm
control through increased programmability of network
elements to make it simple to design, deploy, manage
and scale networks and (4) Reduce CapEx by enabling
Preprint submitted to Internet Conference 2018

November 16, 201833

Internet Conference 2018

successfully integrates the capabilities of DPDK (Data
Plane Development Kit) [3] with Poptrie [4] to achieve
stable and reliable high speed software IP packet routing. Kamuee is a fully fledged software router that canrun on COTS PC Server and is capable of forwarding
344.28 Gbps random destination IP traffic with Ethernet frame size greater than 512B and approx. 600,000
full routes.
In this paper we present the design, implementationand evaluation of Kamuee. Section 2 describes the related research. Section 3 highlights the design and implementation methodology of Kamuee. Section 4 elaborates the performance evaluation of Kamuee. Kamuee
was used as one of the core routers in Interop Tokyo
2018 and the relevant experience has been shared in section 5. Section 6 concludes the paper.

achieve the latter, for concurrency control owing to its
lock/synchronization specialization.
Kamuee-Zero [6] presents the routing table mechanisms of the previous version of this implementation.
The paper shows that 1) in order to achieve near wirerate performance in 40GbE, more than three queues
per port are necessary, 2) the di↵erence in throughput performance between NUMA-aware and NUMAnonaware is not large (if not negligible), and 3) performance exceeding one hundred Gbps can be achieved using software based router, with four 40GbE interfaces
and 128B short packet random traffic. Kamuee-Zero
did not have routing capability as it did not support any
routing protocol. In contrast, Kamuee (the version presented in this paper) supports all major routing protocols such as BGP, OSPF, and RIP, and other required
functions that are necessary to function as a basic router,such as ARP, VLAN, and statistics counter. Also, while
Kamuee-Zero supports only 40GbE network hardware,
Kamuee can additionally support 100GbE hardware as
well.
While NFV tackles the problems posed by legacy
proprietary middleboxes [7] by leveraging virtualization technologies to implement network functions (NFs)
on commodity hardware, the advantages of NFV comewith some downsides [8] as software-based NFs can potentially introduce significant performance overheads.
Several research works have been done to address
the performance drawback of software based NFV.
ClickNP [9] o✏oads software logic onto programmablehardware like FPGA to accelerate individual NFs. NetBricks [10] runs NFs on a single CPU core instead of
virtual machines and containers to improve NF performance. ClickOS [11], DPDK [3] and NetVM [12] optimize and accelerate packet processing from the network
hardware to and between virtual machines. Recently,
there have been some astounding progress in NFV performance in the past couple of years. Metron [1] realizes high performance NFV service chains at the emerging and extremely challenging link speeds at 100 Gbps
using commodity hardware, while significantly reducing latency. Andromeda [2], Google Cloud Platform’s
network virtualization stack demonstrates that an OS
bypass software data-path provides performance competitive with hardware, achieving 32.8Gb/s using a single core. Some other advancements in this area include
SafeBricks [13] protecting NFs in cloud environments,a novel programming interface forNon-Volatile Main
Memory called PASTE [14] , NFV resource manager
ResQ [15] supporting high performance in multi-tenant
NFV clusters, and, highly scalable and resilient general
purpose L2 switching software FBOSS [16] capable of

2. Related work
Achieving high performance in software routing implementations has been a major challenge over the lasttwo decades and has lead to some cutting-edge advancesin this field. Slowness of Linux network stack performance has become increasingly relevant issue over theyears because of the exponential increase in the amountof data that is being transferred over networks and thecorresponding workloads. Even the widespread use of
10 GbE network cards could not resolve this issue because of some bottlenecks in Linux kernel itself that prevent packets from being quickly processed. There havebeen many attempts to circumvent these bottlenecks
with kernel bypass techniques that enable packet processing without involving the Linux network stack suchthat the application running in the user space communicates directly with networking device. Intel’s DPDK [3]is one such solution which takes care of the packet forwarding performance bottleneck. DPDK leverages existing Intel Processor technologies like SIMD instructions (Singles Instruction Multiple Data), Huge-pages
memory, multiple memory channels and caching to provide packet processing acceleration with its own libraries. Recent innovation like Poptrie addresses another major bottleneck of IP routing lookup. Poptrie [4] leverages the population count instruction to
give the indirect indices to the descendant nodes in order to keep the small memory footprint within the CPU
cache and enables extremely high speed IP lookup. Kamuee harnesses (1) packet processing acceleration of
DPDK (2) high-speed packet lookup provided by Poptrie and (3) parallel processing for its superior performance. Read-Copy Update (RCU) [5] has been used to34

Internet Conference 2018

running on commodity hardware.
3. Design and implementation

bgpd

The main motivation of Kamuee design is the following: if the software is good and simple, we should be
able to get a good performance out of a good hardware.
Furthermore, we should be able to increase the overall
performance by adding more hardware resources (i.e.,
CPU cores). To achieve this, Kamuee was designed andimplemented as simple as possible, in the belief that any
complexity may lead to performance degradation (i.e.,
KISS principle).
Kamuee employs the run-to-completion model [17]rather than pipe-line model: we adopted this model because the run-to-completion model is suggested as abetter-performance model in a past work called RouteBricks [18]. By employing the run-to-completion
model, we can scale-out the packet forwarding process
over the multiple CPU cores, enabling the design goalof increased performance by increased hardware.
Some design policies are inspired by others’ work.
RCU is utilized in Linux kernel and also in some DPDK
applications [19]. Use of Tap devices [20, 21] or KNI
interface [22] to map the physical NICs in Linux to connect to the open-source software, is a well-known approach and is also supported by VPP [23].
CPU core (equivalently, CPU time) is a very precious
resource for our purpose: if we have spare CPU core,
we could gain more performance. Thus, we assemble the slow tasks (i.e., the tasks that do not need highperformance), such as netlink, RIB, acl, tap, arp, andvty (i.e., virtual terminal), on one CPU core, to avoid
wasting CPU core. To achieve this, we used Lthread
library [24] included in the DPDK source (located under examples/performance-thread). Furthermore,since the function call interface are the same, we canchange native DPDK thread to lthread thread and viceversa, enabling balance in performance. For example, because our experience suggested to speed them,in our current recommended setting, rib-manager, tapmanager, and snmp-manager run as the native DPDK
threads, consuming one CPU core for each.
Figure 1 illustrates the internal structure of the Kamuee software router. In the fundamental DPDK concepts, Network Interface Cards (NICs) belongs to either Linux space or DPDK space. The figure happens
to show the case that two NICs belong to Linux, andfour NICs belong to DPDK, but it is configurable. The
packets received in DPDK NICs are distributed to a specific CPU core by the RSS/multiqueue technology of the
NIC. The assigned CPU core is running a “forwarder”

zebra
RIB

kernel

FIB

FIB

arp
routing table

CPU socket

NIC

NIC

NIC

NIC

CPU socket

NIC

NIC

Figure 1: Kamuee internal structure: the ordinary linux space with
two NICs and the DPDK space with four attached NICs are illustrated on left and right, respectively. Two CPU sockets are shownon the right, with most of the CPU cores running “forwarder” DPDK
thread, enabling scale-out of packet forwarding tasks on the multiple
cores. The routing table (RIB) is compiled as FIB using Poptrie, anddistributed to each CPU socket’s L3 cache using RCU. The manager
threads such as ones dealing with netlink, tap, and vty, are launchedon the right-most core using the “lthread” library. DPDK-attached
physical Kamuee NICs are 1-to-1 mapped on the tap devices in theLinux space so that the routing protocol open-source software (e.g.,
Quagga) can run on the Kamuee NICs. The routes calculated by therouting daemons are first installed in the Linux kernel, and then propagated to Kamuee RIB using netlink socket/messages.

thread of Kamuee, that is built around the DPDK thread
and occupies the CPU core. The packet, if it is to be
forwarded, is solely handled by that CPU core, without the need of using the other CPU cores; hence therun-to-completion model. The forwarder thread processes the protocol headers such as Ethernet and IP,
looks up the routing table (labeled “FIB” in the figure),
and then directly forward the packet to the other NIC
to emit the packet. Thanks to the Poptrie [4] that cancompress some hundreds of thousands of routes intoa few megabytes memory footprint, the routing tablelookup can be completed in some CPU L3 cache accesses, avoiding a lot of main memory accesses. This
simple run-to-completion forwarding process without
main memory access, together with the parallelization(in other words, scale-out) on the number of CPU cores,is the main reason of high-performance of Kamuee.
This is the key design of Kamuee, and is the main contribution of this paper.
The control protocol packets and the self-destined
packets (i.e., the packets that are to be received by the
Kamuee host itself) are handled as follows: by routing
table lookup in the forwarder, the packet is indicated tobe passed to the Linux part of the system. Then, thepacket is passed to the “tap manager” (shown top-rightin Figure 1). The tap manager delivers the packet to the35Internet Conference 2018

Table 1: Hardware specification of Kamuee
0.0.0.0/2 nexthop: 192.85.1.3 port: 2 flags:
64.0.0.0/2 nexthop: 193.85.1.3 port: 0 flags:
128.0.0.0/2 nexthop: 194.85.1.3 port: 8 flags:
192.0.0.0/2 nexthop: 195.85.1.3 port: 6 flags:

Hardware Type
ChassisMotherboard
CPU
MemoryNIC

Figure 2: Four default routes or “default4”

Product Name
SYS-7049GP-TRT
Supermicro X11DPG-QTIntel Platinum 8180 ⇥2
DDR4-2133 16GB ⇥12 = 192GB
Mellanox Connect-X5 100GbE Dual-Port ⇥5Intel X710 10GbE Quad-Port ⇥1

Table 2: Softwares used in Kamuee

Linux kernel via the correspondent tap device that is 1to-1 mapped to the receiving NIC. In this way, the Linuxkernel, and thus the Linux user processes, can receive
the packet from DPDK attached NICs without problem.
The routing protocol daemons use this mechanism: forexample, Quagga bgpd (shown top-left in the figure) receives the BGP packets, processes them, and installs thecalculated BGP routes in the Linux kernel. The newly
installed routes are notified through the Netlink mechanism to the Kamuee’s “netlink manager” (shown topright in the figure). The “rib manager” is informed of
the new routes by the netlink manager, and the rib manager installs it in the main routing table (labeled “RIB”
in the figure), and produces the FIB using the Poptriealgorithm. One FIB for each CPU socket is prepared toproperly support the CPU cache mechanism.

Software Package
OS
DPDK
userspace-rcu
Quagganet-snmp

VersionUbuntu 16.04.5 amd64
17.11
0.9.3
0.99.24
6.0.1-2either transaction performance or the bandwidth of subsystems, such as CPU core, QPI, and PCIe. Since wewant to understand the overall performance of the system as a whole, and since the transaction performancecan be calculated from the bandwidth performance, we
generally focus on bandwidth performance, unless wehave a specific interest.
Our version of the software demonstrated a significant fluctuation of the performance over time. We havemeasured the performance as the average of five samples. It should be noted that our measurement may notcover the significant period of the fluctuation. Sometimes, after 30-40 seconds, Kamuee exhibits performance degradation from 394 Gbps to 383 Gbps in thesame setting (this is shown later in Figure 4).
Table 1, 2 lists the hardware and software specification, respectively. Quagga was used to provide
BGP4/4+, OSPF and OSPFv2 functionalities on Kamuee.

4. Evaluation
4.1. Benchmark setup
In our benchmark method, we measure the performance of the Device-Under-Test by sending therandom-destination IP traffic from the network test:
Spirent, by having the DUT forward back the traffic,
and then by counting the packets returned to the network tester. To achieve this, we install in the DUT
four prefixes that cover all IPv4 address space, so thatthe DUT can return all the packets that it could forward, back to the Spirent tester machine, without causing “route not found” error. We refer to the four prefixes
that are shown in Figure 2 as “Four default routes” or“default4”.
Wherever BGP full routes are used in the benchmark,the snapshot taken in NTT Communications’ TestBed
on 2016/12/12 has been used, in addition to Four default
routes. The snapshot includes 612,916 prefixes.
If not specified explicitly, the compiler optimization
option defaults to ”-O3”.
We generally focus on the achieved bandwidth rather
than transaction performance (i.e., packet per second orpps). The factor limiting the performance is generally

4.2. Overall Throughput in Bandwidth (BPS)
Figure 3a shows the bandwidth throughput performance of Kamuee when given wire-rate random traffic
from all four 100GbE interfaces. The figure compares
the performance on one core per port (1C/P) throughtwelve cores per port (12C/P). It shows that Kamuee
successfully increases its performance as the number ofCPU cores increase. With 64B shortest Ethernet frame,
one core/port setting and twelve cores/port setting exhibit 12.20 Gbps and 180.18 Gbps, respectively. With
1518B longest frame, 12C/P demonstrate almost wirerate of 394.36 Gbps.
The setting of Figure 3a is normal Linux connectedroutes plus “default4”, leaving the Local Loopback
Address 127/8 destined to the Linux host’s upper layer.

36

Internet Conference 2018

Skylake 100GbE x 4 default4 DAC

350
300
250
200
150
100

350

50
0

12C/P
10C/P
8C/P
6C/P
4C/P
2C/P
1C/P

400
Throughput (Gbps)

12C/P
10C/P
8C/P
6C/P
4C/P
2C/P
1C/P

400
Throughput (Gbps)

Skylake 100GbE x 4 default4 DAC

300
250
200
150
100
50
0

64 128 256 512 10241518
Frame Size (Bytes)

64 128 256 512 10241518
Frame Size (Bytes)(a) LoopbackTap(b) LoopbackBlackhole
Figure 3: Throughput with/without Tap Routeshows the potential capability of the software router, if
we trust the reliable Spirent tester.
Figure 4 compares the two settings of Local Loopback Address that are either directed to TAP or Blackhole. With four 100GbE I/Fs, twelve cores per port isthe best setting we can get, and the figure only shows thecase. 64B case degrades from 180.18 Gbps (at LoopbackTap) to 80.52 Gbps (at LoopbackBlackhole).
We integrated ACL functionality into Kamuee, byincorporating the DPDK ACL library. Our ACL implementation in the benchmark test did not include
ANY entry, and just searched in the ACL list only tofind the default ACL entry. Even in that setting, theACL function exhibits a significant performance degradation. We show the overhead of the ACL functionality: NoACL-LoopbackBlackhole outperforms LoopbackBlackhole significantly. This suggest that by improving the ACL functionality, we may be able to reduce the performance degradation in the future.
Also we show the impact of FullRoute: comparing LoopbackBlackhole (equipped with default4) and
FullRoute-LoopbackBlackhole, we can see the impact
of holding and looking up the BGP full routes is notlarge, thanks to the Poptrie technology.

Skylake 100GbE x 4 default4 DAC 12cores/port
400
Throughput (Gbps)

350
300
250
200
150

NoACL-LoopbackTap
LoopbackTap
NoACL-LoopbackBlackhole
LoopbackBlackhole
FullRoute-LoopbackBlackhole

100
50
0
64

128

256 512 1024 1518
Frame Size (Bytes)*

Figure 4: With/Without Tap Route. After 30 or 40 seconds with
1518B 400 Gbps traffic, With-Tap-Route degrades its performanceslightly (shown in * mark in the x-axis). Except the one labeled with
FullRoute, the route-setting is default4.

Since we launch fully-random-destination traffic fromthe tester to the Kamuee, the traffic destined to 127/8
fills and overloads the TAP socket, and sometimes cuts
the BGP session through it. To avoid such problem, we
installed 127/8 as blackhole route, and unexpectedly it
lowered the throughput performance for some unknown
reason. The performance is shown in Figure 3b. Since
traffic without the TAP destined ones are more realistic,
this can be deemed as the real performance value. We
can infer the root cause of the performance degradationsuch that some bug or problem lies in Kamuee or DPDK
library. In either way, Figure 3a can be recognized as thepotential value of the software router: no matter what
bug the root cause is, the performance value of Figure 3a4.3. Overall Throughput in Transaction (PPS)
Figure 5a shows the transaction performance values
in Packet Per Second (PPS), in contrast to the theoretical limit labeled as “Wire-rate”. Figure 5b illustrates the achievement rate against the ideal wire-rate.
In 64B case, the most realistic setting, i.e., FullRouteLoopbackBlackhole, exhibits 111.42 Mpps (achievement rate: 0.19), while NoACL-LoopbackTap for refer-37Internet Conference 2018ence shows 292.17 Mpps (achievement rate: 0.49). The
NoACL-LoopbackTap’s reference value is not a badvalue, but the realistic FullRoute-LoopbackBlackhole isnot surprisingly fast, and gives a moderate speed performance value.

configuration and number of cores as the physical environment, with each virtual core using “vcpupin” suchthat the virtual cores do not operate on the same physicalcore. NICs are directly connected with SR-IOV using
PCI-passthrough.
Figure 7 compares the performance of two cores per
port (2C/P) through twelve cores per port (12C/P). Here,for packets longer than 1024B, a strange phenomenon isobserved: the performance improves on reducing number of cores. The cause of this phenomenon can be
IOMMU. The intel iommu is an option related to DMA
for enabling PCI-passthrough in Intel CPUs. Further
investigation of the di↵erence in performance due tothe presence or absence of intel iommu=on revealed
that performance always degrades when IOMMU is effective regardless of bare-metal or virtual environment.
This is illustrated in Figure 8.

4.4. E↵ect of compiler optimization
Figure 6 shows the e↵ect of compiler optimizationon the performance of LoopbackTap setting. It demonstrates that gcc optimization option -O1 and above areroughly the same performance when the gcc version is(Ubuntu 5.4.0-6ubuntu1 16.04.9) 5.4.0 20160609. Further discussion such as which optimization option impacts the most is future work.
4.5. Microflow: the Benchmark of a Single IP Flow
Table 3 gives a list of latency measurements that is
conducted for five minutes or more. Microflow means
the single IP session flow, so the RSS (Receive-Side
Scaling) of NIC cannot split the traffic onto multiple
cores. We have two NUMA types (Same or Cross,meaning whether the test traffic needs to come accrossthe di↵erent NUMA nodes), and six Ethernet frame
sizes.
Overall, around 5 Mpps is performed for the single
core forwarding performance. No visible di↵erence inlatency was observed between NUMA types of the traffic. The latency is in average 20-30 microseconds for
the Ethernet frame longer than 512B, but it was larger(such as 254 and 333 microseconds) in the Ethernet
frame shorter than 256B. We suspect that the e↵ect of
PCI’s Max Read Request Size is involved [25].

5. Experience in Interop Tokyo 2018
We deployed Kamuee as a backup core router in the
backbone network of Interop ShowNet 2018. Interop
ShowNet has an experimental Internet backbone network deployed during the three-day Interop event. Thisis one of the largest experimental networks and every
year, many product vendors bring in their new products
to test their performance and interoperability. This year,
over 2600 devices and services were connected to the
network and over 450 engineers participated to build
this network. As a backup core router of the network,
Kamuee was responsible for forwarding all the traffic of
this large scale network in case the primary core router
fails.
The hardware specification used for Kamuee in Interop ShowNet 2018 is the same as the one in theprevious benchmark, and shown in Table 1. Total of
six routers were connected directly to Kamuee; fourconnected using 100GbE-SR4, one connected using
100GbE-LR4, and one connected using 10GbE-LR.
The one using 10GbE-LR was the route reflector. Additionally, two network traffic generators were connected,
one connected using 100GbE-LR4, and another connected using 10GbE-LR.
Kamuee was configured to provide the best performance for user traffic within the hardware constraints,
such as limited number of CPU cores and NICs. We
allocated eight cores per port to forwarder threads for
100GbE ports connected to the primary core router andthe backup aggregation router. As we had limited number of CPU cores, we chose to only allocate six cores
per port to forwarders for 100GbE ports connected to
the AS border routers and the network traffic generators

4.6. Packet loss
10 Gbps traffic was measured to test the packet loss
rate in the not-so-heavy traffic load. This time the IP
destination address field is randomized so that the RSS
of NIC can split traffic to multiple cores. The 10 Gbps
traffic was forwarded without major problem regardlessof NUMA type. For the duration of five minutes, arather small number of frames are dropped such as lessthan 10,000 frames (Table 4). It suggests the packet loss
rate is significantly low to support the real traffic.
4.7. Benchmark for Virtualized Function
In order to investigate the bandwidth performance of
Kamuee in virtual environment, VMs have been createdusing KVM with the same configuration as physical environment. Benchmarking has been done using similar
test environment and default4 routes as described earlier. The VMs set up virtual CPUs with similar NUMA

38

Internet Conference 2018

Skylake 100GbE x 4 default4 DAC 12cores/port

Wire-rate
NoACL-LoopbackTap
LoopbackTap
NoACL-LoopbackBlackhole
LoopbackBlackhole
FullRoute-LoopbackBlackhole

NoACL-LoopbackTap
FullRoute-LoopbackBlackhole

Throughput (Mpps)

600
500
400

Mpps Achievement

Skylake 100GbE x 4 default4 DAC 12cores/port

300
200
100
0
64

128

256 512 1024 1518
Frame Size (Bytes)

1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
64

(a) PPS throughput

128

256 512 1024 1518
Frame Size (Bytes)(b) PPS achievement rate
Figure 5: Throughput in PPS
Table 3: Microflow Latency

NUMA
Same
Same
Same
Same
Same
Same
Cross
Cross
Cross
Cross
Cross
Cross

Cable
DAC
DAC
DAC
DAC
DAC
DAC
DAC
DAC
DAC
DAC
DAC
DAC

fsize
64
128
256
512
1024
1518
64
128
256
512
1024
1518

Tx load
100Gbps/148.8Mpps
100Gbps/148.8Mpps
100Gbps/148.8Mpps
100Gbps/148.8Mpps
100Gbps/148.8Mpps
100Gbps/148.8Mpps
100Gbps/148.8Mpps
100Gbps/148.8Mpps
100Gbps/148.8Mpps
100Gbps/148.8Mpps
100Gbps/148.8Mpps
100Gbps/148.8Mpps

Avg. over 5 samples
Rx throughput
3.53Gbps/5.26Mpps
5.63Gbps/4.76Mpps
8.71Gbps/3.94Mpps
21.49Gbps/5.05Mpps
38.02Gbps/4.55Mpps
61.19Gbps/4.97Mpps
3.32Gbps/4.94Mpps
5.88Gbps/4.97Mpps
6.40Gbps/2.90Mpps
22.07Gbps/5.19Mpps
39.93Gbps/4.78Mpps
51.56Gbps/4.19Mpps

as these ports only forwarded limited number of traffic.
As 10GbE ports do not require many cores to provide
performance, we only allocated two cores per port toforwarders responsible for the 10GbE ports. In total,
fourty-six cores were used as forwarders to forward thetraffic.
As a core AS router, the routing table of Kamuee
consisted of the Internet full routing table and AS internal routes. Over 700K routes were registered on the
IPv4 routing table while IPv6 routing table and had only
about 59K routes.
From our experience of operating Kamuee in Interop
ShowNet 2018, we discovered the following key problems that need to be addressed when running software
routers as core routers using COTS devices:

mm:ss
Time
5:18
6:20
6:31
5:34
8:21
5:54
7:16
7:01
5:12
11:55
8:05
12:15

#rx-frames
1,587,401,784
1,823,246,252
1,542,903,228
1,670,079,851
2,378,373,317
1,696,514,167
2,220,846,968
2,089,926,340
903,051,580
3,661,038,680
2,309,901,569
3,194,555,373

Min.
16.66
10.43
12.49
4.86
5.86
10.87
16.35
12.18
12.02
4.85
6.57
9.79

Latency (us)
Avg.
Max.
69.4
692.2571.95
120.82253.73884.2422.01
112.3622.18
892.3534.23
184.03
69.46
859.5
75.63
2,183.4333.07
369.8
22.06
64.8
22.63
950.9325.37
812.38ing of the NICs. Unlike specialized networking chassis which have optimized cooling for NICs and network processors, the COTS server chassis used for Kamuee was not equipped to do so. The temperature sensor readings showed temperature of up to 67 degrees
centigrade while the maximum operating temperaturefor100GbE-LR4 QSFP28 module is 70 degrees centigrade [26]. This calls for some additional cooling design while using COTS hardware as high speed network
device to avoid errors due to overheating.
Second problem we faced is the di↵erence in implementations of NIC functionalities and their corresponding DPDK drivers per vendor. Kamuee’s initial designused KNI as the packet interface between the dataplaneand kernel. Though it worked fine for NICs from asingle vendor, it malfunctioned when we started to use
NICs from multiple vendors simultaneously. We needed
to switch back to the slower Tun/Tap kernel interface toaddress the malfunctioning problem.

• Nonoptimal cooling inside the chassis• Di↵erences in NIC implementation per vendor

First problem we encountered was excessive heat-39

Internet Conference 2018

Table 4: 10Gbps traffic packet loss

NUMA
Same
Cross

Cable
DAC
DAC

fsize
64
64

Tx load
10Gbps/14.88Mpps
10Gbps/14.88Mpps

Avg. over 5 samples
Rx throughput
10.00Gbps/14.88Mpps
10.00Gbps/14.88Mpps

mm:ss
Time
5:22
5:13

#tx-frames
4,793,907,953
4,666,135,849#rx-frames
4,793,899,029
4,666,135,251#loss*
8,912
592

loss-rate+
1.86e-06
1.27e-07* The tester’s tx, rx, and loss counts didn’t seem to be consistent for unknown reason.
+ Loss-rate is calculated by dividing #loss by #tx-frames.

SR-IOV VM on KVM 100GbE x 4 default4 100G-SR4

400

400

350

350
Throughput (Gbps)

Throughput (Gbps)

Skylake 100GbE x 4 default4 DAC 12cores/port

300
250
200
150

-O3
-O2
-O1
-O0
-g-O0

100
50

300
250
200
150
100
50

0

12C/P
10C/P
8C/P
6C/P
4C/P
2C/P

0
64B 128B 256B 512B 1024B1518B
Packet Size

64B 128B 256B 512B 1024B1518B
Packet Size

Figure 6: Compiler E↵ect

Figure 7: KVM cores per port e↵ect

Kamuee is the first ever software router to be used inInterop Shownet backbone as one of the core routers,
and throughout the event Kamuee ran properly without
any glitches or errors. Kamuee lived up to the challenge of a fully functional software router interoperablewith most of the world’s leading router vendors, namely,
Cisco, Juniper, and Huawei, and this is a promising
stepping stone for its future commercial success as amainstream software router.

We have seen many unstable characteristics of Kamuee, that might be common to the general software
router. The throughput performance fluctuated overtime, in a significantly large range of a few tens of Gbps.
Further, we sometimes saw performance degradationthat we cannot explain (yet). Since the performance ofthe software router is very high and promising, the needto address the aforementioned drawbacks becomes evenmore imperative.
Even with some drawbacks, our Interop experience
proved that Kamuee satisfies the necessary functions
and quality needed to sustain the large scale IP infrastructure. Overall, Kamuee demonstrated a promising
performance for the use of future virtual network functions in the NFV environment.
As an open problem for the future network, the algorithms for the Access Control List (ACL) and firewall
applications that maintain high performance even withsome hundreds of thousands to some millions of ACL
entries are the next challenge in this field.

6. Conclusion and future work
We revealed the tricks for high-performance software
router design: we think the run-to-completion model in
DPDK, the Poptrie algorithm, and the keep it as simple as possible principle, are the main grounds for our
superior performance.
We show a good performance benchmark value ofKamuee: for 512B-sized frames or longer, Kamuee canforward around 349.60 Gbps random destination trafficwith BGP full routes (at FullRoute-LoopbackBlackhole
in Figure 4). Further intralaboratory evaluation of
12C/P at 64B frame in LoopbackTap (Figure 3a), theKamuee showed the potential of forwarding 292.17
Mpps.

References[1] G. P. Katsikas, T. Barbette, D. Kostić, R. Steinert, G. Q. M.
Jr., Metron: NFV service chains at the true speed of the underlying hardware, in: 15th USENIX Symposium on Networked
Systems Design and Implementation (NSDI 18), USENIX

40

Internet Conference 2018[10] A. Panda, S. Han, K. Jang, M. Walls, S. Ratnasamy, S. Shenker,
Netbricks: Taking the v out of NFV, in: 12th USENIX Symposium on Operating Systems Design and Implementation (OSDI16), USENIX Association, Savannah, GA, 2016, pp. 203–216.
URL
https://www.usenix.org/conference/osdi16/
technical-sessions/presentation/panda[11] J. Martins, M. Ahmed, C. Raiciu, V. Olteanu, M. Honda, R. Bifulco, F. Huici, Clickos and the art of network function virtualization, in: 11th USENIX Symposium on Networked Systems
Design and Implementation (NSDI 14), 2014.
[12] J. Hwang, K. K. Ramakrishnan, T. Wood, Netvm: High performance and flexible networking using virtualization on commodity platforms, IEEE Transactions on Network and Service
Management 12 (1) (2015) 34–47.
[13] R. Poddar, C. Lan, R. A. Popa, S. Ratnasamy, Safebricks:
Shielding network functions in the cloud, in: 15th USENIX
Symposium on Networked Systems Design and Implementation (NSDI 18), USENIX Association, Renton, WA, 2018, pp.
201–216.
URL
https://www.usenix.org/conference/nsdi18/
presentation/poddar[14] M. Honda, G. Lettieri, L. Eggert, D. Santry, PASTE: A network
programming interface for non-volatile main memory, in:15th USENIX Symposium on Networked Systems Design and
Implementation (NSDI 18), USENIX Association, Renton,WA, 2018, pp. 17–33.
URL
https://www.usenix.org/conference/nsdi18/
presentation/honda[15] A. Tootoonchian, A. Panda, C. Lan, M. Walls, K. Argyraki,
S. Ratnasamy, S. Shenker, Resq: Enabling slos in network
function virtualization, in: 15th USENIX Symposium on
Networked Systems Design and Implementation (NSDI 18),USENIX Association, Renton, WA, 2018, pp. 283–297.
URL
https://www.usenix.org/conference/nsdi18/
presentation/tootoonchian[16] S. Choi, B. Burkov, A. Eckert, T. Fang, S. Kazemkhani,
R. Sherwood, Y. Zhang, H. Zeng, Fboss: Building switch software at scale, in: Proceedings of the 2018 Conference of the
ACM Special Interest Group on Data Communication, SIGCOMM ’18, ACM, New York, NY, USA, 2018, pp. 342–356.
doi:10.1145/3230543.3230546.
URL http://doi.acm.org/10.1145/3230543.3230546[17] 8. Poll Mode Driver – Data Plane Development Kit 18.08.0 documentation, http://doc.dpdk.org/guides/prog_guide/
poll_mode_drv.html.
[18] M. Dobrescu, N. Egi, K. Argyraki, B.-G. Chun, K. Fall, G. Iannaccone, A. Knies, M. Manesh, S. Ratnasamy, Routebricks: Exploiting parallelism to scale software routers, in: Proceedingsof the ACM SIGOPS 22Nd Symposium on Operating Systems
Principles, SOSP ’09, 2009.
[19] S. Hemminger, Making a virtual router a reality with dpdk,
rcu and 0mq, https://events.static.linuxfound.org/
sites/events/files/slides/DPDK_RCU_0MQ.pdf.
[20] Universal TUN/TAP device driver., https://www.kernel.
org/doc/Documentation/networking/tuntap.txt.
[21] 33. Tun—Tap Poll Mode Driver – Data Plane Development Kit
18.08.0 documentation, https://doc.dpdk.org/guides/
nics/tap.html.
[22] Ferruh Yigit, Interworking with the Linux Kernel, https://dpdksummit.com/Archive/pdf/2016Userspace/
Day02-Session06-FerruhYigit-Userspace2016.pdf.
[23] VPP Sandbox/router - fd.io, https://wiki.fd.io/view/
VPP_Sandbox/router.
[24] Hasan Alayli, lthread, a multicore enabled coroutine librarywritten in C, https://github.com/halayli/lthread.

PCI Configuration Effect, 1518B 100GbE
400
Throughput (Gbps)

350
300
250
200
150
iommu=on VM SR-IOV 1VF
iommu=on VM PCI passthroughiommu=on Baremetal
iommu=off Baremetal

100
50
0
0

2

4

6
8
10 12 14
Number of Cores per Port

16

18

Figure 8: PCI configuration e↵ect

Association, Renton, WA, 2018, pp. 171–186.
URL
https://www.usenix.org/conference/nsdi18/
presentation/katsikas[2] M. Dalton, D. Schultz, J. Adriaens, A. Arefin, A. Gupta,
B. Fahs, D. Rubinstein, E. C. Zermeno, E. Rubow, J. A.
Docauer, J. Alpert, J. Ai, J. Olson, K. DeCabooter, M. de Kruijf,
N. Hua, N. Lewis, N. Kasinadhuni, R. Crepaldi, S. Krishnan,
S. Venkata, Y. Richter, U. Naik, A. Vahdat, Andromeda:
Performance, isolation, and velocity at scale in cloud network
virtualization, in: 15th USENIX Symposium on Networked
Systems Design and Implementation (NSDI 18), USENIX
Association, Renton, WA, 2018, pp. 373–387.
URL
https://www.usenix.org/conference/nsdi18/
presentation/dalton[3] Intel, DPDK – Data Plane Development Kit, http://dpdk.
org/.
[4] H. Asai, Y. Ohara, Poptrie: A compressed trie with population
count for fast and scalable software ip routing table lookup, in:Proceedings of the 2015 ACM Conference on Special Interest
Group on Data Communication, SIGCOMM ’15, 2015.
[5] P. E. McKenney, J. D. Slingwine, Read-copy update: Using execution history to solve concurrency problems, in: Parallel andDistributed Computing and Systems, 1998, pp. 509–518.
[6] Y. Ohara, Y. Yamagishi, Kamuee zero: the design and implementation of route table for high-performance software router,in: Proceedings of Internet Conference 2016, IC 2016, 2016.
[7] J. Sherry, S. Hasan, C. Scott, A. Krishnamurthy, S. Ratnasamy,
V. Sekar, Making middleboxes someone else’s problem: Network processing as a cloud service, in: Proceedings of the
ACM SIGCOMM 2012 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, SIGCOMM ’12, ACM, New York, NY, USA, 2012, pp.
13–24. doi:10.1145/2342356.2342359.
URL http://doi.acm.org/10.1145/2342356.2342359[8] N. W. Paper, Network functions virtualisation: An introduction,
benefits, enablers, challenges & call for action. issue 1 (Oct2012).
[9] B. Li, K. Tan, L. L. Luo, Y. Peng, R. Luo, N. Xu, Y. Xiong,
P. Cheng, E. Chen, Clicknp: Highly flexible and high performance network processing with reconfigurable hardware, in:Proceedings of the 2016 ACM SIGCOMM Conference, SIGCOMM ’16, ACM, New York, NY, USA, 2016, pp. 1–14.
doi:10.1145/2934872.2934897.
URL http://doi.acm.org/10.1145/2934872.2934897

41

Internet Conference 2018[25] Y. Ohara, Y. Yamagishi, S. Sakai, A. D. Banik, S. Miyakawa,
Revealing the necessary conditions to achieve 80gbps highspeed pc router, in: Proceedings of the Asian Internet Engineering Conference, AINTEC ’15, 2015.
[26] Mellanox, Mellanox 100GbE QSFP28 LR4 Optical
Transceiver, https://www.mellanox.com/related-docs/
prod_cables/PB_MMA1L10-CR_100GbE_QSFP28_LR4_
Transceiver.pdf.

42Internet Conference 2018

Poster43

Internet Conference 2018

Lightweight Packet Loss Detection andMulticast Delivery Tree Recovery in SDN

Siva Sairam Prasad (cs14resch01003@iith.ac.in), Kotaro Kataoka (kotaro@iith.ac.in)Indian Institute of Technology Hyderabad, India
Multicast Delivery Tree Recovery

Outline• Bypass the lossy link in the tree.

Monitoring quality of multicast streaming is difficult because 1) generally intermediate multicast routers and switches do not maintainthe fine-grained state about multicast flow and 2) sampling QoS
statistics from destination clients introduces significant operational
overhead. Therefore, its difficult to properly locate where packet
losses happen and how severe they are. This paper proposes amechanism to detect and locate packet losses using a packet tagging technique in Software Defined Network (SDN). Our system also
dynamically recalculates the multicast delivery tree to bypass a lossy
link and mitigate packet loss for the tree.

• If bypass is not feasible then recalculate the partial tree that is

affected by packet loss.

Controller
Flow rule
Database

ﬂow
rules

ﬂow rule data

Multicast monitoringand packet loss
calculation

packet loss info
packet_in
handler

Problem Description

topo
info

Topology
moduletopo
info

Recalculation ofpartial multicast
delivery tree

packet_in
messageinstalling
ﬂow rule• In traditional network it is difficult to detect and impossible to

SDN Switch

locate packet loss for multicast in real-time.
• With the evolution of SDN, calculating packet loss at link levelis not feasible in real-time due to variable bit rate and variable
duration of the flows.
• By using short lived test flows can get the packet loss at link level,
but they lead to overhead in the network and also more TCAM
consumption.
• Need to utilize the unused links that are non-lossy for multicast
delivery tree calculation.
• Recalculation of entire multicast delivery tree whenever packet loss
happens leads to frequent interruptions to the users, also for thoseare not affected by packet loss.

Figure 2: System Diagram

Experimental Setup & Preliminary Results
Network Configuration using Mininet

S3
H2

lossy
link
S1

S2

S5

S6

S4

M

Tagged packet
Normal packet

N-

Monitoring flow rule
Normal flow rule

After tree recalculation

1

2

M

1

2

M

1

2

M

1

2

3

4

N

3

4

N

3

4

N

3

4

SourceSwitchIntermediate
SwitchInitial multicast tree

H1

H3

Figure 3: Network Diagram• In the above network diagram S1-S6 are SDN Switches, H1 ismulticast source and H2,H3 are multicast destinations.
• Packet loss rate for (S3,S5) is 10%, for all other edges there is nopacket loss.
• Initial and recalculated multicast delivery tree are shown in theabove figure.

Destination
SwitchFigure 1: Packet Tagging Mechanism

Proposed solution

Preliminary Results

Packet Loss Detection• As shown in Figure 3, the recalculation is done via partial tree

• Install short lived monitoring flow rules on existing traffic.

recalculation because bypass is not possible.

• Tag packets based on fixed time intervals as shown in Figure.1 for• Packet loss calculation for every 10 s, time taken to recalculatemonitoring at source switch.
• Monitor the tagged packets at intermediate switches and remove
tag before reaching the destination.
• Get packet loss statistics from monitoring flow rules in periodic
intervals.
• Calculate packet loss from statistics and also deduce the lossy link
location.

for one link on above network is 1.8 ms.

Discussion Points• Minimize the control overhead for monitoring, scalable to large

networks.
• Time complexity for each lossy link to bypass is O(E logV), forpartial recalculation is O(DE logV) here D is the affected destinations.
44Internet Conference 2018

Trust Management in Multi-Domain
SDN Networks Using Blockchain

Prashanth Podili (cs15resch01003@iith.ac.in), Kotaro Kataoka (kotaro@iith.ac.in)Indian Institute of Technology Hyderabad
Outline

C2

S2

S2

S1

Controller Communication• Quantifying trust between a pair of domains for a service profile• Trust value is 1 if parameters conforms to expected (QoS) values, else 0.
• Aggregated trust value calculated over a period of time, (Tagg )= (m/n), m= successful interactions, n= total interactions.
• Every domain controller puts Tagg of domains it interacted to blockchain.
• Trust management using blockchain• Smart contract is created to store and distribute trust values.
• Trust graph (Fig.3) is generated for each service profile across all the domains
and global trust is evaluated based on trust transitivity property.

Physical Link
Ci

Controller

Si

OpenFlow Switch

System Design and Implementation

Fig. 1 MD-SDN Network• To evaluate trust in a given domain D (Fig.4), the domain con-Background and Motivation

troller checks the TCIB for SDN deployment parameters of D andretrieves global trust value from blockchain.
• If D is trustworthy, the controller establishes a session and negotiates service parameters for auditing.
• Audit log retrieved from D is verified for evaluating trust.
• Our Implementation uses Ethereum, Solidity for creating smart
contract, Mininet with Open vSwitches and RYU SDN controllers.

• Programmability of SDN offers flexibility for E2E service provi-

sioning in MD-SDN networks[2].
• Information exchange between domain controllers are not verified(similar to BGP) to ensure integrity of exchanged messages.
• Finding trusted domains among multiple domains is challenging.
• Services with varying QoS values require different trust levels for
SDN domains to collaborate.

Blockchain
Node

Retrieve
Global Trust
value

Trust Management-Challenges• Heterogeneity of SDN implementation across domains.

Identify adomain-D

Trustworthy• Difficulty to quantify and evaluate trust between domains.

Yes

Update Trust

Establish Session
Negotiate service
parameters

Evaluate Service
Verifylog(parameters)

No• Mechanism to build truly distributed trust management system.

TrustedInformation
Base• Handling collusions/fake trust values of domains.

Domain Controller

Fig. 4 Trust evaluation of a peer domain in controller• Tamper proof trust data storage and dissemination among SDN

domains.

Fig. 3 Sample Trust Graph• Service Profile Trust• Service Profiles classify distributed services with varying QoS. E.g., service
profiles for video traffic delivery, virtual networks, service chains etc.
• Identify (openflow) parameters for every service profile.
• Negotiate parameters and obtain audit logs from collaborating domains fortrust evaluation.

OpenFlow

AS4

0.9

0.8

Fig. 2 Blockchain Controller
Communication

AS3

S2

AS5

0.6

AS4

S2

S1

AS3

Store & Retrieve Trust Values

C3

C4

AS1

0.8

0.5

C3

C4

AS2

S1

AS1

C1

C2

S1

AS2
0.7

In Multi-Domain Software-Defined Networks (MD-SDN) such as Internet (Fig.1), controllers communicate to provision end-to-end services across multiple domains besides enabling inter-domain routing[1]. Trust management across the domains provides operational
feasibility, transparency, enhanced security and prevention of dataabuse. However, quantifying and evaluating trust across domains
with heterogeneous SDN implementations is challenging. This work
aims to evaluate trust by enabling auditability across domains andbuilds a distributed trust management system for MD-SDN networks
using blockchain. Blockchain allows a) to verify integrity of audit
records b) tamper proof trust data storage and dissemination.

C1

Blockchain

Smart Contract

Current Progress and Discussions

Proposed Approach• Developed testbed integrating RYU controller and blockchain(Fig.

2) and currently working on design of trust evaluation algorithms.

• Trust Definition:

Domain A trusts domain B, when domain B
operates/provides the services in a manner that is promised to A.
• Evaluating trust by verifying audit logs from service provider domain controllers• Building Trusted Controller Information Base(TCIB)• Discussion points:a)Frequency of trust value updates to blockchainb)Missing trust values for a pair of domains in trust graph.

References

1. Zhou, Haifeng, et al. "SDN-LIRU: A lossless and seamless method for
SDN inter-domain route updates." IEEE/ACM Transactions on Networking 25.4
(2017): 2473-2483.
2.
Kotronis, Vasileios, et al.
"Stitching inter-domain paths over
IXPs."Proceedings of Symposium on SDN Research. ACM, 2016.

• Exchange Domain Information Message(DIM) (xml/json message) during do-main discovery process. DIM includes SDN deployment parameters and services offered with in a domain.
• Hash of DIMs are verified through blockchain.

45

Internet Conference 2018

On Accurate Packet Loss Estimation
for Networks without Traﬃc Models
Masahiro Terauchi

Kohei Watabe

Kenji Nakagawa

Graduate School of Engineering, Nagaoka University of Technology, Nagaoka, Niigata, Japan.

Introduction!

The model-less approach follows the procedure below.
! A simulation with Poisson traﬃc model is performed.
! Input traﬃc, output traﬃc and loss processes are discretized with ∆.
! Change-of-measure is based on frequency of discretized traﬃc pattern.
! Our estimator is!

It is important to accurately model network traﬃc when we evaluate Quality ofService (QoS) of networks through simulations.
! It is diﬃcult to select an appropriate traﬃc model and tune its parameters.
! Even if the accurate traﬃc modeling is achieved, it is also diﬃcult toaccurately estimate QoS regarding rare events.

1
lˆ =
c̃

Trace-driven simulation

Traffic in real
networks

Only for non-correlated and large
Direct change-of-measure number of traces on a single router.
in Model-less approach
Trace-driven IS
IS simulation

Difficulty in model selection
and parameter tuning.

where

Poisson model

IS for Poisson

FBM model

Difficulty in analysis, andrestrictions on topology, etc.

Trace based model…

Experiments
As a first step in the development, we investigate the case when the packet loss
rate of an MMPP/M/1/K system is estimated from an M/M/1/K simulation.
! The simulation time is 2000 [s], simulation sets is 30, ∆ = 0.025 [s], and k = 2.
! In these systems, since the packet arrivals and a service time are independent.
! Therefore, the change-of-measure can be expressed as
P (X1,N,k ∩ Y1,N,k )/P̃ (X1,N,k ∩ Y1,N,k ) = P (X1,N,k )/P̃ (X1,N,k ).
!

Goal of our study
We propose a model-less approach to accurately estimate a packet loss rate
through a simulation without directly modeling traﬃc, including real network
traﬃc.

Table 1: Target network parameters

Model Based IS

Arrive Rate at State 1 [packet/s] 100
Arrive Rate at State 2 [packet/s] 339

Orignal condition network model

Modified condition network modelServicemodel

ModifyPacket

Traﬃc
model

Transition Rate of Each State [times/s] 1.00
Mean Service Time [s/packet] 0.001

Service
model

Queue Size K [packet]

Estimator of IS

Packet loss rate
Change-of-measure: The set of lost packets,: The queue length process,: Probability density of an eventin the original condition,: Probability density of an eventin the modiﬁed condition.

ˆE[l]: The number of packets,

2.0 × 10−5

10−9

1.5 × 10−5

10−10

1.0 × 10−5
5.0 × 10−6

Figure 2: Outline of model base IS

When IS estimates a loss rate on a single router into which a single flow
streams, the change-of-measure is performed based on probability density of apath ω of the queue length process [2].
! The change-of-measure p(ω)/p̃(ω) is analytically derived from a traﬃc model inmodel-based IS.
!

Theoretical Value
Model-less Approach

0.0 × 100 −5
10
10−4 10−3 10−2 10−1
Packet Loss Rate of Simulation Network
Figure 4: Result of mean

Model-less Approach!

10

Packet Loss Rate [-] 10−5

Packet lossˆVar[l]

Traﬃc
model

(1)

D̂(n): Discretized packet loss process.
When we assume a single router and a single flow, in the limit as ∆ → 0 and
k → N , our estimator converges to that of model based IS.
! By expressing the estimator by input and output traﬃc instead of a queue length
process, (1) is applicable for multiple flows on a network with complicatedtopology.

!

!

N =1

P (X N,k ∩ Y N,k ),P̃ (X N,k ∩ Y N,k )!

Figure 1: The model-less approach and the conventional simulations.

Importance Sampling (IS) for accurate estimations of rare events [2]! The events occur more frequently in IS simulation.
! The estimator is obtained by the change-of-measure.
! The applicable traﬃc models, topology etc. are extremely limited.
! Trace-driven IS without traﬃc models [3]! It cannot be applied for single flow traﬃc.
! It is not applicable for traﬃc with correlated flows.

D̃(N )

X N,k = {X(n)}N −k<n"N : Discretized input flow traﬃc in past k periods.
Y N,k = {Y (n)}N −k<n"N : Discretized output flow traﬃc in past k periods.

(not trace-driven)…

∞!

Model-less Approach
Trace Driven

10−11
10−12
10−5
10−4
10−3
10−2
10−1
Packet Loss Rate of Simulation Network
Figure 5: Result of variance

According to the figures, we can find the region in which the model-lessapproach can estimate the packet loss rate of the original system.
! Additionally, we can confirm that the variances of the estimators are about 1/3
in the region, compared with the estimator by the trace-driven simulation.
!

Our goal is to accurately estimate a packet loss rate through a simulation in areal network without assuming any traﬃc model.

Conclusions and Future Directions
We proposed the model-less approach to accurately estimate a packet loss rate
through simulation with traﬃc trace without traﬃc models.
! We will verify the applicability of our approach to the various trace on various
networks in our future works.
!

References[1] J. Zhang et al., “A Survey of Network Traﬃc Generation,” in Proc. of CCT 2015.
[2] N. Kobayasahi et al., “On-line Estimation by Importance Sampling for the Tail Probability of FIFO Queue
Length, ” in Proc. of RESIM 2014.
[3] I. C. Paschalidis et al., “Importance Sampling for the Estimation of Buﬀer Overflow Probabilities via
Trace-driven Simulations,” IEEE/ACM Transactions on Networking, vol. 12, no. 5, 2004.

This work was partly supported by JSPS KAKENHI Grant Number JP17K00008 and
JP18K18035.
Figure 3: Outline of model-less approach46

Internet Conference 2018

IC2018

An Ocean Target Detection Mechanism in IoT Environment
Yaqiang Zhang1,2, Xiangbo Kong1, Lin Meng1, Zhangbing Zhou2 and Hiroyuki Tomiyama1,
1Graduate School of Science and Engineering, Ritsumeikan University
2School of Information Engineering, China University of Geosciences¾¾

Toxic target like crude oil leak will cause great damage to human and marine
environment.
With the development of IoT system, devices like UAV can be deployed todetect and track continuous target.

Get initial boundary region

Mobile devices deployment

Interpolate in the region
Collect sensory data
9 A heuristic algorithm based mechanism is proposed for routing mobile IoT
devices like UAV in order to track the boundary region of marine pollutant.

New stops?
YNz Static IoT sensors are firstly
deployed in the interested ocean
network region and separated
into different groups according
to their reading.
z The gray region is the scope ofthe marine pollutant.
z Black nodes: a sensor whose
reading is exceed the thresholdof toxic target and all of its
neighbor nodes are event nodes.
z Blue nodes: a sensor whose
reading is exceed the thresholdof toxic target and some of its
neighbor nodes are event nodes
while others are not.
z Green nodes: a sensor whose
reading is under the threshold of
toxic target and some of its
neighbor nodes are event nodes
while others are not.
z Light green nodes: a sensor
whose reading is under thethreshold of toxic target and allof its neighbor nodes are normal
nodes.

Get final boundary region¾ Interested network region is divided by static IoT sensor nodes and an
initial boundary region is generated.
¾ According to the sensory data gathered by static IoT sensor nodes,
sensing holes that don’t have sensory data are interpolated and find apredicted boundary line.
¾ Some stops are selected on predicted boundary line if there are.
¾ Multi-UAV are applied to traverse selected stops and get sensory dataon stops.
¾ A new boundary region is generated according to new data andrepeat above steps until there are no new stops.
z The yellow dotted line is the predictedboundary line on which all positions
are equal to threshold according tointerpolated results.
z Yellow triangular marks are stops
selected on the predicted boundaryline and there is a proper distance
between each stop.
z A suitable number of UAV are
deployed to traverse stops and genetic
algorithm (GA) is applied to route forMulti-UAV in order to optimize thetime and energy consumption of UAV.

Changes in boundary region with different number of static sensors.

••

Initial boundary region

Through continuous iteration, the scope of the target boundary
region is gradually narrowed and kept stable.
In different scale of static sensors deployment, the size of the target
boundary region varies greatly. When static IoT node deployment ismore densely, the result is more accurate.

¾ The proposed mechanism can effectively detect and track theocean target boundary region.
¾ The experimental data shows that the scope of target boundary
region is shrunken and it reflects the actual situation of toxic target.
¾ The GA based mechanism for routing UAV can effectively balance
the energy and time consumption.

Final boundary region[1] L. Shu, M. Mukherjee, and X. Wu, “Toxic gas boundary area detection in large-scale petrochemical plants with industrial wireless sensor networks,” IEEE
Communications Magazine, vol.54, no. 10, pp. 22–28, 2016.
[2] R. Roman, J. Lopez, and M. Mambo, “Mobile edge computing, Fog et al.: A survey and analysis of security threats and challenges,” Future Generation Computer
Systems, 2016.
[3] J.-H. Kim, K.-B. Kim, S. H. Chauhdary, W. Yang, and M.-S. Park, “DEMOCO: Energy-efficient detection and monitoring for continuous objects in wireless sensor
networks,” IEICE Transactions on Communications, vol. E91-B, no. 11, pp. 3648–3656, 2008.

47

Internet Conference 2018

e-Learning System for
Cryptography on Moodle†Osaka Electro-Communication University‡Shinshu University§Tokyo University of Technology

Tatsuki Miyamoto†, Shogo Shimura‡, Tatsuki Watanabe†,
Hiroyuki Okazaki‡, Yuichi Futa§, Yasuyuki Murakami†
Summary
In Japan, due to the lack of ICT engineers, fostering human resources for ICT is an urgent task. Especially, cryptographic technology is a fundamental
element for realizing information security. Learning knowledge and training techniques on cryptography are indispensable not only to researchers andengineers specialized in cryptography but also to ICT engineers such as network engineers and operators. However, the educational environment andteaching materials of cryptographic technology for ICT engineers are not sufficient. There is also a lack of teachers who can educate the theory and thetechnology of the cryptography.
Recently, e-Learning using the Internet has been widely spread especially at the educational places such as universities. Moodle is popular and widelyused as an e-Learning system. In Moodle, students answer questions on quizzes on the browser via Internet and whether the answer is correct or not
can be judged depending on whether or not their answer matches the model answer set by the teacher. Moodle is excellent e-Learning system which
also has an automatic scoring function. However, learning programming with Moodle is not always easy because the program is not necessarily one
correct answer.
VPL, Virtual Programming Lab for Moodle, is a free system formed by two components: the Moodle plugin and the execution system(Jail-System).
The Moodle plugin can be installed as a regular Moodle plugin. The execution system needs to be compiled for installation. The installation is notalways easy for teachers.
Formal verification of cryptographic protocols has been studied extensively in recent years. ProVerif is one of the most successful automatic
cryptographic protocol verifiers. In the previous work, we developed an e-Learning system for learning C programming based on Moodle with VPL byusing VM, Virtual Machine, for easy installation[1]. In this research, we newly support ProVerif to the previously developed system and create thecontents for learning ProVerif.

What is Moodle / VPL
Students:• Edit• Run• Evaluate

VPL is a free system formed by two
components: the Moodle plugin and the execution
system. The Moodle plugin can be installed as aregular Moodle plugin. The execution systemneeds to be compiled for installation.

Moodle is a free, online Learning Management
system. Moodle is widely used as an e-Learning
system in many educational institutions. It iseasy to install and can be expanded with plugin.

Teachers:• Easy Evaluation

Developed e-Learning System

ProVerif Sample
free c: channel.
free hirabun: bitstring [private].
type pkey.
type skey.
free Rsky: skey [private].
event DECSUCC.
event SEND.
query event(DECSUCC).
query attacker(hirabun).
(*common key cryptosystem*)fun enc(bitstring, bitstring): bitstring.
fun dec(bitstring, bitstring): bitstring.
equation forall x: bitstring, s: bitstring; dec(enc(x,s),s) = x.
(*public key encryption*)
fun pk(skey): pkey.
fun encrypt(bitstring, pkey): bitstring.
fun decrypt(bitstring, skey): bitstring.
equation forall x:bitstring, sky:skey; decrypt(encrypt(x, pk(sky)), sky) = x.
let R =
in(c, (m1:bitstring, m2:bitstring)); (* m1 = encrypt() m2 = ctxt *)let sk = decrypt(m1, Rsky) inif(dec(m2, sk) = hirabun) then event DECSUCC.
process(event SEND;
new randx: bitstring;let ctxt = enc(hirabun, randx) inout(c, (encrypt(randx, pk(Rsky)), ctxt)))| R

Fig.1 Moodle Screen on Browser

Fig.2 Learning ProVerif on Moodle+VPL

Benefits for Students:• No compiler required, Browser only required.
→Available on Tablet or Smartphone.
• No source code submission required.
• Discover mistakes themselves instantly.

VM A

VM B

Mizar

Java

Jail-System

Jail-System
VM moodle

Benefits for System Managers:• Using VM, Any host OS available.
• Easy to Install, manage and update.
• No need to introduce compiler for eachclient.

Fig.4 ProVerif Sample Source Code

VM C

VPL

VM D

ProVerifC

Jail-System

Benefits for Teachers:• Automatic evaluation.
→No program download, nor compile,
nor execution required.
• By the test pattern, it is easy to find mistakes.
• The correct answer is judged as correcteven if it is not the model answer.

Jail-System

Internet

Linear part:
Completing equations...
Completed equations:
Convergent part:dec(enc(x,s),s) = x
decrypt(encrypt(x_7,pk(sky)),sky) = x_7
Completing equations...
Completed equations:decrypt(encrypt(x_7,pk(sky)),sky) = x_7
dec(enc(x,s),s) = x
Process:({1}event SEND;{2}new randx: bitstring;{3}let ctxt: bitstring = enc(hirabun,randx) in{4}out(c, (encrypt(randx,pk(Rsky)),ctxt))) | ({5}in(c, (m1: bitstring,m2: bitstring));{6}let sk: bitstring = decrypt(m1,Rsky) in{7}if (dec(m2,sk) = hirabun) then{8}event DECSUCC)- Query not attacker(hirabun[])Completing...
Starting query not attacker(hirabun[])RESULT not attacker(hirabun[]) is true.
- Query not event(DECSUCC)
Completing...
Starting query not event(DECSUCC)
goal reachable: end(DECSUCC)
1. The message (encrypt(randx[],pk(Rsky[])),enc(hirabun[],randx[])) may be sent to the attacker at output {4}.
attacker((encrypt(randx[],pk(Rsky[])),enc(hirabun[],randx[]))).
2. By 1, the attacker may know (encrypt(randx[],pk(Rsky[])),enc(hirabun[],randx[])).
Using the function 2-proj-2-tuple the attacker may obtain enc(hirabun[],randx[]).
attacker(enc(hirabun[],randx[])).
3. By 1, the attacker may know (encrypt(randx[],pk(Rsky[])),enc(hirabun[],randx[])).
Using the function 1-proj-2-tuple the attacker may obtain encrypt(randx[],pk(Rsky[])).
attacker(encrypt(randx[],pk(Rsky[]))).
4. By 3, the attacker may know encrypt(randx[],pk(Rsky[])).
By 2, the attacker may know enc(hirabun[],randx[]).
Using the function 2-tuple the attacker may obtain (encrypt(randx[],pk(Rsky[])),enc(hirabun[],randx[])).
attacker((encrypt(randx[],pk(Rsky[])),enc(hirabun[],randx[]))).
5. The message (encrypt(randx[],pk(Rsky[])),enc(hirabun[],randx[])) that the attacker may have by 4 may be received at input {5}.
So event DECSUCC may be executed at {8}.
end(DECSUCC).
A more detailed output of the traces is available with
set traceDisplay = long.
event SEND at {1}new randx: bitstring creating randx_404 at {2}out(c, (~M_410,~M_411)) with ~M_410 = encrypt(randx_404,pk(Rsky)), ~M_411 = enc(hirabun,randx_404) at {4}in(c, (~M_410,~M_411)) with ~M_410 = encrypt(randx_404,pk(Rsky)), ~M_411 = enc(hirabun,randx_404) at {5}ClientFig.3 System Configuration

event DECSUCC at {8} (goal)
The event DECSUCC is executed.
A trace has been found.
RESULT not event(DECSUCC) is false.

Fig.5 Verifying Process by ProVerif

Conclusion
In this research, we have constructed a programming education support system using Moodle and VPL using VM. We have newly supported ProVerif
to previously developed e-Learning system using VM. In addition, we have newly created the contents for learning ProVerif and actually started thelearning exercise of ProVerif by using the developed system. As a future plan, we would like to enrich the contents and evaluate the effect of learning
the security programming by using the developed e-Learning system.
Acknowledgement: This study was supported in part by JSPS KAKENHI Grant Numbers JP18K02917 and JP17K00182.
[1] M. Nakamura, T, Watanabe, M. Kaneda, H. Okazaki and Y. Murakami, “Programing education support system using Moodle,” 40th Symposium on Information Theory and Its Application,
Poster session, SITA2017, Nov. 2017 (in Japanese).

48Internet Conference 2018

VISIBLE: Application for Vehicle Visibility andIncident Reporting in Real-Time

Mehul Sharma, Suhel Magdum, Antony Franklin A, Bheemarjuna Reddy Tammaand Digvijay S. Pawar⇤
Department of CSE, IITH, ⇤ Department of Civil Engineering, IITH
Email: [cs17mtech11020, cs17mtech11012, antony.franklin, tbr, dspawar]@iith.ac.in

I NTRODUCTIONA PPLICATION F EATURES• Safety issues in the transportation system are the major concerns.
• V2V/V2I are emerging as an efficientsolution for achieving road safety.
• Blind Spots, Intersections, and Ghat
Sections are the major accident-prone
areas where there is no clear visibilityof moving vehicles.
• Internet connectivity is the main concern in areas like ghats.

C LOUD VS A DHOC M ODE

1. Real-time visibility of neighbouring
vehicles in the collision domain.
2. Incident Reporting within a certain radius.
3. App has two modes, Cloud and P2P.
4. Application automatically switchesfrom cloud mode to P2P mode when
there is no Internet.

P2P Mode

Cloud Mode

Range is <80m

No bound on range

Unreliable due to link
breakage

More reliable

More time to discoverpresence of neighbour

Less discovery timeMore discovery time but lessdata sharing timeMore time to share data i.e.
cloud latency

Multihoping

Direct Information sharing
using centralized cloud

A PPLICATION F LOW D IAGRAMO BJECTIVE• To build a reliable platform that effectively utilizes mobile devices for grasping the traffic situation.
• To develop efficient V2V/V2I communication using cloud technology and
P2P.
`

V2V/V2I C OMMUNICATIONINTELLIGENT TRANSPORTATION SYSTEM
Location
updates

Roadside
Equipment

CLOUD

Infrastructured
mode

V2I
communication

V2V
communication
Ad-hocmode
Vehicles moving
in realtime

A PPLICATION S CREENST ECHNOLOGIES U SED
Delay Tolerant Networking

Activity to show
Green markers shows
the real-time location of connected peers and abuttonto display locationneighbouring vehicles
on map

New users can register
using Google or Email
Sign-In methods

In case of no Internet,
location is sent to peers
and displayed on map

Nevigation drawer toswitch among different
activities of application

Share message withincertain radius i.e Incident
Reporting

R ESULTS AND A NALYSIS
1200

800

Discovery Time (ms)

400
300
200
100

800

600

400

200
0

70

60

50

40

30

20

This work was supported by M2Smart
Project, JST/JICA SATREPS, Japan.

500

10

A CKNOWLEDGEMENT

1000
600

0

• We developed a smartphone-based application that can make use of P2P andcloud technology to detect vehicles in
the collision domain.
• Future work comprises of audible
beeps/alerts if any vehicle comes into
danger zone.
• Developing efficient RF (eg. Bluetooth)scanning methods for estimating traffic
congestion and speed.

Location share time (ms)

C ONCLUSION

700

Distance (m)Figure 1: Location share time vs Distance

0

P2P

Cloud

Figure 2: Device Discovery Time• Fig. 1 shows that time taken to share location to peers in P2P mode increases with increase in inter-node distance.
• Clock of both sender and receiver in P2P is synced using Network Time Protocol (NTP).
• Discovery time is the time taken to discover the presence of neighbour and display its
location on the map.

49

Internet Conference 2018

Sanouphab Phomkeona and Koji Okamura
Graduate School of Information Science and Electrical Engineering, Kyushu University, Japan

Our research focus on developing a new algorithms by using email header information analysis for malspam filtering and also to increase a possibility of zero-day malicious email detection

Fig. 1 CIS Cybersecurity report on malware infection vector
1. Email is the most common entry point of targeted attacks
2. About half of all email traffic is malspam, it means about 14.5 billion malspam are

Fig. 4 Design Method for EHIA and Deep-Learning

sent every single day in Q1 2018
3. Currently, the majority of security systems are unable to detect and stop today’s advanced email threats that are specifically designed to fool the security systems

Fig. 5 Features extraction flows chart

From email dataset we first extract 3 features: source address, timestamp and subject
Then we can extract more features from those 3 to get other features in order.

Fig. 6 Bag of subjects data collection’s flows chart

Email subject database are created for matching propose and receive M-translate detected,
and risk-words detected features

Fig. 2 Example how human being analyze email header
Unlike machine, cybersecurity experts also take consider in email header where suspicious data and their relationship among them are provided. For example:- A relationship between domain zone and language- A relationship between time zone and time sent
- Email was written by machine translation detection

In this research, we proposed a method by using new features extracted from email headers
Fig. 3 Differnetial of email spawn time between normal email, work email and malspam

and deep-learning approach to detect malspam. From the current experiments, we have not

From 436 work mails (Green), 4251 normal mails (Blue), and 277 malspam (Red) We

used all the features yet, but we got the best detection result at 78.66% accuracy. Thus, we

can see that most of normal and work mails were sent on work time (8AM-8PM), but

keep doing more experimentation and improving the method technique to evaluate the detec-

the malspam’s sent time were variedtion result
Email: 3IE17305G@s.kyushu-u.ac.jp

50

Internet Conference 2018

How Japan's Approach Towards Cybersecurity has Changed:
Quantitative Content Analysis of Cybersecurity Strategy from 2013 to 2018
PIYUSH GHASIYA & Prof. KOJI OKAMURAISEE, Kyushu University, Fukuoka, Japan

BackgroundCo-Occurrence Network Analysis

Quantitative Content Analysis helps in obtaining a complete picture
and in investigating the features of the data while avoiding thebiasness of the researcher.
Moreover, it not only helps in examining the manifest content(visible)
but also the latent content (the meaning behind the manifest content)of the text.

Japan's 1st Cybersecurity
Strategy (2013)

Aim of the ResearchFirst, by statistically analyzing Japan's Cybersecurity
strategy, the research would try to show how Japan's
approach towards cybersecurity has changed over
the year.
Next, the researcher will try to analyze whether or notthese strategies are effective in making Japanese society
safe from the cybersecurity challenges.
Japan's 2nd Cybersecurity
Strategy (2015)

MethodThis research will be using KH Coder for analyzing
the text (Japan's Cybersecurity Strategy).
Step 1. Extracting the most frequent words.
Step 2. Co-Occurrence Network Analysis of the words
with 30 or more frequency.

Term Frequency Analysis
Japan's 3rd Cybersecurity
Strategy (2018)

Co-Occurrence Network
Analysis (Freq= 30=<)

The Co-Occurrence Network Analysis shows thecentrality (significance) of the particular node(concept or word).
It is clear from the analysis of all three documentsthat though the policymakers adopted the term
"Cybersecurity", however it is acctually"Information Security" that occupies their
imagination.

Resources
1. https://www.nisc.go.jp/eng/pdf/cybersecuritystrategy-en.pdf
2. http://www.nisc.go.jp/eng/pdf/cs-strategy-en.pdf
3. https://www.nisc.go.jp/eng/pdf/cs-senryaku2018-en.pdf
4. http://khcoder.net/en/

Presenter's Contact:
Piyush Ghasiya, PhD Researcher,
ISEE, Kyushu University, Fukuoka, Japan
E-mail : piyushghasiya@gmail.com
51

Internet Conference 2018

A Design of Failure Injection Testing
considering Edge Computing Environment
Kenta Hayashi†, Kaori Maeda†, Tohru Kondo‡† Graduate School of Information Sciences, Hiroshima City University, Japan.
‡ Information Media Center, Hiroshima University, Japan.

Background• The current cloud services composed by many distributed microservices[1]• Demand of edge computing for IoT• Long latency or unstable connections in an edge computing
environment have many negative effects on IoT applications• High complexity of collaboration of micro services• Requirement for availability and capability without service disruption • Edge computing environments including IoT devices have different
failure occurrence rates depending on places• Emerging of Chaos Engineering[2] to improve for resilience of complex
distributed systems

The goal of this research
Implementation of a Failure Injection Testing(FIT) system for edge computing environment• Design of a failure injection scenario which is friendly to application providers• Implementation of the FIT system based on an arbitrary scenario such as power failure into 50% of edge servers

Design of failure injection testing system①

FailureInjection
Scenario

Application Provider

Failure Injection Testing system
Failure Injection Scenario Generator

micro
service

Cloud side②

FIT system⑦

Configuration Information Acquirer

③

⑧

UE

micro
serviceUE

microservicemicroserviceUE④, ⑪, ⑭ Edge Computing Platform
Management System(ex. kubernetes)⑤

microservice

UE

⑨, ⑫

⑥

Cloud App.

Edge side

Failure Injection
Controller

Failure Injection Tool
(ex. pumba)

⑩, ⑬

UE

UE (User Equipment) : Edge devices such as sensors

Fig. FIT system configuration

Failure injection flow:
Step 1 (①-⑦) : Acquisition of application configuration information
Step 2 (⑧) : Failure injection preparation

Step 3 (⑨- ⑪) : Failure injection testing based on the scenario which
defined in Step 2
Step 4 (⑫ -⑭) : Restoration to the original state- Creation of failure injection scenario based on
configuration information in Step 1

Failure injection function

Failure injection scenario• Indicates structured scenarios for the edge computing environment
including the following items• Micro service operation• Network emulation• Micro service stop

• delay• Failure injection range (ex. edge side server, access network)• Slow stop

• packet loss

• Type of failure (ex. packet loss, jitter)• Immediate stop

• duplicate• Probability of failure occurrence (ex. 50%)

• Pause• corrupt• Failure injection period (ex. 10 minutes)• Micro service removal

Future prospects• Implement a FIT system using pumba[3] for failure injection and kubernetes[4] for edge computing environment• Demonstration of the effectiveness of the developed FIT

Reference[1] Jim Gray, “Why do Computers Stop and What Can Be Done About It?,” Tandem Computers Technical Report 85.7, PN87614, June 1985.
[2] Ali Basiri, Niosha Behnam, Ruud de Rooij, Lorin Hochstein, Luke Kosewski, Justin Reynolds, Casey Rosenthal, “Chaos Engineering,” IEEE Software, vol.33, no. 3, pp. 3541, May 2016.
[3] “pumba,” https://github.com/alexei-led/pumba, (accessed 08/24/2018).
[4] “Production-Grade Container Orchestration, ” https://kubernetes.io/, (accessed 08/24/2018).

This research and development work was supported by the JSPS KAKENHI Grant Number 15K00130,
52 16H02808, 18K11266 and MIC/SCOPE #162108102.

Internet Conference 2018

Counting Passengers from Images of Drive Recorder Inside Buses-  by Using Background Subtraction and OpenPose!"#"$% &"'"()*+", , Ismail Arai, , Kazutoshi Fujikawa,1 Nara Institute of Science and Technology

Background

Problems and purposeu Bus company's management crisis

u Past: Manually counting by investigators

u The motorization mainly in local cities→Only investigate several times a year

u The declining birthrate and aging population
u The progress of depopulation Bus stops

u Recent: Automatically counting system→Need to install equipment for counting→Costly: 300,000 Yen/bus
Propose automatically counting at low cost

1 tripu Optimal route planningex) EAGLE BUS (Saitama, Japan)

Deficit sectionu Count passengers at each bus stopu Find out which section on routes is deficitu Change bus stop / routes for revenue

Need to know the number of passengers at each bus stop

Equipment on buses

Counting method

The bus company in Japan can install equipment withsubsidies from the government.
u Drive recorderu Verification of accidents and in-vehicle troubleu Digital tachographu Verification of accidents and in-vehicle trouble
u Operation managementu Vehicle data (e.g. vehicle speedengine speedGPS
etc...) can be stored on memory card or cloudu Implementation counting passengers
u From drive recorder

Update the route planning

u From sensor data

Number of passengers(3G/LTE)
DigitalDatabase

TachographSensordata
SensorManagers

Congestion
information

VideosDrive Recorder

Numberof passengers Operation

Passangers

Estimate a number ofpassengers from sensor
data videos using image
processing.

Bus

Analysis data

Image analysis method of drive recorder
IN
OUT
Correct Estimated Precision Recall FCorrect Estimated Precision Recall FPeoples People
Rate
Rate measure Peoples People
Rate
Rate measureu Try 2 methodsu Background Subtractor (KNN)

Background
Substraction
OpenPose
multi-person keypoint detection library for bodyu Using OpenPose

20
69

u Background Subtractor (KNN)

1352

1 0.650.75 0.56

0.64
0.32

19
69

8
43

0.875 0.37
0.84 0.52

u Using OpenPose

1. Detection of count target personu Calculate rectangular outline and the center of gravity

1.

Detection of count target person
u Using OpenPoseӡߦthe
B: 2018
೥ 5 ݄ 12 ೔ 09:50ʙ10:35
u Use the position• ofneck• ӡߦ C: 2018 ೥ 5 ݄ 12 ೔ 11:50ʙ12:36

前後フレーム間の同一人物探索ー·ͨɺͦΕͧΕͷӡߦͷ֤ఀཹॴͰͷ৐߱٬਺Λද 1 ʹ

Future Workࣔ͢ɻ͜ΕΒͷө૾Λ‫ʹݩ‬ఏҊγεςϜͰਪఆਓ਺Λө૾

点!" とユークリッド距離が1番近い点#$ を選択্ʹඳը͠ɺਪఆਓ਺Λਫ਼౓͕ਖ਼͍͔͠Λ໨ࢹͰ֬ೝΛ点#$ が点!" 点の属する長方形輪郭の範囲内
Last frame
Current frame

者運行管理者

ߦͬͨɻBS adapted
frame u(b)Using(a) લϑϨʔϜ(b) ‫ݱ‬ϑϨʔϜ(a) લϑϨʔϜ(b) ‫ݱ‬ϑϨʔϜ(a) લϑϨʔϜ‫ݱ‬ϑϨʔϜother sensor data
→点!" と点#は同一人物の重心点とするਤ
6:എ‫ࠩܠ‬෼๏Λద༻ͨ͠ϑϨʔϜྫ
ਤ
3:
ϑϨʔϜྫ
ਤ
3:
ϑϨʔϜྫ
4.2 ධՁ݁Ռ
$2. Identical
people search between last & current frames
u There is a correlation
the door opening time for3. Counting#$ਪఆਓ਺ɺద߹཰ɺ࠶‫཰ݱ‬ɺF ஋Λද 2 ʹࣔ͢ɻશମͷ܏
passenger get on/off
the bus and the number of޲ͱͯ͠࠶‫཰ݱ‬͸ߴΊʹͰ͍ͯΔ͕ɺద߹཰͕௿͘ͳͬͯ
passengers. ͠·͍ͬͯΔɻ͜ͷ‫ݪ‬Ҽͱͯ͠ɺϘʔμʔϥΠϯ෇ۙͰཱ!"

ͪࢭ·Δ৐٬͕ଟ͔ͬͨͨΊͰ͋Δɻਤ 10 ͷΑ͏ʹ൶͔Βӡ௞ശͷ‫͕ۙ͘཭ڑ‬ɺ݁Ռͱͯ͠ϘʔμʔϥΠϯͱӡ௞ശͷ‫ͨͨͬ·ͯͬ͠ͳ͕ۙ͘཭ڑ‬Ίɺ1 ਓʹରͯ͠ෳ਺ճ
Χ΢ϯτͯ͠͠·ͬͯద߹཰͕௿͘ͳͬͨͱߟ͑ΒΕΔɻ(a) લϑϨʔϜ(a) લϑϨʔϜʔϜͷάϑϨʔϜͷά

ʹਤ
5ͷ 5ͷ
ͨΊʹਤ

Ξϯ΅͔
΢γΞϯ΅͔

(a) લϑϨʔϜ(b) ‫ݱ‬ϑϨʔϜ(b) ‫ݱ‬ϑϨʔϜਤ 7: 2 ஋ԽϑΟϧλΛద༻ͨ͠ϑϨʔϜྫਤ 4: ਤ
άϨʔεέʔϧԽͷϑϨʔϜྫ
4: άϨʔεέʔϧԽͷϑϨʔϜྫ

2. Identical people search(b) ‫ݱ‬ϑϨʔϜ

17

Graduate School of Information Science
Nara Institute of Science and TechnologyΛߦ͏ɻ஋ԽΛߦ͏ɻ

·ͨɺӡߦ A ΑΓ΋ B ΍ C ͷํ͕ F ஋͕௿͘ͳͬͯ͠
·͏ͷ͕໨ཱͭɻ͜Ε͸೔ࣹྔ͕ؔ܎͍ͯ͠Δ͜ͱ͕෼͔ͬͨɻӡߦ B ΍ C Ͱ͸ɺόεͷ൶Λ։͚ͨͱ͖ʹࠩ͠ࠐ

3. Counting

The door opening time[second]ΉޫͷมԽΛೝࣝͯ͠͠·͏͜ͱ͕ଟ͔ͬͨɻҰํͰӡߦA ͸ேํͷ࣌ؒଳͰ͋ΔͨΊɺ೔͕ࠩ͠‫͘ͳ͘ڧ‬ɺυΞΛ෼๏Ͱಈ‫ࠩܠ‬෼๏Ͱಈ

͢ɻThe number of passengers

利用客։ดͯ͠΋ޫͷมԽͷ‫ޡ‬ೝࣝ͸গͳ͔ͬͨɻͦΕ͚ͩͰ͸

53

http://inet-lab.naist.jp/ͳ͘υϥΠϒϨίʔμͷ࢓༷ͱͯ͠ඃࣸମͷ໌Δ͞ʹΑͬͯ࿐ग़͕ࣗಈతʹมԽ͢ΔΑ͏ʹͳ͍ͬͯΔͷ΋‫ࠩޡ‬ͷ‫ݪ‬Ҽʹͳ͍ͬͯΔɻ໌Δ͕͞‫ʹܹٸ‬มԽ͢ΔͨΊɺө૾શମ

0.64
0.64

Internet Conference 2018

IDS in the CAN bus using Statistical
Analysis and Neural Networks
Araya Kibrom Desta, Ismail Arai, Kazutoshi Fujikawa
Nara Institute of Science and Technology, Inet-Lab&'(&)'

5. Future Work

+

*
,-

After we calculated Tt, the corresponding pvalue is solved , and if the p-value is less thana predefined threshold(0.26), the detector
alerts the driver to take appropriate measures.

P value

Present-day vehicles are equipped withmultiple Electronic Control Units(ECUs), eachof which communicate with one another using
a protocol called Controller Area
Network(CAN).
Even though, CAN provides its own share ofbenefits in modernizing automobiles, it also
opens a new security hole in the automotive
industry. CAN bus doesn’t use any mechanism
for encrypting or authenticating CAN packets.
Security researchers have been able to exploit
this security hole to remotely control somecritical car components. As a counter measureagainst this drawback two methodologies ofdefense, Prevention and Detection, have been
proposed. But due to the low processing
power of ECUs and a desire of unaltering the
CAN de facto standard, we are mainly focusing
on a mechanism to detect intrusions inside the
CAN bus.

$# =Threshold

True positive rate= 0.9
False Positive rate= 0.88

Time

Fig1: Blue dots are benign CAN packets and red dots
represent anomalies.

2. IDS using One Class Support Vector
Machine[2] ,we trained OCSVM against Np, μt and σ2t

2. Purpose of the Research

Each CAN packet, along side with otherinformation, has an arbitration ID and timing
information. Using this two information and thefact that CAN packets appear in the CAN bus ata fixed frequency[1], we aim to detect malicious
message sequences in a fixed time window.
Given the available information from the CAN
bus and knowledge of attack signatures, wehave evaluated some statistical methods thatcan effectively identify CAN attacks.

3. Replication of existing Researches
To evaluate the methods, we have collected 10
minutes of CAN data from a real car.
1. One Sample/Universal t-test method[2]This anomaly Detection approach works by
calculating statistical data about on going
network traffic and comparing them withhistorical values (!"#) measured during training.
In every 1 second, we collected the following
information for each arbitration ID.
ü ID: arbitration ID
ü Np : the number of packets in the flowü μt: the average time difference between
successive packets
ü σ2t: the variance of the time difference
between successive packets
ü Tt: the time difference test value

Arbitration ID 32
Arbitration ID 295

32

Arbitration ID

1728

Fig3: Packet count of all arbitration IDs in one second.

In our research we are trying to improvesome of the methodologies described here
and we will also use sequences of CAN
packet data portion to identify anomalies.
A simple strategy for general sequencelearning is to use RNN with LSTM[3].

Fig2: data view for IDs 32 and 295

The training gave us good results forboth insertion and drop attacks.
Fig5: Module in an LSTM[4]With this technology, we will predict data
frames using the trained network anddepending on how close our prediction
was with the actual received data frame,
we will determine whether a data
sequence has an anomaly or not.

True Positive rate

The main purpose of this research is to detectcyber attacks inside CAN bus by using different
statistical anomaly detection methods andLong Short Term Memory(LSTM) Recurrent
Neural Networks(RNN). We will train a neuralnetwork to predict subsequent packets, using
data from sequences of previously seen
messages on the CAN bus. The error difference
found by evaluating the actual value and thepredicted value will be used for detecting
anomalies in a sequence of CAN Packets.

Most of the methods described here mainly
focus on periodicity and timing information of
CAN packets. None of the methods used any
information from the data portion of thepackets. And we believe the optimal time thata user should be notified about an intrusion
should be in about 1 second. But, for periodic
messages which appear in the CAN bus inaverage of later than 1 second it is impossible
to notify the driver before the intrusions causemuch more damage.

Count

1. Introduction

False Positive rate
Fig3: ROC curve for arbitration IDs 32 and 295
References[1] Song, Intrusion detection system based on the analysis of timeintervals of CAN messages for in-vehicle network. International
Conference on Information Networking. Vol. 2016-March IEEE
Computer Society, 2016. pp. 63-68[2] A. Taylor, N. Japkowicz, and S. Leblanc, “Frequency-based anomaly
detection for the automotive CAN bus,” in Proc. 2015 World Congress on
Industrial Control Systems Security (WCICSS), Dec. 2015, pp. 45–49.

4. Discussion
OCSVM method is more efficient in detecting
very short insertion and drop attacks at an
acceptable rate, it is even possible to get morepractical positive false alarm rates with ahigher training data compared to t-test
method. In case of the t-test method, its
performance can be improved by selecting an
optimal threshold value. The training data weused to experiment all the methods are only
periodic CAN messages, but all theaforementioned methods fail to detect any
anomaly sent with a non-periodic arbitration
ID.

54

The advantage of using RNN over thestatistical methods is, unlike statisticalmethods RNN have a better anomaly
detection capability for a short term
anomalies. RNN will also be able to detect
anomalies arriving in the CAN bus with
non-periodic arbitration IDs.
Furthermore, We will continue to tweak
LSTM for better accuracy results and try tocontinue digging on how to use RNN for
identifying anomalies that appear during
abnormal car states, like intrusion
detection during car crashes. Intrusion
detection during this state can be moredifficult due to abrupt data packet
information changes.
References[3] F.A. Gers, J. Schmidhuber, and F. Cummins. Learning toforget: continual prediction with LSTM. Neural Computation,
12(10):2451–2471, 2000.
[4] http://colah.github.io/posts/2015-08-UnderstandingLSTMs/

Contact Information
Araya.kibrom_Desta.js3@is.naist.jp{Ismail,fujikawa}@itc.naist.jp

Internet Conference 2018

1
.A

.

@

@@
, @

A

B2

2

A

@

@
1

A

A

1

@

A A2
12

Introduction

Source code

Extract logging
functions,2

Extract log
message
Replace format
specification

*

Goal

- zlog_warn(“%s: read failed on fd %d: %s”,__func__, fd, safe_strerror(errno));- zlog_info(“%%ADJCHANGE: neighbor %s Up”,
peer->host);- %s: read failed on fd %d: %s- %ADJCHANGE: neighbor %s Up- peer->host- *UNKNOWN*: read failed on fd *DIGIT*: (error
message)- %ADJCHANGE: neighbor *HOST* Up

Application of Generated Templates
1. Log templates’ accuracy evaluation[1]a. State-of-the-art
clustering based
generation
algorithms (IPLoM[2],SHISO[3], Drain[4])Dataset- Vyatta 1.0.8 (napa): Network OS
Vyatta Kernel (kernel)
Vyatta-quagga (bgpd, ospfd, …)
Net-snmp (snmpd)
OpenSSH (sshd)
Ntp (ntpd)
Other many softwares- Actual vyatta log data of APAN-JP- May-June 2018
- 277,034 lines

b. Use our generated
templates as groundtruth

2. Transfer learning : from vyatta to junos
VyattaLog

Logging Functions

Ntp

2- Total: 189,037 templates- Automatically generate more accurate template- From open source code
- Help system operators to extract important
information

OpenSSH1- __func__, fd, safe_strerror

Link error on broad cast tree Interconnect-1T00:00:1:4

log template Link error on broad cast tree

SoftwareVyatta Kernel
Vyatta-quagga
Net-snmp2

Templates from Source Code- Syslog is widely used for system management- Huge volume to handle manually- 70,000 lines / day (SINET4)- No “normative grammar”- Difficult to extract information from logs
- Translate from raw data to Log Template- Based on Software Information- Based on Log Datalog instance

B2

Log

%ADJCHANGE: neighbor 200.0.0.1 Up
Template%ADJCHANGE: neighbor *HOST* Up

Logging Function
printk, pr_*zlog_*, plog_*
snmp_log_*, NETSNMP_LOGONCE,DEBUGMSGTL
fatal, error, sigdie, logit, verbose, debug, debug2,
debug3, pam_syslog, helper_log, authlog
msyslog

Label
Des

Des

Var Des

JUNOS%BGP-5-ADJCHANGE: neighbor
200.0.0.1 Up

Knowledge transfer
Template%BGP-5-ADJCHANGE: neighbor*HOST* Up

References[1] ,  “#."!.'($&,.+ %-)*.& ”,  
IA, p.8,
, 2018[2] Makanju, A., N. Zincir-Heywood, and E. E. Milios. "Iplom: Iterative partitioning log mining." Tech. Rep. CS2009-07 (2009).
[3] Mizutani, Masayoshi. "Incremental mining of system log format." Services Computing (SCC), 2013 IEEE
International Conference on. IEEE, 2013.
[4] He, Pinjia, et al. "Drain: An online log parsing approach with fixed depth tree." Web Services (ICWS), 2017
IEEE International Conference on. IEEE, 2017.

- Difficult to make templates from source code
completely automatically55

Internet Conference 2018

IMMGLM D.:.: @E E- MHI EH NT•
EWMSREP RVWMW WI SJ RJSU EWMSR ERH 0S•@LI ARMYIUVMW SJ @SO S

2MNM 8.C.
IMNM OE-RMGW KS NT•
EWMSREP RVWMW WI SJ RJSU EWMSR ERH 0S

RMGEWMSRV @IGLRSPSKRMGEWMSRV @IGLRSPSK

Virtual hosts for experiment use (A,E)(An experiment will be held between A and E network)

EU

Hypervisor-1• . IWLSH SJ GUIEWMRK VTIGMJMG RIW SUO US WI JSU VS I I TIUM IRW MWL YMUW EP LSVWV• @UEJJMG IRKMRIIUMRK SR
US WMRK VWU GW UI MWL HSGOIU M EKI•
BSR
US WMRK TUSYMHIV E IU GSRRIGWMSR FIW IIR WLI LSVWV

A
B

Point-to-Point network
between virtual hosts/EGOKUS RH• 4IRIUEPP E W RRIP GSRRIGWMSR FIW IIR L TIUYMVSUV MV VIH JSU RIW SUOI TIUM IRW FIW IIR YMUW EP LSVWV• @LI W RRIP GSRRIGWMSR MV WLI VLSUWIVW TEWL FIW IIR L TIUYMVSUV• S WLEW MW MV HMJJMG PW WS EOI JPI MFPI TEWL GUIEWMSR• 2 VTIGMJMG TEWL JSU
B YIUMJMGEWMSRPSRK HMVWERGI TEWL JSU MRWIU TPERIW RIW SUO I TIUM IRW

Conventional path
(Conventional Method)E

Proposed path
(Proposed Method)C

D

Hypervisor-3

Hypervisor-2

Virtual hosts for network use (B-D)(Create specific network path with traffic engineering)

USTSVEP• 0UIEWI US WIU EV WUEJJMG IRKMRIIUMRK TSMRW PMOI E LMRKI• AVI
US WMRK FIGE VI SJ WLI IEVI SJ GUIEWMRK W RRIP ERH VIPIGWMRK TEWL
• UEGWMGEPP AVI HSGOIU US WIU M EKI•
US WMRK MV SRI SJ WLI GLSMGI WS HS E WUEJJMG IRKMRIIUMRK• 5S IYIUIK IRW US WMRK S PH FI WLI ERSWLIU GERHMHEWI WS HS WLIWUEJJMG IRKMRIIUMRK

Fig 1. Proposed system
Use BGP routing at “Network containers”“Experiment containers”(2,3,… MN-1) with “vyos” image(1 and MN)
Point-to-Point network
between docker containers
with docker overlay network driver

N+1

TPI IRWEWMSR• AVI YMUW EP EGLMRIV SU TL VMGEP EGLMRIV EV HSGOIU RSHIVM I 5 TIUYMVSUV• UITEUI HSGOIU V EU GP VWIU WS HS RMJMIH GSRWUSP EPP HSGOIUGSRWEMRIUV• AVI HSGOIU EGLMRI WSSP EW HSGOIU EREKIU RSHI WS GSRWUSP
GSRWEMRIU EPP WSKIWLIU• UITEUI W TI SJ GSRWEMRIUV I TIUM IRW VI ERH RIW SUO VI• 0UIEWI TSMRW WS TSMRW RIW SUO VIK IRW FIW IIR GSRWEMRIUV MWL HSGOIUSYIUPE RIW SUO HUMYIU• 0UIEWIUS WMRK RIW SUO FIW IIR RIW SUO GSRWEMRIUV• /4 US WMRK MV VIH MWL
US WIU GSRWEMRIU M EKI Y SV SR
RIW SUO GSRWEMRIU• AVI Y SV B
LIR E IU GSRRIGWMSR FIW IIRI TIUM IRW GSRWEMRIUV MV RIIHIH• 1IWEMPIH TSPMG GSRWUSP MV EYEMPEFPI MWL /4 US WMRK• USYMHI I TIUM IRW GSRWEMRIUV MWL
US WMRK RIW SUO GSRRIGWMSR

2

N

N+2

2N

MN
dockernode-1

dockernode-2

dockernode-NFig 2. An example of network
through multiple containers

IJIUIRGI• 1SGOIU• LWWTV,HSGOIU GS• :MRMRIW• LWWT,
MRMRIW SUK• MR RE IVTEGI• LWWT,ER SUK PMR
ER TEKIV ER RE IVTEGIV LW P
• STIRVWEGO RI WUSR
• LWWTV, HSGV STIRVWEGO SUK VIG UMW K MHI RIW SUOMRK EUGLMWIGW UI LW P
• VIK IRW US WMRK• LWWT,
VIK IRW US WMRK RIW

Fig 3. Routing information
through 24 containers

EVW TUIVIRWEWMSR•IMMGLM D.:.: @uspc ab 0@ wgehkfi
vx
gehkfi op IT
7ETERIVI• LWWTV, WIVWFIH RMGW KS NT F ROEOEM THJ F ROEOEM ) ( THJ

56

el

h S@

jd

nm ry

t

p

Prepare M
docker containers
on everydocker node.
(M is number)

Internet Conference 2018

Dynamic Adaptation of Cooldown
Period for Auto Scaling of VNFs

[itemize]leftmargin=5.5mm

Mohit Kumar Singh, Gaurav Garg, Tulja Vamshi Kiran Buyakar, Venkatarami
Reddy, Antony Franklin A, and Bheemarjuna Reddy Tamma
Department of Computer Science and Engineering, IIT Hyderabad, India

I NTRODUCTION• Recently, network operators anddata centers have moved towards
Virtualization of Network Functions (VNFs).

A LGORITHMS
Monitor Loadat timeinstance i

Initialize
T=Monitoring_period(100sec),
load_threshold = 80%
load_sum, monitoring_count,ito zero and instances to 1

If
cooldown period ON

check for scaling(avg>=instances*load_threshold)

NO
NO
YES

• An Auto Scaling Entity (ASE)
monitors the load on the VNF andscale up services depending on theusage of the VNF instance.

YES

Scale up the
instancesinstances =avg/load_thresholdload_sum += load at imonitoring_count += 1
avg =load_sum/monitoring_counti += T

Reset the variables
monitoring_count=0,
load_sum=0• ASE checks the load at each timeinterval called monitoring period
and the VNF needs to wait forcooldown period to ensure thatscaling action takes place.

Ifload at i >= load_threshold

NO
YES

YES

scale down the
instances toload at i /load_threshold,i = i + T

• Existing algorithms, used by theoperators to scale the VNFs, use astatic cooldown period.
• We propose an algorithm with the
dynamic adaptation of cooldown
period for scaling of the VNF.

NO

Ifload at i <instances*load_threshold

Start thecooldown
periodi = i + Ti = i + T

Fig. 1: Existing Scaling Algorithm.
Reset monitoring_count,load_sum to zeroT = monitoring_periodi += TNO

If load at i >=instances*avg_threshold

Initialize
T=monitoring_time,
avg_threshold = 80%
load_sum,monitoring_count,monitoring time, 'i' to zero,
instances to 1

Monitor the load attime iYES

If
cooldown period is
ON

YES

NO

S IMULATION

load_sum += loat at imonitoring_count += 1
avg =load_sum/monitoring_countT = quick_monitoring_period• We generate number of HTTP re-quests based on poisson distribution model to a docker acting as an
HTTP server and then, monitoring
the CPU utilization of the docker.

NO
Ifmonitoring_count >= count_threshold andavg >= instances*avg_thresshold

YES

Scale up the instances toceil(avg/load_thresold)
and reset monitoring_count,load_sum to zeroi = i+T• We compare the performances ofboth the algorithms in terms ofnumber of instances instantiatedand number of monitoring requests made over time.

• This is because the proposed algorithm checks the utilization atshort and regular intervals. This
enables the ASE to take the decision at the time when scaling is actually needed.
• However, the proposed algorithm
induces an overhead in terms ofmonitoring requests to CPU.
• As future work, we will try to apply machine learning models to
predict the behaviour of traffic totake effective scaling decisions.

8

10
900

7

Apt number of instances

800

Existing Scaling Algorithm

8

Number of Monitoring Requests

gorithm is better than the existing
approach, where unnecessary scalings are avoided.

R ESULTS
Proposed Scaling Algorithm

700

Number of Instances• We conclude that the proposed al-i = i+T

Fig. 2: Proposed Scaling Algorithm.

CPU Load (in %)C ONCLUSIONS

Start cooldown period and reset
load_sum, monitoring_count to zeroT = quick_monitoring_period

600
500
400
300
200

6

4

2

5

4

3

2

1

100
0

Existing Scaling Algorithm
Proposed Scaling algorithm

6

0

5000

10000

15000

Time(in secs.)

20000

0

0
0

2000

4000

6000

8000

10000

12000

Time(in secs.)

14000

16000

18000

20000

0

5000

10000

15000

20000

Time(in secs.)(a) CPU util. of docker.
(c) # Monitoring requests.
(b) # Active instances.
Fig. 3: Evaluation of the proposed algorithm• Fig. 3 (a) shows the CPU load pattern on the server, on which we test the algorithms.
• Fig. 3 (b) shows how do both algorithms react to traffic. The proposed algorithm
uses less number of instances at the times when less number should have been used,and vice-versa.
• Fig. 3 (c) shows number of CPU monitoring requests made in each interval. A
total of 200 and 394 monitoring requests have been made by existing and proposed
algorithm respectively.

57

Internet Conference 2018

Collecting a great number ofactive IPv6 addresses

Yudai Aratsu1

aratsu@hongo.wide.ad.jp

Satoru Kobayashi2

Kensuke Fukuda2

sat@nii.ac.jp

hiroshi@wide.ad.jp

1:The University of Tokyo 2: National Institute of Informatics

Background••

Hiroshi Esaki1

kensuke@nii.ac.jp

Scanning whole IPv4 address takes only 45 min.
IPv6 has vast address space.
‒ to scan efficiently, active IPv6 address Hitlist is needed.

Goal•

Generating IPv6 address Hitlist by employing various methods.

How to collect a large number of active IPv6 addresses?
Methods•

Using server logs•

Crawling P2P network•

IID based classification- Web, Mail, NTP, DNS- BitTorrent, Bitcoin•

rDNS enumeration [1]Since Jun, 2018

IP addresses of server or client?

•

Result [2]•Response rate (icmp6)

Total numbers

mostly IP addressess do not respond.
(not stable?)•collecting in three countries- Japan (Tokyo), US (California), Europe(Netherland)- since Sep, 2018

result of NTP server (33 days)
country based collected address classification•

Time evolution
time evolution

Huge bias
among server location

the number of addresses
are not saturated.

[1] T. Fiebig, et al. “Something from nothing (There): Collecting global IPv6 datasets from DNS.” PAM’17[2] 新津, et al. “大規模IPv6アドレス収集手法の検討” 信学技報 2018.09[3] P. Foremski, et al. “Entropy/IP: Uncovering Structure in IPv6 Addresses” IMC’16[4] O. Gasser, et al. “Clusters in the Expanse: Understanding and Unbiasing IPv6 Hitlists” IMC’18

Discussion
How to collect more IPv6 addresses?
‒ multiple location‒ more service‒ employing machine learning [3]

How to generate “high quality” Hitlist? [4]‒ collecting stable IPv6 addresses‒ pseudo active space detection

58

Internet Conference 2018

Fast Logging in Time Series
for a Computer Security Incident Response
Motoyuki OHMORI††Center for Information Infrastructure and Multimedia, Tottori University

Abstract➢ Time Series Database (TSDB) dedicated for a computer security incident➢ Lower storage and faster search➢ Performance improvement adopting logging message normalization➢ Lock-free clustering support for scalability

Background
In order to avoid data breach, it is important to quickly and accurately
identify and confine a suspicious host when a computer security incident
happens. When an external organization alerts a suspicious host, an IP
address of the host is given. In order to identify the suspicious host,ones may then search for the IP address in related logs. Searching timeof logs is then important to shorten a delay to identify a host. To thisend, there have been already several logging systems such as fluentd,kibana, and splunk that are based upon text messages of syslog.

5.

– Logging message format are automatically normalized:
Because a logging message is usually output using printf functions,the fast logging database indexes a message format. A Logging
message is then stored as a tuple of a message format index andvariable values, i.e., variable arguments of printf.

6.

7.

Research goal is implementing a fast logging database dedicated for acomputer security incident that has:
1. Scalable logging database that requires smaller storages.
2. Fast search especially for recent logging messages.

Basic Ideas of the Fast Logging Database1.

– Recently added records are in memory, and older records in disk
When a computer security incident happens and quick response isnecessary, recent logging messages are searched in most cases. Older
messages are not required to be fast to be searched because its searchitself is enough delayed already. The fast logging database then always
keeps recent logging messages in memory as much as possible, andwrite the messages to a disk if possible or all memory is consumed.
Even after older messages are searched once, these older messages are
not in memory in order to prioritize quick response for a recent
computer security incident.

Each record always has a timestamp
Since each logging message must have a timestamp, the fast logging
database always stores the timestamp as a primary key. All records
are basically stored in ascending order of timestamps. Some records
are, however, not strictly in ascending order for lock-free operation
described later.

Overview of the Fast Logging Database
Figure 1. depicts overview of the proposed fast logging database. The fastlogging database consists of multiple database servers. All multiple
database severs has the same IP address for IP anycasting. Network
equipment or other servers (e.g., Web server, mail server and so on) send
logging messages to the fast logging database using syslog protocol. The
logging messages are then stored into one of database servers.
When one, say a CSIRT member, searches for logging messages, one sends
a search request to one of database servers. The database server receivinga request forward the request to the other database servers. All database
severs then sends responses back to one who sends a search request.

Fixed Record Length–4.

Low performance of existing logging systems based on text
message
Existing logging systems are basically based upon text messages
while logging messages of network or security equipment usually
are in pre-defined text format. The fast logging database then stores
binary values only in a record in a table, and text messages areindexed in another table.

Time Series Database (TSDB)–

3.

Recent in Memory and Old in Disk

Binary Based Key Value Store–

2.

Lock-Free Clustering Support– Lock free insertion and lookup
The fast logging database does not strictly consider an order of a logging
message. Timestamps in records are, therefore, not always inascending order. This nature may delay to finish all search in order tomake sure that the all log messages in specified timestamp in search are
examined. This nature, however, makes insertion and lookup operations
lock-free. Lock-free clustering can be then archived.

These existing logging systems are, however, not so efficient. For
example, we have experienced that fluentd caused high CPU usages andlost log messages. In addition, these existing logging systems are notdedicated for a computer security incident. They, therefore, need moretime to search for required logging messages for an incident.

Research Goals

Logging Message Normalization

Length of all records in a table is always same
In order to improve search performance, the fast logging databasehas the same record length for a table as same as recent Relational
Database Management System (RDBMS).

The Fast Logging Database

Timestamp Index–

Search

A location of a record at a timestamp is indexed
Regarding searching a record, a timestamp is usually specified for acomputer security incident. In order to improve searching speed, alocation of a record at a timestamp is indexed. Since the number oflogging messages may depend upon daytime or night, timestamp
index improves searching a record of a specified timestamp.
59

syslog

CSIRT member(searching logging messages)
Servers
network switches

Figure 1. overview of the fast logging database

Internet Conference 2018

Development of Local Cloud Environment
in the User Vicinity
Tomohiro Yoshida †1 RANDRIANARIVONY Nirinarisantatra†1
Teruaki Yokoyama †2†1 Kobe Institute of Computing Graduate School of Information Technology† 2 National Research and Development Institute of Information and Communications Technology

BackgroundAs the Internet environment has evolved, terminals connected to cloud services are increasing. This situation isfacing new challenges. In order to solve problems such as communication delay, has emerged a processing
model called edge computing.
However, in order to perform edge computing, it is required to have the server near the user. Neighboring
placement on the Internet can be achieved by installing a server at a data center or the like, while physicaledge computing outside the Internet is another way which is used as the de facto standard in construction andoperation. With the spread of IoT devices, the demand for local intra-communication that does not need toconnect to the Internet is rising, but it is time-consuming and expensive to operate such communication
network, especially the construction and the control mechanism in the physical environment.
Conventional modelThis study is focusing on the research and development ofphysical infrastructure systems for local environment

IssuesSolution
We propose a compact and inexpensive
portable cloud that can solve
the problem of physical infrastructure.
The scalability and migratory are
considered, and it's cheap andit can be exchanged easily.
More than one single board computers
are used and mounted.

There are some challenges in
Service delivery for local environment,
communication platform for IoT devices
using edge computing, and physicalinfrastructure implementation
Outdoor, mountains and fields etc...

Construction

Edge Computing

Challenges on installation / Reproducibility
OS and network equipments set-up for a specific area

Construction

Since it is possible to prepare multiple units and to unify settings, OSinstallation and network construction

Operation
Operation
Control

Mobility and failure in local.
Configuration expansion issue or hardware upgrade problem.

Operation

Flexible control mechanism tailored to the situation
Deployment of networks that can accommodate users and IoT devices.

Compact size makes it easy to handle and is ideal for moving Because it isinexpensive and easy to obtain, it can cope with trouble, etc.

ControlServices and networks according to requirements.
Systems that can be flexibly controlled and managed.

Network provision

Control

MethodConstruction
Operation

Physical environment

Consideration of scalability, mobility,
easy to replace with single board computer
Multi-equipement implementation.

1st Prototype System
Configuration(9 units)
2 small switching hubs

2nd Prototype System
Configuration(5 units)
1 small switching hubs

Operation
ControlService delivery

It provides a network for user
accommodation the nodes
operate as a single board computer

Available access points depending on the number ofconnected terminals.
can adapt according to the needs.

Internal service provisioning is implemented with Docker. It
is possible to activate required applications only,
depending on the usage / situation giving more flexibility

Future Works● Implementation of functions that enable to backup and set up of processed data in the local area using the internet or the data Storage media.
● Improvement of the system configuration from current bag to physicalAcknowledgment: A part of this research was conducted with the support of the Information Technology Promotion Agency (IPA) MITOU Project 2018. https://www.ipa.go.jp/jinzai/mitou/portal_index.html

60