Version du 6 février 2019 à 16:44

Présentation générale

Nom du projet : Discussion pair à pair

Etudiants : Fabien DI NATALE & Ibrahim BEN DHIAB

Description

Sur Internet, lorsqu'on souhaite communiquer avec une personne, on passe généralement par un service de discussion instantanée qui transmet le message via leur serveur.
Mais ici, on souhaite concevoir un dispositif de communication en pair à pair c'est à dire que le message ne passe pas par un serveur tier. Ainsi, l'utilisateur devient lui-même client/serveur ou "servent" et forme des "pairs" avec les autres utilisateurs comme on peut observer sur l'image suivante:

Schéma de fonctionnement réseau P2P et réseau serveur

Il y a plusieurs années, chaque appareil connecté chez l'utilisateur avait sa propre adresse IPv4 public, hors IPv4 peut fournir 2^32 (4,294,967,296) adresses et avec l'évolution massive d'Internet ces adresses auraient étaient rapidement déplétées, en effet on compte 23 milliards appareils connectés en 2018.
Ce problème a été anticipé, et de nouvelles technologies ont été crées afin d'y répondre, notamment la translation d'adresse "network address translation" (NAT) ou encore l'IPv6 en 1998, qui lui peut fournir 2^128 (340,282,366,920,938,463,463,374,607,431,768,211,456) adresses. La translation d'adresse a permis de réduire l'utilisation d'adresse IPv4 considérablement, en attribuant à chaque foyer une seule adresse IPv4 public et en distribuant des IP privées à chaque appareil du foyer.
C'est l'apparition de ces technologies et la mise en place d'IP privées qui a mis à mal le principe de pair à pair sur Internet.

Objectifs

Schéma du dispositif de communication P2P UDP IPv4 Hole Punching

L'objectif est de concevoir un dispositif permettant de retrouver une communication en pair à pair sans communication des messages à un tier.

Le pair à pair peut être centralisé (les connexions passent par un serveur central intermédiaire) ou décentralisé (les connexions se font directement). Dans notre cas, on considère un modèle centralisé.

Plusieurs techniques peuvent être envisagées :

communication en IPv6 pour les utilisateurs dont les opérateurs offrent ce service ;
communication en Ipv4/UDP avec envoi simultané de messages pour ouvrir les ports sur les "boxes" (synchronisation par SMS ou par tier) ;
communication en IPv6/TCP avec contournement de la mascarade (NAT) des "boxes" par communication des numéros de séquence par tier ;
toute autre technique trouvée dans la littérature sur le sujet.

Nous utiliserons la technique de communication par UDP & TCP Hole Punching, on a schématisé sur la figure suivante le dispositif a mettre en place:

Les deux utilisateurs parviennent à communiquer en "perçant" un tunnel et ainsi laisse le passage ouvert momentanément pour la réception d'un message.

Egalement, le serveur permet de sauvegarder les ID et adresses IP des utilisateurs, et il établit un canal de contrôle de type "handshake" entre les pairs qui permet d'établir leur communication directe. Les noeuds sont en connexion constante TCP avec le serveur.

Par exemple, sur le schéma, node A envoie un message du type "je souhaite communiquer avec node B", ainsi le serveur a une connexion établie avec node B et va pouvoir lui envoyer un message avec les informations nécessaires (IP publique de node A etc...) pour que node B puisse faire une requête UDP Hole Punching vers node A.

Ce modèle permet à l'utilisateur de ne pas configurer l'ouverture des ports de son router.

Finalement, on souhaite aussi avoir une application sous PC et Android ainsi qu'une couche de chiffrage en utilisant les clés publiques et privées.

Analyse du projet

Positionnement par rapport à l'existant

De nos jours, de plus en plus d'informations sont recueillis sur les utilisateurs sans leur accord, mais les utilisateurs recherchent :

l'anonymat (afin de protéger sa vie privée ou d'éviter d'éventuelles poursuites judiciaires) ;
le brouillage du protocole (afin d'éviter les filtrages du fournisseur d'accès internet) ;
le chiffrement (« on peut savoir qui je suis, mais pas ce que je télécharge »).

Ces problématiques peuvent notamment être répondues à l'aide du peer to peer avec les technologies adaptées.

Analyse du premier concurrent

Skype

En août 2003, Skype était lancé sur une architecture peer-to-peer, décentralisée et distribuée. Pourquoi P2P? P2P offrait plusieurs avantages, notamment pour VoIP (voice over IP). En effet, Skype n'avait pas besoin de mettre en place et d'entretenir des serveurs pour le contrôle et l'envoi des données vidéos et vocales sur l'internet. Ainsi, chaque nouvel utilisateur qui se connectait au réseau représente un nœud avec sa bande passante et son infrastructure matériel, ou éventuellement un super nœud.

