Daishi Kondo
email: daishi.kondo@loria.fr

STUDENT-MEMBER, IEEE Thomas Silverston

Vassilis Vassiliades

Hideki Tode

AND Tohru Asami

Name Filter: A Countermeasure against Information Leakage Attacks in Named Data Networking *

Keywords: Firewall, Information leakage attack, Name filter, Named data networking

Named Data Networking (NDN) has emerged as a future networking architecture having the potential to replace the Internet. In order to do so, NDN needs to cope with inherent problems of the Internet such as attacks that cause information leakage from an enterprise. Since NDN has not yet been deployed on a large scale, it is currently unknown how such attacks can occur, let alone what countermeasures can be taken against them. In this study, we first show that information leakage in NDN, can be caused by malware inside an enterprise, which uses steganography to produce malicious Interest names encoding confidential information. We investigate such attacks by utilizing a content name dataset based on uniform resource locators (URLs) collected by a web crawler. Our main contribution is a name filter based on anomaly detection that takes the dataset as input and classifies a name in the Interest as legitimate or not. Our evaluation shows that malware can exploit the path part in the URL-based NDN name to create malicious names, thus, information leakage in NDN cannot be prevented completely. However, we illustrate for the first time that our filter can dramatically choke the leakage throughput causing the malware to be 137 times less efficient at leaking information. This finding opens up an interesting avenue of research that could result in a safer future networking architecture.

I. INTRODUCTION

Currently, in the business world, information leakage through a targeted attack is an issue for many companies because it drastically impacts on their benefits and profitability [1]. For example, in 2013, the retail chain "Target" suffered from a 46% drop in profits after an attack and spent more than $100 million on a system upgrade to prevent another attack [START_REF]Understanding Targeted Attacks: The Impact of Targeted Attacks[END_REF]. In order to perform information leakage, an attacker must first send malware to an employee of the targeted company, for example, through an email that appears to be legitimate so the employee opens the email and infects their computer with the malware. The malware then creates a communication channel to the outside attacker, who can remotely control the malware and finally steal confidential information from the company. As this security threat occurs as a result of accessing suspicious media, one countermeasure would be to provide employees with cybersecurity education [START_REF] Beuran | CyTrONE: An Integrated Cybersecurity Training Framework[END_REF]. However, it is almost impossible to eliminate all human error. Thus, it is critical to investigate the prevention of information leakage after a computer has been infected by malware under the assumption that it is difficult for the computer to avoid the infection.

In recent years, information centric networking (ICN) [START_REF] Ahlgren | A Survey of Information-Centric Networking[END_REF] has been proposed as a promising future networking architecture; it performs a shift from a host-to-host to a host-tocontent communication paradigm. An ICN request packet includes a desired content name rather than an address of the content producer (in the Internet, an IP address of the VOLUME 4, 2016 content server), and the packet moves toward a nearby content producer. As for the content producer, not only the actual content publisher but also an ICN node installing cache (i.e., in-network cache) can reply to this request. This means that the architecture focuses not on where the content is but what content is being requested, and therefore ICN is more suitable for host-to-content oriented applications such as video services, which are one of the major use cases in the current Internet. As one of the ICN architectures, we adopt named data networking (NDN) [START_REF] Zhang | Named Data Networking[END_REF] since many researchers are currently paying attention to NDN and are attempting to deploy it for future Internet.

To be adopted at Internet scale, NDN must resolve inherent issues of the current Internet. Since information leakage is a big issue in the Internet and it is absolutely crucial to assess the risk before replacing the Internet with NDN completely, we investigate whether a new security threat causing the information leakage happens in NDN. Assuming that (i) a computer is located in the enterprise network that is based on an NDN architecture, (ii) the computer has been already compromised by suspicious media such as a malicious email, and (iii) the company installs a firewall connected to the NDN-based future Internet, we focus on a situation where the compromised computer (i.e., malware) attempts to send leaked data to the outside attacker.

NDN is essentially a "pull"-based architecture, and there are only two types of packets: Interest and Data, which are request and response packets, respectively. In order to retrieve content, a consumer first sends the Interest to the NDN network and then obtains the corresponding Data from the producer or the intermediate NDN node. In other words, they cannot send a Data unless they receive the Interest packet. Therefore, as one of the naive methods to mitigate information leakage through a Data, an enterprise network firewall can carefully inspect a Data to publish and produce it instead of the inside employee in the network (i.e., a whitelist). In this case, all the publicly-accessible content is on the firewall as the originals or their caches.

However, the firewall cannot manage a naming policy on the outside content and NDN forwarding nodes do not verify whether the name actually exists. This results in the risk of information leakage through an Interest since the malware can hide information such as customer information in the Interest name using steganography and send it toward the outside attacker. The malware can pretend to access outside content, so it is very difficult for the firewall to detect the information leakage attack. We argue that the information leakage attack through an Interest in NDN should be one of the essential security attacks at protocol level and it is important to develop a detection method for this attack. Against the information leakage attack through an Interest, we first propose a name filter using search engine information. When the filter receives an Interest, it performs a request to a search engine in order to check whether the Interest name is indexed by the search engine. This filter judges the indexed name as legitimate since the malicious name created by the malware is not published anywhere and therefore cannot be indexed. However, this filter cannot predict whether the unindexed names are legitimate because they are not always malicious (e.g., unindexed names such as newly generated or passwordprotected content should be legitimate). To overcome the limitation of the filter, we propose a name filter using an isolation forest [START_REF] Liu | Isolation Forest[END_REF]. An isolation forest is an unsupervised learning algorithm for anomaly detection, and therefore it is useful when there is an insufficient number malicious samples. We evaluate the performances of the proposed name filters by collecting uniform resource locators (URLs) from the data repository provided by Common Crawl [START_REF]Common Crawl[END_REF]. Our experiments show that (1) the path part is useful for malware to create malicious names leaking data and hide the activities, [START_REF]Understanding Targeted Attacks: The Impact of Targeted Attacks[END_REF] it is difficult to completely prevent information leakage even in NDN, and (3) the filters can dramatically choke the information leakage throughput and make malware send 137 times more Interest packets to leak information than when filters are not used.

To the best of our knowledge, our previous work [START_REF] Kondo | Risk Analysis of Information-Leakage through Interest Packets in NDN[END_REF] was the first to perform risk analysis on information leakage attacks through an Interest, and this paper is an extended version. We extend the previous work with the following contributions:

• investigating vulnerability of available elements other than a name in an Interest to perform information leakage, • adopting a different algorithm (i.e., isolation forest) to build a name filter using name datasets, • preparing larger name datasets and analyzing them deeply, and • proposing and evaluating different ways to create malicious names -one of which can bypass the name filter more efficiently and achieve higher information leakage throughput.

The remainder of this paper is organized as follows. Section II describes an overview of NDN and explains a URL-based NDN name under the assumptions made in this paper. Section III explains information leakage attacks in NDN. Against the attack, Section IV proposes a name filter using search engine information and using an isolation forest. Also, a simple name filter against information leakage attacks through a Data is proposed. Section V describes the NDN name dataset corresponding to the collected URL dataset and its statistics. Using the dataset, Section VI evaluates the proposed name filters. Section VII discusses our results, and Section VIII presents related works. Finally, Section IX concludes the paper and proposes future research directions.

II. OVERVIEW OF NDN AND URL-BASED NDN NAME

In this section, we present an overview of NDN [START_REF] Zhang | Named Data Networking[END_REF], and then we define a URL-based NDN name, which we adopt in this study.

A. OVERVIEW OF NDN

An NDN node consists of three components: a forwarding information base (FIB), pending Interest table (PIT), and content store (CS). The FIB has routing information to forward Interests. PIT keeps all pending Interests and the arrival interfaces of the Interests into entries, and each entry is removed when the matching Data is received or a timeout occurs. The CS is used for caching Data packets with the caching replacement policy. When a producer publishes content, the producer must first advertise the name prefix (e.g., /DOCTOR/pub) for name routing to the NDN network. Then, in order to retrieve content, a consumer specifies the desired content name, including the producer's name prefix (e.g., /DOCTOR/pub/video), in the Interest and sends it to the NDN network. The corresponding Data can be returned from the content producer or the intermediate NDN node with the cached Data. After receiving the Data and the content producer's signature, the consumer verifies the signature.

B. URL-BASED NDN NAME

The NDN naming policy [START_REF]NDN Packet Format Specification[END_REF] refers to a uniform resource identifier (URI) defined by RFC 3986 [10], which means that the NDN name has hierarchical structure. The naming policy specifies ndn in the <scheme> part but ignores the <authority> part. In order to request a specific Data, the NDN name in the Interest may include the SHA-256 digest of the entire corresponding Data packet as the last name component, but the full name of every Data must include the digest. Moreover, according to "NDN Technical Memo: Naming Conventions" [START_REF]NDN Technical Memo: Naming Conventions[END_REF], the name can carry the segmenting, versioning, time stamping, and sequencing.

The URL in the Internet is similar to the name in NDN. RFC 1808 [12] defines a URL as <scheme>:// <net_loc>/<path>;<params>?<query>#<fragment> and the <net_loc> part indicates a host generating the URL (e.g., a fully qualified domain name (FQDN)). A user or an organization who owns this host creates URLs by following its own naming policy, and URLs must be unique. According to a report from Google [START_REF]We knew the web was big[END_REF], in 2008 there were one trillion unique URLs on the Internet, so we believe that people are accustomed to current URLs.

Considering the high affinity between many already published URLs and people who are familiar with them, we believe it is highly likely that NDN naming policy will become the natural evolution from the current URL naming policy. Schnurrenberger [START_REF] Schnurrenberger | Comparing Apples to Apples in ICN[END_REF] has also discussed content names based on URL datasets. Moreover, in the case that the NDN naming policy is extended from the current URL naming policy, it would be very easy to translate the current numerous content names distributed in the Internet to the corresponding NDN names. Thus, we predict that the naming policy of NDN will be based on that of the URL.

We adopt the NDN naming policy, except for in the <authority> part. As mentioned previously, in the NDN naming policy, the <authority> part, which corresponds to the <net_loc> part in RFC 1808, is ignored. However, we consider that an authority described in the <net_loc> part can define the name uniquely, which means that the authority should not be ignored. So this idea is different from the NDN naming policy. Fig. 1 shows the URL-based NDN name we adopt in this paper. The <path> part is constructed from several name components. We omit the <params> part because this part is an option in file transfer protocol (FTP).

III. INFORMATION LEAKAGE ATTACK IN NDN

