Présentée Par

Florent Fourcot

Frédéric Cuppens

Alexander Schill

M Gérard Memmi

Professeur M Jorge Cardoso

M Alexander Schill

M Laurent Toutain

Jorge Cardoso

Corinna

Sara

Louisa Karl

Susanne Michi

Keywords: eine große Rolle gespielt, besonders auch bei meiner Entscheidung, nach meinem Erasmusaufenthalt nach gekämpft, die durch diese Cotutelle entstanden ist, und er hat Lösungen vorgeschlagen, die für beide Universitäten akzeptabel waren. Ich war sehr froh, jedes Semester eine Einladung

The rotation of identifiers is a common security mechanism to protect telecommunication; one example is the frequency hopping in wireless communication, used against interception, radio jamming and interferences.

In this thesis, we extend this rotation concept to the Internet. We use the large IPv6 address space to build pseudo-random sequences of IPv6 addresses, known only by senders and receivers. The sequences are used to periodically generate new identifiers, each of them being ephemeral. It provides a new solution to identify a flow of data, packets not following the sequence of addresses will be rejected. We called this technique "address spreading".

Since the attackers cannot guess the next addresses, it is no longer possible to inject packets. The real IPv6 addresses are obfuscated, protecting against targeted attacks and against identification of the computer sending a flow of data. We have not modified the routing part of IPv6 addresses, so the spreading can be easily deployed on the Internet.

The "address spreading" needs a synchronization between devices, and it has to take care of latency in the network. Otherwise, the identification will reject the packets (false positive detection). We evaluate this risk with a theoretical estimation of packet loss and by running tests on the Internet. We propose a solution to provide a synchronization between devices.

Since the address spreading cannot be deployed without cooperation of end networks, we propose to use ephemeral addresses. Such addresses have a lifetime limited to the communication lifetime between two devices. The ephemeral addresses are based on a cooperation between end devices, they add a tag to each flow of packets, and an intermediate device on the path of the communication, which obfuscates the real address of data flows. The tagging is based on the Flow Label field of IPv6 packets. We propose an evaluation of the current implementations on common operating systems. We fixed on the Linux Kernel behaviours not following the current standards, and bugs on the TCP stack for flow labels. We also provide new features like reading the incoming flow labels and reflecting the flow labels on a socket.

Introduction xix

List of Figures xxiii

List of Tables xxv

1 State of the art 1 1.1 Flow management on the Internet . . . . . . . . . . . . . . . . . . . . .

Résumé Introduction

Les technologies de l'information et des communications ont une place importante dans la vie moderne. Dans ce cadre, Internet est le réseau le plus influent. Il permet des communications quasi-instantanées à travers le monde. Ce très grand réseau est utilisé pour des besoins très divers, par un grand nombre d'utilisateurs et d'applications. Malgré cette diversité des usages, toutes ces communications reposent sur un seul protocole : l'Internet Protocol (IP).

La base de ce protocole est la notion d'adresse. Les adresses IP sont des localisateurs, comme les adresses dans le réseau postal. Pour chaque communication, la première étape est de savoir où transmettre le paquet de données. Cette adresse de destination est lue quand le paquet traverse le réseau, et chaque routeur intermédiaire prendra une décision de routage à partir de cette adresse. Chaque paquet est indépendant, il n'y a pas de notion d'appel (avec réservation de ressource comme dans le réseau téléphonique historique) ou de flux de données (ce paquet est lié au paquet précédent) au niveau IP.

Mais cette notion de flux est une fonctionnalité essentielle pour proposer de la sécurité et des garanties de qualité de service, au minimum pour les protocoles de la couche transport. Une connexion TCP ne devrait pas accepter des paquets qui ne font pas partie de la communication. De nombreux pare-feu sont basés également sur cette notion de flux : un paquet non conforme aux états internes autorisés pour ce type de connexion sera rejeté.

Cette construction virtuelle des flux associe couramment les adresses IP et les identifiants de la couche transport, appelés ports pour TCP et UDP. Les adresses IP ne sont alors plus seulement utilisées comme localisateurs, mais également comme identifiants. Malheureusement, on ne peut pas faire confiance à ces identifiants. Il est très simple d'usurper une adresse IP, et donc de contourner les politiques de sécurité basées sur cet identifiant.

Dans le même temps, cette identification des flux grâce aux adresses IP est un problème pour la protection de la vie privée des utilisateurs. Tous les flux de données et toutes les activités d'un utilisateur seront envoyées avec la même adresse, le même identifiant. Quelqu'un capable d'écouter les communications pourra facilement construire un profil des activités de l'utilisateur. Même dans le cas ou le contenu des paquets est chiffré, ces adresses peuvent être utilisées comme métadonnées pour identifier qui communique avec qui.

Dans cette thèse, nous proposons tout d'abord un nouveau paradigme d'identification des flux pour Internet. Nous utilisons une nouvelle variable, le temps, pour générer des séquences d'identifiants, connus uniquement par l'émetteur et le récepteur de la communication. C'est le même principe que les identifiants à usage unique, appelés parfois tokens. Ces séquences pseudo-aléatoires sont codées directement dans les adresses IP. Comme nous ne rajoutons pas d'en-têtes, les performances du réseau ix x RÉSUMÉ sont préservées. Nous appelons cette technologie l'étalement d'adresse. Même si elle ne change pas le routage habituel, une coopération entre l'émetteur et le récepteur est nécessaire pour la déployer.

Une autre contribution de la thèse propose une aide à la protection de la vie privée des utilisateurs. Nous proposons une solution basée sur des adresses éphémères, sans besoin de coopération avec les services contactés. Nous allouons une adresse à chaque flux de données, et révoquons cette adresse aussitôt que la communication est terminée.

L'étalement d'adresse

La principale contribution de cette thèse est la proposition d'étalement d'adresse. C'est un nouveau protocole, permettant de changer les adresses utilisées par une communication. Avec cette technologie, chaque flux de données est défini par une séquence unique connue uniquement par l'émetteur et le récepteur.

Ce travail a été publié dans une conférence internationale et a gagné le prix du meilleur papier [FKC + 14]. Une version plus courte a également été publiée en français [FTC + 14].

Définition et architecture de l'étalement d'adresse

L'étalement d'adresse change un des fondamentaux d'Internet : du fait que les adresses IP sont couramment utilisées comme identifiants, le protocole IP est construit sur l'idée que les adresses sont statiques. Cette hypothèse est reprise par les protocoles de niveaux supérieurs : si un ordinateur change d'adresse IP, toutes les connexions TCP en cours seront cassées.

L'idée d'utiliser énormément d'adresses pour une communication était bien entendu non réaliste dans le monde IPv4. Les administrateurs des réseaux IPv4 avaient à gérer la rareté des identifiants. Bien avant les problèmes de la rareté des allocations, les 32 bits des adresses IPv4 ne permettaient pas de déployer ce type de technologies. Avec IPv6, les choses changent. Les adresses sont désormais codées avec sur 128 bits, et étaler les adresses devient envisageable. D'autres technologies utilisent déjà la grande diversité de ces adresses, comme par exemple les adresses cryptographiques [START_REF] Aura | Cryptographically Generated Addresses (CGA). RFC 3972[END_REF].

Un autre avantage du très grand espace d'adressage en IPv6 est la réelle séparation entre la partie concernant le routage des paquets et les identifiants d'interface. Alors que la première partie est lue et interprétée par les routeurs à la traversée le réseau, les identifiants d'interface n'ont une signification que localement, et peuvent être changés sans se soucier de problèmes de compatibilité. La taille typique de ces identifiants est de 64 bits, qui peut souvent être considérée comme un minimum pour la plupart des réseaux.

Cette thèse propose un algorithme pour initialiser chaque flux de donnée par une séquence unique d'identifiants, grâce à un secret préalablement configuré sur les terminaux. Cette séquence est envoyée dans la seconde moitié des adresses IPv6 (les identifiants d'interface), sans conséquence sur le routage. Cette séquence est alors utilisée pour identifier les flux, avec une efficacité supérieure à l'identification traditionnelle : un attaquant ne peut pas deviner la prochaine adresse utilisée. Il est donc incapable d'usurper les adresses IP, d'insérer des paquets dans les connexions établies, ou d'effectuer une attaque ciblée sur un équipement. Comme l'espace d'adressage est immense, l'espace de rotation des adresses est suffisant pour apporter un vrai gain de sécurité.

Architecture

Même si le routage n'est pas modifié, les réseaux locaux peuvent avoir des problèmes en cas d'utilisation de l'étalement d'adresse. Si des équipements n'ont pas un préfixe dédié d'adresses IPv6, le dernier routeur doit maintenir une table de relation entre les identifiants d'interfaces utilisés et les adresses MAC des équipements. Cette table de relation est nécessaire à la livraison des paquets à la bonne destination.

Sans aucune mise à jour de ce dernier routeur pour être compatible avec l'étalement d'adresse, l'utilisation de nombreuses adresses aura pour conséquences :

• d'inonder le réseau avec des paquets de découverte de voisins. Le routeur n'a pas connaissance de l'étalement d'adresse, et ne peut pas faire le lien entre la séquence d'adresse IP et l'adresse MAC statique de l'équipement ;

• de saturer la table des voisins du routeur : en changeant trop souvent d'adresse, le routeur ne pourra pas stocker toutes les correspondances entre les adresses IP et les adresses MAC ;

• introduira une latence à chaque changement d'adresse IP, le temps de la découverte de voisin.

Cette thèse propose une argumentation sur la meilleure place pour activer l'étalement. Nous proposons d'introduire un nouvel équipement sur le chemin de la communication (voir la figure 1). Nous appelons ces équipements des « étaleurs », équipements chargés de protéger les réseaux locaux grâce à l'étalement d'adresse.

Le choix d'une architecture (sécurité de bout-en-bout, l'étaleur étant l'équipement terminal) ou d'une autre (les étaleurs sont sur le chemin de la communication, avec un filtre des paquets en amont du réseau) ne change pas les algorithmes et protocoles utilisés par l'étalement d'adresse.

Absence d'en-têtes supplémentaire

Pour initialiser une connexion utilisant l'étalement d'adresse, les deux étaleurs doivent échanger des données de session pour chaque connexion. Il y a plusieurs méthodes pour cet échange. La première est d'utiliser des paquets supplémentaires, envoyés à La seconde solution est d'envoyer ces informations dans des paquets existants, par exemple en ajoutant des informations dans une extension des en-têtes IPv6. Comme ces entêtes seront ajoutées par les étaleurs, cela pourrait conduire à un problème de taille maximale de paquet. En effet, il est impossible d'ajouter cet en-tête à un paquet déjà à la taille maximale.

Nous proposons une autre approche, nos étaleurs codant les informations directement dans les adresses IPv6, sans ajout de données supplémentaires. Cela limite la quantité d'information échangeable, mais n'a aucun coût en terme de latence ou de bande passante.

Détection des paquets désynchronisés

Comme les identifiants sont dynamiques avec l'étalement d'adresse, les horloges une nouvelle variable pour l'identification de la communication. Une adresse n'est valide que pour une courte période, et un paquet retardé sera rejeté car il pourrait avoir été envoyé par un attaquant. En cas de latence naturelle dans le réseau, cela peut conduire à des faux positifs, décrits par la figure 2.

La seconde source de problème est la désynchronisation des horloges des deux étaleurs : si les horloges ne sont pas synchronisées, un paquet valide sera rejeté car il ne suivra pas correctement la séquence d'adresse. Un paquet peut ainsi arriver « trop tôt », comme le présente la figure 3. Les deux problèmes sont détaillés dans la thèse, et nous en évaluons les conséquences sur la qualité de la communication. Une étude théorique de la perte de paquet est notamment calculée pour les deux problèmes.

Évaluation de l'étalement d'adresse

Après la définition et l'évaluation théorique de l'étalement d'adresse, le protocole a été implémenté dans le noyau Linux et des tests ont été conduits sur différents réseaux réels. Nous avions deux architectures de test : une sur un réseau local (avec une très bonne connectivité et d'excellentes performances), et une à travers Internet et un tunnel 6to4 de mauvaise qualité. Nous avons comparé les résultats entre nos estimations théoriques de perte de paquet et nos expériences : les résultats sont très proches.

Dans le chapitre d'évaluation des performances, nous proposons d'ajouter des fenêtres temporelles recouvrantes pour améliorer les performances de l'étalement d'adresse. L'idée est qu'un étaleur peut à un moment donné accepter deux identifiants différents : la valeur courante, ainsi que soit la prochaine valeur la séquence, soit la précédente. Grâce à cette idée, nous pouvons obtenir une configuration parfaite permettant d'utiliser l'étalement d'adresse sans aucun faux positif (voir la figure 4).

Une autre amélioration décrite dans ce chapitre est le concept de resynchronisation des horloges, en utilisant les fenêtres temporelles recouvrantes. Comme un paquet valide arrivant « trop tôt » est une preuve de désynchronisation, l'étaleur recevant trop de paquets sur cet intervalle peut régler l'horloge interne générant la séquence des adresses. Quand le trafic est suffisant, cette solution permet une meilleure synchronisation que le protocole NTP (Network Time Protocol).

xiv

RÉSUMÉ

Masquage des adresses IPv6 grâce à des boîtiers intermédiaires

Bien qu'Internet soit construit grâce à une coopération de réseaux, la majeure partie des communications s'effectue sans coopération explicite entre les équipements terminaux. Un utilisateur accèdera à une information sans avoir contacté préalablement le propriétaire du site Web. Cette communication est rendue possible grâce à des protocoles communs entre le client et le serveur.

Cette base de protocoles communs doit être prise en compte pour déployer des solutions sur Internet : un nouveau protocole n'assurant pas la compatibilité avec l'existant ne pourra pas établir de connexions avec de nombreux serveurs. La seule façon de déployer un nouveau protocole est de convaincre le réseau destinataire de le déployer également. Ce réseau ne le fera que si il y trouve son intérêt, la plupart du temps s'il y a un gain financier attendu ou une amélioration des services.

Pour les méthodes de protections de la vie privée des utilisateurs, cette coopération ne peut pas être attendue de la majorité des fournisseurs de service. Les informations sur les utilisateurs ont une valeur, et sont le coeur du modèle économique de nombreuses entreprises. Ils ne déploieront pas un protocole empêchant le traçage des utilisateurs.

En complément de l'étalement d'adresse, nous proposons les adresses éphémères [FTK + 13], construites sur l'idée que le réseau de destination ne coopérera pas pour protéger la vie privée des utilisateurs. Le réseau distant ne déploiera pas de nouveau protocole, et notre solution doit être basée sur les protocoles existant comme IPv6 et TCP. Pour accéder aux sources d'informations, par exemple un journal en ligne, les mêmes protocoles que ceux du fournisseur de contenu doivent être utilisés.

Protection de la vie privée grâce au masquage d'adresse

Cette thèse ne fournit pas de solution complète de protection comme le réseau Tor [START_REF] Dingledine | Tor: The secondgeneration onion router[END_REF] ou le projet AN.ON [START_REF] Berthold | Web mixes: A system for anonymous and unobservable internet access[END_REF]. Notre but est de protéger les utilisateurs contre des attaquants à « agressivité modérée », comme Google et Facebook, et non pas contre une organisation comme la NSA (National Security Agency) des États-Unis. Pour protéger la vie privée, nous proposons d'attribuer une adresse externe par flux. Il n'y a pas de changement de l'adresse utilisée localement, qui reste stable. L'équipement terminal est seulement chargé d'étiqueter les flux par des valeurs pertinentes de Flow Label 1 .

Un boîtier intermédiaire est ensuite inséré à la frontière d'un réseau de confiance (voir la figure 5). Ce boîtier attribue une adresse IPv6 externe pour chaque paire (adresse-IPv6-locale, Flow Label) et réécrit l'adresse source des paquets sortants, et l'adresse destination des paquets entrants.

Comme le boîtier est en position de routeur de frontière, il reçoit l'ensemble des paquets en provenance et à destination du réseau local. De ce fait, il n'y a pas besoin d'envoyer de paquets de découverte de voisins.

Cette thèse fournit les détails du traitement à effectuer sur le boîtier. Nous avons également évalué le risque de collision en utilisant les adresses éphémères, lorsque le même préfixe est utilisé pour les adresses externes et internes. Nous proposons des solutions pour réduire ce risque. Une analyse de la compatibilité avec le réseau Internet d'aujourd'hui est également fournie.

Implémentation sur le boîtier et sur les clients

Module noyau pour la réécriture d'adresse

Pour tester et évaluer notre solution, nous avons développé un module pour le noyau Linux. Nous avons décrit les détails de notre implémentation ainsi que les choix technologiques. La performance de cette implémentation a été comparé avec le mécanisme populaire de réécriture « NAT », et nous avons conclu que notre implémentation est suffisamment efficace pour être massivement déployée.

Gestion des étiquettes de flux : une étiquette par application

Comme les adresses éphémères reposent sur les étiquettes de flux, une solution pour allouer ces labels est nécessaire. La meilleure solution est de mettre à jour chaque application, pour les attribuer le plus finement possible. Un exemple de cette segmentation est d'utiliser un label par onglet d'un navigateur Web.

Cependant, cette solution n'est pas réaliste à court terme. Nous avons besoin d'une alternative pour attribuer les étiquettes de flux, sans attendre une mise à jour de chaque application. Nous proposons donc une solution pour les systèmes d'exploitations basés sur Linux, en utilisant une bibliothèque pré-chargée. Cette bibliothèque permet d'attribuer une étiquette par application, séparant ainsi les activités d'un utilisateur.

Étiquettes de flux avec Linux et divers systèmes d'exploitation Diversité des systèmes d'exploitation

Les règles actuelles pour gérer les étiquettes de flux sont décrites dans la RFC [START_REF] Amante | IPv6 Flow Label Specification[END_REF]. Il s'agit du dernier document d'une longue série, commencée en 1995. Cette thèse propose un court historique de ces évolutions, donne quelques explications aux décisions, et explique les règles actuelles.

Cependant, ce processus de standardisation n'est pas terminé. Un problème majeur est l'absence de standardisation pour gérer les étiquettes de flux sur les systèmes d'exploitation. Il n'y a pas de description des interactions entre les applications et les systèmes d'exploitation pour cet en-tête. Du fait de ce manque de standardisation, il est impossible d'écrire une application portable entre différents systèmes d'exploitation qui utilise ces étiquettes de flux.

Chaque système d'exploitation a sa proche approche. La plupart permettent à une xvi RÉSUMÉ application de définir une étiquette sur une prise 2 TCP cliente, mais plus rarement pour une prise serveur. Le problème n'est pas simple : est-ce que les prises filles doivent partager la même étiquette ? Où bien doit on attribuer une nouvelle étiquette à chaque prise fille, dérivée ou différente de l'étiquette reçue ? Le lien entre le système d'exploitation et les applications est de même difficile à définir. Est-ce qu'une application doit pouvoir connaître l'étiquette actuellement utilisée ? Comment peut-on définir la même étiquette sur plusieurs prises, appartenant à un même flux applicatif de données ? Une application peut-elle grouper plusieurs prises réseaux, afin d'autoriser le partage d'une étiquette à toutes les prises d'un groupe ? Qu'en est-il de la connaissance de l'étiquette reçue ?

Il est ainsi possible d'explorer de nombreuses fonctionnalités. Nous avons restreint notre analyse à quatre questions :

• Comment attribuer une étiquette à une prise cliente ?

• Comment attribuer une étiquette à une prise serveur ?

• Comment connaître l'étiquette assignée actuellement sur une prise réseau ?

• Comment lire l'étiquette reçue sur une prise réseau ? Nous avons comparé cinq implémentations répandues d'IPv6 : Microsoft Windows, MAC OS X, le projet KAME (utilisé par les systèmes BSD), Solaris, et le noyau Linux. Nous avons trouvé un support partiel sur la plupart des systèmes d'exploitation pour attribuer une étiquette sortante, mais une large absence des autres fonctionnalités. Grâce à cette analyse, il était clair pour nous que le noyau Linux était le meilleur choix pour nos tests utilisant les étiquettes de flux.

Modifications sur le noyau Linux

Comme le noyau Linux propose la gestion des étiquettes de flux avec le plus de fonctionnalités, nous les avons décrites en détail. Ce travail de documentation est le plus complet à ce jour sur ce sujet, à la connaissance de l'auteur. Il a été suivi par plusieurs contributions acceptées dans le projet Linux officiel, et disponibles sur tous les systèmes d'exploitations récents basés sur Linux.

Rendre les étiquettes de flux plus utilisables

Du fait de l'évolution des standards, une partie de l'implémentation du noyau Linux est devenue obsolète (la première implémentation des labels de flux a été réalisée en 1999 pour Linux). Il n'est pas toujours possible de corriger ces obsolescences, car la règle du noyau est de ne jamais casser une interaction possible entre l'espace utilisateur et le noyau.

Nous avons pu cependant supprimer trois restrictions sur la gestion des allocations des labels de flux, permettant plus de cas d'usages sans casser les interactions existantes. Dans le même temps, nous avons corrigé quelques bugs dans l'implémentation des labels pour les prises TCP.

Pour permettre des utilisations plus complexes des labels de flux, nous avons ajouté des options à l'interface entre le noyau et les applications. La première est de pouvoir lire les informations concernant l'étiquette actuellement attribuée à une prise, ainsi que la valeur de l'étiquette de flux utilisée par les paquets entrants.

Introduction The Identifiers on the Internet

The Internet is one of the most prominent technologies that has transformed modern life. This global network, allowing instant communication everywhere in the world, has been an important change all over the globe. Social life is impacted by the Internet, a lot of business is conducted on the Internet, and many technologies use the Internet as protocol for their communication.

This very important place of the Internet in our life generates more and more constraints on its architecture. It has to be robust (an Internet failure has many social and economical consequences), but above all secure. This security sometimes allows to perfectly identify the owner of a communication. At the same time, recent press articles show that there is a need to protect user's privacy against attackers [START_REF] Greenwald | Nsa collecting phone records of millions of verizon customers daily[END_REF].

The key to building security and therefore protecting the user's privacy are identifiers used on all protocols involved in the communication. Some examples of these identifiers are IP addresses, ports, cookies, MAC addresses, etc.

All identifiers involved in a communication are important to protect, but the challenges and the impact of doing it are not equivalent. Among them all, IP addresses are the first to protect in building a secure Internet: they are involved in all communications on the Internet, the scope of IP addresses is global (all routers on the path can read them), and they are mandatory for the initialization of the connection and for the communication of data. It can be noted that a protection cannot change the properties needed to run the network, therefore we cannot hide without the cooperation of intermediate routers.

To understand the primary goal of the IP addresses, we have to refer to networking theory. One element of this theory is the Open Systems Interconnection (OSI) model, that is a reference to build a network. In this model, the identifiers are called Service Access Point (SAP). A SAP is used to allow interaction between several layers. At the network layer, the SAP is called Network Service Access Point (NSAP), identifying one end device connected to the network.

If one end device can be identified by several NSAP, their identifiers are stable over the connection lifetime. This stability is mandatory for the routing of data and to allow interaction with the Transport Layer, generating a flow of data.

Our proposition

Dynamical identifiers and security

In comparison, dynamical identifiers are used for security at the physical layer. This idea was first patented in 1942 [START_REF] George | Secret communication system[END_REF], to protect transmission to the radio-controlled torpedoes. The signal is changed by a piano roll, within a range of 88 frequencies. It xix INTRODUCTION makes harder for an attacker to follow the transmission, protecting against radio jamming. The same idea is today the base of frequency hopping in wireless communication, where both sender and receiver are following a temporal sequence of frequencies, instead of always using the same one. It spreads over a wide range of frequencies, thus protecting communications from interception, radio jamming and interferences.

At the application layer, some devices generate one-time-passwords, similarly with a short validity, called tokens. They use a time synchronized algorithm with a server, generating the same sequence of passwords/tokens. It works as long as both devices are time synchronized, and if one attacker is not able to guess the secret used to generate the sequence.

Dynamical network identifiers

In our work, we propose to use this idea of dynamical identifiers at the network Layer. In other words, we shift the flow identification from a paradigm with stable NSAP, to a paradigm with dynamical NSAP. As with frequency hopping, the receiver and the transmitter will follow a sequence of dynamical identifiers, changing over the connection lifetime.

Both solutions are equivalent, but not at the same layer. The frequency hopping spreads the radio frequency spectrum, and our solution will spread the network identifiers used for a communication. In both cases, the sender and the receiver have to agree on a sequence of identifiers, replacing the traditional static identifier. The radio receiver will periodically switch to another frequency, and the IP node will switch to a new listening IP address. We show in this thesis the same benefit as with the spectrum spreading: it avoids injection of packets (radio jamming), and protects against identification of an IP flow by middle man. (interception). One risk with frequency hopping and address spreading is that there could be a desynchronization of devices and therefore, breaking the sequence of identifiers leading to packets being dropped by the receiver.

Challenges of dynamical network identifiers

This approach is challenging, since all the Internet and the OSI model are built on static identifiers. This stability is often taken as an assumption made by upper layers, even when they should not be concerned with the information available at the network layer.

On the actual Internet, an IP address is not only used for the routing of packets but also as SAP for the Transport Layer Protocol. IP addresses are used for the identification of a flow at the Transport Layer, and sometimes at the application layer. Since layers are not independent, it does not follow the OSI model. A way to identify the flow given by the sequence of IP addresses for the upper layers is needed.