Le vent a commencé à tourner en 2011, lorsque Microsoft a racheté le service et l’entreprise éponyme, pour plus de 8 milliards de dollars. Le nombre d'utilisateurs a atteint 50 millions, et l'efficacité du P2P a été questionné, surtout après deux pannes très sérieuses causées par l'incapacité du réseau P2P a supporter cette situation. Le grand nombre de nœuds demandant l'accès au service nécessité de plus en plus d'algorithmes compliqués. Une autre raison a été le développement sur le marché de la téléphonie, car l'application mobile consommait bien trop de batterie, parce que les appareils doivent souvent agir comme un nœud, donc en communication constante.

Avec le temps, Microsoft a réorganisé le back-end de Skype en un service cloud sur la plate-forme Azure.

Face à ceux qui considèrent que cette transformation facilite la collecte de données, y compris par les agences gouvernementales, la firme préfère mettre en avant l’émergence de nouveaux services comme le partage de fichiers, les appels de groupe sur mobile, Skype Translator ou, plus récemment, Skype Bots.

Analyse du second concurrent

mIRC

L'IRC (Internet Relay Chat) est un protocole qui permet de dialoguer en temps réel avec d'autres utilisateurs en se connectant grâce à un logiciel spécifique (appelé un client) à un serveur IRC, lui-même relié avec d'autres serveurs IRC. Toutes les personnes ainsi connectées peuvent discuter sur des forums publics ou privés à l'aide de commandes.

C'est ce que propose mIRC, il permet de communiquer, partager, jouer ou travailler avec les autres sur des réseaux IRC autour du monde, soit en groupe de plusieurs personnes, soit en discussion privée 1 à 1. Cependant, ce système utilise des serveurs pour être fonctionnel, mais il propose un moyen pour communiquer directement avec un utilisateur qu'on appelle DCC (direct client to client), c'est une commande à taper sur le client IRC qui permet ensuite de communiquer et partager des fichiers de manière privée et sécurisée.

Scénario d'usage du produit ou du concept envisagé

Ivan, espion Russe en mission en Ukraine, doit faire un rapport à son patron comme toutes les fins de semaines. Habituellement, il passe par une plateforme de discussion classique en utilisant des messages codés, donc cela lui importé peu que la communication soit enregistré dans un serveur quelque part sur Terre.

Cependant, cette semaine ci, les tensions se sont accentuées en Crimée entre Russie et Ukraine, et la sécurité a été amplifiée dans le pays, d'ailleurs un de ses collège a été emprisonné pour espionnage. Ainsi, pour ne prendre aucun risque, Ivan décide de changer de méthode de communication, il lui fallait un moyen plus sécurisé pour faire ses rapports.

En cherchant sur le net, il est tombé sur notre dispositif P2P. Il a donc décidé de l'utiliser et d'envoyer son rapport, mais pour cela il faut que son patron soit également enregistré sur le dispositif, il doit ainsi contacter une dernière fois son patron par le moyen habituel, mais comme il ne s'agit pas d'informations d'espionnage, il n'y a aucun risque.

Enfin, il a pu contacter son patron à travers le dispositif P2P et lui envoyer son rapport sans devoir se préoccuper d'être emprisonné.

Réponse à la question difficile

Hole Punching pour TCP ?

Oui c'est aussi possible, c'est un peu plus complexe qu'en UDP, mais c'est très similaire au niveau protocolaire. Après il est possible qu'il ne soit pas supporté par tous les NAT, mais si par chance le NAT se comporte bien, la communication P2P par TCP peut s'avérer plus robuste qu'en UDP, parce que comparé à l'UDP, la machine d'état du protocole TCP donne aux NATs sur le chemin une manière standard de déterminer précisément le temps de vie de la session TCP.

Pourquoi Skype a t-il arrêté le P2P?

De son nom originelle “Skype peer to peer” créé en 2003, a beaucoup utilisé le peer to peer jusqu’à son rachat par Microsoft en 2012. Nous allons voir en quoi Skype a était un concurrent et comment il va pouvoir nous aider dans notre projets afin de ne pas répéter les mêmes erreurs et pouvoir perdurer dans le temps en fonctionnement peer to peer.

Skype utilisait les communications UDP et du TCP entre les super nœuds.

Cependant leurs protocole propriétaire fermé et non-standard permettant une bonne discrétion et augmentant la difficulté d’espionnage des communications rends leurs système très peu compatible avec les nouveaux système d’exploitation et les nouveaux supports.

Skype a abandonné le P2P à cause de la trop grande utilisations de bande passante des utilisateurs faisant donc monter les factures de forfait mobile qui était très cher en internet en 2012. Skype a pour objectif de s’implanter partout et voulait remplacer les forfaits délivrant peu de communication et peu d’internet pour un coût sans limite, donc s’implanter dans la majorité des téléphones. Ils devait donc limiter l’utilisation de bande passante. Ils utilisent maintenant le même procédé sauf que les super nœuds ne sont plus les utilisateurs mais des serveurs implanté et possédé par Skype ce qui s'apparente beaucoup plus à un réseau client serveur.

