dataesr/scientific-paragraphs-categorization huggingface dataset:
An additional query of the ESO HARPS archive was performed in May 2016 on a limited number of stars to retrieve the most recent observations. In addition to these archive measurements, we conducted a large follow-up programme on SOPHIE between 2015 and 2017 in the DPAC-GBOG frame, in order to obtain new observations of a selection of RV-STD candidates lacking recent measurements. The southern RV-STD candidates of the initial list  (Crifo et al. 2010 ) have also been re-observed with CORALIE since 2013. We also updated the NARVAL dataset with observations of several stars that were not part of the initial list. After we gathered all the RV measurements and properly sorted and selected them, the stars needed to be correctly identified with a rule that allowed us to recognize multiple observations of the same star under different names.
2 ). The horizontal line marks the offset of 38 m s -1 applied to the catalogue to set its ZP on the asteroid scale. Stars different from the Sun are expected to be differently affected by the gravitational and convective shifts. For instance, the gravitational redshift is expected to be low for giant stars. In order to quantify the effects of convective shifts, we checked with SOPHIE data whether stars analysed with the G2 mask and another mask (supposedly not corrected of convective shifts) exhibit significant differences in the computed RVs. We considered the 129 stars of our dataset measured with both the G2 and K5 masks. The mean difference (K5 -G2) is 34.
Then we considered the stars with a standard deviation, σ RV , lower than 100 m s -1 (the level of stability is defined by 3σ RV ). These requirements were fulfilled by 2 712 RV-STDs. A slight difference arises between the list of RV-STDs used for Gaia DR2 and the list that will be used to produce the data for DR3. One reason is that our 2017 observations on SOPHIE were not yet integrated when the RVS processing started for Gaia DR2. Some RV-STD candidates were found to exceed the 100 m s -1 limit in σ RV with the recent observations and will no longer be used for calibrations. The 26 rejected stars are flagged in the catalogue. The second reason is that the astrometry of some RV-STDs was uncertain at the beginning of the RVS processing, and they were excluded from the initial calibration that produced the RVs for Gaia DR2.
Comparison with other catalogues Each RV catalogue has its own RV ZP attached to the system and to the software used for the data processing. In particular, the use of masks and/or specific synthetic spectra of different stellar atmosphere models can be different from one system to the next, as mentioned previously. Here we compare our catalogue with other large catalogues of ground-based RVs with typical precisions of the order of or better than 1 km s -1. The results are presented in Table  3. Our results agree excellently well with the catalogues of  Nidever et al. (2002)  and  Chubak et al. (2012) , as shown also in Fig. 8. By construction, these two catalogues have the same velocity ZP, defined by observations of the day sky and the asteroid Vesta. Thus it is expected that our ZPs coincide very well, with an offset as small as 26 m s -1.
Conclusions We have presented a unique dataset considering the number of stars (4 813), the homogeneity and precision of the RV measurements, and their time baseline (median 2 307 days). The high internal precision of the catalogue is shown in the σ RV of individual stars (median 15 m s -1 ) and confirmed by comparison to the accurate RVs of  Nidever et al. (2002). Our RVs were set on a ZP defined by repeated observations of asteroids. The resulting RV scale differs by only 26 m s -1 from that of  Nidever et al. (2002). Our catalogue includes 2 712 stars RV-STDs that fulfill the RVS requirements for calibrations. Creating a list of RV-STDs was mandatory for Gaia, but we took advantage of this task to build a larger compilation of RVs that was also essential to validate the first Gaia RVs published in DR2.
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.
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.
To the best of our knowledge, our previous work  [8]  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.
B. URL-BASED NDN NAME The NDN naming policy  [9]  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"  [11] , 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  [13] , 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  [14]  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.
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.
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  [16]  to perform an information leakage attack is discussed briefly in Section III-B4.
2) Name Filter Using Isolation Forest To overcome the established limitations, we propose a name filter using an isolation forest  [6]. 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.
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  [7]. 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).
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  [23]  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.
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 forest 2. 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  [28]  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.
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.
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  [8] , 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  [8]  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]).
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.
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. [37]  show that DNS tunneling can achieve up to 110 KB/s in throughput with DNScat  [38] , which is as DNS tunneling application, but it adds huge traffic overhead. Merlo et al. [39]  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. [40]  and Qi et al. [41]  analyze character frequencies of domain names and detect DNS tunneling.