Even for the last communication hop, identification remains a problem: the border router of the network needs to follow a mapping between IP addresses and MAC addresses. A solution cannot be scalable without this mapping: a neighbor discovery for each new address will consume a lot of resources. Some solutions for using dynamical and ephemeral IP addresses are already available, but all of them have chosen to add complexity on the network: tunneling of real packets inside a dynamical communication, additional headers to the packet, or flow identification at the application layer. In our work, we propose a solution to spread IP addresses without any additional header or information in the upper layers. Our solution is based on IP headers only, and it works with all upper layers protocols.

xxi

Our contributions

Address spreading

As previously mentioned, we propose in this thesis a new paradigm: IP addresses are not static, but can fluctuate in time, with a high frequency of change. One device does not use a single address, but each software instance will have a randomized address to connect to the Internet. Thanks to the version 6 of the Internet Protocol, each device can now use millions of addresses each day.

We propose a protocol to allow dynamical addresses with negligible drawbacks at upper layers. We call it the address spreading, a mechanism adding security and privacy for Internet communications. Thanks to our work, each flow of data will be based on a sequence of IP addresses. Since an attacker cannot guess the next address to be used, he will not be able to inject data in the flow, and will not be able to make a targeted attack to the device. As a side effect, it protects the privacy of users, since someone tracking the traffic will not be able to correlate a flow to a device.

Our contribution analyzes the architecture consequences of the spreading, such as routing problems to send a packet to a real destination. We propose a protocol to initialize a unique sequence of addresses for each data flow. Since we changed the standard way to identify a flow, we will evaluate the risk to reject a valid packet (false positive detection), as well as the risk of invalid packet bypassing our protection (false negative).

Our spreading protocol and the evaluation has been published in an international conference [FKC + 14], and awarded as one of the best papers of the conference. A shorter version with the theoretical grounds has been published in a French conference proceeding as well [FTC + 14].

From one IP per device to one IP per flow

Since spreading needs a cooperation between networks, we will complete this proposition with a mechanism to obfuscate the IP address of one end device, without any cooperation of the remote network. Our solution assigns an ephemeral IP address to each data flow, valid only over the connection lifetime. In this work, a flow is defined to be as granular as possible, in order to maximize the number of addresses in use without breaking applications. This new IP allocation scheme protects against correlation of flows, and identification of one user from the IP address. It is a lightweight solution in comparison to full featured anonymity systems, but it is enough to mitigate the correlation of flows and re-identification based on the IP address. Given the place of the IP addresses in the Internet, this protection is essential to building protection on upper layers.

While our solution provides an increase of privacy on the Internet, we do not give up the security on the local network and our solution is compatible with a strong security validation on the local network. It allows logging every ephemeral address, and user identification in case of legal requirement. It provides the best of both worlds if the local administrator can be trusted: a protection of privacy on the Internet, with good security on the local network.

Tests and evaluation

Our theoretical work is followed by empirical tests and validations. We evaluated both propositions thanks to our implementations, based on the Linux Operating System.

INTRODUCTION

We ran tests in laboratories, as well as on the real Internet. We prove that IP address spreading can be done without substantial performance drawbacks, and we show viability of the solution in several situations.

Our tests of the new method to identify a flow thanks to flow label have lead to an evaluation of Flow Label management on several popular Operating Systems. More specifically, our implementation and tests on the Linux Kernel have lead to a contribution on the mainline Vanilla Linux Kernel. We complete our tests on the Flow Label with a proposition of a library to automatically assign a Label to each process running on the computer. Both theoretical and practical work have been published in an international conference proceeding [FTK + 13].

Structure of the manuscript

The thesis is organized as follows: Chapter 1 describes the state of the Art of flow identification on the Internet. While this flow identification is traditionally based on simple identifiers, the constraints in some environments and the large number of usage cases add complexity. One strength of the Internet is to allow theses cases, and to remain compatible with other devices. After a general approach of usage on the Internet, we explain the added value of Internet Protocol version 6 (IPv6). Indeed, IPv6 introduces a large address space, allowing one to add properties to the flows. We explain the use of Cryptographically Generated Addresses, the multihoming solutions in IPv6, and the randomization of IP addresses. We end this Chapter with the presentation of works related to our propositions that already suggest adding some dynamics to IP addresses.

In Chapter 2 we present a new privacy solution, allowing an easy allocation of many addresses to each device. We assign one address to each independent flow of data, removing the linking of several flow to a single IP address. The real address appears obfuscated for someone outside the local network, but stable inside. It allows strong security on the local Network, and a good privacy gain on the Internet. This solution is easy to insert into the network, and is compatible with the current Internet.

Chapter 3 describes a protocol to spread addresses of a connection, with high frequency change of addresses. We describe in this chapter our theoretical work on dynamical addresses. We begin with a proposition of architecture, followed by a proposition of protocol to enable spreading. We complete it with detailed processing steps on involved devices. The chapter ends with a theoretical computation of packet loss in case of latency and time desynchronization.

Our work is fully implemented and tested. Chapter 4 describes in detail the identification of a flow thanks to IPv6 flow labels. Since no standards of the implementation exist, we have studied the flow label management on several popular Operating Systems. We then focus our work on the Linux Kernel, with the description of the Linux API and the changes done as part of our implementation. We conclude it with a proposition to automatically assign a flow label to each application.

Chapter 5 describes our experimental results on address spreading. Tests on Local Area Networks and on the Internet are presented, and compared with theoretical results. The solution has been improved thanks to overlapping temporal windows for the lifetime of addresses. Thanks to temporal windows, we can avoid packet loss on flows using address spreading. We conclude with a proposition to use the temporal windows to detect desynchronization of devices. At the end, we shortly introduce tests for the spreading benefits for a IPsec tunnel.

Chapter 6 contains the conclusion of our work, and the outlook of address spreading.

Flow management on the Internet

The notion of flow is very important in networking technologies because it helps to regroup packets that will be similarly processed on the network. Even if this definition seems obvious, it has been subject to many debate during the past years. A flow can be explicit as in the old telephony network where wires were connected together 1 to allow a user to talk to another one. It has been virtualized since with the use of virtual circuit, and the use of datagram networks. Indeed, a flow can be implicit as in the IP network where packets belonging to the same flow can follow different paths in the network. In that case, the flow is only known by the sender and the receiver. Intermediary elements, or routers, process each piece of information individually, that is the definition of datagram.

As nothing in a packet can directly indicate a flow, in the IP world upper layer protocols are needed to read information and explicit a flow. Fortunately, the notion of flow is more natural at the transport layer. This is a mandatory function to sort packets, reassemble segments and detect errors, like the popular Transmission Control Protocol (TCP) [START_REF] Postel | Transmission Control Protocol[END_REF] protocol does. To have this notion of flow, Transport Layer addresses are used, named ports in case of TCP. On each computer, one port is mapped to only one application, and ports are used to discriminate flows. Nevertheless, since the same port number can be used on several computers, the source and destination ports are not enough to characterize the flow. The source's and destination's IP address are needed: IP addresses are unique by nature on the Internet, and they can be used as identifiers for the flow. This is why a tuple of five elements is needed in order to extract the notion of flow on the network. The first two are the source's and destination's IP addresses, directly available in IP headers. The next one is the transport layer number. With the transport layer number, the structure of the transport header is know and can be parsed. The transport addresses can be read, and they complete the tuple, already filled with the three identifiers of IP header.

This has some consequences on the Internet structure. IP addresses are not only used in the routing process, but are also part of identifiers of a flow.

Consequences of using IP addresses identifiers

This duality of an IP address between a locator ("where") and an identifier ("who") is probably one explanation of the big success of the IP protocol. Indeed, it makes the network easy to understand, easy to deploy, easy to debug and to scale. There is one uniqueness of IP address by design, and the interconnection is very easy, thanks to the original hierarchical address space. In comparison, IPX of Novell was widely deployed and had many additional features, like the auto-configuration, but the complexity to interconnect networks was too high.

The drawback of this IP address duality is the lack of some features. Mobility in the IP network is hard to provide, a device moving across several networks cannot use a stable identifier. A device moving across several networks will get a new IP address, breaking all established connections. One IP address does not provide any ownership feature. A computer will receive a flow of packets because of its right place of the network according to the routing rules, not because of its identity.

Flow transformations: identifiers for special cases

Because of the Internet complex topology and the variety of devices, the standard features of the IP protocol may in some cases not be enough. The additional features are then added by a flow transformation, that manipulate headers on the communication path. In this case, the standard flow identification is often not enough.

The most popular transformation is currently the sharing of IP address, allowing several devices to be seen as only a single the Internet. The standard Internet topology does not allow this sharing, and an insertion of a device is needed, providing a mapping between some external identifiers to internal identifiers. An external observer is not aware of the internal topology behind the device. This mapping on the outgoing traffic (to the Internet) can be described as a function F , that takes some local identifiers available in the packet header as argument and gives as a result new identifiers used on the Internet. F -1 is the inverse function to convert incoming traffic to the flow expected by the local device.

The are two strategies to build F : adding new headers in the packet, or rewriting available identifiers. The first one has an important drawback: the size of a packet maximum size, and adding an extra header can exceed this maximum. The consequences and the risks to exceed the packet maximum size are summarized in the RFC 4459 [START_REF] Savola | MTU and Fragmentation Issues with In-the-Network Tunneling[END_REF]. In any case, these identifiers increase the amount of headers, reducing the network performance for data transfer.

The second strategy is the most deployed. In this case, the simplest function F will take as argument the standard tuple of five elements, composed of:

• IP src the local address used by the connected devices;

• IP dst the destination address;

• port src the source port of the transport layer;

• port dst the destination port of the transport layer;

• protocol the identifier of the protocol layer.

It returns a new tuple, used on the Internet. The function F can be split in five sub-functions:

F (tuple) = f IP src (tuple), f IP dst (tuple), f portSRC (tuple), f portDST (tuple), f protocol (tuple)
Since protocol cannot be changed without many consequences (functionalities of User Datagram Protocol (UDP) and TCP are not the same, for example), the partial function f protocol is always the identity function. A translation from one transport layer protocol to another does not exist.

address dst and port dst cannot be changed without consequences on the destination device. This is why f IP dst and f portDST are very often the identity function too. The two local values, address src and port src , can be locally overwritten, and are the more popular way to change the tuple.

It is important to notice that F has to be a one-to-one mapping function, i.e. a bijective function. Without this mapping, two internal flows will share the same external flow and probably break one (or both) connections. In the same way, F has to map every external flow to one local flow. This mapping assure the existence of F -1 , bijective too. Bijectivity of F is equivalent to say that for each local valid tuple, there is exactly one global tuple sent on the Internet.

Private addresses and the renumbering problem

A local network needs to use IP addresses to reach and to be reachable on the Internet. Administratively, there are two ways to have the right to use IP addresses. The first group is the Provider-Independent (PI) Addresses, an independent block of addresses.

The route to a block of PI addresses can be announced by any Internet Provider, without constraint of location. One advantage is the simplicity to change to another Internet Service Provider (ISP). All the IP addresses are stable, the network "owns" the IP addresses. The main issue of this approach is its scalability: if each local network "owns" one IP address and announce it on the Internet, the routing table will be extremely large.

The second group is the Provider-Assigned (PA) addresses. A PA block of addresses is assigned by one ISP to a local network. It is the standard for residential networks and for small companies. It introduces a dependency to the ISP: the ISP owns the addresses. If the client wants to change the ISP, he/she has to reconfigure all devices using the addresses. The location of a PA block is restricted: it has to be connected to the upstream ISP. The IP address, used as identifier, is in this case a locator too. The PA blocks reduce the pressure on the routing table, since all addresses of one ISP can be aggregated in one route.

This problem is called the "renumbering problem". A network is configured with an address prefix, but if it changes, the configuration has to be renewed. To simplify the work of the network administrator, one idea is to use private addresses on the local network, and to convert these private addresses to public addresses at the border of the network. In this way, the local network is stable, and only the border router needs a new configuration in case of new prefix. This idea is normalized in the RFC 1918 [RMK + 96].

There are two difficulties of using private addresses. The first obvious one is rewriting of addresses between the local network and the Internet. One of the possible solutions is the Network Address Translation (NAT), described in Section 1.3.4. The second problem is the connectivity between several private networks. If two companies want to share there private networks 1 , thanks to a Virtual Private Network (VPN), they have to be sure that they do not use the same IP address space. Reconfiguration is required in case of conflict.

Locator/Identifier Separation Protocol

The report from the IAB Workshop on Routing and Addressing, published in RFC 4984 [START_REF] Meyer | Report from the IAB Workshop on Routing and Addressing[END_REF], concludes with a call to break the link between Identifier and Locator in the IP address semantic. One well known solution to do it is the Locator/ID Separation Protocol (LISP) [START_REF] Farinacci | The Locator/ID Separation Protocol (LISP)[END_REF], providing a new way to identify computers. With this solution, a computer is identified by a unique identifier, used by end devices. The core of the network contains a mapping between this identifier and one or several locators, and the original packet is routed inside a tunnel (the original packet is encapsulated by a LISP router aware).

While LISP is a solution to solve the growth of the routing table and to remove the identification role of one IP address, it adds some complexity. The most important issue is to provide a mapping between one identifier and one locator. The choice made by LISP for the function F is to add extra headers, encapsulating the real packet. It changes the Max Transport Unit (MTU) of the transmission, and it implies to add a lot of intelligence in the network. Another LISP router will be in charge to encapsulate and decapsulate packets with the reverse function F -1 . Since the mapping of F is done by several independent devices, the mapping between identifier and locators has to be unique.

LISP has been deployed on several networks, and a RFC on deployment consideration is already available [JCAC + 14]. However, it is too early to guess about the success 1 Often needed if a company buys a second one.

of LISP.

Host Identity Protocol

An alternative to LISP is Host Identity Protocol (HIP) [START_REF] Moskowitz | Host Identity Protocol[END_REF], providing a proof of a host identity thanks to a public/private key pair. The architecture of HIP is not the same as LISP: LISP is based on an upgrade of routers in the core of the Internet, while end devices do not need to be upgraded and can remain unaware of the change. With HIP, the authentication and the cryptographic computation is done on end devices.

One strong point of HIP is its support of mobility: the IP address used in the communication (as a locator only, the cryptographic keys are the identifiers) can be updated without loss of connectivity. Since only end devices are involved, they are aware of the function F adding extra headers, and the MTU problem is less an issue.

As LISP, HIP is an experimental protocol and no big deployments are expected before years.

IP address exhaustion and the NAT

The Internet grows at a tremendous pace and connects today a larger number of than excepted at the beginning. Since addresses are encoded in a defined size, the initial underestimation causes an important issue: the number of devices is larger than the number of Internet Protocol version 4 (IPv4) addresses. In other words, the IPv4 address space is too small. One workaround found by the Internet community is to deploy many private addresses, and to convert them at the border of the network to a public address.

Time sharing of an IP address

The trivial way of doing it is documented in the RFC 1631 [START_REF] Egevang | The IP Network Address Translator (NAT). RFC 1631 (Informational)[END_REF], published in 1994. It allows rewriting of an IP address (non-routable on the Internet) to another (routable on the Internet). The main idea was that all computers of a network do not need to simultaneously access to the Internet. It works as long as two computers of the same local network does not need an Internet access at the same time.

It is simple, since it only requires a one-to-one mapping of the source address, thus the function F is easily defined. However, first problems were already identified, like compatibility with File Transfer Protocol (FTP) [START_REF] Hethmon | Extensions to FTP[END_REF], an application layer protocol to send and receive files. FTP sends the IP address in some communication messages and this address is not rewritten by the NAT, since it does not care of the application layer. Additionally, the translator has to deal with the checksum, invalidated by the address rewriting.

The popular NATP solution

Restricting the access to the Internet to a single computer is of course not realistic in modern networks. Many devices are connected to local networks, and they all need a good connectivity to the Internet at the same time. The NAT idea was extended, and has today more features. The IP address sharing works with simultaneously connected computers, and a big NAT can share one public IP address for several thousand devices with private addresses. This is done with Network Address Port Translation (NATP). The partial function f IP src of F is not enough to assure the one-to-one mapping, because local computers do not share information and can open two communications simultaneously with same four tuple address dst , port src , port dst and protocol. This is why the router uses information from the transport layer (TCP, UDP) to rewrite the port source with the partial function f portSRC , to assure the one-to-one mapping of F . Note that the acronym NAT is used for NATP in current communications. It is though badly named because it does not only rewrite the IP addresses but also the identifiers of the transport layer. RFC 2663 [START_REF] Srisuresh | IP Network Address Translator (NAT) Terminology and Considerations[END_REF] tried to define NAT types, and the terminology to speak about this technology.

To assure the mapping of received packets, the five tuple source (input of F ) and the modified tuple (output of F ) are stored on the router (see Figure 1.3.4 for an example), which has to maintain a state for all connections. This storage provides means to rewrite incoming packets with the inverse function F -1 to deliver packets to the correct local computer. Note that without explicit configuration, all incoming packets without correspondence in the NAT context will be dropped. A local computer cannot be directly contacted by an external device, only outgoing connection establishment is allowed.

Consequences of NATP

This stateful function has a cost for router complexity, they need to have enough memory and computational capacity to manage flows. For each received packet, the router has to look for a valid context and to rewrite headers, including those computed like the checksum used to detect transmission errors.

It does however not only have drawback for hardware performance, but also adds complexity to the architecture of the Internet [START_REF] Hain | Architectural Implications of NAT. RFC 2993[END_REF] and applications (see [START_REF] Holdrege | Protocol Complications with the IP Network Address Translator[END_REF], [FBD + 11] and [START_REF] Srisuresh | State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs). RFC 5128 (Informational)[END_REF]). For the Internet Engineering Task Force (IETF), the consensus was always that NAT is a bad idea. To mitigate problems, a lot of work has been done, like adaptation of Internet Protocol Security (IPsec), solution to NAT traversal like Simple Traversal of UDP through NATs (STUN) [START_REF] Rosenberg | STUN -Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs). RFC 3489 (Proposed Standard)[END_REF]. Even if the NAT process was never standardized2 , two RFCs described best current practices for UDP [START_REF] Audet | Network Address Translation (NAT) Behavioral Requirements for Unicast UDP[END_REF] and TCP [GBF + 08] nating. Note that the publication of best practices was done in 2007 and 2008, more than five years after the publication of problems and implications of NAT.

"Address + Port" translation

The NATP was traditionally done at the border of a home network: for each subscription to an Internet connection, the customer receives a public IP address. Since the exhaustion of IPv4 addresses is every day more real, one IP address per customer is not possible anymore for some providers. To increase the number of users sharing one IP address, they move the NAT device inside the network of the operator. This technology is called Carrier-Grade NAT (CGN).

Since the NAT is is no longer controlled by the subscriber, and since the CGN adds a new NAT on the communication path and does not replace the first one, the issues are even worse than for a standard NATP. A packet will be mapped at home with a first NAT with a F 1 function, and second by the ISP with a function F 2 . It has implication both for the network applications [DHK + 13], and for the management of private IP addresses [START_REF] Srisuresh | Unintended Consequences of NAT Deployments with Overlapping Address Space[END_REF].

An intermediate solution to give some control of public IP addresses to customers is to "divide" IP addresses by ports. In this solution, named "Address + Port" [START_REF] Bush | The Address plus Port (A+P) Approach to the IPv4 Address Shortage[END_REF], the port number of TCP and UDP are used as identifiers for the packet routing. This "extended addressing" remove the need of a second NAT for the ISP. The solution still requires a device for mapping ports and customers, but packets are not modified.

For the customer, the function F appears a standard NAT function, except that the output of the partial function f portDST (tuple) is bounded to a range of the 65535 ports. To keep the bijectivity of F , the range has to be large enough [FGK + 12]. In case of exhaustion of available ports, no new connection can be opened.

Multihoming

A network is called multihomed when it is connected to more than one ISP, or to several link layers of one ISP. A multihomed network has several paths to connect to the Internet, which increases the complexity of the network. It has however many benefits, and the first of them is reliability. If a link of an ISP goes down, the network can still reach the Internet thanks to the second provider.

Variant of the renumbering problem

If the network is large enough to have a PI's address space, the local network uses these addresses to manage the network and only organizes the transit with upstream ISP. The second advantage is that the network can change ISP without changing IP addresses configured on the network.

For a small multihomed network, each ISP delegates a prefix of addresses3 . This prefix is only reachable via this ISP, and if the link goes down, the prefix can no longer be used. All flows using these addresses are broken, as long as the link is down, and no new flow can be established with the addresses.

To mitigate this problem, one solution is to avoid the addresses allocated by the ISP on the local network, and to use private addresses. Rewriting at the border of the network is required, using NAT for example. If the link goes down, it still breaks all the established connections (using the unreachable address as identifier), but all new connections will not use the unreachable link, if the router is aware of the malfunctioning. This fallback works without changing the configuration of end devices.

Increasing performances with Transport layer solutions

If a network is multihomed, a natural idea is to use all links for performance and resilience improvement, instead of only one. A flow could even use several paths, and use all the available bandwidth.

If a network owns a PI address space, routing capabilities provide means to optimize load balancing and capacity of all links. It does not change the flow identification.

If the network has no PI addresses but several Internet accesses with several prefixes, a flow has to be built with several source IP addresses. As for a flow with only one IP address, it cannot be done with only identifiers of the IP layer and compatible transport layer protocols are needed. We introduce two of them here.

The first one is a complete new transport protocol, Stream Control Transmission Protocol (SCTP) [START_REF] Stewart | Stream Control Transmission Protocol[END_REF]. In comparison with TCP and UDP, this is a rather young protocol, as the RFC was published in 2007. The motivation was to bypass limitations of TCP, and to take benefit from accumulated experience to provide a modern protocol adapted to the current Internet. SCTP supports more than one available address, and allows switching to another address in case of failure. All addresses are exchanged by the peers at the connection initialization. With SCTP, the source and the destination have to use a function F to convert all combinations of IP src and IP dst to only one connection.

The second protocol is even younger, and is an extension of TCP called Multipath TCP (MPTCP) [FRH + 11]. It allows a TCP connection to use all the available bandwidth, and is designed to improve performances. It has an experimental status at the IETF as explained in the RFC 6824 [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF]. With MPTCP, two devices will be able to generate and add subflows to the main one. In this case, a function F is needed to group all subflows with the main one. The mapping is provided by a new option in TCP headers.

Security and privacy consequences of flow transformations

The identification of a flow is the base of security: it provides means to identify the sender of packets, in order to filter legitimate traffic and dangerous traffic. On the other side, the protection of identifiers is an important feature to provide privacy on the Internet. Indeed, identifiers can be used to identify a user, correlate traffic, etc.

Security of flow transformations

Since a flow transformation changes the classical identifiers, it adds a new security risk: how secure is this new or modified identifier? How to do the mapping between the identifiers before and after the transformation? The function F has to be secure, to map only the legitimate packets from some identifiers to new identifiers. The mapping is insecure if someone is able to inject traffic in a valid flow transformed by the F function, without providing valid identifiers for the transformation. This mapping is obviously essential in real time to provide connectivity. Furthermore, the mapping has often to be logged in case of legal requirement. Only the classical tuple available after the transformation is usually logged by destination servers. in case of legal requirement, the administrator has to provide the mapping used by the function F at all times.

SECURITY AND PRIVACY CONSEQUENCES

Do not broadcast identifiers to protect privacy

If the protection of identifiers is a goal of all privacy technologies, Internet flows have a specific issue: a flow will broadcast identifiers to the Internet. A card ID is an identifier, but is not broadcast everywhere.

To protect privacy, a solution is to avoid static identifiers, and to replace them with shared pseudo-random sequences [START_REF] Nikander | Enhancing privacy with shared pseudo random sequences[END_REF], or random values, or to reduce the value of the identifiers (making harder the mapping between one identifier and one identity).

Sharing the same address

The first naive solution to reduce the value of one identifier is to share this identifier with other people. If the group of people is large enough, it hardens the identification of the real flow owner.

From this point of view, NAT is a kind of privacy feature. It rewrites the unique identifiers to only one IP address, and all users behind the NAT cannot be identified with the IP address.

Random address

As already said, one IP address is not a standard identifier and it cannot be randomized without connectivity issue. The locator semantic, or the routing part of the address, cannot be changed. However, the last part of an IP address is only used to identify end devices on a local network, and does not change routing.

To protect users, one solution is to use ephemeral addresses, with a rotation of the second address part. Of course, the risk of collision in the address generation has to be considered, but it is a standard solution for networks with enough addresses [START_REF] Narten | Privacy Extensions for Stateless Address Autoconfiguration in IPv6. RFC 4941[END_REF].

Privacy protection offered by multihoming

Multihoming allows several paths to send communications, a multihomed device can split a flow in several paths. If a malicious observer is known to be at one path, but not on all of them, sending data across protected paths protects the communication. Since it is often not possible to know where attackers are, a good idea is to split the communication onto all paths. An attacker must control all of them, if he wants a full observation of exchanged data.

To accomplish that, the first way to protect relies on using several connections to spread data [START_REF] Sifalakis | Network address hopping: a mechanism to enhance data protection for packet communications[END_REF]. It protects privacy, as long as an observer cannot read all the traffic and correlate addresses to one specific end device. The MPTCP can be used for it as well.

However, if the attacker can observe all the paths of the communication, the standard multihoming protocols do not add any privacy benefit. The SCTP and MPTCP do not protect against eavesdroppers to make correlation between flows and do not mask the identity of the computer. They both add a new identifier, allowing one attacker to follow the flow of data.