Le second problème était le problème de la batterie, un téléphone a une batterie très limité contrairement aux PC fixes, il est donc pour eux impossible d’agir comme un nœud voir un super nœud sans réduire considérablement l’autonomie d’un téléphone. Il était donc impératif pour Microsoft de centralisé les communication et de se tourner vers un système plus standard de type client-serveur.

Qu'apporte de plus notre produit qui le rend plus original ?

Notre produit n'est pas plus original, mais il s'agit plus d'un rafraîchissement de ce que réalisé Skype, notamment avec l'utilisation des IPv6, qui n'étaient pas utilisées auparavant. On essayera également d'utiliser des technologies récentes et plus efficaces.

Préparation du projet

Cahier des charges

Présentation:

Notre application aura pour but de créer un réseau de discussion P2P (Peer to peer) sans communiqué des messages à un tier.
Afin de mettre ceci en oeuvre nous développerons un logiciel PC et une application Android (si possible).

Fonctions à réaliser:

Enregistrer les ID utilisateurs et leur IP (IPv4 ou IPv6) sur le serveur
Envoie d’un message par la méthode Hole Punching UDP & TCP, et IPv6
Crypter les messages et décrypter à la réception

Nous devons avoir un produit le plus sécurisé, le moins énergivore possible et utiliser le moins de donnée internet pour application mobile.

Pour le banc de test:

mettre au point le serveur de relais (handshake)
communiquer entre deux ordinateurs avec la méthode Hole Punching UDP & TCP

Choix techniques : matériel et logiciel

2 Raspberry Pi 3 avec Wifi inclus (ou Pi 2 avec dongle Wifi)
2 Câbles Ethernet

Pour le banc de test:

2 routeurs qu'on interconnectera en filaire

Liste des tâches à effectuer

Analyser le projet
Configurer les deux routeurs cisco 4221
Développement du logiciel
- Hole Punching UDP IPv4
- Hole Punching TCP IPv4
- Hole Punching IPv6
Développement du serveur répertoire
- enregistrement d'un nouvel utilisateur
- Vérification de l'appartenance des clients à notre répertoire

Calendrier prévisionnel

Réalisation du Projet

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S7	Heures S8	Heures S9	Heures S10	Total
Analyse du projet	4
Banc d'essai	4 4 4

Prologue

Semaine 1

Installation de 2 routeurs CISCO ISR 4221 dans un rack en E304. Ils seront utilisés pour notre banc d'essai, pour mettre en place la communication P2P en local. On a debuté la configuration d'un des routeurs et on recherchera de quelle manière configurer le NAT.

Configuration du premier routeur:

minicom -8 -o -b 9600 -D /dev/ttyUSB0

enable
conf t
 interface Vlan 1
  ip address 10.0.0.1 255.0.0.0
  .
 interface GigabitEthernet0/0/0
  ip address 50.0.0.1 255.0.0.0
  negotiation auto
  no shutdown
  .
 router rip
  version 2
  network 10.0.0.0
  network 50.0.0.0
  no auto-summary
  .

Semaine 2

Configuration 2nd routeur, recherche sur la doc CISCO à propos du NAT, qu'on appliquera en semaine 3.

Configuration du second routeur:

enable
conf t
 interface Vlan 1
  ip address 20.0.0.1 255.0.0.0
  .
 interface GigabitEthernet0/0/0
  ip address 50.0.0.2 255.0.0.0
  negotiation auto
  no shutdown
  .
 router rip
  version 2
  network 20.0.0.0
  network 50.0.0.0
  no auto-summary
  .

Semaine 3

Configuration NAT routeur 1:

enable
 conf t
  int gigabitEthernet 0/0/0
   ip nat outside
   .
  int Vlan 1
   ip nat inside
   .
  ip access-list standard NAT_CES_ADRESSES
   permit 10.0.0.0 0.255.255.255
   .
  ip nat inside source list NAT_CES_ADRESSES interface gigabitEthernet 0/0/0 overload

Documents Rendus

Bibliographie

https://github.com/samyk/pwnat
http://bford.info/pub/net/p2pnat/index.html
https://www.itprotoday.com/compute-engines/9-steps-setting-cisco-router
https://www.cisco.com/c/en/us/td/docs/routers/access/4400/software/configuration/guide/isr4400swcfg/bm_isr_4400_sw_config_guide_chapter_010.html
https://baptiste-wicht.developpez.com/tutoriels/reseau/introduction/?page=6 protocole TCP et UDP
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-15-mt-book.pdf doc cisco
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/xe-3s/nat-xe-3s-book/iadnat-addr-consv.html#GUID-4B9A2ED6-FC5D-4FF9-98FB-482486D0411E

@@ Ligne 149 : / Ligne 149 : @@
 | Analyse du projet
 | 4
+|-
 | Banc d'essai
 | 4 4 4

IMA4 2018/2019 P26 : Différence entre versions