This section first introduces an information leakage attack through a Data and then one through an Interest. Moreover, as for the information leakage attack through an Interest, this section shows a more sophisticated attack to exploit an Interest name rather than simply adding leaked data into a name; this involves generating a steganography-embedded Interest name, which looks like a legitimate name at first glance, but is in fact a malicious one to leak data.

A. INFORMATION LEAKAGE ATTACK THROUGH DATA

After collecting confidential information from an enterprise network, malware can create Data packets of the information and associate them with the names that the outside attacker knows. In this case, in order for the attacker to retrieve the Data packets using the corresponding Interests, the name prefix used in the names must be routable from the attacker to the malware. For example, in Fig. 2 it is assumed that the two name prefixes "/DOCTOR/priv" and "/DOCTOR/pub", which are created by the enterprise, are utilized to share the private and the public content, respectively. When employees perform private content sharing between them inside the enterprise network, the name prefix "/DOCTOR/priv" should be used. If an Interest with the name prefix is sent to the enterprise network from the outside network, based on the name prefix "/DOCTOR/priv", the firewall drops the Interest (i.e., a blacklist). The name prefix "/DOCTOR/pub" is used to publish the public content such as a web page, but the malware can also exploit the name prefix for information leakage as follows. In advance, the attacker and the malware share the same name components, which should be appended to the name prefix "/DOCTOR/pub", and then the attacker attempts to retrieve the Data created by the malware, which should be named "/DOCTOR/pub/(the shared name components)", using the corresponding Interest. Goergen et al. [START_REF] Goergen | A Semantic Firewall for Content-Centric Networking[END_REF] propose a firewall to prevent some types of content (such as .doc and .pdf documents) from being shared externally. However, they do not discuss an attack caused by malware at all, so their firewall is not sufficient to protect against a more sophisticated attack.

B. INFORMATION LEAKAGE ATTACK THROUGH INTEREST

Assuming that an attacker's name prefix is routable from the malware, by hiding (or simply adding) leaked data into Interests and sending them out from the enterprise network, the malware can leak the confidential information to the attacker. In particular, when the malware exploits the content names in the Interests to hide the data, it is very difficult for the company firewall to detect the information leakage since the Interests seem to attempt to retrieve an outside producer's Data packets associated with the names. This paper focuses only on information leakage attacks through an Interest name. Exploitation of the other available elements in the Interest such as Nonce [START_REF]NDN Packet Format Specification 0.3 documentation[END_REF] to perform an information leakage attack is discussed briefly in Section III-B4. There are two possible methods for performing an information leakage attack through an Interest: the (one-way Interest method shown in Fig. 3) and the (Interest/Data method, which exploits an Interest with the corresponding Data, shown in Fig. 4). The features of these methods are summarized in Table 1.

As for the one-way Interest method, the malware transmits the leaked data from the enterprise network by sending the malicious Interests to the attacker. The malware must know the name prefixes toward the compromised NDN nodes (e.g., Wi-Fi AP installed by the attacker) in order to forward the Interests to the attacker. In this method, the attacker does not reply to the malware with any Data packets, so the attacker cannot have fine-tuned control of the malware. Therefore, in the case that some Interests have been lost, the attacker cannot request a retransmission of the missing information. This can happen when the firewall drops the Interests or the PIT is overflowed. In order to deal with the dropped Interests, the attacker may use erasure coding such as LT codes [START_REF] Luby | LT Codes[END_REF] and Raptor codes [START_REF] Shokrollahi | Raptor Codes[END_REF]. Although this method is not the most efficient to leak information, the main advantage of it is the preservation of attacker anonymity since the attacker only receives malicious Interests and does not reply to them with any Data packets, which include the attacker's signature.

As for the Interest/Data method, assuming that the attacker's name prefix is routable from the malware, the attacker explicitly controls the malware by utilizing Interest and Data packets. Thus, the attacker can communicate with the malware. In the case of a packet drop, the attacker can request the retransmissions of the missing Interest packets by exploiting the Data packets, so there is no need to utilize erasure coding. This method is more efficient than the oneway Interest method, but once the attack is detected, it is possible for the attacker to be tracked as the attacker's signature has been included in the Data packets. The attacker, however, can control bots remotely and avoid being tracked.

Hereafter, in order to assess the risk of information leakage, we focus on the Interest/Data method since it is more efficient than the one-way Interest method.

2) Information Leakage Attack through Steganography-Embedded Interest Name

Generating a steganography-embedded Interest name to act as a legitimate one (in fact, a malicious one to leak data) should be a more sophisticated attack to exploit an Interest name than simply adding leaked data into a name. As a similar use case of steganography, Mason et al. [START_REF] Mason | English Shellcode[END_REF] propose English Shellcode to encrypt and hide information, which transforms the Shellcode to be similar to English prose. To create a steganography-embedded Interest name, as shown in Fig. 5, the attacker and the malware must share the same table for steganography, which includes each token (strings) and the corresponding digits. Note that in order to describe how to generate and utilize the steganography embedded Interest name, Fig. 5 adopts the Interest/Data method, but the description is also available in the one-way Interest method.

Assuming that the malware knows the attacker's name prefix "/attacker" and the name prefix is routable from the malware, the malware converts the leaked data 1010110001000011 to the Interest name "/attacker/apple/banana" using the table of steganography. After the malware sends the Interest along with the name to leak data, the attacker decrypts the name using the shared Fig. 6 illustrates a general framework for transmitting leaked data from malware to the attacker. First, the malware compresses collected data to a format such as zip. For the one-way Interest method, the malware further encodes the compressed data with erasure encoding. To bypass a firewall and perform information leakage through an Interest name, the malware further encodes the output data with token encoding for steganography. Then, it creates and adds a malicious name to leak the data into an Interest.

3) Propterties of Malware Generating Malicious NDN Names

When malware creates a malicious name to leak data, there is a naive idea to ameliorate the information leakage throughput: adding the data into the name as much as possible. However, the properties of the generated name may not be similar to those of a legitimate name. For example, when the leaked data is composed of hexadecimal digits, the name, which includes as much leaked data as possible, may be much longer than the legitimate name and the frequencies of letters and the other printable characters in the malicious name could be different from the ones in the legitimate name. Therefore, it is potentially easy to detect the name as malicious.

As discussed in Section III-B2, malware can create a steganography-embedded Interest name as a more sophisticated attack. In this attack, each token corresponds to the digits, and after the attacker gathers several tokens from the malware, they can be decoded and then become the leaked data. Thus, to improve the throughput, it is essential to add as many tokens into the name as possible. To do so, the malware can exploit the path and the query in the name shown in Fig. 1. As for the fragment, in the Internet, the fragment is resolved by a browser and is not sent to the server by the browser [START_REF]URL Fragments and Redirects[END_REF], so the fragment cannot be used to add the tokens. When adding the tokens, the malware must concatenate them with delimiters in order to allow the attacker to decrypt the steganography-embedded Interest name safely (e.g., assuming that "/attacker.com/aaa" is a steganography-embedded Interest name and the token table includes "a", "aa", and "aaa", the leaked data cannot be decrypted uniquely). As for the delimiters between the tokens, we use a slash character ("/") in the path and equals and ampersand characters ("=", "&") in the query. Since the tokens are used, the frequencies of letters and the other printable characters in the path and the query of the created name may follow the ones of a language used in the tokens (e.g., English).

A naive information leakage throughput improvement method by malware will adopt four properties, as shown in Table 2. By adding as many tokens into the name as possible, the number of "/" in the path and "=" in the query increases (Property 1), and therefore the lengths of the path and query become large (Property 2). In addition, to improve the throughput, the length of token, which corresponds to the leaked data, should be small (Property 3), and by exploiting the tokens, the frequencies of letters and the other printable characters in path and query follow the ones of a language used in the tokens (Property 4). The number of equals characters is related to the number of ampersand ones since they are used to construct and concatenate key-value pairs (e.g., key1=value1&key2=value2), and therefore we do not consider the number of ampersand characters as one of the Properties.

TABLE 2: Properties of malware generating steganography-embedded Interest name

Property 1 The number of "/" in the path and "=" in the query will be large. Property 2 The length of path and query will be large. Property 3 The length of the token will be small.

Property 4

The frequencies of letters and the other printable characters in the path and query will follow ones of a language used in the tokens.

VOLUME 4, 2016

4) Vulnerability of the Other Available Elements in Interest

In the current specification of an Interest [START_REF]NDN Packet Format Specification 0.3 documentation[END_REF], available elements other than a name are CanBePrefix, MustBeFresh, ForwardingHint, Nonce, InterestLifetime, HopLimit, and Parameters. All elements except the name are optional, but as for the Nonce, which is used to detect looping Interests, it is required when an Interest is forwarded over the network links. Thus, we assume that for malware to send malicious Interests to the attacker, the malware must create them with at least a name and a Nonce.

In the elements, CanBePrefix and MustBeFresh cannot have a value. The InterestLifetime and the HopLimit can include only a non-negative integer and a 1-byte unsigned integer as a value, respectively; this restriction makes it hard for the malware to utilize these elements to hide the data. On the other hand, the name, ForwardingHint, Nonce, and Parameters can be exploited to perform an information leakage attack through an Interest since they are of variable length, except for the Nonce, which is a randomly-generated 4 byte string. However, other than the name and the Nonce, these are optional, as mentioned previously. Therefore, we do not take the ForwardingHint and the Parameters into account to perform an information leakage attack through an Interest.

In this paper, as for the Nonce, we utilize it to express a sequence number that is needed for a retransmission of some missing Interests in the Interest/Data method. Essentially, the Nonce should be randomly generated, so the malware and the attacker must produce random numbers corresponding to the sequential numbers and share them in advance. Otherwise, their malicious activity may be detected because of the Nonce, which is a sequential number. As mentioned in Section II-B, the name may include the SHA-256 digest of the corresponding entire Data packet as the last name component, segmenting, versioning, time stamping, and sequencing, which are all optional. The size of the SHA-256 digest is 32 bytes, and therefore it could be useful to leak the data. However, in the Interest/Data method, after receiving the SHA-256 digest from the malware, the attacker must create and send the Data whose SHA-256 digest corresponds to the digest appended in the Interest. To generate the Data, the attacker must break the second pre-image resistance property of the SHA-256, so it should be extremely difficult to produce the corresponding Data. Thus, the SHA-256 digest cannot be used to leak the data. As for the segmenting, versioning, time stamping, and sequencing, similarly to InterestLifetime and HopLimit, they have a restriction (e.g., a sequential number), and therefore they are not useful for the attack.