A second protection can be done thanks to multihoming protocols: switching to new addresses and using simultaneously more than one address are in the basis of the multihoming concept. This can be used4 to build privacy solutions, based on ephemeral addresses. Since it needs many available addresses to be deployed, it is not realistic on the restricted IPv4 address space. Nevertheless, it is with the IPv6 one.

New flow properties offered by IPv6

IPv4 and IPv6 are two versions of the same protocol, they share the same interconnection goal and the same bases. However, IPv6 adds some improvement and opportunities to develop new features on the Internet. In this section, we first describe the important new features of IPv6 for the identification of flows. Afterwards, we explain the change involved by IPv6.

New IPv6 features

A large address space

In the early designed and still in use IPv4 world, the address values are stored in short words. Addresses are encoded using 32 bits, and up to 4 294 967 296 addresses may be allocated. There is no longer enough addresses for all Internet devices. Because of this shortage, some computers do not even have a public IP address. In many situations, devices are configured only with private IP addresses and have to share the public address with other devices through a NAT system. Due to this lack of addresses, it was not possible to make some variations of identifiers, even if connectivity problems were solved. With IPv6 and the very large address space of 128 bits5 , it is now possible to consider using more than one address per device and randomization of addresses becomes a relevant research topic.

Separation between routing part and interface identifier

Another important change happened with IPv6 addresses partitions. As for the IPv4 [START_REF] Postel | Internet Protocol. RFC 791[END_REF], IP addresses are divided into two parts. The first one contains routing information, called "network number" in IPv4. The second one is the local address, or "rest field". The size of the rest field was actually very limited because of IPv4 address space exhaustion. The idea of separation into two parts still holds in IPv6, as described in RFC 3587 [START_REF] Hinden | IPv6 Global Unicast Address Format[END_REF]. There are two distinct parts: the routing information (the global routing prefix and the subnet ID) and the Interface Identifier, as show in Figure 1.2. While the first part is read by routers, the Interface Identifier is not used in the Internet core network and can be locally changed without routing implications across the Internet. The classical size of Interface Identifier is 64 bits, it can be assumed to be a minimum for typical networks6 . The size of IPv6 addresses, and more specifically the size of the Interface Identifier, allows many new features to identify or to transform a flow.

Auto-configuration of IPv6 nodes

The IPv6 Interface Identifier is not only large, it can also be auto-configured by nodes. On many IPv4 networks, the lack of available addresses led to the need of a stateful solution to allocate node addresses. With IPv6, the risk of collision is very low, and the risk of address exhaustion on the network is null. The management can be stateless.

In a stateless configuration, each node generates itself an Interface Identifier. The first standardized method is to derivate an address MAC to an Identifier, called EUI-64 format [START_REF] Hinden | IP Version 6 Addressing Architecture[END_REF]. This generation raises a privacy issue: the interface identifier remains always the same, even if the network changes. It allows the tracing of a device position. ------------------------+-----------+---------------------------- ------------------------+-----------+---------------------------- ------------------------+-----------+---------------------------- ------------------------+-----------+---------------------------- To prevent this issue, the generation can be extended by ephemeral addresses [START_REF] Narten | Privacy Extensions for Stateless Address Autoconfiguration in IPv6. RFC 4941[END_REF]. Another solution is to replace the EUI-64 addresses by static addresses, but generated for each network [START_REF] Gont | A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC). RFC 7217 (Proposed Standard)[END_REF].

+-

+ | global routing prefix | subnet ID | interface ID | +-
+ | N bits | 64-N bits | 64 bits | +-
When addresses have to be managed, the DHCPv6 protocol [DBV + 03] can provide a stateful solution. It takes the advantage of the IPv6 large space, allowing the distribution of temporary addresses (TA) to protect user privacy.

Flow labels

IPv6 introduces a new IP header field: the flow label value. IPv4 does not have equivalent header. This new header is the consequence of another change: the format of IPv6 extensions is not fixed. There is no standard access to the size of an extension, and it is not possible to only read first octets and go then to the next one. For accessing to transport headers, all extensions have to be parsed one by one. The problem has been identified and recently fixed in RFC 6564 [KWK + 12], but the solution only works for future extensions, not for those already in use. This is why transport protocol identifiers like TCP and UDP ports, can be hard to get and, as a consequence, flows hard to identify. As performing identification without complex parsing makes sense, the IETF introduces the "flow label" in IPv6 headers for it. The flow label field is described in RFC 3697 [START_REF] Rajahalme | IPv6 Flow Label Specification[END_REF], and updated by RFC 6437 [START_REF] Amante | IPv6 Flow Label Specification[END_REF]. The flow label is a new alternative and easier solution to manage and identify network flows, directly at the network layer.

Local Network Protection

The IPv6 technology not only changed in IP packet headers, but also included new schemes and new protocols. Internet Control Message Protocol (ICMP) of IPv6 protocol has many new features, the auto-configuration is a new scheme for address allocation, etc. IPv6 changed the standard configuration of IP network, and added a new solution for flow transformations. While flow transformations in IPv4 relied on the NAT, IPv6 solves many issues.

RFC 4864, named "Local Network Protection for IPv6" [dVHD + 07], summarizes new schemes provided by IPv6, and the equivalent technology in IPv4. Indeed, the NAT has some properties for security, local usage tracking, privacy, renumbering and multihoming, and more.

In the particular case of multihoming, IPv6 is by design built to support several IP addresses on each end devices. While the NAT was used to provide a low cost multi-homing, a network can now easily broadcast several routers to configure several communication paths to each end device.

Cryptographic protection of addresses

Since IP addresses are used as identifiers for computers, proving the ownership of an address can be important. This is the goal of Cryptographically Generated Addresses (CGA), defined in RFC 3972 [START_REF] Aura | Cryptographically Generated Addresses (CGA). RFC 3972[END_REF]. CGA IPv6 addresses are defined as an interface identifier generated by a cryptographic hash function. Inputs of the hash function are public and one of them is a public cryptographic key. It is then possible to check whereas public given parameters are consistent with a given identifier. Since the public key is sent with the packet to protect, no external Public Key Infrastructure (PKI) is needed. The goal of the protection here is to prevent spoofing attacks: an attacker cannot claim to be the owner of an IP address.

Without PKI, the CGA protection works like a pseudonym. A connected device chooses a pseudonym (a couple of private/public key) and sends a proof that all packets sent from one address are not spoofed by someone else. To provide a real owner proof without pseudonym, the administrator still has to deploy a PKI and to self deploy the couple of private/public keys on all connected devices.

CGA generation

A CGA is only meaningful with the associated generating parameters. CGA generation needs three inputs:

• a subnet prefix of the device (8 octets);

• a cryptographic public key (variable size);

• a security parameter (Sec) (described below).

The complete generation process is described in section 4 of RFC 3972. In short, the generation works the following way:

1. Generate a random 128-bit value, named "modifier value"; Though there are 9 steps defined in the RFC. All parameters have to be public in order to perform a CGA verification. Additionally, the real algorithm performs duplicate address detection and sets the Universal/Local and Individual/Group bits of IPv6 address to zero. The hash function is defined in RFC 3972 as SHA-1 function [rJ01], but according to RFC 4982 [START_REF] Bagnulo | Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)[END_REF] it is now possible to use multiple hash algorithms, and not only SHA-1.

Security parameter of CGA

The security level (Sec) can be configured between 0 and 7, in order to make bruteforce attacks more difficult. The goal of an attacker is to generate the same interface identifier with another public key and valid CGA parameters. The security parameter is encoded as an unsigned 3-bit integer which is part of the interface identifier (first 3 bits). To generate a valid CGA with Sec parameter, Hash2 has to be computed (see below) with the leftmost 16 * Sec bits set to zero. Note that increasing the difficulty of a brute force attacking, also means increasing the difficulty to generate valid CGA parameters. The cost for generating a valid CGA address follows a factor of 2 16 * Sec computations. With current computers, it takes on average half an hour to generate a CGA with Sec = 2, several years with Sec = 3 and higher values are not computable.

For an attacher (without PKI deployed on the network), the goal is to find a valid pair of public/private keys that matches the interface identifier value (59 bits are free in CGA, since Sec value is encoded in 3 bits and two bits are reserved in IPv6 interface identifiers) and also the Hash2 value with 16 * Sec zeros at the end. It means that the complexity for an attack is O(2 59+16 * Sec ) computations, theoretically not computable today.

One of the CGA limitation is the non-predictable generation time. The algorithm is not deterministic and not guaranteed to find a Hash2 with enough zeros. It is only possible to calculate an average generation time. Ahmad Alsa'deh, Hosnieh Rafiee and Christoph Meinel propose [START_REF] Alsa'deh | Stopping time condition for practical IPv6 Cryptographically Generated Addresses[END_REF] to reduce the granularity of Sec parameters from 16 to 8 (since higher values are not computable), and to let the user configure the time of the hash generation, instead of the security parameters. At the end of the generation time, the algorithm takes the hash which corresponds to the best Sec value.

Secure Neighbor Discovery (SEND) protocol

A CGA provides a binding between a cryptographic public key and an IPv6 address. It is though not enough to provide spoofing protection, since all CGA parameters are public. The Secure Neighbor Discovery (SEND) protocol [START_REF] Arkko | SEcure Neighbor Discovery (SEND). RFC 3971[END_REF] adds a signature to the Neighbor Discovery Protocol (NDP), generated with the private key. A fundamental property of asymmetric cryptography is that private keys cannot be calculated from public keys without a very high effort, impossible to achieve with modern computers. A cryptographic signature is then enough to proof the identity of the sender.

With SEND, the local network is protected against spoofing attacks. It is though a first hop security. Outside the local network, a CGA address looks like a randomly generated address (public key and other parameters are not broadcasted). SEND is the main protocol taking advantage of CGA addresses, but the benefit of linkability between IP addresses and identity is only available on local area network. It does not protect against external address spoofing (an attacker pretending to be part of the network to a third party server), and other solutions like IPsec have to be used to provide real remote identification and authentication on the network layer.

Conclusion on CGA

CGA allows in coordination with SEND to prove of the sender's identity. This feature is useful against spoofing on a local network. The drawbacks are the computational cost to generate addresses, and the possibility that a CGA with a high Sec cannot be regenerated and will be used as a permanent address, in the same way as autoconfigured addresses. This stability implies the same consequence for privacy, and the same security problems that auto-configured addresses.

Site Multihoming by IPv6 Intermediation

Site Multihoming by IPv6 Intermediation (Shim6) is a protocol which provides efficient failover in multihoming environment, for IPv6 flows only. It is longly defined in RFC 5533 [START_REF] Nordmark | Shim6: Level 3 Multihoming Shim Protocol for IPv6[END_REF], and is on standard tracks. The Shim6 protocol finds its place between the IPv6 protocol and transport layers. It provides compatibility with all upper protocols layers. Since the IPv6 layer is not modified, the protocol does not need the upgrade of routers to work.

Nevertheless, location between network and transport layers is not the only particularity of Shim6. It can also be activated anytime in the connection lifetime, and not only at the initialization. After the activation of a Shim6 context (both computers exchange available addresses), packets are not modified as long as the current link works. The Figure 1.5 depicts an initialized Shim6 connection .

Additional headers are only introduced in case of failures (failure detection is spec-ified in the RFC 5334 [START_REF] Arkko | Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming[END_REF]). This header contains a Context Tag (CT) to allow the mapping to the old address. As shown in Figure 1.6, the connection falls back to another route in case of failure. Note that Shim6 is not a load balancing solution, interfaces are never simultaneously in use. The Shim6 header is added as an IPv6 extension header.

The security provided by Shim6 is very interesting in our context because it can use Hash Based Addresses (HBA) [START_REF] Bagnulo | Hash-Based Addresses (HBA)[END_REF], a variant of CGA. HBA provides a security link between an address pool and a host, useful to provide protection against communication hijacking. HBA uses the large IPv6 address space to include information about available prefixes in the address itself. CGA and HBA are compatible and can be used simultaneously for the same address.

In conclusion, the five element tuple is completed with a new identifier. Rewriting of addresses via f IP src and f IP dst is done on end devices and after the checksum verification of the transport layer. It can be considered as an extension of the classical flow identification paradigm.

Encoding more information in addresses

New identifiers encoded in addresses

Even though several IP addresses can be allocated to a computer, it often happens that only one IP address is used for all software on a computer. All users, all software, can send data using one assigned address. It might be complex to change this policy (but possible, the Linux Netfilter allows to set a firewall policy for each user) and only possible on the local computer. It is nevertheless not possible for a network administrator to deploy filtering policies against connected users on a computer, or against a special application. Not enough information are available at the network layer.

Some contributions propose to change this paradigm. The first one is to improve firewall rules [START_REF] Peter | Transient addressing for related processes: improved firewalling by using ipv6 and multiple addresses per host[END_REF]. Each application would use a single address with encoded information about the ports to open. To provide address uniqueness, the port to open would be encoded in the "free" part of the auto-configuration of EUI64 [START_REF] Hinden | IP Version 6 Addressing Architecture[END_REF], standardly fixed for all bits to 1. The authors consider that there is no risk of duplicate address and they have not perform Duplicate Address Detection on the local network. Some modifications of applications and operating systems have to be done, and they discuss Domain Name System (DNS) interoperation too.

The second idea is to assign one address to each user [PTCB + 09]. In the proposal, the user ID is encoded in the "free" part of EUI64 too, and the operating system is in charge of the address assignment. With this solution, it is possible to efficiently restrict traffic of not authorized users, and to build a complex access control [START_REF] Preda | Reliable context aware security policy deployment -applications to IPv6 environments[END_REF].

Addresses as a container for raw data

The idea of data encoding in interface identifier can be extended to provide a side channel [START_REF] Lindqvist | IPv6 is bad for your privacy[END_REF], especially if randomly generated addresses are allowed on the network. Indeed, how to be sure that the random address is really random and does not include information on the address itself?

Solving the renumbering problem thanks to NPTv6

If multihoming is by design in IPv6, the renumbering problem is still not really solved. If a network receives a new prefix of addresses, it breaks the internal connectivity between computers, and the configuration of services has to be updated. For example, the addresses publicly announced in the DNS are obsolete. In such case, rewriting from private addresses to public addresses can still be a solution.

In such cases, IPv6 allows an elegant solution. RFC 6296 [START_REF] Wasserman | IPv6-to-IPv6 Network Prefix Translation[END_REF] proposes to rewrite internal addresses to external addresses with a specified arithmetical scheme. Thanks to the large IPv6 address space, this scheme is able to compute a new address without any change in the checksum of the packet. It spares a lot of resources, the device in charge of rewriting does not have to parse the packet to get the checksum and to modify it.

While this solution has better performances than standard NAT, some issues still remains: for example rewriting will invalidate all cryptographic protection on the packet (IPsec, TCP signatures, etc). Moreover, the end-to-end connectivity for protocols sending the IP addresses in use in the payload of the IP packet is broken.

Clock based flow identification

We described in previous sections some ways to identify, and to transform flows. All the transformations are done in a static way: some identifiers of a flow are added or modified, but the identifiers are static over the lifetime of the connection. It is not surprising, since all the Internet is built on static identifiers.

For example, an address with a randomized interface identifier will be used for all TCP connections established by the device over the address lifetime. If the computer changes the address, all established TCP connections would break. The randomized interface identifier does not allow a fast rotation of addresses.

However, some works provides dynamical identifiers, or something close to it. The goal is them to provide a function F taking as argument the time t, in addition to traditional identifiers. The receiver of the flow can then rebuild a static flow with the inverse function F -1 , taking the time as argument as well.

We describe some of them in this section.

Shim6 extension for privacy improvements

Since Shim6 can use more than one address for a connection, it can be used for privacy improvements. This is the idea of Marcelo Bagnulo, Alberto Garcia-Martinez, Arturo Azcorra in [START_REF] Bagnulo | An architecture for network layer privacy[END_REF]. They do not use Shim6 to maintain a connection after a failure, but to jump from one address to another periodically. By design, Shim6 is multihoming compatible, and flow packets can be split between several Internet providers.

To obfuscate the Shim6 identifiers, they propose Diffie-Hellman key generation in the negotiation of Shim6 context. This key is optionally used to generate a pseudorandom sequence of Context Tag (CT). In this mode, the CT is no more stable (stability provides a way for an eavesdropper to identify flows), a sequence is computed at the beginning of the communication.

One problem of the solution is the address pre-reservation. Before the Shim6 establishment, a node has to assign each address to the interface and to perform Duplicate Address Detection. It can raise problems for a long communication with many addresses.

Privacy improvement is not the only way to use Shim6 for unintended proposes. Xiangbin Cheng, Jun Bi, and Xing Li propose in [START_REF] Cheng | Swing -a novel mechanism inspired by shim6 address-switch conception to limit the effectiveness of dos attacks[END_REF] a protection against Distributed Denial of Service (DDoS). The idea is that the attacked server switches all established connections to an alternative address. The main address is shaped and controlled to give an acceptable flow to the main server. It does not provide protection for new clients, they still have difficulties to contact the service, but all established connections are safe.

Note that both solutions based on Shim6 have a performance overhead due to the new headers, and that the identifiers are not really dynamical. At the initialization, many identifiers are reserved. It avoids collisions (the same identifier value is used for two or more connections), but it does not take all the advantage of dynamical identifiers. At the end of the pre-computed sequence, the communication has to use static identifiers or to be fully reinitialized.

Address hopping thanks to the application layer

In case of DDoS attacks, it is important to discriminate legitimate users from attackers. One solution to mitigate attacks is to change periodically network identifiers (IP addresses) to provide some obfuscations. A legitimate user will have the current valid address and an attacker will send traffic using an old address. It is then easy to filter traffic on an upstream router and to prevent attacks. Whereas the network layer is not efficient to discriminate "legitimate" users and cannot send new network identifiers in case of change, the application layer has more possibilities.

The Prateek Mittal proposition [START_REF] Mittal | Towards deployable ddos defense for web applications[END_REF] is to periodically hop addresses, to increase the difficulty of an attack against a host. Since addresses cannot be distributed by DNS (for two reasons: first, the DNS architecture is not good for high frequency updates; second, new addresses would be publicly given to attackers), the DNS will point to a "puzzle server". The puzzle server is a third-party server and can be seen as a single point of failure. It must itself ensure that it cannot be successfully attacked by the DDoS.

The role of the puzzle server is to send a cryptographic puzzle solvable only with high computational costs. The solution of the puzzle is an ephemeral active IP address assigned to the server that the user wants to connect to. The condition for a protection is to have a too high computational cost for attackers (they have to calculate it for each address jumping), but, on the other side the puzzle must be solvable by the legitimate users. The point of the authors' demonstration is that the legitimate user calculates only one address (they do not stay connected, they only get information in a short period of time), and attackers have to recalculate the puzzle for all new addresses. The cost is higher for attackers than for legitimate users.

In the practical implementation, the puzzle has to be solved using Javascript. Other implementations are possible, but the principle remains the same: an application layer will permit filtering on the network layer.

Nevertheless, this solution is not really based on dynamical identifiers. It only gets IP addresses in another way than standard DNS, and opens new TCP connections at each period of time.

A Moving Target IPv6 Defense

A Moving Target IPv6 Defense [DGU + 11], or MT6D, is a proposition of Matthew Dunlop, Stephen Groat, William Urbanski, Randy Marchany and Joseph Tront. They rotate periodically source and destination addresses. This has two benefits: privacy improvement and protection against targeted Deny of Service attacks (the attacker has to change periodically the address to attack).

To be fully transparent to the applications on the hosts and to transport protocols, the dynamical identifiers are not directly used in the original packets. The real IPv6 packets sent by hosts are encapsulated in an UDP tunnel. This tunnel is established and secured thanks to a symmetric key exchanged before the beginning of the communication. The secret exchange is not addressed in the paper.

In this proposition, the tunnel uses real dynamical identifiers. The IPv6 addresses and the UDP ports are following a pseudo-random sequence, without limitation of a pre-reserved value. However, the cost to transform a static flow to a dynamical one is high, because of the real packets encapsulation. Headers are added, reducing the available bandwidth and adding problems to detect the MTU of the segment.

Toward dynamical identifiers 1.7.1 Dynamical identifiers without adding headers

In the whole history of network identifiers, the use of dynamical identifiers has never really be considered. The first limitation was of course the restricted size of IPv4 addresses, but even with IPv6, many issues remains before deploying a real solution.

Since all the Internet is built on static identifiers, technical issues have to be to analyzed and solved. One of them is to create a new definition of a flow, not based on a five element tuple but on dynamical identifiers. The currents clock based flow identifications bypass this issue with an additional external identifier (see Table 1.1). Before our contribution, there was no function F taking as input the time and a standard IP packet, giving as result an IP packet of the same size, with dynamical identifiers. Of course, this constraint makes the challenge harder. One of the fundamental question is the connection initialization.

Solution

New Beyond these technical issues, an evaluation of the performance has to be made. The spreading looks promising, but it has to be transparent for the network. The solution has to be robust against packet loss, and the new identification paradigm has to be robust. The goal is to achieve more security than the standard identification, but not at the cost of too many false positive detection. The Chapter 3 presents a protocol allowing the identification of flows thanks to dynamical identifiers, at a minimal cost. We evaluate this solution on real networks in Chapter 5.

From temporary to ephemeral addresses

A non technical issue remains: the lack of cooperation on the Internet. We assumed for spreading a cooperation between both networks in communication 7 . Nevertheless, on the Internet, each actor is independent, each actor has personal motivations, and nobody has the power to pressurize all actors. This lack of cooperation makes hard to deploy a new protocol on the Internet: nobody wants to be the first to deploy (and to pay for) a new protocol that nobody uses. In the worst case, even when two networks want to use a protocol, some devices on the path can still reject the packets using an unknown protocol. This problem is sometimes called the "Ossification of the Internet".

In this world, dynamical identifiers cannot be widely deployed now. It is however possible to improve the idea of ephemeral addresses with some basic rules. The first one is the isolation of flows: an identifier should not be used more than necessary (each identifier should not identify more than one connection). Thanks to this first rule, a second one becomes realistic: an identifier should be revoked as soon as possible (at the end of the transmission). Current solutions are today not fine enough to accomplish it (see Table 1.2). The lifetime of temporary addresses can be reduced (the lifetimes announced in the table are only defined as default value in the standards, or not defined at all), but since all of them use a global address for all applications, they cannot switch to another without breaking all established connections.

Solution

Defined A smarter management of ephemeral addresses does not break compatibility with the current Internet, the cooperation of actors is not needed. We describe our solution which complies with these constraints in the next chapter, and some an attempt to deploy it in a real environment in Chapter 4.

Chapter 2 Whereas Internet is built on network cooperations, the major part of communications is running without any explicit cooperation between end devices. A user will access to information available on a website without having previously asked the owner of the website, and will use for this communication the available standard protocols.

IP address obfuscation on middleboxes, managed by end devices

This base of available protocols has to be considered to deploy solutions on the Internet: a new protocol not based on existing solutions will not be able to access to many servers to open communications. The only way to deploy a new protocol is to convince the remote network to deploy a new solution. They will proceed only if there are some advantages to do it, mostly an excepted gain of money in the future.

For technologies to protect privacy of users, a cooperation between a majority of remote networks cannot be expected. Information about users is valuable, and is the core of most companies' business plan. They will not deploy a protocol removing the possibility to track users.

In this chapter, we assume that the remote network refuses to cooperate to protect the user's privacy. The remote network will not deploy any new protocol, and our solution has to be based on the standard protocols like IPv6 and TCP. For accessing to an information source, for example a newspaper, the same protocols as the information dealers have to be used. This chapter is organized as follows: we first describe our goals and our motivation to obfuscate the IP addresses of a computer. We then propose a lightweight solution to provide some basic anonymity to users. The basic principle is to use a new ephemeral address for each Internet flow. At the network layer, each flow is independent, each flow uses unique identifiers. This way, the user privacy is protected because of the difficulty to correlate activities of a user with an IP address.

To simplify the deployment, and to maximize the number of the available IPv6 addresses, we insert a device on the communication path. It does not change neither the architecture or the address management of the local network. The role of this device is restricted: it is only in charge of address rewriting, not of flow classification. It is an architecture choice: the classification of Internet flows on the communication path is hard and computationally intensive. For example, it is fast impossible to group two connections sending encrypted data to an unique flow, without the knowledge of the data content.

The flow classification done on the sender itself is then discussed. It appears to be very efficient, the end device is the best place to classify several transport layer connections into flows. Based on this classification, the end device adds a signalization to each connection for their flow membership.

The next section of the chapter describes an implementation on the Linux Kernel. We discuss technical choices, and detail the steps of packet processing on the inserted device.

We close this chapter with an evaluation of our solution. Theoretical aspects are presented first: we evaluate the collision risk introduced by ephemeral addresses, and the consequences on upper layers. The last part of the chapter contains a description of performance tests ran on the Internet with our implementation.

Protection of user privacy thanks to address obfuscation

Since IP addresses are also used to identify and to track users of the Internet, it is important to provide solutions to obfuscate their addresses. Of course, other various ways exist to track users, for example through cookies [START_REF] Schoen | New cookie technologies: Harder to see and remove, widely used to track you[END_REF] or the web browser configuration [START_REF] Peter | Browser versions carry 10.5 bits of identifying information on average[END_REF]. Nevertheless a privacy friendly Internet with secure IP addresses is required first to build privacy protection on other layers. Some full featured protections already exist, based on the David Chaum idea of Mixes [START_REF] David | Untraceable electronic mail, return addresses, and digital pseudonyms[END_REF]. The most popular is probably the Tor network [START_REF] Dingledine | Tor: The secondgeneration onion router[END_REF], based on Onion routing. In this system, a packet will not go directly to the destination, but will first be several times encrypted and then sent across several intermediate servers (see Figure 2.1). At the end of this path, an output point will take the payload of the packet and send it to the real destination. From the destination point a view, the source address is the source address of the Tor outgoing server. The Tor network protects the user's privacy as long as someone does not control enough Tor nodes or is not able to monitor the incoming and outgoing traffic flows to correlate traffic flows with each other in time [DRH].

Based on the same Mixes idea but built on static path of trusted servers (see Figure 2.2), the AN.ON project [START_REF] Berthold | Web mixes: A system for anonymous and unobservable internet access[END_REF] provides the same kind of privacy protection. The path of a user communication is not random like in Tor, but the servers in the Figure 2.1: The Tor onion routing "Mix Cascade" can be trusted by users, since they know the organizations providing the service. This service protects users as long as Mix Servers do not work together to track them.

If these networks try to protect themselves against powerful attackers (like a governmental organization, one example of world widely deployed surveillance is done by the National Security Agency (NSA) [START_REF] Greenwald | Nsa collecting phone records of millions of verizon customers daily[END_REF]), it is at the price of complex design and deployment, and drawbacks for users. The first problem is usability: the user has to know the tools and how to configure them. The second issue is the latency and bandwidth overhead, because this system slows down the connection. The last one is the congestion on these Mixes networks. To obtain a good anonymity set that provides good privacy protection, a user has to share the Mixes networks with many users. In the Tor network, the drawback is then a very slow connection. Even though there are many Tor nodes, they are still not enough for the number of users, and all nodes do not have a high bandwidth to the Internet. In the AN.ON project, it is possible to pay for a better quality a service, thanks to high performance servers funded by users, but this financial price can discourage users.

All these costs are probably too high for standard users who want to protect themselves against weaker attackers than the NSA. A prominent example of weaker attackers would be a web service which tries to reidentify its users, like the Google and Facebook companies. They are not in a position of man in the middle attacker and they cannot monitor the international traffic. However, since a majority of websites adds embedded objects like graphics provided by Google and Facebook services, they are in a very good position to track all activities and interests of users.

Architecture and components for the obfuscation

Overview of the solution

To increase user privacy, we propose to assign an individual external address to each flow. To each independent flow of packets, the connected device assigns a new flow label 1 . The connected device still uses the same address for each flow, addresses are stable locally.

To provide privacy protection, a middlebox is inserted at the border of a trusted network (see Figure 2.3). The middlebox assigns a new external address to each pair of (internal IP address, flow label) and rewrites the source addresses of the outgoing packets and the destination addresses of the incoming packets. Because the middlebox is in position of a border router, it receives all the packets from the local network. Therefore, it does not need to send extra neighbor discovery packets. In contrast, if the rewriting happens on the end devices, this solution implies some active neighbor discovery.

Since some applications can be incompatible with address rewriting (similar to the implications of NAT in IPv4 [START_REF] Hain | Architectural Implications of NAT. RFC 2993[END_REF]), a flow label set to zero is a signal to forbid rewriting. This special label can be used if a temporary address is undesirable, for example in case of IP source address filtering on the destination device or an incompatible 1 Given the 20 bits for a flow label, the risk of exhaustion is quite low. To summarize, the intelligence to discriminate flows and optimize privacy relies on end devices, and all rewritings rely on the middlebox, i.e. under control of the network administrator. There is no need to change local address assignment policy. The middlebox should be located between the local firewall and the Internet; it avoids to rewrite firewall policies.

Input

Computation on the middlebox

Since the "intelligence" of flow classification relies on connected devices, the middlebox does not need to do a complex parsing of packet headers, and to follow a TCP stream in a stateful way. However, it has to maintain a context to perform rewriting (cf. Table 2.1). For each outgoing packet with an unknown pair (internal IP address, flow label) (short (IP int , label)) the middlebox creates a context and generates a random interface identifier. This random identifier becomes an address by concatenation with the prefix, named external IP address (short IP ext ). The stored context is a 3-tuple (IP int , label, IP ext ), and all following packets matching the pair (IP int , label) will be rewritten with the IP ext . For all incoming packets, the middlebox rewrites the destination address with IP int if a context exists, or applies the standard routing and firewall policies. In both directions, the middlebox has to adjust the transport layer checksum, since IPv6 addresses are part of the checksum. This adjustment is a simple operation, explained in Section 2.4.3.

Note that a flow (defined by all packets sharing the same source IP and the same flow label) can be made of several TCP connections (or other transport protocols). For example, we recommend to use the same flow for all elements of a given webpage. The middlebox itself does not care about upper protocol layers, because the flow assignment is done on the end device.

Flow label assignment by application

The connected device is the best place to discriminate flows and to assign flow labels. For example, a peer-to-peer application probably needs to use the same address for several TCP connections, a Web browser knows if one connection is related to another, etc. In our case, the best way is to modify the application to assign flow labels efficiently.

However, this solution is no realistic. The lack of standardized API for flow label is discussed in Chapter 4. We found some workaround, and we propose a solution to assign one flow label to each application in the Section 4.6.

Implementation with the Linux Kernel

Address rewriting and flow management by the middlebox

To test our solution, we implemented and deployed the middlebox in a real network environment. The middlebox is based on a standard Linux Kernel, and we added a Netfilter module to spread addresses. The middlebox is in charge of rewriting addresses for outgoing and incoming packets.

Outgoing packets processing

The Figure 2.4 depicts the processing of packets going to the Internet. For each outgoing packet, we read the flow label information and the IP source address in step one. If this label is zero, we stop the work of the module and the standard policy of the kernel is applied (step two and eight). Otherwise, we check if a context with the pair of source address and flow label already exists (step three).

If the context does not exist, we have to create one (step four). The next step is to generate a random address, and to check if the address is not in collision as explained in Section 2.4.1. The prefix part is static and cannot be rewritten, but it is possible to configure the length of the prefix (routing information), to maximize the size of the rewritable address part. We add the new external address to the pair (source IP address, flow label), and append this context to the context table.

If a context exists, or after the initialization of a context, we rewrite the source address with the value stored in the fetched context (step six). Afterwards we have to adjust the transport layer checksum (step seven). There is no standard way to rewrite this checksum, therefore we have to write code for each protocol. Currently, our implementation supports the three most popular protocols: TCP, UDP and ICMP (cf. Section 2.4.3). After this rewriting, we return the packet to apply standard kernel policy.

Incoming packets processing

The Figure 2.5 depicts the processing of incoming packets. We first only read the destination address in step one. We check if a context exists for this address in step two. If not, the packet is transmitted to the standard kernel way. Otherwise, we rewrite the destination address with the value stored in the context (step 3). The last step is to adjust the transport layer checksum, and to mark the timestamps.

Identification of a context

The identification of a context has to be efficient on both directions. The identification of outgoing flows is done by matching the source address and the flow label with all existing contexts. For incoming packet, the identifier of the context is the destination address, unique by nature of our solution.

We implement these searches with two hash tables, one for outgoing packets using "source IP address + label" as key value, and the second one for incoming packet using destination address as key value. The Linux Kernel provides one internal implementation of hash tables, that we use in our implementation. The key function are DEFINE_HASHTABLE(), hash_add() and hash_del() to define a table, insert and delete an element.

Since hash tables are fast and consume reduced memory, our double hash table allows fast matching between packets and contexts.

Cleanup of old context

At the term of a flow, the middlebox has to remove the corresponding context to potentially reassign the address and to free the memory used. Nevertheless, there is no concept of connection and there are no communication messages to signal the end of a flow in the IP network.

In IPv4 networks, RFC 4787 and 5382 [AJ07, GBF + 08] give some recommendations to maintain a connection context for a NAT. In our case, it is not possible (and desirable) to trace the state of a TCP connection. On the one hand, a flow can span more than a single TCP connection, on the other hand additional transport protocols can be in use. The only available solution is to introduce a timeout after an inactivity period. It should not be less than 120 seconds, according to recommendation for IPv4. A large timeout period will help to avoid breaking established connections, at cost of resource consumption. Based on empirical tests, we recommend a value of 30 minutes, which gives a good trade-off between resource consumption and connection stability. The local administrator can overwrite this standard configuration in case of particular needs, such as long inactive TCP connections.

To implement the cleanup of old contexts, one solution is to use internal timers available in the operating system. On Linux, it is possible to use timers with the functions add_timer() and mod_timer(), to initiate a timer at the first run and to reinitialize the timer after each cleanup. This timer is in charge to run a function processing all timestamps of contexts, and to remove the too old ones.

Our Netfilter Kernel module

To test and evaluate our solution, we developed a Linux Netfilter module. Our module uses the capability of Netfilter to accept some "hooks" from an external module. These hooks are registered with the function nf_register_hook(), and allow full processing of packets in the module2 , without any modification of the standard packet processing. At the end of the module processing, it is possible to return a reject or an accept command for the packets. In case of reject, processing of the packets stops here.

Configuration of the hooks

There are three main configuration parameters for a Netfilter hook. The first one is the type of packets to deal with. For us, it is always the parameter PF_INET6 for IPv6 packets. The second is the localization of the hook in the packet processing. The Figure 2.6 depicts the five possibilities. In our case, only two cases are relevant: before the routing process and after it. The last configuration is the priority of this hook in the packet processing for this place, for example it can be done before or after the firewall rules.

In our module, we configure two hooks. The first one works on outgoing packets, after the routing decision. We set the configuration NF_INET_POST_ROUTING for the hook place, and NF_IP6_PRI_NAT_SRC for the priority, i.e. the standard priority to rewrite the source address of a packet.

The second hook works on incoming packet. Since the rewritten IP destination address can affect the routing, the packet processing has to be done before the routing decision. We configure our hook with the parameter NF_INET_PRE_ROUTING. For the priority of the hook, we choose the standard NF_IP6_PRI_NAT_DST value.

Registration of the cleanup timer

The Linux Kernel has a timer interface that all modules can use. The definition of a timer is done with the DEFINE_TIMER() function, and is enabled by the add_timer() function. At the end of the given time period, the timer calls a defined function (here the cleanup of old contexts). Our function is here in charge to recall the next cleanup with the help of the function mod_timer().

Kernel version compatibility

The Linux Kernel is always under active development, and there is no guaranty of internal stability, meaning that internal functions can change at any time. For example, the definition of the function called by a hook changed in October 2013, invalidating the code of the module.

The module is currently tested on Linux Kernel between version 3.2 and 3.14.

Evaluation and consequences

Our middlebox is an active component on the network: it rewrites packet addresses before the transmission to the next hop. We evaluate the consequences of our solution in three parts in this section. First, we evaluate the risk of collision between addresses allocated on the local network and generated addresses. Second, we analyze the compatibility of our address rewriting with the current Internet. Third, we evaluate the performances of the middlebox.

Risk of address collision

Uniqueness of external addresses

Since a generated address is used as an unique flow identifier for incoming packets, the address has to be unique behind all local subnets. In the same way, if the rewriting uses the same prefix for IP int and IP ext , a generated address cannot be equal to an address allocated to an end device. Here, there is only a negligible risk of collisions between randomly generated addresses and those already assigned to end devices. The first condition can be easily checked by looking at the context table. Thanks to the huge IPv6 address space, there is no risk of address exhaustion, even when setting one address to each flow. The verification of the second condition is more complex. A solution would be to check whether the address is not already in use; by using the Neighbor Discovery Protocol (NDP). Nevertheless, it is unacceptable for at least two reasons. First, it increases the latency for all connection initializations, because the middlebox has to wait until the NDP timed out before making a decision. Second, no response to a NDP request does not mean that this address is not in use, e.g. the device can currently be down.

Mitigation of the collision risk

To mitigate the problem of collision between generated and allocated addresses, we propose the following:

• The middlebox can be configured not to use the autoconfiguration space derived from the MAC address (this means removing results with 4th byte and 5th byte set respectively to 0xFF and 0xFE). This configuration should be enabled by default to prevent conflicts with the standard configuration;

• In case of DHCPv6 address distribution, the DHCP address space should not be included in the rewriting space configured on the middlebox;

• In case of CGA or static configured addresses, the administrator can manually forbid addresses;

• In any case, the middlebox should maintain a list of devices currently in communication. Clearly this is not exhaustive, since devices can be connected without established connections.

These four rules eliminate the risk of collisions in most networks, and minimize it for some special cases. Additionally, it is important to notice that the risk of collision is actually very low -even without applying the rules mentioned above. We discuss this risk in the next paragraph.

Computation of the collision risk

The evaluation of the probability of a collision is a variant of the "birthday paradox", as defined in [vM39] and [START_REF] Feller | An Introduction to Probability Theory[END_REF]. Given a pool of n addresses and already j addresses assigned, the probability p(n, j) to choose the j + 1 address without collision is:

p(n, j) = 1 - j n = n -j n (2.1)
This means that if we assign J addresses in a free space, we have a probability to have no collision of:

P (n, J) = p(n, 0).p(n, 1) . . . p(n, J -1) = n • (n -1) . . . (n -J + 1) n J (2.2)
Then, the probability to have at least one collision is:

P (n, J) = 1 -P (n, J) = 1 - n • (n -1) . . . (n -J + 1) n J (2.3)
That can be rewritten as:

P (n, J) = 1 -1 - 1 n • 1 - 2 n . . . 1 - J -1 n (2.4) P (n, J) = 1 - J-1 i=1 1 - i n (2.5)
Since all i are less or equal to J -1, we can give an upper bound for the probability with:

P (n, J) ≤ 1 -1 - J -1 n J-1 (2.6)
We can now perform an evaluation of this probability. In a network with only one prefix of the minimal auto-configuration size, the interface identifier uses 64 bits. We can calculate n = 2 64 . On a big network with one thousand computers, where each of them maintains one thousand flows, we need to allocate J = 1000 • 1000 = 10 6 addresses. A simple computation informs us than the probability of collision is less at least than 5.5 • 10 -8 .

Table 2.2 gives some collision probability for some network sizes. We take the hypothesis of 1000 flows for each device, a very large number for standard devices. In this table, our evaluation is very careful: the prefix size is the minimum acceptable size for these kinds of networks.

Compatibility analysis with the current Internet

Devices involved by the communication

In order to support wide spread deployment, a smooth integration of our solution into existing networks has to be considered. In our case, we only need to deploy middleboxes at the border of the networks and an adaptation of the end devices to enable address rewriting. More specifically the necessary changes are as follows:

Remote routers and servers: since our solution is based on standard IPv6 packets, it is compatible with the standard IPv6 network. There is no need to upgrade intermediate routers or remote servers. It can be deployed locally without cooperation or impact on other networks: the real source addresses are obfuscated but packets are still valid.

Local devices: for local devices, packets without flow label are not rewritten and which induces no compatibility implications. Though, for full benefit of our solution, upgrades are usually necessary. First, not all Operating Systems (OSes) provide means to set flow labels. Second, on compatible OSes, the applications have to use the flow label option. We discuss assignment of flow labels in Chapter 4, with a testing of popular Operating Systems in Section 4.2 and a solution for a Linux client in Section 4.6.

Common address translation issues

Address rewriting is a kind of address translation which can have the following consequences:

IP addresses sent by application layer: first, some applications send the IP address to the peer within the application layer protocols, for example File Transfer Protocol (FTP) and Session Initiation Protocol (SIP). If transmitting the address at the application layer is mandatory for a given protocol, the addresses cannot be easily rewritten.

ICMP packets encapsulation:

The ICMP protocol is used to send messages signaling errors in the transmission. An ICMP error message containing IP addresses is encapsulated in another ICMP packet, and send back to the transmission source. The internal addresses quoted in the encapsulated ICMP packets have to be rewritten too. It makes parsing a little bit more complex but it does not break ICMP messages.

IPsec: the case of IPsec leads to the same case as Network Prefix Translation (NPTv6) and the same conclusion: peers should be able to detect the address translator, and IPsec should work.

Disabling the ephemeral addresses:

In all cases, our solution is better than standard address translation since it can easily be disabled. For all incompatible connections, applications can set the flow label to zero, the default value.

Performance of the middlebox

Checksum computation

In IPv6, there is no checksum contained in the IP header but the transport layer protocols like TCP and UDP are in charge of error detections and therefore utilize a checksum. This checksum has to be adapted if a rewriting happens. Fortunately, the flow label is not part of the checksum calculation and can be overwritten without implication. Nevertheless, the source address rewriting has an impact on the transport layer protocol checksum.

The large IPv6 address space supports some checksum neutral modifications, like in NPTv6 [START_REF] Wasserman | IPv6-to-IPv6 Network Prefix Translation[END_REF]. However, this solution is unacceptable in our case. A checksum neutral modification gives a way to group all rewritten addresses of a device, with a simple checksum calculation of the source address. This removes the unlinkability between several random addresses.

Nevertheless, thanks to good properties of the standard Internet checksums, the cost of checksum computation is low, and an incremental update is possible [START_REF] Rijsinghani | Computation of the Internet Checksum via Incremental Update[END_REF]. A fully computation of the new packet checksum C new is not needed, the difference C D between the 16-bit checksum C int of the internal IP address and the 16-bit checksum C ext of the external IP address can be easily added to the already computed checksum C old :

C new = C old + (C int -C ext ) = C old + C D .
There are two strategies to recompute the packets checksums of a flow. The first one is to compute it for each packet, without caching. It reduces the memory load of the middlebox, but at the cost of more CPU consumption. The other solution it to calculate C D = C int -C ext once, and to cache this value. Our tests of CPU performance and memory consumption are done with and without this cache.

CPU consumption and cache of the checksum

To evaluate the CPU consumption of our solution, we made a profiling of the Kernel. We used the OProfile software, part of the standard tools of the Linux Kernel package. Our middlebox was a virtual machine with a 2.4 GHz CPU, and a fast network between the two networks (bandwidth is about a bidirectional 1.5Gb/s).

The CPU of the middlebox itself was not really loaded, and our code had only a little impact on the global CPU consumption for the packet processing. Results are summarized in Table 2.3. The first column is a data transfer without address rewriting, our middlebox is only set as a router. The second column is with a standard NATP enabled (standard implementation of the Linux 3.12 Kernel). The third column is the rewriting without caching of the checksum modification; computed for each packet. The last one presents the results with rewriting and checksum caching enabled.

The rewriting is always a very little part of packet processing and is not a problem for the processor. As expected, better performances are obtained with the checksum caching. Our implementation parses less information than the IPv6 NATP of the Linux Kernel, and reaches therefore better performances.

Memory impact

Within a context, the following pieces of information have to be stored:

• the real source address IP int of the computer (128 bits);

• the randomized source address IP ext (128 bits);

• the flow label (20 bits), stored in an integer (32 bits);

• the cached checksum difference C D (16 bits);

• the "last seen" value, to remove old entries (same size as the jiffies_64 kernel variable, i.e 64 bits);

• two node structures in the hash tables (128 bits each).

The total size is about 80 octets for each context. With the current hypothesis of 1000 computers with 1000 flows each, we need about 80MB to store all contexts. On a home network with 5 computers and 100 flows each, less than 100KB of memory is necessary. Moreover, each context needs less space than a usual entry of the conntrack table used for NAT in IPv4. Therefore, the memory consumption of our solution will not be a problem for modern routers with NAT capacities.

Conclusion

Our solution has many advantages in comparison with Privacy Extensions or a set of random addresses on an end device. First, the set of addresses is larger. When the Privacy Extensions address is restricted to the local prefix, the middlebox can rewrite addresses on all the address space available on the end site, or the network located after it. For example, we can imagine a middlebox at the border of the ISP network, with a very large address space and a large number of users. Since all users cannot trust the ISP, one feature of the middlebox is the possibility to cascade several middleboxes. One typical architecture could be one at the border of the home network, and one at the border of the ISP network.

Second, a Privacy Extension is restricted to only one address in use for all applications. It is not enough to protect user privacy: the traffic of a session is still easy to detect, and all activities of a user (Online Banking, chatting, Video Games. . . ) can be grouped. With one address assigned to each flow, we provide the best protection for a light solution, without adding intermediate servers.

The major drawback is to introduce a stateful device on the Internet path. In case of device reinitialization, all contexts will be lost and current connections will be broken. It is however already the case in the most of Internet networks, due to the NAT devices.

The resources consumption of our middlebox is quite low, allowing a scalable solution to be deployed on large networks. It is an important feature, since larger networks allow bigger anonymity sets and a better protection of user privacy. If two end networks agree to cooperate, new protocols can be imagined to protect privacy and to enhance security. The cooperation of end networks is assumed in this Chapter, but not the cooperation of intermediate Autonomous System (AS) on the communication path. Indeed, an upgrade of all intermediate devices is not realistic at all. The designed protocol has to be compatible with the IPv6 standard to provide the connectivity between two end networks across the Internet. The solution we propose protects against spoofing on the top of IPv6.

The present chapter is organized as follows. We first explain our motivation and the goals of our solution in the Section 3.1. To explain it, we do a short overview of the current flow identifications and spoofing protections on the Internet. We then define the concept of address spreading, an attacker model, and the expected properties of this protection for this attacker model.

We present the best way to easily enable spreading in Section 3.2. Indeed, several architecture choices are possible. The first one is an end-to-end solution, with a Neighbor Discovery problem for the last router. The second solution is to add an intermediate device on the communication path. This solution is easier to deploy, but cannot provide an end-to-end security. However, malicious packets are rejected as soon as possible, protecting the network bandwidth. The last solution is to delegate a address prefix to each end devices. The IPv6 address space is large enough to allow this intermediate solution.

The main contribution of this Chapter is presented in Section 3.3. The protocol and the prerequisite are described in details. We explained step by step the initialization of each connection, and the security gain added by this protection. Since the step by step description follows the ideal case, without any loss of packets, we describe the real processing of packets by spreaders. This processing works with all transport layer protocols, and is insensitive to packet loss.

We end this Chapter with an evaluation of the false detection risk in Section 3.4. The first issue is the inevitable latency in the packet transmissions across the Internet. If the packet arrives to late to the receiver, the address spreader will reject the packet. The second issue is the need of clock synchronization, which is never perfect. We propose a mitigation of the both issues with the introduction of overlapping temporal windows of previous and following addresses.

Address spoofing on the Internet and countermeasure

Standard identification of a flow

An address spoofing attack relies on packets with a forged IP source address. Since the source address is often the only identifier available for computer identification, the attacker can bypass all defenses of a network.

Indeed, a traditional firewall bases identifies flows with the traditional five element tuple (IP src , IP dst , N extHeader, P ort src , P ort dst ), not reliable by nature. The source IP address and the source port especially can be easily manipulated by an attacker. If an attacker is able to send packets with a spoofed source IP address, he will be in good position to try TCP reset attacks, to inject packets on the destination network, to try a targeted attack to the destination, etc.

Firewalls can have extra features to identify packets. For example, a stateful firewall can follow all packets and states of a TCP communication. If a packet does not follow the TCP standard, it will be dropped.

Other spoofing protections

Since the source address is not reliable at all, some solutions exist to enforce packet identification, thanks to other fields in IP headers. One of them is based on the Time-To-Live field (named Hop Limit in IPv6). The principle of the protection is to drop packets with non-standard values in comparison to other packets from the same source [START_REF] Wang | Defense against spoofed ip traffic using hop-count filtering[END_REF]. For each totally or often unused IPv4 field, a solution exists to use it for spoofing protection. One example is the identification field, that can be used against address spoofing [START_REF] Savage | Practical network support for ip traceback[END_REF]. However, this idea is not allowed in RFCs [START_REF] Touch | Updated Specification of the IPv4 ID Field[END_REF], and this field is not available anymore in IPv6.

Another class of spoofing protection uses the cooperation of routers on the communication path. In case of cooperation between all Internet operators, this could solve the problem. By rejecting outgoing packets with invalid source address, an operator enforce the security of the Internet. This has been documented for 14 years in the RFC 2827 [START_REF] Ferguson | Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing[END_REF], but it is still not enough deployed to protect against spoofing. The cooperation of all Autonomous Systems (AS) is not a realistic assumption. One other way is to use trusted routers on the communication path to mark legitimate packets [START_REF] Hamadeh | Performance of ip address fragmentation strategies for ddos traceback[END_REF]. This solution needs a field to write the extra identifiers, which reduces the MTU or implies fragmentation of packets. Moreover, it is complex to deploy.

Since no solution is really satisfactory at the IP layer, some protections are based on transport or application layers. At the transport layer, identifiers can be randomized (named ports in case of TCP and UDP). Examples are the port hopping proposal [START_REF] Lee | Port hopping for resilient networks[END_REF], or the port knocking [START_REF] Ali | Simple port knocking method: Against tcp replay attack and port scanning[END_REF].

A firewall can use one or several of these solutions to protect a network. They all have advantages and drawbacks. The identification due to the Hop Limit is not really secure, but is easy to deploy. The spoofing protection thanks to the router at the border of the AS is the most efficient long term solution, but probably not realistic at this time. An upgrade of hardware and router configurations is expensive, and convincing all Internet actors takes time.

Other protection mechanisms are not based only on IP headers, and are therefore specific of a protocol or an application.

Definition of address spreading