Hereafter, we assume that a malicious Interest is composed of a name and a Nonce, and the name does not include the SHA-256 digest, segmenting, versioning, time stamping, or sequencing.

IV. NAME FILTER

We propose several NDN name filters against an information leakage attack through a Data and through an Interest, as introduced in Section III. The proposed name filters are installed in the enterprise firewall.

A. NAME FILTER AGAINST INFORMATION LEAKAGE ATTACK THROUGH DATA

NDN is a "pull"-based architecture, so a producer cannot send the Data unless they receive the corresponding Interest from the consumer. Thus, although malware sends the Data toward the firewall before receiving the corresponding Interest, the firewall cannot forward it to the outside network since there is no PIT entry for the Data. Thanks to this big advantage in NDN, an information leakage attack through a Data can be prevented easily by making a name filter based on a whitelist. When the firewall builds the name filter, it must follow the policies below.

• Policy 1: The firewall must carefully inspect content and determine whether it can be published to the outside network.

• Policy 2: The firewall must accept only Interests including whitelisted names from the outside network, otherwise it must drop the other Interests from the outside network. • Policy 3: The firewall must publish all the content accepted to be public to the outside network instead of the inside employees. In this case, all the publicly accessible content is on the firewall, and therefore when employees attempt to publish content to the outside network, they must ask the firewall beforehand. Once the firewall follows these policies and creates the whitelist-based name filter, the name filter can eliminate the information leakage attack through a Data.

B. NAME FILTER AGAINST INFORMATION LEAKAGE ATTACK THROUGH INTEREST

Considering regular employee behavior to access outside content from the enterprise network, we first make the below assumptions.

• An employee accesses an outside content name via a search engine. • The employee also contacts an outside content name, which is not indexed by the search engine, directly (e.g., password-protected content).

• By managing a content access policy, the firewall can prohibit access to unwanted content names and also explicitly define a whitelist with names that can be accessed.

1) Name Filter Using Search Engine Information

Assuming that search engines will still exist even in future Internet, the search engine may serve to detect a legitimate name since a malicious name to leak the information from the enterprise network is not indexed by the search engine (the malicious name is created by malware, and therefore the name is not published anywhere). Thus, we propose a name filter using search engine information. When the filter receives an Interest, it performs a request to a search engine to determine whether the Interest name is indexed by the search engine. If the name is found by the search engine, the filter considers the Interest as legitimate. It is simple to implement this filter, but, as will be explained next, there is a limitation in terms of today's Internet use.

According to [START_REF] Hawkins | Under The Ocean of the Internet -The Deep Web[END_REF], search engines index only 4% of all content (referred to as Surface Web), and the remaining 96% are not indexed (referred to as Deep Web). In addition, the number of Internet users using search engines has decreased from 55% in 2014 to only 49% in 2015 [START_REF]Google's search business might not be as water-tight as people think it is[END_REF]. One of the factors contributing to this decrease is the mobile era. Since it is difficult for users to search content with a small-size mobile screen, they prefer accessing content via other methods such as social networks. However, from an enterprise perspective, it is usually prohibited for employees, who work with company-supplied personal computers, to use social networks in order to increase labor productivity and prevent information leakage. Following these conventions, the firewall in an enterprise must define a content access policy to allow employees to access outside content using a search engine or an authorized link toward the content.

As most content comes from the Deep Web, much of it is still accessible by employees. For example, accessing content that is unreachable from a search engine, such as newly generated or password-protected content, should be legitimate behavior. Therefore, a naive name filter using search engine information will not be accurate enough to determine whether a name is legitimate. Indeed, this filter cannot be aware of most content names that are not indexed. Thus, there is a need to add further information to improve the efficiency of the name filter.

2) Name Filter Using Isolation Forest

To overcome the established limitations, we propose a name filter using an isolation forest [START_REF] Liu | Isolation Forest[END_REF]. The isolation forest is an unsupervised learning algorithm for anomaly detection, and therefore it is useful in the case that there are too few malicious samples. Regarding NDN architecture, as it has not been deployed yet, there is neither a legitimate NDN name dataset nor a malicious one available. Thus, assuming that an NDN name will be based on URL as stated in Section II-B and that the legitimate NDN name dataset is derived from the URL dataset, we extract 122 features from each of the NDN names and build the filter (see Table 3). We also extract the frequencies of characters in the NDN name, and for this, we use the function F , which is defined below.

Let S be the set of all printable characters according to RFC 3986 [10]. Let L ⊂ S be the set of letters (i.e., a . . . z and A . . . Z), and let C = S \ L be the set of the other printable characters that are not letters (i.e., 0123456789~!@#$%&*()-_=+;:',./?[]). We use N to denote the set of all possible NDN names constructed with characters in S.

We define the function

F (•, •) : N × S → R, F (n, c) = # of occurrences of c in n size of n ,
which takes an NDN name n and a character c as input from N and S, respectively, and returns the frequency of c in n.

V. NDN NAME DATASET AND ITS STATISTICS

This section presents the NDN name dataset derived from the URL dataset and describes the statistics of the dataset.

A. NDN NAME DATASET

In order to infer properties of names commonly used in the Internet, we collect URLs from a data repository provided by Common Crawl [START_REF]Common Crawl[END_REF]. At first, we obtain the crawl archive for February 2016, which holds more than 1.73 billion URLs, and we extract unique URLs belonging to eight top-level domains (TLDs): "com", "net", "org" and "info", which are generic top-level domains (gTLDs), and "jp", "fr", "uk", and "de", which are country code top-level domains (ccTLDs). In this dataset, the number of URLs varies greatly for each TLD (millions to billions), and therefore, in order to obtain the same number of URLs for each TLD, we extract two million URLs for each TLD randomly. In other words, we use 16 million URLs.

Then, assuming that a protector and an attacker collect a name dataset from their own crawlers independently and these two obtained datasets have no overlapping FQDNs, we divide the dataset, which includes 16 million URLs, into two datasets that include randomly chosen unique FQDNs: one for the protector to make a name filter (see Section VI-A1) and the other for the attacker to create a malicious name (see Section VI-A2).

Table 4 summarizes the name datasets for the protector and for the attacker. Fig. 7 shows FQDN ranking versus the number of names for each dataset. As for the definition of the FQDN ranking, an FQDN is ranked by the number of unique names it holds in each TLD dataset. Fig. 7 indicates that, despite having no overlap, the protector and the attacker's datasets have a similar relationship between FQDN ranking and the number of names.

B. STATISTICS

We analyze nine name attributes in each of the datasets: 1.

(the number of slash characters ("/") in the path), 2.

(the number of equal characters ("=") in the query), 3.

(the length of the path), 4.

(the length of the name component), 5.

(the length of the query), 6.

(average frequencies of letters in the path), 7.

(average frequencies of the other printable characters in the path), 8.

(average frequencies of letters in the query), and 9.

(average frequencies of the other printable characters in the query).

For some names, no name component exists because some default pages such as index.html are often omitted (e.g., http://www.doctor-project.org/). In such a case, we set the length of the name component to zero. To obtain the average frequencies of letters and the other printable characters in the path and query, we first calculate their frequencies from each name, respectively. Then, we sum the obtained frequencies and average them within each TLD.

Table 5 shows the computed 90 th , 95 th , and 99 th percentiles of attribute 1 to 5 for each TLD. After summing each percentile for eight TLDs, we divide the sum by eight to obtain the average (i.e., "overall"). The percentiles of these attributes from each TLD in the protector and attacker's name dataset are similar. Also, the percentiles of these attributes in the protector's name dataset are similar to the ones in the attacker's name dataset. The cumulative distribution function (CDF) of each attribute is given in Appendix A.

Figs. 8,9, 10, and 11 show the average frequencies of letters and the other printable characters in the path and in the query. These figures all show that the average frequencies of letters and of the other printable characters from each TLD in the protector and attacker's name datasets are similar. Moreover, by calculating the cosine similarities 1 of "average frequencies of letters and the other printable characters in the path and query" between the protector's name dataset and the attacker's one, it can be seen that the respective average frequencies resemble each other (Table 6). Specific characters such as "-", "_", ".", and "%" are used more often than the others.

As explained in the following, the properties of these attributes can be discussed by considering search engine optimization (SEO). SEO is optimization to improve the rank of a web site in search engines such as Google so it appears in the top level of retrieval results by search engines. One of the methods to improve rank is to modify the structure of the URL. The documentation on SEO provided by Google [START_REF]Search Engine Optimization (SEO) Starter Guide[END_REF] states that a URL should be composed of information that is easily understood by a crawler constructing a search engine as well as a user seeing the web site. Then, it is convenient for the crawler to obtain information easily and for the user to cite a link, and therefore this operation improves the rank. Moreover, Moz, which is an SEO company, reports policies to modify the structure of a URL [24]. These policies include "to make the URL human-readable", "to add keywords", "to shorten length", "to make URL suitable to the title of the web page", "to remove stop words such as "and", "or", and "but" while considering readability and length of the URL", "to avoid utilizing the unsafe characters written in RFC 1738 [25]", "to decrease the number of name components", "to avoid utilizing the hash value", "to use "-" or "_" to separate words", "to avoid utilizing keywords repeatedly". Therefore, current URLs possibly follow the above rules to improve their rank, and consequently SEO affects the properties of these attributes.

1 CosineSimilarity = A • B/ A B . 8 VOLUME 4, 2016

VI. EXPERIMENTS

This section evaluates the performance of the proposed NDN name filters against steganography-embedded Interest names.

A. EXPERIMENTAL SETUP

In general, security exploits can be distinguished by two different types: a1) an attacker does not know the countermeasure by the protector and a2) an attacker knows the countermeasure but not its parameters. Similarly, counter- measures can be also categorized by two different types: p1) a protector does not know the attack method and p2) a protector knows the attack method but not its parameters. We consider a scenario where the protector knows the attack method (i.e., information leakage attack through an Interest) and prepare the protection method (i.e., we consider p2). In order to study the upper limit of the information leakage throughput in the case p2, we analyze the risk of attack in the case that the attacker knows the countermeasure but not its parameters (i.e., we consider a2), and this case is beneficial to the attacker.

1) Protector

Fig. 12 demonstrates a flow to check an NDN Interest name using two name filters proposed in Section IV-B. The name should first be checked by the name filter using the search engine information, and when the name is dropped by the first filter, the name filter using the isolation forest (the second filter) inspects the name. The name filter using the search engine information is not efficient enough as malicious names are not indexed by nature. Thus, this section evaluates the sophisticated name filter using the isolation forest. The evaluation of the name filter using the search engine information is discussed in Section VII.