Since network identifiers are used in security solutions, the overall security can be improved with the proof of address ownership. In this chapter, we propose a new security paradigm to enforce security without adding any external information to packets. Our solution is therefore not specific of a transport protocol or an application. With IPv6, the large IP address space allows new security opportunities, like CGA [START_REF] Aura | Cryptographically Generated Addresses (CGA). RFC 3972[END_REF]. Whereas all IPv4 solutions had to minimize the number of IP addresses in use, many addresses can now be used. Our solution provides security based on address spreading. In our solution, source and destination IP addresses of a flow are frequently renewed, according to a temporal sequence. If this sequence is only known by the sender and the receiver, it enhances the security of the identification.

Since only IP addresses are modified, the solution is pretty simple. It does not require complex encapsulation (like IPsec tunnel does), and can be followed by a firewall with knowledge of a shared secret.

We consider a situation, where an attacker wants to inject some traffic with a spoofed source IP address. He can be on the transmission path and also able to read the legitimate traffic.

The solution does not try to protect against flow rebuilding, meaning that the attacker can use upper layer information like TCP ports and sequence numbers to rebuild the real flow. The solution protects against spoofing: packets from the attacker will be identified. As a side effect, we provide protection against correlation between flows and end devices, since addresses are obfuscated. An attacker cannot guess the real source and destination addresses of a flow, and cannot group several flows to one source or destination only with the information available at the network layer.

Discussion on the best places to enable the spreading

On the end device

The key principle of spreading is to generate and follow an address sequence on both end devices (see Figure 3.1). This strategy allows an end-to-end security, and computers do not have to delegate security to someone.

However, this solution implies an upgrade of the local router. The main issue arises in the situation where end devices do not get a delegated prefix, but share the local prefix with several end devices. The use of many addresses will:

• flood the network with Neighbor Discovery packets. The router is not aware of the spreading, and cannot know the link between the temporal sequence of IP addresses and the static MAC address;

• saturate the Neighbor table of the router. With a too frequent address switch, the router will not be able to store all mappings between IP addresses and MAC addresses;

• introduce a latency at each IP address switch, due to the Neighbor Discovery.

The second issue of spreading on a local network is the incompatibility with address management policies of the administrator. For example, a secure local network should use Cryptographically Generated Addresses (CGA) [START_REF] Aura | Cryptographically Generated Addresses (CGA). RFC 3972[END_REF] to prevent local spoofing of addresses. Address spreading is incompatible with CGA, as well as address attribution via a DHCPv6 server.

Solution with a patched router

To solve the problem of Neighbor Discovery packets and the saturation of the neighbor table, a solution is to patch the router to follow the sequence of IP destination addresses in the Neighbor Table. Thus, the router does not have to know the sequence of source addresses received from the Internet, and is not able to insert a packet in a flow.

This architecture is quite complex, implying both a modification of both routers and end devices to work.

On the communication path

As a first approach, we propose to simplify the problem by adding new "spreader", devices on the communication path. These devices are able to rewrite a packet flow with stable addresses into a packet flow with dynamical addresses. The spreader can directly be on the network border (see Figure 3.2) or at the border of the trusted zone (see Figure 3.3).

The first positive argument for this architecture is the simplicity to deploy it. An administrator does not need to upgrade and configure each end device, but can simply insert the spreader in the network. It has the same benefits as a modified router following the relation between IP and MAC address, and less drawbacks.

The second point is the possibility of bad packet filtering. Since malicious packets consume resources, and can be sent to simply saturate the network bandwidth, malicious packets have to be discriminated as soon as possible. With the introduction of spreaders at the border of the trust zone, this goal is achieved efficiently.

We choose this architecture to simplify concepts and experimentations.

Delegation of addresses prefixes to the end device

A spreader on the path is not the sole solution. Enough IPv6 addresses are available to delegate one address prefix to each end device. This has the advantage to solve the mapping problem between MAC addresses and IP addresses, because the intermediate device sends only IP packets matching a prefix to a MAC address. In this case, the end device is in charge of Interface Identifiers management and can actually be considered as a "router". The architecture at the network layer is the same as in the previous method (see Figure 3.2. The delegation of address prefixes is the best architecture in terms of simplicity and security. However, it only works on networks with a large enough IPv6 address space.

Since one end device with a delegated prefix is equivalent from a network point of view to an architecture with spreaders on the path, our work only mentions "spreaders", and our tests were based on a network with spreaders on the path. Again, it perfectly works if the end device does the spreading itself: our solution provides end-to-end security, as well as a device protecting the local network.

Detailed process of the protocol

General principles

Prerequisite of the solution

To enable spreading, at least two networks have to be configured for the mapping between the dynamical addresses and stable identifiers.

This configuration is done by adding a spreader at the border of each network. The two spreaders have to share a secret, that an attacker cannot guess.

Spreader initialization

At the spreader initialization a configuration for each compatible peer with a shared secret has to be created. This configuration contains the prefix list of destinations (to catch packets to be rewritten) and a function to derive cryptographic keys from the shared secret.

Exchange of session data

One of our goals is to spread each data flow with a unique address sequence, making more difficult for an attacker to group all flows of one end device. To do so, both spreaders have to exchange session data at each flow initialization. There are several ways to accomplish it. The first one is to add several extra packets to initiate a context for each flow. It increases latency of connection initialization, and costs some bandwidth.

The second one is to add extra information on real packets, for example by adding one extra IPv6 extension header. Since this extension would be added by the spreader and not by end devices, it could result in some maximal transport unit problem. Indeed, this header cannot be added on a big packet, and two solutions exist in that case. The first one is to fragment the packet on the spreader, which is not allowed by IPv6 RFCs. The second one is to send a "too big" error to end devices, which reduces the performance of all packets for the session.

Step by step initialization

Notations

The description of the protocol follows the same steps as a TCP handshake connection initialization, depicted in Figure 3.4.

We introduce the following notation for the packet rewriting (summarized in Table 3

= P A |IID 1 src IP 1 dst = P B |IID 1 dst 2a → 2b SYN, ACK IP B IP A IP 2 src = P B |IID 2 src IP 2 dst = P A |IID 2 dst 3a → 3b ACK IP A IP B IP 3 src = P A |IID 3 src IP 3 dst = P B |IID 3 dst Table 3

.1: IP address notation

Connection initialization -first packet

Symmetrical rewriting by spreaders: rewriting begins with step 1a, when the spreader A receives a packet with a destination IP address matching one of the prefix in the spreader configuration.

As soon as it receives the first packet of a connection, the spreader A computes the new source and destination IP addresses with the help of a cryptographic function. We choose the Advanced Encryption Standard (AES) [START_REF] Preda | A secured delegation of remote services on ipv6 home networks[END_REF] encryption, but any other encryption system allowing blocks length of 128 bits could be used.

The key of the AES function is derived from the shared secret, thanks to a Key derivation function (KDF). The KDF derives a new encryption key each new period of time. One example of KDF is defined in RFC 5869 [START_REF] Krawczyk | HMAC-based Extract-and-Expand Key Derivation Function (HKDF)[END_REF]. We call this key K(t), with K the KDF.

The AES function takes as an input a block of interface identifiers of both hosts A and B. Since the AES standard assumes a block length of 128 bits, the last 64 bits of both interface identifiers are taken, even though if they can be longer. The spreader divides the 128 bits of the AES output in two blocks of 64 bits to replace the last 64 bits of IP A and IP B .

IID 1 src = AES(IID A |IID B , K(t))[0 -63] (3.1) IID 1 dst = AES(IID A |IID B , K(t))[64 -127] (3.2)
After the address rewriting, the packet follows the standard routing and filtering process. This ends step 1a.

On the destination spreader, stable addresses are recomputed by the AES decryption function (step 1b). After this computation, the destination spreader checks the validity of the transport layer checksum (this checksum is mandatory for UDP and TCP with IPv6). If the checksum is valid, the packet follows the standard policy of routing and filtering.

If the checksum value is not valid, it can be a sign of transmission problem. Another possible cause of this invalid checksum is an attempt of an attacker to inject a packet in the network, with spoofing of the source address. Indeed, IPv6 addresses are part of the checksum computation and if addresses after the second spreader are not the same as addresses sent by the source device, it invalidates the checksum. Since the attacker does not know the shared secret, he cannot compute the AES encryption and the generated packet will be detected by the spreader.

In more details, Table 3.2 depicts the status of the checksum at the different steps of the communication. The checksum seems invalid during the time packets are transmitted between the two spreaders, but it does cause any problem since nobody needs to have a look at the checksum on the communication path. On the contrary, we see in Table 3.3 that the checksum of a spoofed packet seems valid on the Internet, but invalid after the second spreader's rewriting.

Security analysis of the rewriting: if the attacker is aware of this spoofing protection, he can try to guess the checksum modification added by the spreaders AES encryption. The length of the checksum field is 16 bits, which gives one chance out of 65 536 to find the good one. This value is only valid for a short time and for a given address couple, the next value of K at t + 1 will give another checksum modification implied by the AES encryption. This security mechanism is not good enough to filter all packets of an attacker, and some packets can bypass this protection. Nevertheless, it is important to notice that if the checksum is valid, the attacker cannot guess the rewritten addresses and cannot know what is the rewritten destination address. The chance to successfully contact a real computer with a valid address is very low. Indeed, if we assume that the rewriting is fully random, an attacker has first to bypass the checksum (one chance out of 65 536). If the checksum is valid, a targeted attack on a computer on the remote network has one chance out of 2 64 to reach the good address, since the attacker cannot guess the rewritten value after the AES decryption.

Steps

Rewritten IID Source Rewritten IID Destination

1a → 1b SYN IID 1 src = AES(IID A |IID B , K(t))[0 -63] IID 1 dst = AES(IID A |IID B , K(t))[64 -127] 2a → 2b SYN, ACK IID 2 src = random() IID 2 dst = g(t, secret, IID 1 src ) 3a → 3b ACK IID 3 src = g(t, secret, IID 1 src ) IID 3 dst = g(t, secret, IID 2 src )
Table 3.4: Rewriting in initialization steps.

Initialization of the connection -response of the remote spreader

The goal of the address rewriting on the first packet is to protect an initialization of a connection by an attacker. For the next packets, we create a pseudo-random sequence for each data flow, generated by a function g. This function g is a generator of a random sequence, for example a hash function like SHA-1 [rJ01].

The secure generation begins with the step 2a. To do it, the second spreader rewrites the first reply packet of a client with a random value as IP source, and a value computed from the source IP address value in the first packet for the destination.

IID 2 src = random() (3.3) IID 2 dst = g(t, secret, IID 1 src ) (3.4)
The generator g takes as input the current time, the shared secret between the two networks and another value of the size of an IP address. This rewriting introduces a random value for the sequence, but the flow is still easy to identify for both spreaders with the IP address destination set to a value that the first spreader can recognize.

In step 2b, the first spreader recognizes the IP destination address IP 2 dst with the help of a context previously stored. This packet is an acknowledgment of the initialization, spreading can now really begin. The spreader saves the value of the IP source (randomized in step 2a) and rewrites the source and destination IP addresses to the real stable values stored in the context.

It ends the second step. The first spreader is now sure of the connection initialization, and can use the random value to bootstrap a new random sequence.

Connection initialization -Acknowledgment to the second spreader

The step 3a begins as soon as the next packet is sent by the device from the network A. Both source and destination addresses are now spread with:

IID 3 src = g(t, secret, IID 1 src ) (3.5) IID 3 dst = g(t, secret, IID 2 src ) (3.6)
In step 3b, the spreader B recognizes the spread couple with the help of the stored context. This packet is an acknowledgment of the random value sent in step 2a, and the second spreader is now aware of the success of the initialization. Initialization steps are summarized in Table 3.4.

Rewriting during the life of the connection

After the step 3b, both spreaders follow the same sequence of rewriting according to the computation of g(t, secret, IID 1 src ) and g(t, secret, IID 2 src ). The rewriting is symmetrical and both end devices receive stable addresses. An attacker cannot inject any traffic since he does not know the next addresses to use.

Detailed packet processing on spreaders

The protocol described in Section 3.3.2 is an ideal situation. No packet loss is assumed, and both end devices use the TCP protocol. It helps to understand how it works, since our protocol follows the same handshake mechanism as TCP.

Nevertheless, the solution has to be robust against packet loss and data retransmission. In the same way, it has to be compatible with transport protocols, like UDP, where a connection does not follow a rigorous initialization procedure, or ICMP with short sessions like a simple Echo request. We detail in this section a packet processing by spreaders, which actually supports packet loss and which is transport layer protocol independent.

Detailed steps of packets processing (outgoing packets)

Packet processing from the local network to the Internet is depicted in Figure 3.5. For each outgoing packet, the spreader extracts the tuple (IP src , IP dst , f lowlabel) (step 1). It checks if one context already exists (step 2) and whether it has already received an acknowledgment (step 3). If both conditions are valid, the connection is established and both IP src and IP dst can be rewritten with the help of the function g and the information stored in the context. After that, packets continue the standard processing.

If the context does not exist, it has to be created. It will contain the real IP source address and real IP destination address, as well as the flow label value (step 5). It moves to step 6, where the context exists but no acknowledgment has been received so far. AES encryption with K(t) is used to rewrite IP addresses.

Since the rewritten IP src is used as a parameter for a reply from the remote network, it need to be stored (step 7 and step 9). Several addresses can be stored if several packets are sent before receiving an acknowledgment. The packet follows afterwards the standard packet processing.

Detailed steps of packets processing (incoming packets)

Figure 3.6 depicts the packet processing for all kinds of packets coming from the cooperating network or not. Processing of incoming packets begins with the extraction of the pair (IP src , IP dst ). The flow label is not extracted, this value cannot be trusted outside of the local network. This flow label will be rewritten to an internal value to make the future flow identification of local packets going to the Internet. The goal is to know whether a context already exists for this connection (step 2 and 3). If this is the first packet for this context, it is an initialization acknowledgment and the status of the context has to be changed (step 8). The processing ends with the rewriting of dynamical addresses to stable addresses and the packet is returned for standard processing (step 6).

If the context does not exist, IP addresses need to be decrypted with the AES function and K(t) (step 7). This decryption is followed by the computation and the verification of the transport layer protocol checksum in (step 9). A bad checksum implies to drop the packet, since it is probably an attempt of an attacker to send a packet with a spoofed address. If it is valid, a context is initiated (step 10) and the rewritten packet is returned for standard processing.

Identification of a flow thanks to the flow label field

Our goal is to create an address sequence for each data flow. By flow, is meant a sequence of packets where information of upper layers is enough for an attacker to correlate packets with each other and to rebuild the sequence.

The first trivial idea is to make one flow for each pair (IP src , IP dst ). It does not take a lot of resources, but does not prevent correlation if more than one flow are sent between devices. Nevertheless, it can be desirable to obfuscate this information.

IPv6 introduces a new header field to give information about a packet flow: the flow label field [START_REF] Amante | IPv6 Flow Label Specification[END_REF]. It is a 20 bit header, that can be used for Quality of service (QoS) CHAPTER 3. SPOOFING PROTECTION -ADDRESS SPREADING or other uses (RFC 6294 [START_REF] Hu | Survey of Proposed Use Cases for the IPv6 Flow Label[END_REF] gives of survey of uses). This flow label can be rewritten on the communication path, and is not part of the checksum. Because other uses than QoS are allowed, our proposition respects current standard specifications [START_REF] Amante | IPv6 Flow Label Specification[END_REF].

A data flow to spread is defined by the tuple (IP src , IP dst , f lowlabel). If the end device sets a different value for two flows, it will be spread into two different sequences. The flow label is set by the end device itself, which has enough information to know whether a packet sequence should be grouped with another connection or not.

Loss of packets due to desynchronization

Theoretical loss due to false positive detection

Our spreading solution drops packets if they do not follow the address sequences. This spreading protects against attackers, but valid packets sent by the real device can be dropped. Because of the latency in the network, when a packet takes too much time to be transmitted, it will be dropped by the receiver, since it has already switched to the next addresses pair. This false positive detection is depicted by Figure 3.7.

The second source of problems is the time desynchronization between two spreaders: if the clocks are not synchronized, a valid packet will be detected as spoofed even when the sender is not an attacker. In some cases, the packet comes too early, as depicted by Figure 3.8.

In this section, we describe the theory of this packet loss. We first estimate the packet loss in case of latency in the network with perfectly synchronized spreaders.

Second, time desynchronization between spreaders is added. Next, the consequences for a simple ICMP echo request/echo reply communication are explored. We conclude with solutions to mitigate both problems.

Latency effect

The latency is the time needed for a packet to go from a source to a destination. The latency can be less than one millisecond on a local network (LAN), and several seconds between two points on the Internet. If we assume that the latency is stable for all packets and is the same in both directions, it is easy to estimate the proportion of the packet loss. All packets sent at the end of the lifetime of an address will be dropped by the receiver spreader. The duration of this black hole in the communication is precisely the value of the latency. Assuming a constant rate of packet emission, the packet proportion loss is:

loss = latency lif etime (3.7)
For example, with a configuration of 1 second for the address lifetime, with 100 ms of latency for the transmission, 10% of packets will be dropped in both direction between the spreaders A and B.

Desynchronization effect

It is not easy to perfectly synchronize two computers on the Internet. Even with the NTP [START_REF] Mills | Network Time Protocol Version 4: Protocol and Algorithms Specification[END_REF], clocks of computers are not perfect and a little desynchronization always appears. In one way of the transmission, this desynchronization is good, since it reduces the observed latency between both computers. In the other direction, the desynchronization is added to the latency and it implies a longer duration of black hole for the communication.

Assuming that the spreader A is desynchronized with A later than B, the loss in the direction A to B is:

loss A→B = latency + desync lif etime (3.8)
In the other direction from B to A, the loss is reduced to:

loss B→A = |latency -desync| lif etime (3.9)
The perfect case in this direction is reached when the latency is equal to the desynchronization: packets are no longer lost in this direction. If the desynchronization is bigger than the latency, some packets come too early to the spreader A (A has not yet switched to the following address) and packets are dropped.

With the same configuration of 1 second for address lifetimes, with 100 ms of latency on the network, and a desynchronization of 10 ms, 11% of packets are dropped between A and B (110 ms of black hole) and 9% between B and A (90 ms of black hole).

ICMP echo request/echo reply communication

The evaluation of packet loss in both directions is not enough to evaluate the impact on communications. On the Internet, a unidirectional payload transmission is very unusual. The most popular protocol TCP sends many acknowledgment packets even for a unidirectional transmission, and a simple ICMP echo request is replied with an echo reply packet. Packet loss due to address spreading is not distributed like a standard network error (each packet does not have the same probability of failure), but the connection seems to be broken for a short duration, in one or two ways.

For example, in case of ICMP echo transmission between spreaders A and B, the time period over which on echo reply/request packet can be dropped is:

latency * 2 + desync (3.10)
The theoretical ICMP echo request/reply transmission failure is plotted in Figure 3.9 for a given latency with respect to address lifetime, without any spreader desynchronization.

Overlapping temporal windows of previous and following addresses

To reduce the packet loss, it is possible to accept the old address of time t -1 over a temporal window where both current t and t -1 addresses are accepted. With a temporal window larger than the latency, no packets are dropped by synchronized spreaders.

In case of desynchronization smaller than the latency, this desynchronization duration needs to be added to the temporal windows to accept all packets sent in the communication. A spreader cannot know whether a packet is delayed due to the latency or due to a desynchronization problem.

If the desynchronization is larger than the latency, a spreader will receive packets too early. Similarly, a temporal window over which both addresses of t and t + 1 would be valid can be used. If a spreader receives many packets on the t + 1 address, it is a sign of desynchronization and it could help to resynchronize both spreaders. We present our experimental results on temporal windows to accept previous and following addresses in Chapter 5.

Conclusion on address spreading

Address spreading is an innovative solution to identify a connection. This is a new mechanism to protect against spoofing attack, using dynamical addresses as identifiers for the connection. Our spreading protects against connection initialization from an attacker, as well as packet injection inside an established connection. It provides a strong protection, without adding extra headers.

We described the full protocol to securely initiate a connection between two spreaders, with an initialization of temporal sequences of addresses for each flow. We did a step by step description of the spreader internal functionality, and we explained the theoretical packet loss without any temporal windows.

This loss can however be avoided with the use of temporal windows for previous addresses. This temporal window avoids false positive detection of packets due to the network latency. Since it is hard to synchronize computers on the Internet, we propose to add a temporal window for the next address too. It protects against small desynchronization, like the one two computers synchronized with NTP can experience. Furthermore, this system can be used to resynchronize spreaders without any external source of time. Even with the temporal windows, an address is valid only for several durations of the latency in the network, defeating an attacker attempting to spoof an address.

Even though there are many existing solutions to avoid IP spoofing, our solution has advantages on them. First, this protection does not need cooperation of intermediate AS. It can be deployed by two end networks, without involving of other actors. Moreover, the position of the protection can be chosen by administrators, allowing flexibility for the local network architecture.

Second, our solution is based on IP headers only. In this class of solution, we are more secure than identifications using to the Hop Limit fluctuation, based on a 8 bit field, and which need a learning phase. Moreover, we are compatible with this previous solution, because we only rewrite the IP addresses.

For the performance, our contribution does not add any packet encapsulation or external header. This architecture choice does not reduce the network bandwidth, like IPsec tunnel or the MT6D encapsulation do. Moreover, there is no risk for a middlebox to misunderstand the additional header.

Since it does not need complex cryptographic computations (a spoofed packet will be invalidated after one or two AES computations), it can be deployed on devices with small computation capacity, like a sensor network.

The theoretical work of this chapter is further developed in Chapter 5 with a presentation of experimental results. We compare our prevision of packet loss with empirical networks, and we evaluate the performances of overlapping temporal windows.

The flow label field is one of the new features of IPv6. However, it is not really used in practice, the rather few API implementations to set labels on operating systems differ considerably In this thesis, flow labels are used to provide flow identification in the local network. To prove feasibility of this approach, tests of our solution are done on real operating systems.

In this chapter, Section 4.1 explains the flow label implementation complexity, and the current requirements to be compliant with IPv6 standards. The current implementation of the flow label field in IPv6 headers is then described for several popular operating systems in Section 4.2. Our goal is to provide an overview of the state of the art for flow label implementation, to simplify future portable applications using flow labels on several operating systems.

This state of the art is completed with a focus on the Linux Kernel. The Linux Kernel provides today the most complex flow label API. Details are described in Section 4.3, and the reasons of some updates are explained in the same section.

The Linux Kernel has been used for our development and tests, but we realized that the API was not usable in practice. Our modifications on the Kernel are explained in Section 4.5. Our contribution contains bug fixes, the removing of some limitations, and an implementation of new options for the flow label manager. All the modifications were accepted in the mainstream Vanilla Kernel.

Section 4.6 closes this chapter with a proposition to assign a flow label to each application on a Linux client. It is the implementation of the idea explained in chapter 2, allowing to assign a label to each application without patching all of them.

The lack of standardized API

Historical evolution of RFCs

The idea to introduce a new field for Quality of Service management and flow classification came very early in the IPv6 standardization process. The first RFC mentioning flow labels [START_REF] Partridge | Using the Flow Label Field in IPv6[END_REF] was published in June 1995, six months before the RFC on IPv6 specification [START_REF] Deering | Internet Protocol, Version 6 (IPv6) Specification. RFC 1883 (Proposed Standard)[END_REF]. The motivation was to allow a classification of IPv6 flow though IPv6 headers only, to simplify the work done by a router (all packets sharing the same three element tuple {IP source address, IP destination address, flow label} can have the same processing, cached after the first packet) or to allow a simple flow identification without complex parsing of transport protocol headers. Moreover, since the flow label is set at the network layer, it remains available even in case of IP packet fragmentation. The label is set for all fragments.

This field has a long history, and specifications have changed several times over the time. The first update of IPv6 specification [START_REF] Deering | Internet Protocol, Version 6 (IPv6) Specification. RFC 2460[END_REF] moved the flow label specification part in appendix, and reduced the size of flow label from 24 to 20 bits. Since this specification, basic rules are:

• the flow label is 20 bits long;

• the flow label is not part of the checksum;

• the flow label is not secured by IPsec. These rules do not prevent the change of the flow label role in future specifications, but they have a big side effect: flow labels are not secure at all. A transmission error is enough to deliver a bad flow label to the receiver, without any chance of detection.

The next specification step occurred in RFC 3697 [START_REF] Rajahalme | IPv6 Flow Label Specification[END_REF], in March 2004. It introduced new rules for nodes wanting a flow label settings, and forbade modifications of flow labels over the path between the source and the destination nodes.

These rules were recently obsoleted by the RFC 6437 [START_REF] Amante | IPv6 Flow Label Specification[END_REF], given some works on the real use of flow label [START_REF] Hu | Survey of Proposed Use Cases for the IPv6 Flow Label[END_REF] and works on the current specification relevance [START_REF] Amante | Rationale for Update to the IPv6 Flow Label Specification[END_REF].

Thanks or due to all these works, no standardized API for flow label has never been defined. In the basic socket interface for IPv6 [GTB + 03], the sockaddr_in6 C structure has a member called sin6_flowinfo. It is defined as follows: "The sin6_flowinfo field is a 32-bit field intended to contain flow-related information. The exact way this field is mapped to or from a packet is not currently specified". Specification for this member is postponed to the future: "The complete definition of the sin6_flowinfo field, including its association with the traffic class or flow label, is now deferred to a future specification". This specification still does not exist today.

In the full featured API for communication between applications and operating systems for IPv6 sockets defined in RFC 3542 [START_REF] Stevens | Advanced Sockets Application Program Interface (API) for IPv6. RFC 3542[END_REF], flow labels are out of the scope. Flow labels are only referenced for "This API does not define access to the flow label field, because today there is no standard usage of the field".

No newer RFCs have even changed it, even though some protocols are on the RFC standard tracks (old ones [BZB + 97] or recent ones [START_REF] Carpenter | Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels[END_REF]), or mentioned in informational RFC like the RFC 7098 [START_REF] Carpenter | Using the IPv6 Flow Label for Load Balancing in Server Farms[END_REF]. Out of the IETF process, many ways to use the flow label field are proposed. Nevertheless, the question of how to set a label on a node is not really in discussion.

Current standardization

Even without defined API, an IPv6 node has to support the RFC 6437. It is a real problem for operating system developers, since any self-made solution can be obsoleted in the future, but without it nodes will not follow standard IPv6 specifications.

The current rules that IPv6 nodes have to follow to respect the flow label specifications are summarized here.

On a terminal node

Even if a node itself does not require any flow-specific treatment, it still has to be able to set a label on well known flows (for example for TCP connections and application streams).

The default case is to set all flow labels to zero, i.e. when the node does not assign specific labels to flows. In case of labeling in a stateless mode, it should assign each "unrelated transport connection and application data stream to a new flow". This becomes more difficult with the vague definition of a flow. When a flow is "not necessarily 1:1 mapped to a transport connection", it is yet defined as follows: "A typical definition of a flow for this purpose is any set of packets carrying the same 5-tuple {dest addr, source addr, protocol, dest port, source port}". Application and transport layers were previously in charge of the flow definition in RFC 3697, but it is not longer specified.

However, the RFC is more verbose on the statistical distribution of flow labels, which should be an approximation of a discrete uniform distribution. It does not forbid to set the same label for two flows, as long as it remains a low-probability event.

The flow label assignment in a stateful scenario is not covered by this standard.

can be bypassed by the application itself, with the help of the standard setsockopt() function, with IPV6_AUTOFLOWLABEL as parameter:

const int off = 0; const int on = 1; int s; /* socket */ /* disables automatic flow label */ setsockopt(s, IPPROTO_IPV6, IPV6_AUTOFLOWLABEL, &off, sizeof(off)); /* enables automatic flow label */ setsockopt(s, IPPROTO_IPV6, IPV6_AUTOFLOWLABEL, &on, sizeof(on));

This option has to be set before the beginning of the data transmission, and cannot be changed over the connection lifetime. It works for TCP and UDP sockets.

For listening sockets, the operating system randomly sets in the same way flow labels. It means that each child of a TCP listening socket will have a different flow label value, regardless of the label received.

Read the flow label value

To read the flow label value set by the kernel, the draft tells to call the function getsockname(): struct sockaddr_in6 src; int s; /* socket */ socklen_t slen; /* obtain the flow label value */ slen = sizeof(src); getsockname(s, (struct sockaddr *)&src, &slen); printf("flowlabel=%x\n", ntohl(src.sin6_flowinfo & IPV6_FLOWLABEL_MASK));

Though in practice, it does not work (the returned value is always zero), and a look at the kfreebsd code confirms that the flow label is not returned with a getsockname(). To read the received flow label, both implementation and the draft are consistent: it is not possible.

Flow label to Solaris

To test the flow label status on Solaris, we used the last development version of OpenIndiana, a OpenSource version of Solaris 10.

On this system, the field sin6_flowinfo defined in RFC 3493 is used for the sockaddr_in6 C structure. For an outgoing socket, an application can set the field sin6_flowinfo with a flow label. Since the sin6_flowinfo can contain the Traffic Class, a mask has to be applied to the flow label value (0xFFFFF is the hexadecimal value of the last 20 bits of the field): int s; /* socket */ int label; /* the flow label value */ struct sockaddr_in6 dst; dst.sin6_family = AF_INET6; dst.sin6_port = port; dst.sin6_flowinfo = htonl(label &0xFFFFF); connect(sockfd, (struct sockaddr*) &dst, sizeof(dst))

The code works for UDP and TCP protocols, as well as ICMP. During our tests, we have not found any way to read the flow label set by applications or to read the flow label received from a remote server. For listening sockets, no solution is implemented to set a flow label.

MAC OS X

Even though the Kernel of MAC OS X has a network stack based on the BSD system, and that the IPv6 stack comes from the KAME project, the implementation of flow labels is slightly different on Mac OS X.. Tests are run on the versions 10.6, 10.8 and 10.9 of MAC OS X.

We notice an evolution on the flow label implementation, confirmed by the available code of the Darwin Kernel (the OpenSource part of MAC OS X).

Version 10.6

On the version 10.6 of MAC OS X, the C code above used to set a flow label on Solaris works, in a client mode. Without any configuration, the flow label of a TCP connection is always zero.

The behavior is not the same with the UDP protocol. The same sysctl entry as on BSD systems is available. The net.inet6.ip6.auto_flowlabel automatically controls flow label assignment for UDP. This assignment is very simple: it follows incremental values, allowing someone outside the network to know the number of connections used by a computer. Individual configuration is not possible to configure sockets, the IPV6_AUTOFLOWLABEL option always returns an error.

Version 10.8

On the version 10.8 of MAC OS X, the flow label assignment for TCP sockets is the same as the version 10.6. However, the IPV6_AUTOFLOWLABEL does not return an error anymore, but is simply ignored by the operating system.

On the UDP socket, it is now allowed to disable or enable the auto-assignment of a label with the IPV6_AUTOFLOWLABEL option. The label values still follow an incremental sequence.

Version 10.9

On the version 10.9, of MAC OS X, flow label implementation is a mix between the BSD auto assignment solution and the one per application manual assignment of Solaris. First, the net.inet6.ip6.auto_flowlabel sysctl and the IPV6_AUTOFLOWLABEL socket option are available. They work both on UDP and TCP sockets. Furthermore, is is now possible on a TCP socket to manually set a label with the sin6_flowinfo, with the same code as with Solaris. The developer of an application can choose between three alternatives to manage flow labels on MAC OS X: 4.1: TCP flow label behavior on MAC OS X (versions 10.6, 10.8 and 10.9).

• Let the Kernel take a random value;

• Manually set a non-zero value;

• Disable the automatic setting and do no set a value to get a zero flow label.

For listening socket, only the Kernel random value is available. We have not yet found any solution to read the label allocated by the Kernel and to read the received flow label value.

Comparison of MAC OS X versions

The TCP client behavior on MAC OS X is summarized in Table 4.1. The autoassignment of labels did not work before the version 10.9, but an individual configuration like on Solaris is allowed. This configuration has the priority on the random value assigned by the Kernel on the version 10.9.

Results on a listening socket are not listed in the table, since it only works for MAC OS X 10.9 with an auto-assignment.

The behavior for UDP sockets differ considerably from TCP sockets, as summarized by table 4.2. First, the sin6_flowinfo field is always ignored. Second, it is always possible to automatically assign a flow label with the Kernel. On the version 10.6, only a global configuration is possible with the sysctl. On the version 10.8, the IPV6_AUTOFLOWLABEL option works. On the 10.9, the auto-assignment returns a random value, in accordance with RFC rules.

Version

No flow label on Microsoft Windows

The IPv6 API is very restricted on Microsoft Windows, and many standardized options are not available. We ran tests on Windows 7 and Windows 8, without any success to set or read a flow label on a socket. Since these features are not documented, it is likely not possible at all.

Comparison of operating system implementations

To summarize our results, Table 4.3 depicts the capacity to set a flow label on an operating system. On BSD and MAC OS X, the Kernel can randomly set a flow label value whereas applications ask for it. On Solaris and MAC OS X, an application can freely set an arbitrary value, even if another application already uses it. On the MAC OS X, the manual setting has the priority on the random value.

Operating We tried to read flow label sent and received by TCP socket. It is currently not possible on the majority of operating systems, except for Linux that we describe in the next sections.

Need of the Linux API refactoring 4.3.1 Historical implementation on the Linux Kernel

The flow label implementation on Linux was released in the version 2.2.7, in April 1999. Implementation choices are documented in the current iproute documentation [START_REF] Alexey | IPv6 flow labels in Linux-2[END_REF]. Between 1999 and 2013, no real change has been made on this API, only some small internal refactoring.

Principles of the implementation

The implementation is based on a new socket option IPV6_FLOWLABEL_MGR of the standard setsockopt() function. IPV6_FLOWLABEL_MGR takes as argument a C structure named in6_flowlabel_req, allowing to pass many configuration options. This implementation is based on the cooperation between the userspace (passing options, requesting options, etc) and the Kernel, managing the flow label assignment. This option itself is not enough to send packet with a flow label. After requesting a label, the application has to enable the option IPV6_FLOWINFO_SEND.

To read the current label, there is no easy way. All allocated flow labels are displayed in the /proc/net/ip6_flowlabel special file, but it implies parsing the file to read the information. Moreover, it is impossible to know whether an allocated label is set on a specific socket, or to another one.

Sharing and permission system

The Linux implementation provides means to set some permissions in a label. The process owning a flow label can share it with everyone, or restrict the sharing with all sockets of the process, or with processes of the user. Of course, the sharing can be fully disabled.

The current implementation in details

The in6_flowlabel_req structure is defined as follows: The first important member is the variable flr_action, which is used to set the requested action. Three different actions are possible: get a flow label (flow label request to the kernel), renew a flow label, or release a flow label. The get action can be completed by flags assigned in the flr_flags member. The flags can request the creation a new flow label, or ask for an already allocated label.

struct in6_flowlabel_req { struct
For the get action, flr_label can be set to a desired value, or to zero. In case of zero, the kernel will automatically assign a label.

The flr_share is here to allow or restrict sharing of label. Four options are possible:

• IPV6_FL_S_EXCL: this label is private (only for this socket);

• IPV6_FL_S_PROCESS: share this label with other sockets opened by the process;

• IPV6_FL_S_USER: all processes of the user can use this label;

• IPV6_FL_S_ANY: everyone is allowed to reuse this label.

The members flr_expires and flr_linger are used to set the label lifetime. A label will never be released while a socket is using it. Nevertheless, if nobody uses it anymore, the flr_expires is the minimum label lifetime, and the label will never be destroyed before this time (in seconds), even if all sockets that used it are closed.

The linger is the time (in seconds) before allowing a socket to reuse a flow label. Both timers are restricted to 60 seconds by default for users.

In conclusion, this API is not simple, but allows a variety of flow label applications. The Linux Kernel is the only operating system allowing a system of permissions for flow labels. This permission system is not trivial: it supports several sharing modes and a reservation time before reusing of a flow label. At the end, since the Linux Kernel is an Open Source project, this API can be extended for research purpose and to develop new applications based on flow label.

Limitations of the Linux Kernel API

Even though the Linux flow label API seems to be more complex than APIs of other operating systems, there were some bugs and limitations. Most of them are historical: the flow label definition was not the same in 1999 as today.

Restrictions incompatible with RFCs

Since Linux followed the rules of the RFC 1809, there were strong restrictions:

• One label is only valid for one destination. Even with sharing enabled, one label cannot be sent to more than one IPv6 destination address.

• All sockets of a label have to share the same set of IPv6 extension headers;

• The lifetime of a label is very short. A standard user cannot request a label for more than 60 + 60 = 120 seconds.

Lack of options in flow label Management

The flow label setting is fully featured, with many configuration options. However, after the initial setting, a software cannot follow the status of a label without parsing a special file. If the Kernel randomly assigns flow labels, it is even not possible to know the label in use Similarly, how should an application renew a label, without any knowledge of the label lifetime? Though it is theoretically possible to read incoming flow labels, it is not standardized for all protocols. Moreover, the implementation was bugged in some situation for the TCP protocol.

Modifications on the Kernel

All contributions described here are accepted and released in the version 3.13 and 3.14 of the Linux Kernel.

Removing old restrictions

We first removed the condition on the destination on the Linux Kernel API. With the current kernel, it is now possible to send one label value to more than one destination. It is very useful in case of label sharing for a user or an application. Many application flows indeed use more than one IP destination.

Second, we removed the obsolete condition on IPv6 extension headers. The rule that all packets sharing a flow label have to share the same extension headers is obsolete.

Adding options to read flow label

Sent flow label

To read the flow label assigned to a socket, we built a call with the function getsockopt. This reading is useful in some cases, for example when a software asks for a random flow label value to the kernels, but needs the value for future internal sharing. Similarly, an application needs to know the status of the label lifetime to renew it.

This new call follows the API defined for setsockopt(). The option name is IPV6_FLOWLABEL_MGR, and takes as argument a pointer to a C structure1 . The Kernel returns all label status in the following order:

• the flow label value assigned to the socket;

• the sharing permission of this label;

• the expire time left and the linger timer.

The only information available in the /proc file and not retrieved here is the identity of the label owner. The following code reads the flow label information and prints it to the user. For comparison, the /proc/net/ipv6/ip6_flowlabel file gives the following information:

Label S Owner Users Linger Expires 03707 255 0 1 6 59

The software is now able to read the flow label information and to take decisions based on it.

Flow label received

To read the received flow label, we extended our work with getsockopt() function.

The user can set the flag IPV6_FL_F_REMOTE to get the received flow label value. Of course, it does not contain any other information like the expire value, because they do not make sens locally. It was actually possible to get this information via the option RECV_FLOWINFO specified in the RFC 2292 [START_REF] Stevens | Advanced Sockets API for IPv6. RFC 2292[END_REF]. However, it is not so easy to because of the answer complexity, second, it was not consistent with the concept of flow label manager to read/set flow labels, and third is was bugged for some TCP states (the returned value was zero, and not the received flow label).

The reflecting option

In case of a stateful identification of flows based on flow label, it is a good feature that IP packets of a flow share the same label in both directions. Indeed, protocols like TCP send packets in both directions by nature, even if the payload is unidirectional. It was not possible to implement it in the userspace with the Linux kernel API, because some information is obfuscated to the userspace. For example, at the connection initialization, a listening socket can read the received flow label only after the internal Kernel processing for the TCP SYN/ACK packets. It is then too late to set the flow label on the SYN-ACK packet.

Description of the reflect mode

To achieve an early setting of the flow label, an implementation in the kernel is required. Our goal was to make all packets of a flow received and sent on a listening socket sharing the same flow label in both directions. It includes packets used for the initialization process and all TCP states, even for half closed sockets. Of course, this functionality is not limited to the TCP protocol. However, it could be implemented for UDP protocols in userspace before this new option.

To be consistent with the flow label API, a configuration flag for a flow label request has been added. With the IPV6_FL_A_GET action, an application can set the flag IPV6_FL_F_REFLECT.

Uniqueness in the flow label manager

In the behavior of the previous Linux Kernel, flow labels are unique. It allows granular permission management, but it triggers a problem for the reflect mode. Indeed, if a socket receives a flow label already set, reserved by a socket, what can the kernel do? Setting a flow label according to the received flow label value allows someone outside the system to set arbitrary values.

Not to break applications based on the permissions of the current API, we added a sysctl variable to bypass the restriction. This variable can be set or read with the sysctl command, or with the special file /proc/sys/net/ipv6/flowlabel_consistency.

Difficulties on TCP

TCP is a complex protocol with many states. The Kernel implementation has to follow all these states, but at the same time, it has to optimize the memory and processor consumption. This is why some states have a special structure and not the same as an established connection. The structure stores less information than the real one, reducing the memory pressure. The first state, which has a special structure, is of course the listening socket after the first reception of a SYN. To reflect the flow label received, the value cannot be stored in the listening socket structure, since the listening socket may have other children in case of simultaneous connections.

The only way is to store the flow label information in the inet_request_sock structure. This structure can store the header received in the first SYN segment. It is then possible to read the flow label sent with the SYN/ACK packet.

The second special case is the TIME_WAIT state. This state is reached by the end device closing the connection first. It allows the socket to be sure that the port will not be reused by another application for a short time, and to send acknowledgment to the last received packets (like the ACK of the FIN/ACK sent by the remote device).

It appeared during our tests that flow labels are not stored in the TIME_WAIT state, and that packets sent in this state are not consistent with the flow label set by the application. To fix it, we replaced some padding available in the inet_timewait_sock structure. The flow label value sets by the application (or by the received packet in the reflect mode) is stored, and the stored value is read to send ACK when needed. Since this padding was unused, not memory overhead is added on sockets.

Preload library

The solution presented in Chapter 2 is based on the flow differentiation to flow labels. The best way to achieve it is to patch each software, allowing a very fine granularity of flow label management.

However, it is not realistic to hope this major change on all software. It could be easy to patch popular2 software like the Firefox browser to set a label to each navigation tab, but there are too many applications to scale this solution.

To use the benefits of our solution without major change, we propose a solution to set automatically one label to each software. It will not break any application layer protocols, and it is sufficient to separate various activities of one user into several flows.

Preloading the library on dynamically compiled software

The call to the connect() function can be intercepted. It allows to check whether a flow label is already set and to continue with the standard function connect() if it is the case. Otherwise, the flow label can be enabled and a value (derived from the process identifier PID, and a random value generated at each system startup time) via the setsockopt() function.

Using this approach, patching every application is not needed to use spreading. At the same time, it does not interfere with a patched application since it does not overwrite an existing flow label value. Even if this is not an optimal solution, the gain is high in comparison with using just one address for all applications running on a given computer. returns immediately the real connect() function.

Implementation and installation of the library

The second step is to check whether the user has disabled the library. Indeed, a user can set an environment variable to disable the auto-configuration of a label if the software does not need to have one. It is complementary with the next step, when the library checks if a label is already assigned to a non-zero value. In both cases, the preload library does not correct user's wish and returns the real connect() function. Otherwise, the library assigns a label to the socket, thanks to the IPV6_FLOWLABEL_MGR option for setsockopt(). The assigned value is unique for each PID and sharing is only allowed within the same process.

Evaluation of the library performance

A potential latency cost comes from the library preload, that assigns a flow label to each application. Our tests were done on a virtual machine with a 2.4Ghz CPU. We ran 20.000 times four different tests:

• open and read a short file, with library preload disabled;

• the same command, but with library preload enabled;

• a short netcat command, sending an UDP datagram to localhost and quitting, without library preload;

• the same netcat command, with library preload enabled. The difference of time spent for the two first test (opening and reading with and without the preload library) comes from the load of the library at the startup, even though the library does nothing. It introduces an average a latency of 5.10 -5 seconds but only at the startup of the software (the library has to be loaded only once). The difference between the two netcat tests reveals the total overhead of the library, time to set up the flow label included. Taking the loading time away, the average latency overhead is 9.10 -6 seconds for each connection, Kernel time included.

As expected, our preload library does not have significant influence on the overall latency.

Conclusion on the flow labels implementation

Since there is no standard to define how operating systems should manage flow label assignement and no API defined to communicate between applications and operating systems, different implementations coexist. Some operating systems do not control flow label assignement at all, sending packets with always a zero value. In contrast, Linux is an operating system with a flow label manager allowing complex interactions between the operating system and the applications.

Our work on Linux makes it more usable and add several options. These options were needed for our work to provide flow identification inside thlocal networks. The IP address obfuscation describes in Chapter 2 cannot work without flow label assignment, or with bugged implementation like in the Linux Kernel versions prior to the 3.13. To help the deployment of our solution, we proposed a preload library, which cannot work checking whether flow labels are already assigned or not. The reading feature is mandatory for it. Additionnaly, the reflect mode can be useful for the spreading proposed in Chapter 3.

However, our work on flow labels is not specific to address spreading. Basic functionalities like reading the current assigned flow label, the received flow label, or replying with the same label are likely to be useful for other applications. For example, the proposition to secure TCP connections [START_REF] Blake | Use of the ipv6 flow label as a transport-layer nonce to defend against off-path spoofing attacks[END_REF] needs to read incoming labels. Another example is the proposition [START_REF] Schmid Stefan | Rsvp extensions for ipv6 flow label support[END_REF] with the RSVP protocol, which implies that the application can read the outgoing flow label assigned to a socket. We hope that the current implementation on Linux Kernel can help to test and deploy innovative solutions based on the flow label field. The encryption and decryption costs of the AES is considered in Section 5.2. The following section describes a way to resynchronize spreaders, thanks to overlapping windows. It is an efficient way to quickly counterbalance this desynchronization and avoid more packet loss.

An evaluation of address spreading to protect an IPsec tunnel closes this chapter.

Evaluation of packet loss

Test beds

Several experimentations have be done on several test beds and this chapter presents results for two of them. The first test bed is an ideal case: a LAN. The typical roundtrip delay time (RTT), measuring the time for a short bidirectionnal communication, is around 2 milliseconds (ms). Packets are neither lost or desequenced. Figure 5.1 shows the cumulative distribution function of the RTT.

The second test bed is between a server in Germany using a 6to4 tunnel and a server with native IPv6 connectivity in France. The network is of poor quality: natural packet loss is about 1% and desequencing reaches about 0.5% on high network load. In the preliminary tests, the 6to4 tunnel was less congested at night. Tests were chosen to run at night to be less concerned by random congestion issues.

Spreading consequences

Tests description

To evaluate the address spreading performances, three tests have been run on each network. The first one sends a standard UDP echo packet. It provides a good evaluation of the network quality for packet loss and latency. The second one is a simple TCP handshake initialization, without data transfer. The last one is a TCP connection with data transfer (65 535 bytes). Because TCP is the most popular protocol on the Internet [START_REF] Zhang | Analysis of udp traffic usage on internet backbone links[END_REF] and the test involves data transfer, it is the best test to evaluate the user experience on a network with spreading. A timeout of 4 seconds is set on both TCP tests, after which the connection is considered as lost.

Simple spreading

Because of the imperfect computer synchronization and of the network latency, address spreading implies some packet loss, deteriorating network quality. As a first approach, a lifetime of one second is set for each address, without any backward or forward overlapping time windows. Figures 5.3 and 5.4 respectively show the results on the LAN and the 6to4 network.

On the LAN, UDP packet are never lost when adress are not spread. When spread, the percentage of failures is around 4%. As UDP does not retransmit in case of loss, the data transmission will never reach 100% of success even at long times.

For their part, the TCP handshake needs three packets to be completed and the connection establishment time of most TCP connections is consistent with the UDP test (three times larger). Some openings are delayed and become successfully completed with retransmission. Those can be seen on Figure 5.4 for the 6to4 network but not on Figure 5.3 because of the reduced graphic window.

On the 6to4 network, packet loss has big effects on TCP performance. During the connection opening, the noticeable steps correspond to the standard time of Linux retransmission strategy for TCP.

High frequency addresses switching

Obviously, the adress lifetime has a big impact on the connection quality. Lifetime duration between 50 ms and 2 seconds have be tried and the percentage of packet loss is summarized in Table 5.1. Figure 5.5 presents the comparison between these empirical results and the theoretical calculations of Section 3.4.1. For the 6to4 network, the typical latency is around 21 ms and a desynchronization of 8 ms was measured at the end of the experiment. These values give theoretically around 50 ms of transmission black hole. Experimental results are very close to this prediction. Nevertheless, since the 6to4 network looses some packets on its own, more failure than expected is observed as the spreading effect decreases.

On the LAN, the latency is approximately zero and desynchronization is the main issue. A desynchronization between 0 and 30 ms is measured, varying a lot during experimentations. An average value was taken to plot theoretical predictions and desynchronization produces a transmission black hole of 17 ms for each address switching.

Backward temporal windows for delayed packets

To prevent delayed packet loss, an overlapping temporal window can be used to accept packets identified with the previous address (see Figure 5 duration, both previous and current addresses of the sequence are accepted by the spreader. This technique is very efficient to decrease packet loss on the 6to4 network, as shown by Figure 5.7. With a temporal window larger than the sum of the network latency and the desynchronization, the same performance as without spreading are obtained. As depicted in Figure 5.8, it is, however, not enough to fully prevent packet loss on the LAN. Desynchronization is larger than latency and some packets arrive too early to the receiving spreader. In this case, the receiving spreader would have to accept the following address as well as the current one in order to avoid packet loss.

Forward temporal window to avoid desynchronization packet loss

To solve the desynchronization problem on the LAN and in general, an overlapping temporal window has been added to accept the future address (see Figure 5.9). Over the temporal window duration, both current and next following addresses of the sequence are accepted by the spreader. The results of UDP tests on the LAN are plotted in Figure 5.10, with an address lifetime of 200 ms and a backward temporal windows for previous addresses of 60 ms. Even if there is no latency, adding a sole forward temporal window accepting the following address is, however, not enough to fully avoid packet loss. The early spreader also has to accept the previous address, the same way as for packets arriving late because of latency (see Figure 5.11). Table 5.2 presents packet loss on the LAN with respect of both temporal window durations for previous and following addresses. Because of desynchronization fluctuations, some values can be confusing with decreasing loss with increasing temporal window durations. However, when both forward and backward temporal windows are larger than desynchronization, packet loss is sucessfully avoided. A value of 64 milliseconds for both window durations is enough here.

Configuration requirement to fully avoid packet loss

The optimal spreading configuration depends on the network quality between both spreaders. To fully avoid packet loss, the minimum temporal window duration for accepting the previous address is equal to the sum connection latency and desynchronization (see Figure 5.12). This value is not always stable, but the order of magnitude could be estimated by network administrators. Between two networks with a good Internet connectivity, latency is never more than 500 milliseconds. The second packet loss source is clock desynchronization between spreaders. If they are synchronized with the NTP, desynchronization should remain low and the forward temporal window accepting the following address can last very shortly, less than 100 milliseconds. Since the configuration of a forward temporal window is most useful in case of desynchronization larger than latency, this desynchronization should be detected, as explained in the next Section.

AES encryption cost

Because of the AES popularity, hardware optimization have very often been implemented for AES computations. With a recent Linux Kernel (version 3.10), a standard i5 Intel CPU at 2.4 Ghz is able to compute 2.6 millions AES computations (128 bit key with 16 byte blocks) per second.

As for the middlebox evaluation in section 2.4.3, performances of AES encryption have been evaluated with the OProfile tool. Tests show that the AES computation at the connection initialization marginally slows down the overall transmission in comparison with the packet processing.

Automatic resynchronization

Detection of desynchronization

Even with a perfect synchronization at the beginning of a communication, clocks of both spreaders can quickly desynchronize. This desynchronization can be detected Figure 5.12: Perfect configuration of spreaders, avoiding any packet loss.

thanks to temporal windows.

The number of late packets (sent with a previous adress) is not useful to assess desynchronization. Indeed, packets can be temporally delayed in the network, because of latency, without any clock desynchronization between spreaders. Information about early packets (sent with a future address) is therefore more meaningful. Their presence implies a larger desynchronization than latency and can be detected by one of the spreaders. This is why a spreader detecting a large number of early packets (according to the local clock) should adjust the connection configuration to change the clock used for the adress computation ahead. This adjustment is done by adding a small difference to the internal computer clock. With the Linux implementation, the standard time unit is a jiffy, used for measuring the time since the system start. The value of a jiffy duration is not absolute and depends on the compilation options.

Rules for resynchronization

The standard address spreading implementation is modified to test resynchronization. The implementation proceeds the following way:

1. Data is collected over ten lifetimes of the spread address. With an address spread every 100 milliseconds, data will be collected for a second. Collected data includes the count of periods with at least one early packet, the total number of early packets and the total of received packets;

2. If at least two spread addresses are received to early over a data collection period, the proportion of early packets of this period is computed;

3. If this proportion is larger than a defined threshold, the clock is adjusted by one jiffy. In a first stage, the threshold is set to 5%.

Counters are reset before to next iteratation of data collection.

A data collection period is needed to assess the presence of desynchronization. The second step is here to avoid to change time because of only one early packet, whose presence could be the sign of just a successful spoofing attempt or a short network latency variation. The third rule shares the same goal, the amount of received packets in advance has to be large enough to justify a clock adjustment. The value can be configured by the administrator.

Since this desynchronization may only be temporary, a rule is added to reverse the internal change. If no packet are received in advance for ten periods, the clock is delayed by one jiffy (if an adjustment is active).

Implementation and tests

To test the resynchronization proposition, a time synchronization is first forced between spreaders. They synchronize their clocks with the same NTP server, before starting the tests.

A connection is then initialized and a constant flow rate of packets is sent. The the threshold defined in the third step is set to 5%, meaning that the clock will be adjusted if more than 5% of packets come too early for the local clock.

In this test, the adress lifetime is set to 400 milliseconds. The backward overlapping temporal windows for late packets has a duration of 200 milliseconds. This value is arbitrary high to avoid any packet loss because of latency. Tests have be run on the LAN, with a very good performance and a low latency. Above tests showed that desynchronization has a major effect on this test bed.

Using a NTP server to provide synchronization

The synchronization forced at the test beginning is approximately perfect. After this synchronization, a NTP daemon runs during the test, without the option to force synchronization for very small differences with the reference server (this is the default configuration for a NTP daemon). Desynchronization rapidly appears after several minutes. Without any forward overlapping window accepting the following address, the first packet loss is detected.

However, the packet loss is never very high, even without our resynchronization mechanism, as shown on Figure 5.13. On this figure, the red plain curve corresponds to tests without the resynchronization mechanism. The NTP daemon avoids larger desynchronization and loss.

Since the packet rate is constant, the 5% threshold is only reached when the forward overlapping temporal window last more than 20 milliseconds, equal to 5% of the 400 milliseconds. In that case, the resynchronization mechanism starts to adjust the clock before the first packet loss and the connection is perfectly preserved. For temporal windows smaller than 20 milliseconds, the 5% rule is never reached before a NTP resynchronization occurs. The packet loss is reduce, thanks to the mechanism presented in section 5.1. Note that in the above section, the loss rate is equal to zero when the temporal windows is actually larger than the NTP tolerance.

If the threshold is reduced to smaller values, packet loss can be fully avoided. This auto-configuration provides a better security than a configuration larger than the NTP tolerance, since the temporal windows are shorter.

Disabling the NTP server after initialization

Without using NTP over the connection duration, internal resynchronization is mandatory. Indeed, after a while, both spreaders can be completely desynchronized and all packets are then lost. The dashed blue curve on Figure 5.14 depicts this case. After 50 minutes, both networks can no longer communicate.

As with NTP, a value of 24 milliseconds is enough to match the 5% rule and to fully synchronize spreaders, without any packet loss. For smaller values of the temporal window, resynchronization only works with a big rate of packet loss (loss reduces the amount of accepted packets, and increases the proportion of early packets).

The 5% rule is, of course, an arbitrary value. With a smaller value, a shorter temporal windows will be enough to match the rule and to provide synchronization without any packet loss. However, experimentation showed that this is a good rule of thumb.

Limitation of detection and resynchronization

This synchronization method, based on the traffic received by both spreaders, suffers from some limitations. The first obvious one is that synchronization only works with a minimum traffic between both spreaders. If the networks do not send any real traffic, spreaders have to send dummy packets to provide synchronization.

The second limitation happens with a brutal resynchronization of a system clock, for example by a manual command of an administrator. The internal adjustment cannot detect it and could break the connection.

Benefits of address spreading with IPsec

IPsec is the standard and widely deployed protocol to provide security at the IP layer. It supports many features, like communication authentication, packet payload encryption, session negotiation at the beginning of a transmission, etc. It works in a transport mode (securing a communication between two hosts) as well as in a tunnel mode, securing communication between two networks by encapsulating packets sent by hosts.

However, the strength of IPsec can sometimes be a weakness: since packet authentication happens close to the communication end, it is impossible to filter packets on an upstream firewall. It introduces a risk of denial of service, by consuming CPU resource of the IPsec device (due to CPU computations required for validating IPsec packets) or by consuming all the available bandwidth. The problem cannot be solved by design without delegating security to an upstream device, which can be a problem for many networks.

In this section, address spreading is evaluated to provide authentication of IPsec flows. Address spreading is done with an additional key, which the IPsec device can send to upstream firewalls.

Identification of IPsec flows

IPsec packets contains the standard IP headers and one additional header, in order to choose between one Authentication Header (AH) [START_REF] Kent | IP Authentication Header[END_REF] or one Encapsulating Security Payload (ESP) [START_REF] Kent | IP Encapsulating Security Payload (ESP)[END_REF]. The first step of the flow identification requires the two source and destination addresses and a Security Parameters Index (SPI). Only packets matching a context with this triplet will be transmitted for cryptographic computation. This flow identification before the cryptographic computation is weak: IP addresses are easy to know for an attacker and the SPI is only 32 bits long. An attacker out of the communication path can guess the SPI value and an attacker on the path can send packets with valid SPI.

CPU on

Spreading to protect IPsec devices

Addresses of the IPsec flow can be spread to provide IPsec filtering. The use of IPsec solves the secret exchange problem, because it can be done during the session opening with an extension of the IKEv2 protocol [START_REF] Kaufman | Internet Key Exchange Protocol Version 2 (IKEv2). RFC 5996[END_REF]. The two IPsec devices will spread the IPsec session thanks to this secret and will send this secret to upstream firewalls. With our solution, firewalls will not be able to send valid IPsec packets or to read the encrypted data: they do not have the key. There are though able to follow the sequence of IP addresses and to filter invalid packets. It provides additional security, without compromising basic security or confidentiality of the IPsec flow.

Performance benefits of spreading to protect IPsec devices

The benefit of address spreading in cooperation with IPsec has been tested in laboratory. On the LAN test bed, a simulated attacker spoofs many IPsec packets, with a fixed rate. The IP source address of packets sent by the attacker was always forged, taking the IP address of a legitimate tunnel. Two kinds of attack tests were conducted: with or without a valid SPI of the established IPsec tunnel.

The legitimate tunnel was sending a constant data flow, taking all the available bandwidth between the firewall and the IPsec receiver, on a 100 Mb/s link. The firewall was connected to a simulated Internet with a bandwidth of 1Gb/s, allowing an attacker to send many packets.

Table 5.3 summarizes the results. The limiting resource is here the bandwidth between the firewall and the IPsec receiver. Even without any knowledge of the SPI, the attacker can inject traffic on this link and reduce the available bandwidth. As a side effect, it reduces the CPU consumption on the IPsec receiver: the rejecting of forged IPsec packets is faster than an decryption of real packets.

With the knowledge of the SPI, the attack could be more efficient. It takes both bandwidth and CPU resources on the IPsec receiver. With a faster network, the CPU could be the limiting resource.

Without any knowledge of the SPI for attackers, address spreading protects against bandwidth saturation. Knowing the SPI, an attacker can overload the CPU. In that case, address spreading provides a very efficient protection to discriminate real packets for a low CPU cost on the firewall.

The spreading is here very efficient to protect the IPsec receiver: all the packets are dropped by the upstream firewall, protecting both CPU and bandwidth of the IPsec receiver.

Conclusion: performance of the spreading

As expected with our theoretical work, address spreading without forward or backward overlapping temporal windows reduces performance. Some packets are rejected due to network latency and to device desynchronization. It leads to a false positive detection: packets should be accepted. To evaluate the performance consequences on real data transfers, the impact of this loss was tested with the popular TCP protocol. Performance is heavily reduced in case of high frequency switching.

However, we propose to use overlapping temporal windows to avoid this drawback. In this mode, the spreader can be listening on several addresses on the same time. It complexifies the identification by the spreader (the looking for a valid state is more complicated), but fully restores the network performances. With temporal windows larger than the latency and larger than the acceptable time desynchronization, packet loss falls to zero, even with high frequency switching.

This high frequency address spreading protects networks against spoofing, since the attacker cannot guess the next address in use. Any reduction of the address lifetime and of the temporal windows' duration will improve the security, reducing the replay attack risk.

In the same performance spirit, the use of overlapping temporal windows has a second advantage: they can be used to detect devices' desynchronization and to automatically fix the gap between both clocks. For a small desynchronization, it is more efficient than synchronization through a NTP daemon. The only condition is, of course, a running traffic between both spreaders. An exchange of dummy packets when the traffic is too low could be considered.

The last part of the chapter proposes a first evaluation of the use of address spreading to protect an IPsec device. Results show a real improvement of performances, without reducing the end-to-end security of the tunnel. This solution looks promising to deploy a global secure architecture.

Chapter 6 Conclusion

This thesis focused on IPv6 headers, and more specifically on identifiers of their headers, called addresses. My main interest was to imagine what could be done with the large IPv6 address space? What properties can be added to improve security and privacy? I proposed two answers to this question. The first is the introduction of ephemeral addresses, protecting the correlation between flows and user activities. They do not protect against powerful attackers, but still provide some privacy at the network layer. It prevents the easy linking between IP addresses in use and all user's web surfing (Online Banking, casino, newspapers, political blogs, inspiration for marriage proposal, search on health trouble. . . ), a linking that is very valuable for some companies, but not really for the user.

My second answer is the introduction of address spreading. It further develops the concept of ephemeral addresses when cooperation is possible between communication partners. The advanatge being that addresses do not have to be valid over a connection lifetime, and can be changed at a very high frequency. I named it address spreading, taking the "spread-spectrum" terminology used in wireless communication. At the IP level, address spreading defines a new paradigm to identify flows.

In this conclusion, I will first describe the main advantages, drawbacks, and outlooks for the ephemeral addresses. Since ephemeral addresses need a signalization through flow labels, I will explain the challenges for the flow label management in the future. I will close this thesis with a description new research topics opened by address spreading, which could provide real benefits for Internet security.

Ephemeral addresses

I defined ephemeral address as an identifier for an unique flow, with a very short validity. Designed to protect user's privacy, their lifetime is no longer than the transmission duration. It is the shortest validity duration to avoid connection cut and this short lifetime implies the use of many addresses. This address consumption was of course not realistic with IPv4, because of the well known IPv4 address exhaustion problem, but this thesis proves the feasibility of deploying such a solution on the IPv6 Internet.

In the next paragraph, I will summarize the advantages of ephemeral addresses. I will explain then the main drawbacks of my solution, and the difficulties to deploy it on a very large scale. I will close the section with a proposition of further research to solve this issue, allowing a large scale deployment and better privacy protection.

87

Advantages and deployment of ephemeral addresses

On initial examination of IPv4 NATP and the ephemeral addresses they look alike. Both solutions are rewriting internal addresses, to external ones. Both impact privacy: real IP addresses are obfuscated. An external observer cannot find the IP address in use, and precisely identify a computer user behind the rewriting device.

However, the similarity ends here. The address space size redefinition between both versions of the IP protocol made a fundamental change, allowing the emergence of protocols based on new basics. The principle of ephemeral addresses is laid on IPv6 headers only, and no other protocol identifiers. The bijectivity of the flow transformation function F is easy to provide, thanks to the 64 (at least) available bits of the interface identifier.

The manipulation of IPv6 headers alone has many advantages. First, it simplifies the packet parsing, improving the performance of rewriting. Second, it improves rewriting compatibility with software applications. If this compatibility is still an issue, a solution can be provided to disable the ephemeral address rewriting for specific protocols or flows.

This disabling of ephemeral addresses is based on the same signalization as the flow categorization: flow labels, which are specific of IPv6 headers. The assignment of flow labels by end devices allows one to find group connections that belong to a same application flow. This grouping is much more efficient than an en-route packet parsing, and maintains the intelligence at the network borders, not in the network. With this solution, the application itself can choose to allocate ephemeral addresses, providing the best possible compartment of packets.

Of course, the use of ephemeral addresses cannot be compared with full featured solutions like the AN.ON project of the Tor network. It does not provide any real anonymity, and a powerful attacker can still identify the user behind an ephemeral address. The user has to choose between a powerful solution, at a high cost, or this lightweight protection for daily use.

One key of the protection benefit of ephemeral addresses is the number of users behind the middlebox. Of course, this information is not always known by attackers, but an unique user behind a middlebox is not really protected. Someone having this information knows that all outgoing flows of the middlebox are owned by this user.

To provide a large group of users, middleboxes can be cascaded. One example of this kind of cascade could be a middlebox at the home router place, providing a group composed of all residents of that home. A second middlebox can be provided by the ISP, at the network borders connected to other Autonomous Systems (ASs). With this architecture, the ISP cannot extract with a traffic analysis more information than already available for connectivity purpose (this IPv6 prefix is assigned to this customer, at this address), and the user privacy is protected outside the ISP network. It does not break the eventual legal requirements, the rewriting can be logged on both devices.

The stateful drawback

However, the large scaling of middleboxes is limited. The flow transformation is stateful, each couple (IP int , label) is stored and linked to an external address IP ext . The states protect against collisions, and provide an easy way to cache values like the checksum modification, and allow to fully randomize interface identifiers. In other words, states are the proof of the bijectivity of F . An external address is linked to one and only one internal address.

This stateful solution has two drawbacks. The first one the status of single points of failure for middleboxes. A middlebox outage will reset all the states, and therefore will break all established connections. The second issue is the difficulty to synchronizes states between several output points on a large network, such an ISP. States have to be synchronized between all routers in order to safeguard the bijectivity of F . It is not acceptable that F (IP int , label) return an IP address IP a on a first output point, and IP b on a second one.

To a stateless rewriting of addresses?

To solve this issue, a future work is to find a stateless function F , defined as follows:

F (IP int , label, secret) = IP ext
The F function takes as argument the same pair (IP int , label) as the middlebox proposed in chapter 2, and a new secret argument. This argument is shared between all middleboxes of an ISP, and protects the F function against attackers. The goal is to prevent attackers from guessing the IP int address with the IP ext information.

Since the F function has to be stateless, the reverse function F -1 is harder to define. It has to be a function taking only the external part of the identifier (here, only the IP dst value) and the secret, to provide a mapping to the internal network:

F -1 (IP dst , secret) = IP int
One example of functions providing a mapping between internal and external values, protected by a secret, is given by the encryption functions. The main difficulty here is the small size of data to encrypt, if a 64 bits size is assumed for the interface identifier. There is a collision risk for outputs (breaking the bijectivity of F ), and a security risk that someone observing the external traffic guesses the secret.

Such a definition of a stateless and secure function F has many advantages: a possibly wide deployment, and a simplification of the mapping logging. The storage of each mapping is not useful anymore, because the secret value is enough to rebuild an identification.

Outlooks of flow label management

One of the key features of ephemeral addresses is the signalization between end devices and middleboxes, through flow labels. In my practical evaluation, I experienced the problem of flow label assignment and of the communication between operating systems and software.

The lack of a standard API explained in chapter 4 is an important issue for deploying flow labels. All protocols defined by engineers and researchers, and using flow labels have the same problem: it cannot work without any end device cooperation.

The overview of the flow label manager implementation on several operating system is a first steps to providing compatibility, with a multi-platforms library. Such a library could help developers to set and use flow labels, to build innovative applications based on IPv6.

However, such a library is not even a long term solution without any work at the IETF or other standardization organization to provide a standard. Even for Quality of service (QoS) purposes, applications have to cooperate with operating systems to assign labels. An extension of the IPv6 socket API is mandatory.

Even though this standardization process is not a current topic, the relevance of this question is proved by the evolution of the features provided by some of the main operating systems. In the last changes, there are of course some security fixes, like forbidding the use of incremental values to set a label, broadcasting the number of connections used on a computer. In the same time, flow label support is being improved on some operating systems, such as the MAC OS one and the Linux Kernel. After my work to fix the flow label implementation and provide new feature on the Linux Kernel, a new functionality has been added by a Google developer to support the IPV6_AUTOFLOWLABEL option, like in the BSD systems. It could become a de facto standard, if the standardization process does not provide an alternative.

Address spreading: a new research topic

The most important contribution of this thesis has been to define and test address spreading. I defined a new clock based identification paradigm, on the top of IPv6. It provides a more secure identification, since an attacker is unable to guess to next address in use, and cannot insert packets in the network protected by spreaders. The solution does not use any external header, preserving the network performance and reducing the risk of packet dropping by an intermediate node that would not recognize the additional headers. Furthermore, it does not need any upgrade of intermediate routers and the solution is fully compatible with the current Internet.

In this section, I will summarize the theoretical proposition and my experimental results. I will describe in another paragraph the most important remaining issues, that I have not had the time to solve. I will close this thesis with some applications for the address spreading, with innovative use cases and propositions to take advantage of all the solution.

Results of this thesis

Theoretical propositions

Address spreading is the first attempt to transform a flow relying on a function:

F (packet, time)
that returns an address temporal sequence. I described in chapter 3 the details of an initialization protocol, providing a separation of each unique flow to an unique sequence. As for ephemeral addresses, the use of the flow label field allows a more granular flow identification, inside a trusted network.

I analyzed the risk of false positive detection. With address spreading, a new metric is inserted: the time. The time is a difficult concept on computers, and more specifically on the Internet. Indeed, all communications take time to be transmitted, which is called latency. This latency depends on the route taken by packets, on the current congestion, and can fluctuate anytime. With address spreading, some packets can be rejected due to this latency, because they come to late for a valid identification on the destination spreader.

I proposed to add overlapping temporal windows, to accept simultaneously the current address computed fo the current time and the address previously in use: F (packet, time), F (packet, time -1) If this temporal window is larger than the latency, it protects against packet rejection.

Since two computers cannot be perfectly synchronized, I added a second overlapping temporal window for the future address in use. For a short duration, the spreader will accept both F (packet, time) and F (packet, time + 1). This window has two functions. First, it prevents rejecting packets because of time desynchronization. Second, it allows for the detection of desynchronization, and to automatically resynchronize devices.

Tests and performance evaluation

I completed the theoretical work on address spreading by an evaluation of performances and tests on the Internet in chapter 5. My implementation is based on the Linux Kernel, and the packet processing follows the steps described in the theoretical part of the thesis. I had two test beds, one in a laboratory, and one across the Internet and a low quality 6to4 tunnel.

This evaluation is the first real evaluation of a clock based protocol on IPv6 networks. For example, the MT6D proposition [DGU + 11] does not provide performance tests on the Internet, and the Shim6 privacy extension [START_REF] Bagnulo | An architecture for network layer privacy[END_REF] has never been implemented.

Tests were consistent with the theoretical evaluation, and the introduction of overlapping windows is very efficient to protect against false positive detection. Even across a low quality network, the address spreading was able to provide a high frequency switching of addresses, with negligible impacts on network performance.

Most important remaining issues

However, this promising work opens some issues. The first one remains time fluctuation. The overlapping temporal windows solved false positive detection, inside an acceptable fluctuation value, but not more. The second issue is the secret exchange between spreaders, which is out of the scope of this thesis. Without this exchange, the architecture is not fully described.

Time synchronization and latency

The Internet traditionally does not provide any kind of performance warranty. Each packet is independent, and a packet can be much faster than the next one in a flow. This variation is a problem for a clock based identification: a packet slower than the configured allowance will be rejected. However, this problem is often restricted. Internet network connectivity is improved each year , and the fluctuation are often included within a range, as proven by the tests on 6to4.

The problem becomes more critical for a brutal and fast variation of the latency, often due to a route change because of a device failure. For example, figure 6.1 depicts the measured latency between a server connected by the French hoster OVH and a server connected through the hoster Gandi. Frequently large fluctuations and some anomalies over a large period of time have been observed.

This fluctuation has to be further analyzed. An evaluation on the PlanetLab network [CCR + 03] was planned, but at the time of the thesis writing, IPv6 was unfortunately not supported.

The second desynchronization issue is a brutal reconfiguration of the spreader clock. Spreaders are able to detect and to correct a clock desynchronization, but it is a symptom of a bigger issue. If clock desynchronization becomes too high, a manual reconfiguration will probably occur in the future, breaking the adjustment computed for address spreading. For both issues, further analysis are mandatory to evaluate the impact of the problem, and to optimize spreader configurations.

Exchange of the secret

Another issue raised by address spreading is the need of a secret shared by spreaders, exchanged before the first connection. It makes an auto-configuration harder, and harder to deploy for administrators. Fortunately, the exchange of secrets is a common problem on the Internet. Good solutions already exist, and the address spreading does not have to invent a new one. However, an evaluation of them in the address spreading context is needed.

Extend address spreading to more use cases

Since address spreading consumes very few resources, it could be deployed on many networks. For example, it could be relevant to deploy this identification paradigm in Smartgrids [GXL + 12], or in RPL networks [WTB + 12].

Furthermore, the use case variety could be increased with small improvements of the solution. I present some of them in this thesis ending.

Multihoming

Multihoming is an interesting extension field for address spreading. Indeed, since the identification process is enhanced by the address sequence, spreaders can easily be multihoming aware: the most important part of the identification is the interface identifier, not the prefix.

A first approach to enable multihoming will be to add a configuration option on spreaders, to set several prefixes for the destination network.

Patched last routers -end-to-end security

The best place to enable spreading is discussed in the chapter 3. One proposition is to add a patched router, receiving a partial information on the secret to follow the relevant part of the sequence for packet transmission. A solution has to consider a way to give partial information to the router: enough to follow the mapping between IP destination addresses received from the Internet and the local MAC address, but without the capacity to build a flow (the key to generate the second address involved in the spreading is still secure).

The security of the information transfer is not the only issue. A performance evaluation is needed as well.

Integration with firewalls

With a secure way to transfer partial information from spreaders to other devices, it becomes possible to build a better integration with firewalls. In the current architecture of address spreading, a stateful firewall can only be placed in local networks, behind spreaders. It does not make sense to try to filter spread packets, with a paradigm based on static flows. This figure 6.2 depicts the current architecture. With this solution, spoofed packets still consume resources on the path between attackers and spreaders.

In the future, it could be very interesting to send partial information to upstream firewalls, allowing a partial filtering as soon as possible. Figure 6.3 depicts this proposition. With this architecture, packets coming from the Internet will first be analyzed by upstream firewalls, and partially filtered. Second, spreaders will reject all of them which do not exactly follow the spreading. Lastly, a standard router can filter packets thanks to the traditional policy. This firewall is useful to apply the traditional filtering policy between networks A and the B.

IPsec extension

Another promising research topic is the combination between IPsec and address spreading. First experimental results in chapter 5 have shown that it can provide additional security, and protect devices against spoofed packets. Without the spreading, an attacker can consume a lot of resources on IPsec devices, taking resources to invalidate packets.

A very good synergy could be built: thanks to IPSec and the IKEv2 protocol, we could add an extension to generate a secret between both devices. This secret could then be used to generate address sequences.

One last advantage of this solution with IPSec is to allow the transmission of the secret used to generate the sequence to an upstream firewall, and not only partial information as described above. The firewall is then able to quickly discriminate packets on the communication path, adding a protection against denial of service and spoofed packets. The end-to-end security remains, the IPSec packet is protected thanks to other secrets to provide confidentiality and integrity.

Figure 1 :

 1 Figure 1 : Étaleurs à la frontière du réseau local.

xiiRÉSUMÉFigure 2 :

 2 Figure 2 : Rejet de paquet provoquée par la latence.

Figure 3 :

 3 Figure 3 : Rejet de paquet provoquée par la désynchronisation.

Figure 4 :

 4 Figure 4 : Configuration parfaite des étaleurs, sans aucune perte de paquet.

Figure 5 :

 5 Figure 5 : Architecture de la solution : l'étalement par le boîtier.

4 . 2

 42 UDP flow label behavior on MAC OS X. . . . . . . . . . . . . . . . . . . 4.3 Socket labelling on various operating systems. . . . . . . . . . . . . . . . 5.1 Proportion of packet loss with respect the adress lifetime on the LAN and the 6to4 network with UDP protocol. . . . . . . . . . . . . . . . . . 5.2 Influence of forward and backward temporal window duration on packet loss, in case of desynchronization (UDP on LAN). . . . . . . . . . . . . 5.3 Performance of IPsec spreading within a LAN. . . . . . . . . . . . . . . Flow management on the Internet . . . . . . . . . . . . . . . 1.2 Consequences of using IP addresses identifiers . . . . . . . . 1.3 Flow transformations: identifiers for special cases . . . . . . 1.3.1 Private addresses and the renumbering problem . . . . . . . . 1.3.2 Locator/Identifier Separation Protocol . . . . . . . . . . . . . 1.3.3 Host Identity Protocol . . . . . . . . . . . . . . . . . . . . . . 1.3.4 IP address exhaustion and the NAT . . . . . . . . . . . . . . 1.3.5 Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Security and privacy consequences of flow transformations 1.4.1 Security of flow transformations . . . . . . . . . . . . . . . . . 1.4.2 Do not broadcast identifiers to protect privacy . . . . . . . . 1.5 New flow properties offered by IPv6 . . . . . . . . . . . . . . 1.5.1 New IPv6 features . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Local Network Protection . . . . . . . . . . . . . . . . . . . . 1.5.3 Cryptographic protection of addresses . . . . . . . . . . . . . 1.5.4 Site Multihoming by IPv6 Intermediation . . . . . . . . . . . 1.5.5 Encoding more information in addresses . . . . . . . . . . . . 1.5.6 Solving the renumbering problem thanks to NPTv6 . . . . . . 1.6 Clock based flow identification . . . . . . . . . . . . . . . . . 1.6.1 Shim6 extension for privacy improvements . . . . . . . . . . . 1.6.2 Address hopping thanks to the application layer . . . . . . . 1.6.3 A Moving Target IPv6 Defense . . . . . . . . . . . . . . . . . 1.7 Toward dynamical identifiers . . . . . . . . . . . . . . . . . . 1.7.1 Dynamical identifiers without adding headers . . . . . . . . . 1.7.2 From temporary to ephemeral addresses . . . . . . . . . . . .

+Figure 1

 1 Figure 1.2: Structure of a IPv6 address and real example

2. 3 . 4 .

 34 Concatenate the modifier, 9 zero octets and the public key. Execute a hash function on the concatenation. The 112 leftmost bits of the hash are named Hash2; Check that the left 16 * Sec leftmost bits of Hash2 is equal to zero. If not, increment the modifier and go back to step 2 (these first three steps are represented in Figure 1.3); Concatenate the final modifier value, the subnet prefix and the encoded public key. Execute a hash function on the concatenation. The result is Hash1. The three leftmost bits of Hash1 are replaced by the Sec value and the result is set as the interface identifier (see Figure 1.4); 5. Assign the new IP (Prefix + interface identifier) to the interface; 6. Form the CGA parameters data structure by concatenating the final modifier value, the subnet prefix, and the encoded public key.

Figure 1 . 3 :

 13 Figure 1.3: Algorithm to find a Hash2 consistent with Sec value (steps 1-3)

Figure 1 . 5 :

 15 Figure 1.5: Shim6 connection: all routes are available

Contents 2 . 1

 21 Protection of user privacy thanks to address obfuscation . 22 2.2 Architecture and components for the obfuscation . . . . . . 24 2.2.1 Overview of the solution . . . . . . . . . . . . . . . . . . . . . 24 2.2.2 Computation on the middlebox . . . . . . . . . . . . . . . . . 25 2.2.3 Flow label assignment by application . . . . . . . . . . . . . . 25 2.3 Implementation with the Linux Kernel . . . . . . . . . . . . 26 2.3.1 Address rewriting and flow management by the middlebox . . 26 2.3.2 Our Netfilter Kernel module . . . . . . . . . . . . . . . . . . 28 2.4 Evaluation and consequences . . . . . . . . . . . . . . . . . . 30 2.4.1 Risk of address collision . . . . . . . . . . . . . . . . . . . . . 30 2.4.2 Compatibility analysis with the current Internet . . . . . . . 32 2.4.3 Performance of the middlebox . . . . . . . . . . . . . . . . . . 33 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figure 2

 2 Figure 2.2: Data transfer in the AN.ON project

Figure 2 . 4 :

 24 Figure 2.4: Outgoing (to the Internet) packet processing

Figure 2

 2 Figure 2.5: Incoming (from the Internet) packet processing

Figure 2

 2 Figure 2.6: The five location of Netfilter Hooks

3 . 3

 33 spoofing on the Internet and countermeasure . . . 3.1.1 Standard identification of a flow . . . . . . . . . . . . . . . . 38 3.1.2 Other spoofing protections . . . . . . . . . . . . . . . . . . . 38 3.1.3 Definition of address spreading . . . . . . . . . . . . . . . . . 39 3.2 Discussion on the best places to enable the spreading . . . 3.2.1 On the end device . . . . . . . . . . . . . . . . . . . . . . . . 40 3.2.2 Solution with a patched router . . . . . . . . . . . . . . . . . 40 3.2.3 On the communication path . . . . . . . . . . . . . . . . . . . 41 3.2.4 Delegation of addresses prefixes to the end device . . . . . . . 41 Detailed process of the protocol . . . . . . . . . . . . . . . . . 3.3.1 General principles . . . . . . . . . . . . . . . . . . . . . . . . 42 3.3.2 Step by step initialization . . . . . . . . . . . . . . . . . . . . 43 3.3.3 Detailed packet processing on spreaders . . . . . . . . . . . . 46 3.3.4 Detailed steps of packets processing (incoming packets) . . . 47 3.3.5 Identification of a flow thanks to the flow label field . . . . . 47 3.4 Loss of packets due to desynchronization . . . . . . . . . . . 3.4.1 Theoretical loss due to false positive detection . . . . . . . . 50 3.5 Conclusion on address spreading . . . . . . . . . . . . . . . .

Figure 3 . 1 :

 31 Figure 3.1: Address spreading without extra device (solution 3.2.1).

Figure 3 . 2 :

 32 Figure 3.2: Spreaders at the local network border (solution 3.2.3 and 3.2.4).

Figure 3 . 3 :

 33 Figure 3.3: Spreaders at the trusted zone border (solution 3.2.3).

Figure 3 . 4 :

 34 Figure 3.4: Time diagram of a connection initialization.

Figure 3 . 5 :

 35 Figure 3.5: Processing of outgoing packet (to the Internet).

Figure 3 .

 3 Figure 3.6: Processing of incoming packet (from the Internet).

Figure 3 . 7 :

 37 Figure 3.7: Packet dropping due to latency.

Figure 3 . 8 :

 38 Figure 3.8: Packet dropping due to desynchronization.

Figure 3

 3 Figure 3.9: ICMP echo failure rate vs latency.

  int s; /* socket */ struct in6_flowlabel_req freq; int size = sizeof(freq); freq.flr_action = IPV6_FL_A_GET; getsockopt(sockfd, IPPROTO_IPV6, IPV6_FLOWLABEL_MGR, &freq, &size); printf("Label %05X share %d expires %d linger %d\n", ntohl(flowstruct2.flr_label), freq.flr_share, freq.flr_linger, freq.flr_expires); It returns the following results: Label 03707 share 255 linger 6 expires 59

Figure 4 .

 4 Figure 4.1 depicts the internal process of the preload library. After the interception of the connect() call, it first checks whether the socket is an IPv6 socket. If not, it

Figure 4 . 1 :Figure 4 . 2 :

 4142 Figure 4.1: Features of the preload library.

Figure 4 .

 4 Figure 4.2 shows the measured times for the 20.000 iterations.The difference of time spent for the two first test (opening and reading with and without the preload library) comes from the load of the library at the startup, even though the library does nothing. It introduces an average a latency of 5.10 -5 seconds but only at the startup of the software (the library has to be loaded only once). The difference between the two netcat tests reveals the total overhead of the library, time to set up the flow label included. Taking the loading time away, the average latency overhead is 9.10 -6 seconds for each connection, Kernel time included.

Figure 5

 5 Figure 5.1: Performance of RTT for UDP echo requests on the LAN.

  Figure 5.2 shows the cumulative distribution function of the RTT. All devices of the networks are time synchronized on the same Network Time Protocol (NTP) server. It does not, however, provide perfect synchronization.

  Figure 5.2: Performance of RTT of UDP echo requests on the 6to4 network.

Figure 5 . 3 :

 53 Figure 5.3: Performance impact of a simple spreading on the LAN for UDP and TCP communications (1 second of address lifetime when spreading is enabled).

Figure 5 . 4 :

 54 Figure 5.4: Performance impact of a simple spreading on the 6to4 network for UDP and TCP communications (1 second of address lifetime when spreading is enabled).

Figure 5 . 5 :

 55 Figure 5.5: Empirical measurement and theoritical predictions of the proportion of failed ICMP echo transmission. l is the latency on 6to4 network, d the desynchronization on the LAN.

Figure 5 . 6 :Figure 5

 565 Figure 5.6: Temporal window for the previous address, solving the latency issue.

Figure 5

 5 Figure 5.13: Packet loss with internal resynchronization and a NTP daemon running. With respect to the forward temporal window address lifetime.

Figure 5

 5 Figure 5.14: Packet loss with internal resynchronization, without any NTP daemon. With respect to the forward overlapping temporal window address lifetime.

Figure 6

 6 Figure 6.1: Latency between OVH and Gandi IPv6 networks.

Figure 6

 6 Figure 6.2: Current architecture of address spreading protection.

Figure 6 . 3 :

 63 Figure 6.3: Address spreading protection with synchronized upstream routers.

1

  Étaleurs à la frontière du réseau local. . . . . . . . . . . . . . . . . . . . xi 2 Rejet de paquet provoquée par la latence. . . . . . . . . . . . . . . . . . xii 3 Rejet de paquet provoquée par la désynchronisation. . . . . . . . . . . . xii 4 Configuration parfaite des étaleurs, sans aucune perte de paquet. . . . . xiii 5 Architecture de la solution : l'étalement par le boîtier. . . . . . . . . . . xv 1.1 Excerpt of a NAT table (conntrack) on a Linux router. 192.168.0.0/24 is the local network, 203.0.113.1 the public IP address . . . . . . . . . . 1.2 Structure of a IPv6 address and real example . . . . . . . . . . . . . . . 1.3 Algorithm to find a Hash2 consistent with Sec value (steps 1-3) . . . . . 1.4 Algorithm to generate interface identifier (step 4) . . . . . . . . . . . . . 1.5 Shim6 connection: all routes are available . . . . . . . . . . . . . . . . . 1.6 Shim6 connection: fallback on another route . . . . . . . . . . . . . . . . 2.1 The Tor onion routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Data transfer in the AN.ON project . . . . . . . . . . . . . . . . . . . . 2.3 Architecture of the solution: spreading by the middlebox . . . . . . . . . 2.4 Outgoing (to the Internet) packet processing . . . . . . . . . . . . . . . 2.5 Incoming (from the Internet) packet processing . . . . . . . . . . . . . . 2.6 The five location of Netfilter Hooks . . . . . . . . . . . . . . . . . . . . . 3.1 Address spreading without extra device (solution 3.2.1). . . . . . . . . . 3.2 Spreaders at the local network border (solution 3.2.3 and 3.2.4). . . . . 3.3 Spreaders at the trusted zone border (solution 3.2.3). . . . . . . . . . . . 3.4 Time diagram of a connection initialization. . . . . . . . . . . . . . . . . 3.5 Processing of outgoing packet (to the Internet). . . . . . . . . . . . . . . 3.6 Processing of incoming packet (from the Internet). . . . . . . . . . . . . 3.7 Packet dropping due to latency. . . . . . . . . . . . . . . . . . . . . . . . 3.8 Packet dropping due to desynchronization. . . . . . . . . . . . . . . . . . 3.9 ICMP echo failure rate vs latency. . . . . . . . . . . . . . . . . . . . . . 4.1 Features of the preload library. . . . . . . . . . . . . . . . . . . . . . . . 4.2 Time to run 20.000 tests with library preload enabled/disabled. . . . . . 5.1 Performance of RTT for UDP echo requests on the LAN. . . . . . . . . 5.2 Performance of RTT of UDP echo requests on the 6to4 network. . . . . Performance impact of a simple spreading on the 6to4 network for UDP and TCP communications (1 second of address lifetime when spreading is enabled). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.5 Empirical measurement and theoritical predictions of the proportion of failed ICMP echo transmission. l is the latency on 6to4 network, d the desynchronization on the LAN. . . . . . . . . . . . . . . . . . . . . . . . 76 5.6 Temporal window for the previous address, solving the latency issue. . . 76 5.7 Performance impact of the backward overlapping window duration with TCP data transmission on the 6to4 network (address lifetime is one second). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.8 Performance impact of the backward overlapping window duration with UDP data transmission on the LAN (address lifetime is one second). . . 78 5.9 Temporal window for the following address, solving the desynchronization issue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.10 Performance impact of the forward overlapping window duration with UDP data transmission on the LAN (address lifetime is one second). . . 79 5.11 In case of desynchronization, the following address temporal window is not enough. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.12 Perfect configuration of spreaders, avoiding any packet loss. . . . . . . . 81 5.13 Packet loss with internal resynchronization and a NTP daemon running. Clock based flow identification . . . . . . . . . . . . . . . . . . . . . . . 1.2 Solutions for ephemeral IPv6 addresses . . . . . . . . . . . . . . . . . . . 2.1 Example of rewriting on the middlebox . . . . . . . . . . . . . . . . . . 2.2 Probability of collisions on some networks. . . . . . . . . . . . . . . . . . 2.3 CPU consumption on the middlebox. . . . . . . . . . . . . . . . . . . . .

	xxiv	LIST OF FIGURES
	5.4 List of Tables
	1.1
	xxiii

5.3 Performance impact of a simple spreading on the LAN for UDP and TCP communications (1 second of address lifetime when spreading is enabled). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . With respect to the forward temporal window address lifetime. . . . . . 83 5.14 Packet loss with internal resynchronization, without any Network Time Protocol (NTP) daemon. With respect to the forward overlapping temporal window address lifetime. . . . . . . . . . . . . . . . . . . . . . . . 84 6.1 Latency between OVH and Gandi IPv6 networks. . . . . . . . . . . . . . 92 6.2 Current architecture of address spreading protection. . . . . . . . . . . . 93 6.3 Address spreading protection with synchronized upstream routers. . . . 94 3.1 IP address notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Checksum validity for a real packet. . . . . . . . . . . . . . . . . . . . . 3.3 Checksum validity for a spoofed packet. . . . . . . . . . . . . . . . . . . 3.4 Rewriting in initialization steps. . . . . . . . . . . . . . . . . . . . . . . . 4.1 TCP flow label behavior on MAC OS X (versions 10.6, 10.8 and 10.9). .

  Table 2.2: Probability of collisions on some networks.

	Network type	# of devices Flows per device Prefix size Collision risk
	Home network	10	1000	64	< 5.6 • 10 -12
	Small company	100	1000	58	< 1.1 • 10 -11
	Campus network	50000	1000	48	< 2.1 • 10 -9
	ISP network	60 000 000	1000	32	< 4.6 • 10 -8

  The global CPU consumption for the NAT column includes the overhead of the conntrack table, used by the NATP

		Rewriting disabled	NAT	Rewriting without cache	Rewriting with cache
	Global CPU consumption	9.7%	12.6%	10.1%	10%
	Middlebox/NAT consumption	∅	0.92%	0.35%	0.29%
	Table 2.3: CPU consumption on the middlebox.
	module. The NAT consumption includes only the cost of the NAT module, without
	the conntrack table.

  .1): P A and P B are the network prefixes for hosts A and B. IP A and IP B are the real IP addresses of host A and B, concatenation of prefixes and interface identifiers are noted IID A and IID B . IP n src is the rewritten source IP address of the packet in step n, and IP n dst the destination IP address in the same step. Since we cannot rewrite prefixes, IP n src and IP n dst are concatenations of a stable prefix (P A or P B ) and a rewritten value.

		Local network	On the Internet
	Steps	Real IP Source	Real IP Destina-tion	Rewritten IP source	Rewritten IP Destination
	1a → 1b SYN	IP A	IP B	IP 1 src

Table 3 .

 3

	Position	Checksum validity	Remarks
	Local network	Valid	Computed by the end device
	Internet	Invalid	Addresses have been rewritten, it invalidates the checksum
	Remote network	Valid	Addresses have been rewritten by the second spreader
	Table 3.2: Checksum validity for a real packet.
	Position	Checksum validity	Remarks
	Attacker's network	Valid	Computed by the attacker
	Internet	Valid	No rewriting if the attacker is not aware of protection
	Remote network	Invalid	Addresses have been rewritten by the second spreader

3: Checksum validity for a spoofed packet.

Table

	Version	IPV6_AUTOFLOWLABEL	sin6_flowinfo	Both enabled
	10.6	Return an error	Works	∅
	10.8	Ignored but no error	Works	∅
	10.9	Works, with a random value	Works	Priority of sin6_flowinfo

Table 4

 4

		IPV6_AUTOFLOWLABEL	sin6_flowinfo
	10.6	Return an error, but sysctl works. Incremental assignment.	Ignored
	10.8	Works. Incremental assignment.	Ignored
	10.9	Works. Random value.	Ignored

.2: UDP flow label behavior on MAC OS X.

Table 4 . 3

 43

	sys-	Flow label for outgoing	Flow label for listening
	tem	sockets	sockets
	BSD/KAME	Yes (Kernel)	Yes (Kernel)
	Solaris	Yes (flowinfo field)	No
	MAC OS X	Yes (Kernel and flowinfo)	Yes (Kernel)
	Windows	No	No

: Socket labelling on various operating systems.

Table 5 .

 5 1: Proportion of packet loss with respect the adress lifetime on the LAN and the 6to4 network with UDP protocol.

	Packet losses

  .6). Over the temporal window

		1
	Proportion of failed transmission	0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9							Real 6to4 Theory 6to4 l=50ms Real LAN Theory LAN d=17ms
		0	100	200	300	400	500	600	700	800	900 1,000
					Addresses lifetime (milliseconds)

Table 5 .

 5

		IPsec tunnel	CPU on
	IPsec receiver	performance	firewall

3: Performance of IPsec spreading within a LAN.

The NATP was described in RFC

[START_REF] Srisuresh | Traditional IP Network Address Translator (Traditional NAT)[END_REF], an extension of RFC 1631. It is however only an informational RFC.

This prefix can be limited to only one address.

Directly or with small protocol modifications.

With 128 bits: 2 128 = 340282366920938463463374607431768211456 addresses, more than 3.4 * 10 38 .

We discuss the real size of IPv6 prefixes in the Appendix A.1.

Including modifications of headers as well than packet payload.

The structure is named in6_flowlabel_req.

and critical in term of privacy, since a browser allows many various usages.

Acknowledgments

The acknowledgments, or the untranslated part of this dissertation. I used to speak and work both in French and German all along my PhD. The same applies to my private life. My friends speak German in Dresden and French in Rennes and Paris. Don't be surprise if you don't find someone in one part, he or she is probably in the other part.

Remerciements

Chapter 4

Flow labels on Linux and various operating systems

Contents

On an intermediate node (router)

Since the RFC 6437, an intermediate node is allowed to rewrite zero flow label values. It could help to set label for upstream routers, for clients not supporting any labeling. Rewriting of non-zero values is not allowed, except for sensitive security networks.

Diversity of implementation on operating systems

Since the implementations specifications is out of scope of the normative references, each IPv6 stack has its own approach. Whereas a majority of operating systems allows the setting of a flow label on a client socket (in case of TCP), it is harder to know what to do with a listening socket. Should each child socket share the same label? Should each child use the same label as received packets? Or should the operating system set a new label on each child, different from the received label?

The link between operating system and user space is very hard as well. Should a software be able to know the current flow label value of a socket? How to set the same label on several sockets of an application flow? Could applications group sockets, to allow the sharing of identical labels for all sockets of the group? What about the knowledge of the received flow label?

It is possible to investigate many features. We restricted our analysis to four major features:

• How to set a flow label to an outgoing socket?

• How to set a flow label to a listening socket? (if the transport protocol allows listening sockets)

• How to know the current flow label set to the socket for outgoing packets?

• How to read the flow label of received packet?

The answers to these 4 questions are mandatory to write applications using flow label. Without knowing how to process flow label on an operating system, it is not possible to deploy Quality of service (QoS) protocols based on it and new flow classification methods based on flow labels.

In this section, our results for several operating systems are reported.

The KAME project

The goal of the KAME project was to provide a full featured IPv6 stack for BSD operating systems, like FreeBSD, OpenBSD and NetBSD. It is one of the most famous IPv6 implementation, and is deployed in many embedded devices. To test the implementation of flow labels, we made our tests on FreeBSD 9.0.

Enabling flow labels

The flow label implementation follows specifications defined in an IETF draft [START_REF] Ichiro Itojun | Socket api for ipv6 flow label field[END_REF].

In this specification, the operating system is in charge to randomly set a flow label on each socket. A software cannot request or set a specified value. The only configuration option is to disable the flow label for specific sockets. In this case, the flow label is set to zero.

There is a global default option to disable or enable the flow label on the system. It is set by the sysctl option net.inet6.ip6.auto_flowlabel. This default configuration IPv6 address spreading described in Chapter 3 is an innovative solution to protect against address spoofing. The above chapter explained the theoretical aspects of the contribution, with an evaluation of the packet loss and a solution to reduce this loss thanks to overlapping temporal windows.

In this chapter, address spreading performances are measured on real networks. This evaluation is based on based on a Netfilter module for Linux, following the steps explained in section 3.3.3. The implementation supports the configuration of both the address validity lifetime and temporal windows for packets out of the current time sequence.

Section 5.1 describes the test plateforms and the spreading consequences. It is followed by a test of the address spreading, without any overlapping window. Results are compared with theoretical estimations of chapter 3. This evaluation ends with an evaluation of overlapping window efficiency to reduce packet loss. Both backward and Appendix A

Some discussions on IPv6 specifications A.1 The real size of IPv6 prefixes

An IPv6 address is divided in two parts: the routing prefix and the interface identifier. IPv6 specifications define no default or static size for the routing prefix. As a consequence, IPv6 routing is done on variable prefix lengths, without any assumption on the length. Network nodes receive information on the size thanks to router advertisements. The size can, however, change at any time.

In practice, a large number of networks use a standard size of 64 bits. This is not surprising, given that it is the minimum size imposed by several interface identifier generation mechanisms (CGA [START_REF] Aura | Cryptographically Generated Addresses (CGA). RFC 3972[END_REF] used to secure the local network, EUI-64 addresses [START_REF] Hinden | IP Version 6 Addressing Architecture[END_REF], HBA [START_REF] Bagnulo | Hash-Based Addresses (HBA)[END_REF] used to secure Shim6 [NB09] protocol, . . . ). These algorithms could use larger sizes without any problem, since the excess bits can be set to zero or a random value.

A draft is currently in discussion at the IETF [BTF + 14], giving the state of the art for sizing these prefixes and the consequences not to use the "usual" size of 64 bits. No rules have been set so far to restrict it to 64 bits, but with the exception of some very specific networks, a minimum size of 64 bits for interface identifiers can be assumed.

A.2 Are some bits of interface identifier significant?

At the beginning of the IPv6 specification process, some bits of the interface identifier have been reserved fo setting specific informations. According to the RFC of IPv6 architecture [START_REF] Hinden | IP Version 6 Addressing Architecture[END_REF], the second bit (the "u" bit) could be set to announce an "universal" address, for example when this identifier derives from an unique hardware identifier. If all end devices had followed this rule, and if hardware providers have respected the uniqueness of hardware identifiers, one would have been sure that an IPv6 interface identifier with the bit "u" were unique. If the node was aware of a collision risk for the interface identifier generation process, generation algorithms would have set the bit to zero. Applying this rule, a generated address would not have interacted with the "unique" address space, even if the generation were fully random, like with privacy extension [START_REF] Narten | Privacy Extensions for Stateless Address Autoconfiguration in IPv6. RFC 4941[END_REF].

According to the same RFC, a second special bit could be set according to the information available in the MAC address: the "i/g" bit. For a MAC address, this bit would indicate a link-layer multicast.

103

Both special bits are today not really used. For the "u" bit, the hardware identifier uniqueness is actually not respected by hardware providers. There is today no warranty of uniqueness in the address space with the "u" bit set. In the same way, the "i/g" bit is often set without signaling a link-layer multicast.

Since the bits were not set according to the previous rules, the RFC 7136 [CJ14] has removed the special states of these bits, and they can now be considered as opaque values. Nevertheless, since the RFC 7136 has not updated previous specifications, some algorithms of interface identifier still set these bits according to them. This does not have any implication for future algorithms: it is allowed to arbitrary set the "u" and the "g" bit on a network.