To build the name filter using the isolation forest, we use the legitimate NDN name dataset for the protector as the training dataset, which is summarized in Table 4. The dataset is based on eight name datasets separated by eight TLDs, and we prepare eight name filters using the isolation forest. For example, when an Interest carries a name including the "com" domain, the name should be checked by the filter derived from the "com" dataset. In addition, to utilize the isolation forest, as a parameter of the protector side, we must configure the proportion of outliers R P O in the dataset, which is one of the parameters of the isolation forest2 . We prepare six outlier proportions: 0.01, 0.05, 0.1, 0.2, 0.3, and 0.4. Since the name dataset is considered as legitimate, the outlier proportion can be the false positive rate, which is defined as the ratio of the number of legitimate names identified as malicious to the total number of legitimate names.

2) Attacker

As mentioned previously, in order to analyze the risk of an information leakage attack, we consider the case that the attacker knows the countermeasure of the protector but not its parameters, which is beneficial to the attacker. Thus, to create malicious names with steganography to leak data, we assume that the attacker builds their own isolation forest-based filter using the NDN name dataset, which is shown in Table 4, in the same way as the protector's dataset.

We prepare three PDF files (Y.4001/F.748.2, Y.4412/F.747.8, Y.4413/F.748.5) from latest ITU-T recommendations [START_REF]ITU-T[END_REF] as leaked data. These PDF files include a variety of text and figures, which are common in technological docu-ments. Specifically, in Y.4001/F.748.2, Y.4412/F.747.8, and Y.4413/F.748.5, there are 6, 4, and 9 figures and 18, 22, and 24 pages, respectively. Then, we compress and convert these files into a single ZIP file (3.4 MB). Hereafter, we consider how an attacker obtains this file.

Fig. 13 describes a flow to create malicious names with steganography to leak data following the properties summarized in Table 2. To ameliorate the information leakage throughput, as discussed in Section III-B3, an essential key is to add as many tokens into the name as possible. Thus, the main principles to create malicious names are (i)

to extract NDN names classified as the inliers by the isolation forest whose proportion of outliers is set to R A O (i.e., 0.01, 0.05, 0.1, 0.2, 0.3, or 0.4) as a parameter of the attacker side; (ii) to select one name with the maximal sum of N / and N = among inliers; (iii) to extract N / , N = , L P ath , and L Query from the name as the thresholds to create the malicious names; and (iv) to create the malicious names with steganography considering the thresholds.

Table 7 indicates the thresholds of N / , N = , L P ath , and L Query extracted from each TLD name dataset using the isolation forest. Moreover, to generate the malicious names with steganography, the attacker must prepare a table with each token and its corresponding digits. The table is configured as follows; using "/", "=", and "&" as delimiters, we collect the tokens from the path and from the query in the inliers identified by the isolation forest and assign four hexadecimal digits (i.e., two bytes of information) to each token in the table.

As for token type, our previous paper [START_REF] Kondo | Risk Analysis of Information-Leakage through Interest Packets in NDN[END_REF] utilizes the dictionary words from WordNet [START_REF] Miller | WordNet: A Lexical Database for English[END_REF] as tokens. However, in this paper, we use tokens collected from the real NDN names or the NDN names converted from the real URLs used in the current Internet. The number of tokens required is 16 4 = 65, 536, and from the attacker's NDN name dataset shown in Table 4, we extract frequently used tokens in the inliers preferentially. Occasionally, we could find some tokens whose length is large (e.g., percent-encoding [10]), and in terms of the information leakage throughput, smaller length is preferable. Thus, when there are several tokens with the same frequency of appearance in the inliers, we take them in ascending order of length and ignore those with a length greater than the 90 t h percentile of the length of name components shown in Table 5. Table 8 shows the number of tokens collected from the path and query in the inliers. As for the tokens from the path, in all cases, the number of tokens is 65,536. However, in some cases, the number of tokens from the query does not reach 65,536. In this case, each missing token is covered by the corresponding four hexadecimal digits. As a comparison to the steganographyembedded Interest name (hereafter, we call this Token), we prepare malicious names, and instead of the token collected from the real NDN names, the corresponding four hexadecimal digits are directly used as the tokens (hereafter, we call this Hex).

TLD R A O = 0.01 R A O = 0.05 R A O = 0.1 R A O = 0.2 R A O = 0.3 R A O = 0.4 N / N=
TLD R A O = 0.01 R A O = 0.05 R A O = 0.1 R A O = 0.2 R A O = 0.3 R A O = 0.
The tokens from the path and the query are inserted in the path and the query in the malicious names, respectively. In particular, in the query, we place reserved keys such as "key1" before the equals characters (e.g., key1=token1&key2=token2) to identify the order of tokens. The reason for this convention is as follows. When the malware uses the tokens as the keys and the values in the query (e.g., token1=token2&token3=token4), the protector's name filter can shuffle the order of the key-value pairs, which does not have an impact on legitimate content retrieval processes, but it is detrimental to the attacker since they cannot successfully decode the malicious names unless they decrypt the tokens in the query while considering the order of them. Finally, the features of the created malicious names should be similar to those of the name selected in the abovementioned principle (ii).

B. RESULTS

Tables 9, 10, and 11 show the performances of each of the NDN name filters (R P O = 0.01, 0.2, and 0.4) against the malicious names to leak data (R A O = 0.01, 0.05, 0.1, 0.2, 0.3, and 0.4) in terms of

• the true positive rate, which is defined as the ratio of the number of malicious names identified as malicious to the total number of generated malicious names, and • the information leakage throughput per Interest, which has unit bytes/Interest.

As an example, when a malicious name "ndn://attacker. com/token1/token2/token3?key1=token4&key2=token5" bypasses the filter successfully, the name can convey 10 bytes of leaked data to the attacker, and the information leakage throughput can be calculated by the total volume of leaked data obtained from the malicious names successfully bypassing the filter divided by the total number of malicious names created. In these tables, the averaged value marked in blue boldface indicates maximum true positive rate or minimum information leakage throughput (i.e., the best performance from the protector's point of view), while the averaged value marked in red boldface indicates minimum true positive rate or maximum information leakage throughput (i.e., the best performance from the attacker's point of view). The performances of each of the NDN name filters for R P O between 0.01 and 0.4 (i.e. 0.05, 0.1, or 0.3) show an increase in true positive rate and a decrease of information leakage throughput as R P O increases. Among them, it is interesting that the true positive rate for Token is higher than the one for Hex for the malicious names including "fr" as the bytes/Interest (see Table 11b, the AVG line with R A O = 0.3). As shown in Table 7, there are three types of malicious name: name composed of only the path, name composed of only the query, and name composed of both. According to Tables 9, 10, and 11, regardless of the type of TLD, the generated malicious names that consist of only the path can bypass the name filters more easily than the other two types of malicious name. This may indicate that, for malware, it is preferable to exploit only the path to create malicious names leaking data and to hide activities.

(b) Information leakage throughput per Interest [bytes/Interest] TLD R A O = 0.01 R A O = 0.05 R A O = 0.1 R A O = 0.2 R A O = 0.3 R A O = 0.
= 0.2) (a) True positive rate TLD R A O = 0.01 R A O = 0.05 R A O = 0.1 R A O = 0.2 R A O = 0.3 R A O = 0.
TLD R A O = 0.01 R A O = 0.05 R A O = 0.1 R A O = 0.2 R A O = 0.3 R A O = 0.
To verify the hypothesis that the path is useful for malware to circumvent an NDN name filter and send leaked data to an outside attacker, we also create malicious names exploiting only the path (see Fig. 14). Table 12 shows thresholds of N / and L P ath to create the malicious names. Tables 13,14, and 15 show the performances of each of the NDN name filters (R P O = 0.01, 0.2, 0.4) against the malicious names exploiting only the path (R A O = 0.01, 0.05, 0.1, 0.2, 0.3, 0.4) in terms of the true positive rate and the information leakage throughput per Interest. As expected, the generated malicious names can bypass the name filters, and therefore the true positive rate decreases and the information leakage throughput increases. Assuming that the protector adopts the name filter whose R P O is 0.4, the average information leakage throughput for all the domains is as high as 32.1 bytes/Interest (see Table 15b, the AVG line with R A O = 0.1). In terms of true positive rate and information leakage throughput, the above method to create malicious names using the tokens obtained from the NDN names in the real Internet is more efficient to leak data than the method proposed in [START_REF] Kondo | Risk Analysis of Information-Leakage through Interest Packets in NDN[END_REF], which uses the dictionary words from WordNet. As for the method in this paper, the frequencies of letters and the other printable characters in the path become similar to those of the inliers in the protector's name datasets. In addition, we select one name with maximal sum of N / and N = among inliers, while [START_REF] Kondo | Risk Analysis of Information-Leakage through Interest Packets in NDN[END_REF] obtains the longest name, so many more tokens can be added.

= 0.4) (a) True positive rate TLD R A O = 0.01 R A O = 0.05 R A O = 0.1 R A O = 0.2 R A O = 0.3 R A O = 0.
TLD R A O = 0.01 R A O = 0.05 R A O = 0.1 R A O = 0.2 R A O = 0.3 R A O = 0.
When the proposed filter is not used, the attacker can fill the Interest name with the leaked data in hexadecimal digits. Selecting the longest name in the attacker's name datasets, which the attacker can add 2,352 hexadecimal digits to, the information leakage throughput reaches 1.18 Kbytes/Interest, which is maximal since 1 byte of leaked data is mapped into 2 hexadecimal digits. Thus, by using the proposed filter, the malware must send 36.8 times (=1.18 K/32.1) more Interests to the attacker. Moreover, theoretically, in NDN, much longer names are acceptable. Since a Data packet must include the corresponding name in the Interest, the length of the name should be less than the maximum size of a Data packet (8800 bytes by default [29]). Thus, assuming that the maximum length name can consist of 8800 digits (i.e. The false positive rate R P O introduced in Section VI is caused by the name filter using the isolation forest. The actual false positive rate should be computed after checking Interest names with the name filter using the search engine information and the isolation forest. Thus, the actual false positive rate is R P O × R N otIndexed , where R N otIndexed is the probability that legitimate users are accessing real Deep Web content (content not indexed by the search engine). Fig. 15 shows that the actual false positive rate for each R P O depends on R N otIndexed , which will be very small if the enterprise network is properly managed. Therefore, the proposed filters can keep the false positive rate relatively low thanks to the name filer using the search engine information.

The proposed algorithms to create malicious names shown in Figs. 13 and 14 may not be optimal for increasing the information leakage throughput. These algorithms concatenate several tokens using a slash character ("/") in the path and equals and ampersand characters ("=", "&") in the query as delimiters. In the case that L P ath or L Query is relatively long, which means that there is large space to append as many tokens as possible to the path or query, by concatenating several tokens using some other delimiters such as "-" and "_" and adding the concatenated tokens to the malicious names (e.g., /apple_banana), the malware could improve the information leakage throughput. However, as introduced in Section V-B, in terms of SEO, "-" and "_" should be used to separate words, and therefore the concatenated words should become a meaningful sentence following the grammar of the relevant language (e.g., in https: //moz.com/blog/15-seo-best-practices-for-structuring-urls, 15-seo-best-practices-for-structuring-urls should be "15 seo best practices for structuring urls" so it follows English grammar). The sequence of tokens depends on the data to be leaked, and therefore, if the malware simply connects the tokens with such delimiters, the connected tokens would neither be meaningful nor follow any language's grammar. The generated awkward name could be detected as anomalous by some natural language processing (NLP) techniques [START_REF] Manning | Foundations of Statistical Natural Language Processing[END_REF]. Thus, it is extremely difficult for the malware to simply concatenate tokens using some delimiters, which means information leakage throughput is decreased.

TLD R A O = 0.01 R A O = 0.05 R A O = 0.1 R A O = 0.2 R A O = 0.3 R A O = 0.
TLD R A O = 0.01 R A O = 0.05 R A O = 0.1 R A O = 0.2 R A O = 0.3 R A O = 0.
TLD R A O = 0.01 R A O = 0.05 R A O = 0.1 R A O = 0.2 R A O = 0.3 R A O = 0.
TLD R A O = 0.01 R A O = 0.05 R A O = 0.1 R A O = 0.2 R A O = 0.3 R A O = 0.
TLD R A O = 0.01 R A O = 0.05 R A O = 0.1 R A O = 0.2 R A O = 0.3 R A O = 0.
In the Internet, in order to detect malicious URLs that induce infection by malware (i.e., drive-by download attack) or access phishing/spam webpages, some countermeasures rely on token-based filtering based on the fact that specific tokens are used in the malicious URLs ( [31]- [START_REF] Khonji | Lexical URL Analysis for Discriminating Phishing and Legitimate Websites[END_REF]). However, this type of token-based filtering is not efficient to mitigate the information leakage attack through an Interest. For example, phishing URLs must attract users using attractive tokens, such as "paypal" and "ebay", and make them click the URLs. On the other hand, since the purpose of generating the name to perform the information leakage attack is not cheating users but leaking data, the name need not include such tokens. Thus, the malware can generate the name to leak data without any restrictions and the protector cannot filter out the name using tokens.

In general, in the Internet, a host generating the URL (e.g., an FQDN) follows its own naming policy to effectively identify each Web page from the others using a small set of VOLUME 4, 2016 keywords. This may reduce the number of tokens following the name prefix. If one name prefix creates many names by appending many different types of tokens, that name prefix and the generated names may be detected as anomalous. Thus, to protect from an information leakage attack, we have to know the statistical distribution of the number of possible tokens appearing after each slash character ("/") based on the many Web pages in the Internet. Once the name prefix is blacklisted, the malware and the attacker must exploit the other name prefixes that are shared between them.

The features used for creating the name filter (Table 3) are very simple as they do not reflect any character ordering. An extension to use n-gram in the features could probably be more effective to detect Hex as anomalous. However, as for Token, the character ordering is derived from the extracted real tokens, so the above extension might be ineffective to judge Token as anomalous.

As the above discussions, the further improvement of the proposed name filter taking semantic and correlation of tokens or characters into account, needs reasonable modelling and assumptions from several other aspects, such as modelling the naming policy of malicious name for the information leakage by non-existing potential attackers. This paper, therefore, treats this kind of extensions as our future work.

As a precondition, to utilize the proposed NDN name filter, a policy to allow an enterprise firewall to inspect traffic from the employees carefully is required. For example, it is possible for a consumer to obfuscate the Interest name in some cases such as by avoiding censorship ( [34]- [START_REF] Kurihara | A Consumer-Driven Access Control Approach to Censorship Circumvention in Content-Centric Networking[END_REF]). Similar to dropping Hex, the proposed name filter would also drop such an obfuscated name even if the name is legitimate and is not exploited to perform the information leakage attack. Moreover, as for an enterprise, in terms of risk hedge, the enterprise should manage any activities of its employees in order to not only detect the malicious Interest names created by malware but also avoid incidents such as malware infection caused by, for example, a drive-by download attack and employee's leaking information to the outside intentionally.

The proposed name filters can drastically choke information leakage throughput per Interest. However, to counteract the filters, malware can send numerous Interests within a short period of time to ameliorate the speed of an attack. Moreover, the malware can exploit an Interest with an explicit payload in the name (similarly to an HTTP POST message in the Internet), which is out of scope of the name filters, and can increase information leakage throughput by adopting a longer payload. These malicious activities can be detected by a filter considering an NDN flow, which we propose as one of our future works.

VIII. RELATED WORK

An information leakage attack through an Interest in NDN imitates one through DNS tunneling in the Internet. By exploiting domain names in DNS queries and the corresponding DNS responses, an outside attacker and the malware inside an enterprise network bypass a firewall and perform tunneling of data and commands, and this threat is called DNS tunneling. Leijenhorst et al. [START_REF] Leijenhorst | On the Viability and Performance of DNS Tunneling[END_REF] show that DNS tunneling can achieve up to 110 KB/s in throughput with DNScat [START_REF] Dnscat | [END_REF], which is as DNS tunneling application, but it adds huge traffic overhead. Merlo et al. [START_REF] Merlo | A Comparative Performance Evaluation of DNS Tunneling Tools[END_REF] compare several DNS tunneling tools in terms of throughput, RTT, and overhead. In order to detect DNS tunneling, some countermeasures have been proposed. Born et al. [START_REF] Born | Detecting DNS Tunnels Using Character Frequency Analysis[END_REF] and Qi et al. [START_REF] Qi | A Bigram Based Real Time DNS Tunnel Detection Approach[END_REF] analyze character frequencies of domain names and detect DNS tunneling. Alternatively, Farnham payload analysis, but also traffic analysis such as analyzing count and frequency of queries. Ellens et al. [START_REF] Ellens | Flow-Based Detection of DNS Tunnels[END_REF] also perform traffic analysis using a flow defined in RFC 3917 [44], and they report that examples of appropriate metrics to detect the tunneling are bytes per flow or the number of flows over time. Kara et al. [45] focus on DNS TXT record and detect DNS tunneling activities. Aiello et al. [START_REF] Aiello | DNS Tunneling Detection through Statistical Fingerprints of Protocol Messages and Machine Learning[END_REF] analyze simple statistical properties, such as inter-arrival time of packets and packet size, and apply them to machine learning techniques. These countermeasures, however, are only effective to detect attacks generated by specific tools such as DNScat or some malware such as Morto worm [START_REF]Morto Worm Sets a (DNS) Record[END_REF], which means that the countermeasures cannot necessarily eliminate the threat of the attack. Xu et al. [START_REF] Xu | DNS for Massive-Scale Command and Control[END_REF] conclude that DNS-based botnet C&C channel, which is based on DNS tunneling, is "feasible, powerful, and difficult to detect and block". Thus, we argue that an information leakage attack through an Interest in NDN should be one of the essential security threats in the protocol level such as interest flooding attack [START_REF] Afanasyev | Interest Flooding Attack and Countermeasures in Named Data Networking[END_REF] and content poisoning attack [START_REF] Ghali | Needle in a Haystack: Mitigating Content Poisoning in Named-Data Networking[END_REF].

As for an Interest name, there are three types: a humanreadable name, a non-human-readable name, and a combination of the two. NDN team encourages the use of humanreadable clear-text strings [START_REF]NDN Technical Memo: Naming Conventions[END_REF]. On the other hand, in order not to use a public key for data authentication, Baugher et al. [START_REF] Baugher | Self-Verifying Names for Read-Only Named Data[END_REF] propose self-verifying names, which utilize a hash value (i.e., non-human readable) in the names obtained from Catalog. Ghali et al. [START_REF] Ghali | Network Names in Content-Centric Networking[END_REF] apply a cryptographic hash function to (usually human-readable) application-layer names in order to translate them into network-layer names, which provides some benefits for FIB, PIT, and CS. Moreover, in order to realize some cases such as evading censorship [START_REF] Dibenedetto | ANDaNA: Anonymous Named Data Networking Application[END_REF]- [START_REF] Kurihara | A Consumer-Driven Access Control Approach to Censorship Circumvention in Content-Centric Networking[END_REF], an encryption method must be applied to Interest names. However, these research works do not discuss information leakage attacks through an Interest name in NDN at all.

IX. CONCLUSION

We presented information leakage attacks through a Data and through an Interest in NDN. Particularly, we investigated such attacks through an Interest and showed two possible methods to perform the attack. Moreover, we introduced a steganography-embedded Interest name to leak information as a more sophisticated attack to exploit an Interest name than simply adding leaked information into a name. Then, as a countermeasure against the attack, we proposed a name filter using search engine information and using an isolation forest to classify a name in the Interest as legitimate or not. In order to build the filter using an isolation forest, we collected URLs from a data repository provided by Common Crawl. Our experiments show that (1) the path part in the URL-based NDN name is useful for malware to create malicious names leaking information and hide the activities; (2) it is difficult to completely prevent information leakage even in NDN; and (3) the filters can choke information leakage throughput dramatically and malware needs to send 137 times more Interest packets to leak information than when filters are not used. By using our filters, we are able to mitigate the speed of an information leakage attack by two orders of magnitude, which makes our filters very efficient to prevent information leakage in NDN.

Proposing the name filter is a first step to prevent the information leakage attack, and in order to address malware's possible counter-attacks against the name such as sending numerous Interests within a short period of time to ameliorate the speed of an attack, the next step is to introduce a flow filter.

APPENDIX A

Figs. 16, 17, 18, 19, and 20 show the cumulative distribution function (CDF) of attributes 1 to 5 for each TLD. After summing each CDF for eight TLDs, we divide the sum by eight to obtain the average CDF (i.e., "overall" in the legend). In all figures, the CDF of "overall" in the protector's name dataset is similar to that in the attacker's name dataset, while the CDF of each of the TLDs in the protector's name dataset is slightly different from that in the attacker's name dataset. [27] F. Pedregosa, et al

FIGURE 1 :

 1 FIGURE 1: URL-based NDN name.

FIGURE 3 :

 3 FIGURE 3: One-way Interest.

FIGURE 4 :

 4 FIGURE 4: Interest/Data.

FIGURE 6 :

 6 FIGURE 6: Transmission of leaked data from malware to attacker.

  Attacker's name dataset.

FIGURE 7 :

 7 FIGURE 7: FQDN ranking vs. the number of names.

  Protector's name dataset.

  0

4 FIGURE 15 :

 415 FIGURE 15:Actual false positive rate using two name filters.

  Attacker's name dataset.

FIGURE 16 :

 16 FIGURE 16: CDF of Number of slash characters in the path.

FIGURE 17 :

 17 FIGURE 17: CDF of Number of equals characters in the query.

  Attacker's name dataset.

FIGURE 18 :

 18 FIGURE 18: CDF of the length of the path.

1) Taxonomy of Information Leakage Attack through Interest

	Enterprise network
	Malware	Interest
	Firewall	(Leaked data such as
		customer information)
	NDN node
		Outside network
	Compromised
	NDN node
		Attacker

TABLE 1 :

 1 Taxonomy of information leakage attack through Interest

	Feature	One-way Interest Interest/Data
	Malware remote control	No	Yes
	Retransmission	No	Yes
	Attacker anonymity	Yes	No †
	Erasure coding	Yes	No
	PIT overflow	Yes	No
	† Yes for some cases such as exploiting bots.

  table and obtains the leaked data 1010110001000011.

		Leaked data
		Compress (zip)
	Sender (Malware)	(Erasure encoding for one-way Interest zip data
		method and) token encoding
		Interest name
		Transmit (and retransmit for Interest/Data method)
		Interest name
		Token decoding (and erasure decoding
		for one-way Interest method)
	Receiver (Attacker)	zip data
		Decompress (unzip)
		Leaked data

TABLE 3 :

 3 Features extracted from NDN name Frequency of the letter ∈ L in query (26 dimensions) F (Query, c) Frequency of the character c ∈ C in query(33 dimensions)

	Notation	Feature variable
	N /	# of "/" in path
	N =	# of "=" in query
	L P ath	Length of path
	L Query	Length of query
	F (P ath, )	Frequency of the letter ∈ L in path (26 dimensions)
	F (P ath, c)	Frequency of the character c ∈ C in path (33 dimensions)
	F (Query, )

TABLE 4 :

 4 Summary of name datasets

		Protector		Attacker
		# of FQDNs # of NDN names # of FQDNs # of NDN names
	com	100,660	986,530	100,294	1,013,470
	net	56,342	947,613	56,348	1,052,387
	org	48,538	997,139	48,382	1,002,861
	info	58,199	969,734	58,141	1,030,266
	jp	58,900	1,383,230	58,847	616,770
	fr	57,057	751,649	57,074	1,248,351
	uk	53,459	1,008,608	53,457	991,392
	de	65,109	1,091,233	65,036	908,767

TABLE 5 :

 5 Computed percentiles (a) gTLDs (com, net, org, info)

							com						net					org						info
	Attributes					Protector			Attacker		Protector			Attacker		Protector		Attacker		Protector		Attacker
					90% 95% 99% 90% 95% 99% 90% 95% 99% 90% 95% 99% 90% 95% 99% 90% 95% 99% 90% 95% 99% 90% 95% 99%
	# of "/" in path			4	5	8	4	5	8	4		5	7	4	5	7	4	6	8	4	6	8		4	5	5	3	4	5
	# of "=" in query			4	5	10	4	5	12	3		4	6	2	3	6	4	5	10	4	5	7		4	4	8	3	5	22
	Length of path			73	88	127	74	89	135	68		80	109	64	79	124	68	86	128	65	84	130		70	84	120	57	70	101
	Length of name component	26	40	69	26	41	69	25		40	71	23	35	62	19	32	66	20	32	66		25	37	64	27	39	64
	Length of query			103	134	217	105	142	209	71		87	136	75	99	161	96	134	209	90	118	205		86	130	193	63	99	222
													(b) ccTLDs (jp, fr, uk, de)
							jp							fr							uk						de
	Attributes					Protector			Attacker		Protector			Attacker		Protector		Attacker		Protector		Attacker
					90% 95% 99% 90% 95% 99% 90% 95% 99% 90% 95% 99% 90% 95% 99% 90% 95% 99% 90% 95% 99% 90% 95% 99%
	# of "/" in path			3	4	6	4	4	6	3		4	6	4	5	5	4	5	7	4	5	9		4	6	12	4	5	8
	# of "=" in query			3	3	7	3	4	6	6		7	9	13	14	14	6	6	11	9	11	13		3	4	8	5	6	11
	Length of path			112	185	190	82	99	200	89		110	115	95	106	126	80	95	126	74	88	117		73	92	121	97	108	129
	Length of name component	83	104	117	18	48	99	35		57	77	55	82	108	29	44	73	27	43	76		20	33	67	39	64	101
	Length of query			42	48	108	79	99	133	160		203	250	174	179	212	124	140	225	131	195	258		224	238	260	95	165	227
													(c) Average (overall)
																	overall
										Attributes				Protector		Attacker
														90% 95% 99% 90% 95% 99%
										# of "/" in path				4	5	7	4	5	7
										# of "=" in query			4	6	9	5	7	14
										Length of path				81	100	164	80	96	129
										Length of name component	28	50	97	30	48	91
										Length of query		112	178	238	100	144	221
	AVG F(Path, )	0.04 0.06 0.08 0.10 0.12																										com net org info jp fr uk de
		0.02
		0.00	aA	bB	cC	dD	eE	fF	gG	hH	iI	jJ	kK	lL	mM	nN	oO	pP	qQ	rR	sS	tT	uU	vV	wW	xX	yY	zZ
													(a) Protector's name dataset.
	AVG F(Path, )	0.04 0.06 0.08 0.10 0.12																										com net org info jp fr uk de
		0.02
		0.00	aA	bB	cC	dD	eE	fF	gG	hH	iI	jJ	kK	lL	mM	nN	oO	pP	qQ	rR	sS	tT	uU	vV	wW	xX	yY	zZ
													(b) Attacker's name dataset.
										FIGURE 8: Average frequencies of letters in the path.

TABLE 6 :

 6 Cosine similarities of average frequencies of letters and of the other printable characters between the protector and attackersâ Ȃ Ź name datasets

					(a) Path
	TLD	com	net	org	info	jp	fr	uk	de
	Letter 1.00 0.998 0.999 0.989 0.985 0.992 0.996 0.994
	Other 1.00 0.999 0.999 0.995 0.937 0.990 0.998 0.983
					(b) Query
	TLD	com	net	org	info	jp	fr	uk	de
	Letter 1.00 0.995 0.998 0.981 0.922 0.973 0.994 0.945
	Other 1.00 0.997 0.999 0.982 0.705 0.975 0.997 0.943

the other printable characters in the path.

	AVG F(Path, c)	0.2 0.3 0.4 0.5 0.6																															com net org info jp fr uk de
		0.1
		0.0	1	2	3	4	5	6	7	8	9	~!	@	#	$	%	&	*	(	)	-	_	=	+	;	:	'	,	.	/	?	[	]
														(b) Attacker's name dataset.
	AVG F(Query, )	0.00 0.02 0.04 0.06 0.08 0.10 0.12	bB FIGURE 9: Average frequencies of aA cC dD eE fF gG hH iI jJ kK lL	mM	nN		oO	pP	qQ	rR		sS	tT	uU	vV		wW	xX	yY		zZ com net org info jp fr uk de
														(a) Protector's name dataset.
	AVG F(Query, )	0.04 0.06 0.08 0.10 0.12																															com net org info jp fr uk de
		0.02
		0.00	aA	bB	cC	dD	eE	fF		gG	hH	iI	jJ	kK	lL	mM	nN		oO	pP	qQ	rR		sS	tT	uU	vV		wW	xX	yY		zZ
														(b) Attacker's name dataset.

FIGURE 10: Average frequencies of letters in the query.

	AVG F(Query, c)	0.2 0.3 0.4 0.5 0.6																																com net org info jp fr uk de
		0.1
		0.0	0	1	2	3	4	5	6	7	8	9	~!	@	#	$	%	&	*	(	)	-	_	=	+	;	:	'	,	.	/	?	[	]
															(a) Protector's name dataset.
	AVG F(Query, c)	0.2 0.3 0.4 0.5 0.6																																com net org info jp fr uk de
		0.1
		0.0	0	1	2	3	4	5	6	7	8	9	~!	@	#	$	%	&	*	(	)	-	_	=	+	;	:	'	,	.	/	?	[	]
															(b) Attacker's name dataset.

FIGURE 11: Average frequencies of the

other printable characters in the query.

	10	VOLUME 4, 2016

TABLE 7 :

 7 Flow to check NDN Interest name using two name filters. Thresholds of N / , N=, L P ath , and L Query to create malicious names

	VOLUME 4, 2016

  LP ath LQuery N / N= LP ath LQuery N / N= LP ath LQuery N / N= LP ath LQuery N / N= LP ath LQuery N / N= LP ath LQuery

	com	32	0	260	0 32	0	260	0 32	0	260	0 32	0	260	0 32	0	260	0 32	0	260	0
	net	38	0	216	0 38	0	216	0 38	0	216	0 38	0	216	0 38	0	216	0 21	0	222	0
	org	1	66	10	1381	1	66	10	1381	3	41	25	726	2	27	24	248	2	27	24	248	2	25	24	231
	info	3	24	26	257	3	24	26	257	3	24	26	257	2	25	26	249 17	0	107	0 17	0	107	0
	jp	2	29	27	244	2	29	27	244 27	0	214	0 21	0	112	0 21	0	112	0 21	0	112	0
	fr	1	61	1	2352	1	61	1	2352	1	61	1	2352	3	26	32	234 18	0	118	0 18	0	118	0
	uk	2	32	20	175	2	32	20	175	2	32	20	175	3	22	18	169	3	22	18	169	3	22	18	169
	de	3	25	23	237	3	25	23	237	3	25	23	237 24	0	173	0 24	0	173	0 24	0	173	0

TABLE 8 :

 8 Number of tokens collected from the path and query in inliers

TABLE 10 :

 10 Performances of NDN name filter against malicious names (R P O

TABLE 11 :

 11 Performances of NDN name filter against malicious names (R P O

  Flow to create malicious names exploiting only the path.

													4
		Hex	Token	Hex	Token	Hex	Token	Hex	Token	Hex	Token	Hex	Token
	com	19.3	51.2	19.3	51.2	19.3	51.3	19.3	50.8	19.3	49.4	19.3	46.0
	net	23.3	44.9	23.3	43.7	23.3	43.0	23.3	44.9	23.3	46.7	26.2	41.9
	org	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00
	info	3.15e-05	0.00 3.15e-05	0.00 3.15e-05	0.00	0.00	0.00 0.524	18.7 0.524	19.2
	jp	0.00	0.00	0.00	0.00	0.0673	46.3 0.246	24.2 0.246	25.0 0.246	25.6
	fr	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00 0.110	16.4
		0.00 0.00487	0.00 0.00456	0.00 0.00252	0.00 0.00473	0.00 0.0229	0.00 0.00216
	de	0.00	0.00	0.00	0.00	0.00	0.00	7.75	23.5	7.75	24.6	7.75	26.0
	AVG	5.33	12.0	5.33	11.9	5.33	17.6	6.32	17.9	6.40	22.6	6.77	22.1
						Start to create
						malicious names
					Extract NDN names classified
					as the inliers by the isolation forest
					whose outlier proportion is set to ! " #
				Select one name composed of only path
					with maximal $ / among inliers
			Extract $ / , $ & (= 0), + ,-./ , and + 01234 (= 0) from the name
				as thresholds to create malicious names
				Append the tokens to "ndn://attacker.(TLD)/"
					considering $ / and + ,-./
			No		Have all malicious names
						to leak data
						been created?
							Yes
						Finish creating
						malicious names
		FIGURE 14:

TABLE 12 :

 12 Thresholds of N / and L P ath to create malicious names exploiting only the path

  4 N / L P ath N / L P ath N / L P ath N / L P ath N / L P ath N / L P ath

	com	32	260 32	260 32	260 32	260 32	260 32	260
	net	38	216 38	216 38	216 38	216 38	216 21	222
	org	21	151 21	151 21	151 21	151 21	151 21	151
	info	17	107 17	107 17	107 17	107 17	107 17	107
	jp	27	214 27	214 27	214 21	112 21	112 21	112
	fr	18	118 18	118 18	118 18	118 18	118 18	118
	uk	24	189 24	189 24	189 24	189 24	189 24	189
	de	24	173 24	173 24	173 24	173 24	173 24	173

TABLE 13 :

 13 Performances

	of NDN name filter against malicious names exploit-
	ing only the path (R P O = 0.01)
	(a) True positive rate

TABLE 14 :

 14 Performances

	of NDN name filter against malicious names exploit-
	ing only the path (R P O = 0.2)
	(a) True positive rate

TABLE 15 :

 15 Performances

	of NDN name filter against malicious names exploit-
	ing only the path (R P O = 0.4)
	(a) True positive rate

 VOLUME 4, 2016

 VOLUME 4, 2016

 VOLUME 4, 2016

We use scikit-learn[27] with default values for the remaining parameters.

 VOLUME 4, 2016

 VOLUME 4, 2016

 VOLUME 4, 2016

"This work is supported by the DOCTOR Project and funded by the French National Research Agency (ANR-14-CE28-0001). Also, this work is partly supported by the JSPS KAKENHI grant number JP17H00734."

Start to create malicious names

Extract NDN names classified as the inliers by the isolation forest whose outlier proportion is set to ! " # Select one name with maximal sum of $ / and $ & among inliers Finish creating malicious names Extract $ / , $ & , ' ()*+ , and ' ,-./0 from the name as thresholds to create malicious names Have all malicious names to leak data been created? Append the tokens to "ndn://attacker.(TLD)/" considering $ / and ' ()*+

Append the tokens to "?" considering $ & and ' ,-./0 Yes No Append "?" to the path TLD when R A O = 0.01, 0.05, or 0.1 and R P O = 0.05 or 0.1. We discuss this exception in Appendix B.

From Tables 9a, 10a, and 11a, for all configurations of R A O , every true positive rate for Token is less than that for Hex, because by using the tokens actually obtained from the attacker's name datasets, the frequencies of letters and other printable characters in the path and query of Token become similar to those of the inliers in the protector's name datasets. Thus, a steganography-embedded Interest name can circumvent a protector more efficiently than a naive name such as one that only includes raw data. Moreover, for every configuration of R A O , the greater R P O is, the greater the true positive rate becomes; this is because by increasing R P O , the name filter is built by a name dataset that excludes more outliers, though the compensation for higher true positive rate is to obtain higher false positive rate. With a higher true positive rate, the attacker can create malicious names to bypass the filter by increasing R A O . From Tables 9b, 10b, and 11b, when the true positive rate for Hex is the same as that for Token, the information leakage throughput using Hex is larger than when using Token, since Hex does not encode the data with steganography, which causes throughput degradation in the case of Token. However, as mentioned previously, Hex can be detected as anomalous more easily than Token, so the information leakage throughput using Token becomes larger than that using Hex when R P O becomes larger. Assuming that the protector adopts the name filter whose R P O is 0.4, the average information leakage throughput for all the domains is as high as 22.6

4 Hex Token Hex Token Hex Token Hex Token Hex Token Hex Token com 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 net 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 org 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 info 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 jp 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 fr 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 uk 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 de 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 AVG 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

4 Hex Token Hex Token Hex Token Hex Token Hex Token Hex Token com

APPENDIX B

Table 16 shows the performances of the NDN name filters (R P O = 0.1) against the malicious names to leak data (R A O = 0.01, 0.05, 0.1, 0.2, 0.3, 0.4) in terms of the true positive rate and the information leakage throughput per Interest. The discussion is much the same as in Section VI-B with the exception of the case of creating malicious names including "fr" as the TLD. For these names, when R A O is set to 0.01, 0.05, or 0.1, the true positive rate for Token is higher than that for Hex. This is because the created malicious names consist of only the query (see Table 7). Figs. 9 and 11 show that the average frequency of the percentage character ("%") in the query is larger than that in the path. Thus, percent-encoding may be used more in the query than in the path. In such a case, the true positive rate for Hex may be lower than that for Token.

Hex Token

Hex Token Hex Token Hex Token Hex Token Hex Token com 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 net 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 org 0.999 0.623 0.999 0.619 1.00 0.898 1.00 0.901 1.00 0.907 1.00 0.911 info 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 0.00 0.00 0.00 0.00 jp 1.00 1.00 1.00 1.00 0.00 0.00


domain: math shs

text:
Ann O'shea

Sinead Breen

Connor Brennan

Frank Doheny

Fiona Lawless

Christine Kelly

Ciarán Mac An Bhaird

Eabhnat Seamus Mcloone

Ní Fhloinn

Caitríona Ní Shé
email: caitriona.nishe2@mail.dcu.ie

Sinead Breen

Sinéad Breen

Eabhnat Ní Fhloinn

Brien Nolan

Technology enhanced Resources for Mathematics Education (TeRMEd)

Keywords: Technology enhanced resource, formative assessment, first year mathematics, evaluation

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The aims of this project are to design and develop formative assessment resources for first year undergraduate mathematics modules and to evaluate the impact of these resources. The types of resources that have been developed to date include: targeted Khan Academy playlists and mastery challenges, a smart phone based audience response system that allows mathematical input, Moodle lessons, student generated screencasts and interactive tasks using Geogebra. The mathematical topics which are the focus of these resources were chosen based on the results of surveys of staff and students [START_REF] Ní Shé | Problematics Topics in first year[END_REF]. In this poster we will present a snapshot of the resources, the evaluation methods and initial results. Augmented reality software and/or QR Codes are used in the poster to demonstrate the resources.

Theoretical framework

The National Research Council (National Research Council, 2001, p. 116) defined mathematical proficiency as comprising of five interwoven and interdependent strands: conceptual understanding, procedural fluency, strategic competence, adaptive reasoning, and productive disposition. This description of mathematical proficiency guided our design of resources. We used the Black and Wiliam (Black & Wiliam, 1998, pp. 7-8) definition of formative assessment: 'encompassing all those activities undertaken by teachers, and/or by their students, which provide information to be used as feedback to modify the teaching and learning activities in which they are engaged' to advise our implementation of formative assessment techniques. We used technology to design and deliver the formative assessment in this project. This is not a new idea; according to the JISC report (JISC, 2010, p. 9) the benefits of using technology in assessment include allowing a greater range of types of assessments, a greater flexibility on timing and location of assessment; improved student engagement especially with interactive tasks which incorporate instant feedback, timely evidence on the effectiveness of course design and delivery.

Methodology

The resources were developed by researchers affiliated to five different higher education institutes in Ireland who lecture on first year undergraduate mathematics. The resources were trialed in the 2015/2016 academic year. According to McKnight et al. (Mc Knight,Magid,Murphy,& McKnight,Thematic Working Group 16 Proceedings of CERME10 2000, p. 10) mathematics education research is 'inquiry by carefully developed research methods' that provides evidence of the nature of teaching and learning. For the evaluation we chose to conduct student surveys, resources usage, student grades and think aloud interviews. The questionnaires, developed from similar questionnaires [START_REF] Macgeorge | Student evaluation of audience response technology in large lecture classes[END_REF][START_REF] Zaharias | Developing a Usability Evaluation Method for e-Learning Applications: Beyond Functional Usability[END_REF] contained 4 dimensions; confidence when learning mathematics; impact on engagement, impact on learning and usability of the resource.

Results, analysis and conclusions

Students were generally positive about the use of the resources, though there were differences between students' opinions on the different resources. For example students using the audience response system found that the resource encouraged them to engage more in class (over 80%) whereas only 32% of students using the interactive tasks reported accessing the extra resources when not assigned on homeworks. Based on the results of this analysis the resources are currently being modified for use in the next academic year, 2016/2017. The data from the evaluations will be further analysed to answer the research questions that we have: What are the benefits of using technology in formative assessment design? How effective are the resources in developing mathematical proficiency?

Proceedings of CERME10


text:
Elena Jedtke
email: e.jedtke@uni-muenster.de

Gilbert Greefrath

Self-assessment and achievement in mathematics education: The influence of immediate feedback included in a computer-based learning environment. Concept of a research study

Theoretical background

. Hattie and Gan (2011) for example identified feedback as one of "the top 10 influences on achievement" (Hattie & Gan 2011, p. 249). Thereby the dimension of this influence would vary depending on different kinds of feedback. Apart from this, we are interested in the influence of feedback on selfassessment as a specific component of metacognition (cf. Ibabe & Jauregizar 2010). More specific we will look at students' self-rating ability. In our study, we will focus on feedback, which is typically encountered in computer-based learning environments. Suchlike feedback concerns the right answer and, in some cases, comments on how to get to this conclusion. Beside it "help me"buttons with hints about how to proceed are added. Both the right answer and the hints can be activated by mouse click.

Research questions

1. Is students' self-assessment better if they work with a computer-based learning environment, including immediate feedback, than it is when they get the feedback outside the learning environment (research based on quadratic functions)?

2. Does a computer-based learning environment, including immediate feedback, have greater benefit on students' math achievement in comparison to their achievement when they get the feedback outside the learning environment (research based on quadratic functions)?

Proceedings of CERME10

Method

Main study (QUANT) We are currently conducting some preliminary studies, including a qualitative (pre-study I) and a quantitative part (pre-study II). The quantitative pilot study includes testing the self-assessment scales and the achievement test. Within this study, self-assessment is used in a context of self-rating the expected performance in the upcoming achievement test. The achievement test includes items about functional thinking as anchor items and items about linear functions (pretest) alternatively quadratic functions (posttest). In the qualitative pre-study, we are proving the designed computerbased learning environment about quadratic functions. Our aim is to reveal problems and misunderstandings and thus to rework and improve the learning environment.

The main study will be a quantitative research study with a quasi-experimental between-subject design. Students will work with the computer-based learning environment. The experimental group receives the learning environment including immediate feedback and hints for the tasks. The control group gets the same learning environment with absent feedback.

Instead, this group gets correctanswer-feedback in outlying paper-sheets. Students' self-assessment as well as math achievement will be measured in a pre-and posttest design. The achievement test will measure the students' prior knowledge about linear functions (pretest) and their concepts on functional thinking (pre-and posttest) as well as their increase of learning after the self-regulated learning with the different types of feedback (posttest). As further research interest, we are going to compare the self-assessment ability of both groups related to the passage of time.


text:
Thomas Janßen
email: janssent@uni-bremen.de

David Reid

Angelika Bikner-Ahsbahs

Anke Reinschlüssel

Tanja Döring

Dmitry Alexandrovsky

Rainer Malaka

Estela Vallejo

Using tangible technology to multimodally support algebra learning: The MAL project

Keywords: Algebra, learning modalities, smart objects

Scope and objective of the presented project

Based on the assumption that activity (as opposed to the passive consumption of verbal instruction) supports learning, and accompanying the rise of learning theories that take into account the bodily grounding of the brain and its development, the usage of manipulativestangible learning materials enjoys widespread trust among algebra teachers. Over the last two decades a variety of virtual adaptations of such manipulatives on personal computers and touch devices has been developed. The potential of such programs lies in the possibility to discover a range of configurations that would not be feasible in the real world, and to get automatic feedback about the correctness of the chosen manipulations. However, these qualities come at the price of abandoning the materiality of the manipulatives. The miniaturization of existing technologies and the creation of new input and output channels raise the question if and how manipulatives in mathematics education could be conceptualized as smart objects or tangiblesmanipulatives that have the ability to interact with its users. Such objects have already been designed for learning purposes in other domains [START_REF] Marshall | Do tangible interfaces enhance learning[END_REF]. For the field of school algebra, the possibilities and challenges of their implementation is to be investigated in the MAL (Multimodal Algebra Learning) project, a collaboration between mathematics education and digital media researchers, experts in data collection and evaluation, and commercial enterprises. This contribution focuses on the didactical conceptualization that underlies the work of the consortium.

Theoretical framework

Many theoretical approaches assume bodily action to be beneficial or even defining for learning processes. Bruner's well-known model proposing the distinction between enactive, iconic and symbolic action offers a starting point. Following [START_REF] Nakahara | Cultivating mathematical thinking through representation. Utilizing the representational system[END_REF], a distinction can be made at the enactive level (between hands-on manipulation and other real(istic) settings) and at the symbolic level (between natural and mathematical symbolic language). Although neither Bruner's nor Nakahara's terminology implies a strict proceeding order, the progression from concrete action with the smart objects to symbolic algebraic language follows from the pedagogical setting at hand.

Design ideas and questions for investigation

Because research regarding traditional manipulatives suggests that only prolonged engagement with such objects reliably supports learning [START_REF] Sowell | Effects of Manipulative Materials in Mathematics Instruction[END_REF], the MAL project wants to design one set of smart objects that can be used for a whole range of topics (e.g., for the generation of algebraic expression from pattern sequences, for transforming expressions, building relations, and for solving Thematic Working Group 16 Proceedings of CERME10 equations). To achieve this, we turn to algebra tiles, which are already integrated in some North American algebra textbooks (e.g., [START_REF] Dietiker | Making Connections: Foundations for Algebra[END_REF]. [START_REF] Marshall | Do tangible interfaces enhance learning[END_REF] offers a framework that allows for the systematic design analysis of tangibles in learning environments. For example, he points to possible learning benefits: the playfulness that can be designed, the potential novelty of links, enhanced accessibility, chances of collaboration, and the learning benefits that may arise from physicality itself. Furthermore, he proposes a distinction between expressive and exploratory activities, which reminds of the more algebra-related work by [START_REF] Drijvers | Algebra and technology[END_REF], who distinguish between (technological) tools for doing algebra and tools for learning algebra, with the latter being subdivided into practicing skills and developing concepts (p. 185). It seems that the existing implementations of algebra tiles are more in the expressive realm of doing algebra, as they always start with a given definition of variables as unknowns, opposed to the possible exploration of their potential in describing change. It is a central goal of the MAL project to bring these two together. In the process, the following questions can be addressed: How do the physical and technical features of the designed objects interact with the didactical goals? To what extend is the integration of many algebraic concepts into one system of smart objects helpful in creating a multi-faceted image of the role of variables in algebra? What are limitations of the smart algebra tiles that could be resolved by either returning to traditional manipulatives or going virtual?

Proceedings of CERME10

Acknowledgments

The research reported on in this document is funded by the German Federal Ministry of Education and Research in the grant program "Erfahrbares Lernen" (experienceable learning). The initial research proposal was developed by some of the authors together with Gerald Volkmann.


text:
Emma Howard
email: emma.howard@ucdconnect.ie

Maria Meehan

Andrew Parnell

Identifying the reasons behind students' engagement patterns

Keywords: Engagement patterns, blended mathematics education, college mathematics

Introduction/Literature review

Previous studies of courses with both face-to-face lectures and online lectures/videos [START_REF] Inglis | Individual differences in students' use of optional learning resources[END_REF] have identified clusters of students based on their resource engagement. They found that students who attended face-to-face lectures or the maths support centre achieved higher grades than students who predominantly used online lectures. Inglis et al. (2011, p. 490) furthermore discuss how "what remains poorly understood is the overall pattern of study choices made when students are presented with many options", and comments on how valuable research into examining student choices would be. Other studies have made suggestions as to why students might opt for a particular engagement pattern including: performance in course to date; proficiency of IT; convenience; and personality type [START_REF] Bassili | Promotion and prevention orientations in the choice to attend lectures or watch them online[END_REF]. Bassili found that both promotion and prevention factors influence students' engagement decisions. This study seeks to expand on the literature by explaining reasons behind students' choices. Subsequently, the research questions for this study are:

 Which resources do students engage with when studying the course content?

 Why do students choose to engage with these resources?

Method

This study took place in University College Dublin (UCD). Data was collected from a large first year undergraduate module, Maths for Business. This is not a traditional, blended or e-learning course. Maths for Business is a unique course in that students have a choice of whether to complete the course material through lectures, online videos or a combination of both. The e-learning segment of the course consists of 68 short videos with average length of 7.6 minutes. The module co-ordinator has chosen to offer online support for students in response to: the large class sizes; acknowledging differences in learning styles and abilities of students; and additional support needed by 'weaker' students. This form of online learning is particularly suited for procedural mathematics courses of large mixed ability cohorts. For our study, we combine quantitative and qualitative survey data to identify engagement clusters based on resource usage, and explain the reasons behind students' engagement clusters.

In order to develop a complete understanding of students' engagement, the data for this study broadly covers three areas: survey response data, background information of students, and engagement data. Students' data was linked together from each of the sections. The first stage was cluster analysis. Rather than cluster students under total videos and lectures, we decided to cluster students based on what resources they engaged with for the lecture material they covered. We developed three variables to describe this; lecture usage, video usage and overlap of resources. Subsequently, cluster analysis was performed on the three variables; lecture usage, video usage and overlap of resources using model-based clustering. Qualitative data analysis is currently being performed under the [START_REF] Braun | Using thematic analysis in psychology[END_REF] framework. Themes are considered to be semantic as students' responses are direct.

Initial results

Cluster analysis has identified four distinct clusters: high lecture usage cluster; high video usage cluster; a cluster with high lecture, high video usage and high overlap between resources; and a cluster which features both lecture usage and video usage but with little overlap. Initial qualitative analysis has suggested the high lecture usage cluster is formed by students who perceive videos as a secondary tool; they find the lecture content has more depth, and enjoy the interactive lecture environment. In comparison, the high video usage cluster is formed by students who have issues with the lecture environment, and find little if any benefit from lectures. Videos offer these students an efficient and flexible method to study. The third cluster, the cluster with high overlap, has occurred owing to weak students accessing all available resources and needing extra support. The final cluster with little overlap of resources is formed by students who have switched from lectures to videos during the semester or are avoiding a specific lecture every week owing to the inconvenience of the timetable.

Mathematical procedural courses differ in their nature and design from other disciplines. Maths for Business use of e-learning allows 'stronger' students to progress at a fast, flexible pace while supporting the 'weaker' students through providing access to multiple resources which can be repeatedly used. Students can choose their resources to suit their learning. Overall there is an opinion from students that "[online learning] works very well for maths however [students] don't know if it would work well for other modules". Understanding students' reasons for choosing their engagement pattern may help in the future design of resources, and identifying whether online resources are particularly beneficial for large mathematics classes of mixed abilities.

The poster will expand on the initial qualitative analysis of the survey responses by explaining in detail the reasons behind each engagement cluster. We would like to thank UCD IT services for providing the Virtual Learning Environment data.

Proceedings of CERME10