Philippe Roudel, Alain Maroc ENIC - TTV02

Sommaire

Présentation VPN :Virtual Private Network   Qu’est-ce qu’un VPN ?   Le concept de réseau privé virtuel   Les trois types de base de VPN   L'accès distant   L'Intranet   L'extranet   Comment marche un VPN ?   A quoi sert un VPN ?   Services des VPN   Qualité de Service   Sécurité   L'accès VPN pour l' entreprise   Rappels, historique   SLIP : Serial Line IP Protocol   Introduction   Caractéristiques   Protocole   Faiblesses   Remarques   CSLIP: Une amélioration de SLIP   PPP : Point-to-Point Protocol   Introduction   Format de la trame   Généralités   Les différentes phases d’une connexion   Le protocole de contrôle de liaison LCP   Informations complementaires sur LCP   Les protocoles de controle réseau NCP   IPCP - Description   PAP - Password Authentication Protocol   CHAP - Challenge-Handshake   Authentification du site distant   Remarque   Conclusion : SLIP ou PPP?   Les principaux protocôles de VPN   PPTP : Point to Point Tunnelling Protocol   Introduction   Cryptanalyse des extensions MS-CHAP   MS-CHAP Versions 1 et 2   Attaques par compatibilité arrière   Conclusions   L2F : Layer Two Forwarding de Cisco   L2TP : Layer Two Tunnelling Protocol de l'IETF   Concepts clés   Concentrateur d'accès LAC   Serveur réseau LNS   Avantages de L2TP   Tunneling Les différents types de tunnels IPSec : IP Secure   Introduction   Principe du fonctionnement SA/SAD/SPD   Protocole AH (Authentication_Header)   Mode transport et mode tunnel   Protocole ESP (Encapsulating Security Protocol)   Limitation IPSec et NAT   Conclusions   Exemple : échange IPSec dans un tunnel L2TP

Autres protocôles impactés par les VPNs   MPLS : Multi-Protocol Layer Switching   Définitions   Introduction   Routage et commutation de paquets   MPLS et ses composants   Qu’est-ce que MPLS ?   LSR et LER   FEC   Labels et association de labels   Label-Switched Paths LSP   Label Distribution Protocol LDP   NAT : Network Adress Translation   Les quatres types d'implémentations de NAT   NAPT (Network Address and Port Translation) / IP Masquerading   Translation d'adresses dynamique   Translation d'adresses statique   Redirection de port   Compatibilité et incompatibilité NAT Exemple routeur CISCO 2500   Matrice de Compatibilité des protocoles VPN FAQ : Foire Aux Questions   Q1: Qu'est-ce que la liste de distribution mail VPN? et comment y souscrire?  Q2: Qu'est-ce qu'un Réseau Privé Virtuel (VPN:Virtual Private Network)?  Q3: Quels sont les types de VPN? et quels sont leurs avantages et désavantages respectifs?  Q4: Qu'est-ce que PPTP? Est-ce une solution viable dans le cadre d'un VPN?  Q5: Qu'est-ce que IPsec? Quelles relations avec les VPN et les firewalls?  Q6: Comment IPSec travaille-t-il avec NAT (Network Address Translation)?  Q7: Comment savoir si un VPN d'accés distant  est la bonne solution pour mon organisation?  Q8: Comment puis-je vérifier qui utilise le VPN pour accéder à mon site?  Q9: Comment puis-je vérifier quels types de trafic réseau sont transmis dans mon VPN?  Q10: Dois-je terminé mon VPN sur mon firewall ou directement sur mon réseau privé?  Q11: En quoi l'utilisation du cryptage affecte les performances des connexions réseaux?  Q12: Qu'est-ce que l'authentification forte?  Q13: Quelle est l'importance de la longueur de la clé?Qu'est-ce qu'une attaque "force brute"?  Sites Web   Bibliographie   Annexes   Présentation PowerPoint   "Les VPNs"  "Le NAT "   "Radius"

Qu’est-ce qu’un VPN ?

Les réseaux privés virtuels (VPN : Virtual Private Network) permettent à l’utilisateur de créer un chemin virtuel sécurisé entre
une source et une destination. Avec le développement d’Internet, il est intéressant de permettre ce processus de transfert de
données sécurisé et fiable. Grâce à un principe de tunnel (tunnelling) dont chaque extrémité est identifiée, les données
transitent après avoir été chiffrées.
Un des grands intérêts des VPN est de réaliser des réseaux privés à moindre coût. En chiffrant les données, tout se passe
exactement comme si la connexion se faisait en dehors d’Internet. Il faut par contre tenir compte de la toile, dans le sens
où aucune qualité de service n’est garantie.

Le concept de réseau privé virtuel

Les réseaux locaux d'entreprise (LAN ou RLE) sont des réseaux internes à une organisation, c'est-à-dire que les liaisons
entre machines appartiennent à l'organisation. Ces réseaux sont de plus en plus reliés à Internet par l'intermédiaire d'un
système proxy (faisant souvent office de firewall pour des raisons de sécurité), c'est-à-dire une machine qui filtre les données
en provenance et à destination d'Internet afin de constituer un véritable garde-barrière.
Sur Internet, les liaisons sont beaucoup plus vulnérables car les données peuvent passer par des lignes susceptibles d'être
"écoutées". Ainsi, étant donné que certaines entreprises ne peuvent pas se permettre de relier deux réseaux locaux distants
par une ligne spécialisée, il est parfois nécessaire d'utiliser Internet comme support de transmission. On parle alors de
réseau privé virtuel (aussi appelé VPN, acronyme de Virtual Private Network) lorsque les données transitant sur Internet
sont sécurisées (c'est-à-dire cryptées). Ce réseau est dit virtuel car il relie deux réseaux "physiques" (réseaux locaux) par
une liaison Internet, et privé car seuls les ordinateurs des réseaux locaux faisant partie du VPN peuvent accéder aux données.
Les VPNs offrent l'évolutivité en terme de connectivité d'entreprise, déployé sur une infrastructure partagée avec les mêmes
critères d'efficacité est appréciable sur un réseau privé. Ces critères incluent la sécurité, la gestion des priorités, la fiabilité, et
la gestion bout en bout.
Un VPN peut-être déployé au-travers d'Internet o u construit sur un réseau IP, frame Relay, ATM d'un fournisseur de service.
Les VPNs basés sur IP peuvent naturellement étendre l'omniprésence des intranets au-delà d'une zone interconnectée
vers les agences distantes, les utilisateurs mobiles ou les télé travailleurs. De plus, ils peuvent étendre les extranets vers
des groupement d'intérêt économique en dehors de l'organisation, relier les partenaires clients et fournisseurs, améliorant
la satisfaction client, permettant de se différencier au niveau marché, et de réduire les coûts de transformation (manufacturage).

Le VPN d'accés,

Il est nécessaire pour ce type de VPN de définir une authentification forte afin de vérifier les utilisateurs distants et mobiles. L’utilisateur utilise donc un ISP (Internet Service Provider) dans le but d’établir une communication sécurisée avec l’entreprise distante. Deux solutions sont possibles : ·    Soit le client établit un tunnel crypté à travers l’ISP vers le réseau de l’entreprise. L’avantage de cette méthode est que la communication est crypté de bout en bout.·    Soit l’utilisateur communique avec le NAS (Network Access Server) de l’ISP, qui lui établit une communication crypté avec le réseau de l’entreprise distante. Cette méthode permet entre autre à l’utilisateur de se connecter avec plusieurs réseaux en utilisant plusieurs tunnels. De plus, le client n’a pas besoin de transporter le logiciel lui permettant d’établir une communication cryptée.

L'Intranet VPN

L’Intranet VPN favorise la communication entre les départements interne d’une entreprise et ses sites distants. Les VPN s'appuient alors sur le réseau d'un opérateur ou d'un ISP. Il est nécessaire de développer un fort chiffrement afin de protéger les informations sensibles qui peuvent circuler tels que les bases de données clients etc..

L'extranet VPN

Enfin, l’Extranet VPN entre une compagnie et ses clients et partenaires stratégiques nécessite une solution ouverte afin d’assurer l’interopérabilité avec les diverses solutions que les partenaires peuvent implémenter. Le standard actuel pour les VPN basés sur Internet est IPSec (Internet Protocol Security). Il est également important de gérer le trafic afin d’éviter le goulot d’étranglement à l’entrée du réseau, pour obtenir un temps de réponse le plus court possible à une demande critique.

Les VPNs d'accès sont un besoin des travailleurs mobiles, télé travailleurs et petites agences.
Ce business est très dynamique, l'institut Forrest Research évalue à 55% des entreprises qui ont des projets de réalisation
de VPNs en tant qu'extension à leur réseau actuel. Les raisons évoquées par les petites ou grandes sociétés sont les
mêmes à savoir le ratio prix/performance avantageux et la flexibilité offerte par l'offre basé sur IP. Toutes les études de
marchés laissent supposer un très grande croissance de la demande pour les VPNs d'accès. Un rapport de Data Corporation
International prévoit que le nombre des accès (d'entreprises) atteindra 85,000 en 2002. Une grande partie de cette croissance
se fera grâce aux segments de marché du sans-fil et de l'accès DSL Les raisons de cette croissance rapide sont à relier au
phénoménal succès de l'Internet et à l'accroissement du nombre de télé travailleurs De même que les télé travailleurs, les utilisateurs
mobiles et les agences "satellite", les fournisseurs de services comme les partenaires (clients, fournisseurs) commencent à prendre
conscience des avantages des solutions accès VPN. Les nouvelles applications comme la vidéoconférence, la formation à distance,
et l'édition permettent d'envisager une augmentation de la productivité et une réduction des coûts. Comme c'est nouvelles applications
sont de plus en plus sophistiquées, les entreprises ont besoin d'utiliser plus qu'un service de transport de base de la part de leur
fournisseur de service. Elles ont besoin d'un contrôle sécurisé pour maintenir l'intégrité de leur propre réseau. De plus, ce service
émergent demandera des applications de management de ressource et supervision pour optimiser les applications stratégiques
et les flux d'informations.
 

Comment marche un VPN ?

Un réseau privé virtuel repose sur un protocole, appelé protocole de tunneling, c'est-à-dire un protocole permettant aux données
passant d'une extrémité du VPN à l'autre d'être sécurisées par des algorithmes de cryptographie.
De cette façon, lorsqu'un utilisateur du VPN nécessite d'accéder à des données situées sur un autre réseau local du réseau privé virtuel,
sa requête va être transmise en clair au système proxy, qui va se connecter au réseau distant par l'intermédiaire d'une ligne téléphonique
(analogique, c'est-à-dire par modem ou numérique) puis va transmettre la requête de façon cryptée. L'ordinateur distant va alors fournir
les données au système pare-feu de son réseau local qui va transmettre la réponse de façon cryptées. A réception sur le proxy de
l'utilisateur, les données seront décryptées, puis transmises à l'utilisateur...
Le principe du VPN est basé sur la technique du tunnelling. Cela consiste à construire un chemin virtuel après avoir identifié l’émetteur
et le destinataire. Ensuite la source chiffre les données et les achemine en empruntant ce chemin virtuel. Pour assurer un accès
aisé et peu coûteux aux intranets ou aux extranets d'entreprise, les réseaux privés virtuels d'accès simulent un réseau privé, alors
qu'ils utilisent en réalité une infrastructure partagée, comme Internet.
Les données à transmettre peuvent appartenir à un protocole différent d’IP. Dans ce cas le protocole de tunnelling encapsule les
données en rajoutant une entête. Permettant le routage des trames dans le tunnel. Le tunneling est l’ensemble des processus
d’encapsulation, de transmission et de désencapsulation.
Un exemple de méthode d’encapsulation : GRE (Generic Routing Encapsulation).

L’encapsulation avec GRE consiste en l’ajout d’un en-tête qui contient les informations relatives au tunnel.

A quoi sert un VPN ?

Auparavant pour interconnecter deux LANs distants, il n’y avait que deux solutions, soit les deux sites distants étaient reliés par
une ligne spécialisée permettant de réaliser un WAN entre les deux sites soient les deux réseaux communiquaient par le RTC.
Une des premières applications des VPN est de permettre à un hôte distant d’accéder à l’intranet de son entreprise ou à celui d’un
client grâce à Internet tout en garantissant la sécurité des échanges. Il utilise la connexion avec son fournisseur d’accès pour se
connecter à Internet et grâce aux VPN, il crée un réseau privé virtuel entre l’appelant et le serveur de VPN de l’entreprise.
Cette solution est particulièrement intéressante pour des commerciaux sillonnant la France : ils peuvent se connecter de façon
sécurisée et d’où ils veulent aux ressources de l’entreprise. Cela dit, les VPN peuvent également être utilisés à l’intérieur même de
l’entreprise, sur l’intranet, pour l’échange de données confidentielles.

Services des VPNs

Ces VPN n’ont pas comme seul intérêt l’extension des WAN à moindre coût mais aussi l’utilisation de services ou fonctions
spécifiques assurant la QoS et la sécurité des échanges. Les fonctionnalités de sécurité sont matures mais par contre la
réservation de bandes passantes pour les tunnels est encore un service en développement limité par le concept même d’Internet.

Qualité de Service (QoS)

La Qualité de Service (QoS) est un ingrédient essentiel des VPN, elle est déterminante et permet d'assigner les ressources
réseaux en vue d'applications de type mission critique(mission critical) ou sensibles en terme de délai de transmission.
Les applications de type haute disponibilité et mission critique (mission critical) étant fondamentales pour les transactions
commerciales, les rapports de gestion financières, les commandes fabrication, les demandes de réapprovisionnement
et le suivi de la chaîne logistique.
Celles-ci demandent un niveau de priorité bien supérieure au surf Web. Les applications sensibles au délai de transmission
comme la formation en ligne ou la vidéoconférence demande une QoS qui alloue suffisamment de bande passante pour
éviter la gigue (jitter) et par la même un faible niveau de qualité.
La QoS répond à deux besoins fondamentaux des applications qui transitent sur les VPN:
-Le niveau de performance est prévisible
-Une politique et des régles peuvent être implémentées.
Les règles sont utilisées pour identifier les applications, les groupes de projet ou toute autre organisation basée sur des
règles de priorité.  L'accroissement du trafic réseau doit être un compromis tout au long des projets entre l'utilisation
de la bande passante réseau et des règles réseaux
avec les objectifs de l'entreprise. Les équipements peuvent offrir aujourd'hui la capacité QoS qui permet aux utilisateurs de
gérer la priorité des classes de service, de gérer l'utilisation de la bande passante, d'éviter la congestion, assure une qualité
de service que ce soit au niveau 2 ou au niveau 3.
La qualité de service (QoS) est une fonctionnalité importante des VPN n’est pas encore une technologie assez mature et les
solutions proposées sur le marché à l’heure actuelle ne permettent que des garanties sur des réseaux locaux propriétaires.
C’est pourquoi peu d’ISP proposent à leurs clients des solutions VPN.
La sécurité des échanges est assurée à plusieurs niveaux et par différentes fonctions comme le cryptage des données,
l’authentification des deux extrémités communicantes et le contrôle d’accès des utilisateurs aux ressources.

Sécurité

La sécurité est un point critique pour tous les réseaux. C'est en fait, la première inquiétude pour l'entreprise qui envisage d'utiliser la technologie VPN. Avec une planification correcte de la sécurité en place, l'information acheminée à travers une
infrastructure partagée peut être sécurisée avec un niveau de sécurité équivalent à celle d'un réseau privé.
Ceci est possible grâce aux cryptages des données, à l'accès restreint aux utilisateurs autorisés et au "traçage"  des
utilisateurs une fois connectés au réseau.
Les VPNs sont construit autour du concept AAA(authentication, authorization, accounting ) :
-Authentification
-Autorisation
-Gestion de compte (accounting)
Ceci grâce à l'authentification des utilisateurs, du niveau d'accès, et à la collecte et enregistrement des informations
de connexion.
Un tunnel logique créé une connexion point à point sur un réseau IP sans connexion. Un tunnel crypté fourni réseau
et données et garantie la confidentialité des informations transmises grâce à un encodage/brouillage qui ne peut être
décrypté que par l'expéditeur ou le destinataire des données.
IPSec incorpore une technologie de cryptage éprouvée et sure. L'encapsulation de protocole sécurisé
( Encapsulating Security Protocol(ESP)) et le cryptage standard de données ( Data Encryption Standard (DES))
sont utilisés par IPSec afin de protéger la charge utile ou la partie données du paquet.
Les télé travailleurs, commerciaux terrains, agents, agence distantes, filiale, et autres utilisateurs distants ou mobiles
sont les premiers candidats à l'utilisation  des VPN d'accès. Les VPN d'accès fournissent un accès à l'Intranet ou
l' Extranet à travers une infrastructure partagée avec la même politique qu'un réseau privé. Cela inclus la connectivité
accès distant via les technologies RTC, ISDN, DSL, du sans-fil et du câble.
Les VPNs d'accès permettent aux entreprises d'externaliser l'accès distant sans compromettre leur politique de sécurité.
Cela englobe deux options d'architecture:
-la connexion sur l’initiative du client.
-la connexion sur l’initiative du serveur (NAS : Network Access Server ).
Avec le VPN d'accès à base de connexion à l'initiative client, les utilisateurs établissent un tunnel IP crypté
de leurs clients via un réseau d'ISP (Internet Service Provider) vers le réseau de l'entreprise. Avec cette architecture,
l'utilisateur distant utilise un logiciel client qui initialise le tunnel. L'architecture VPN à base de connexion sur l’initiative du client
fournit une sécurité de bout en bout du client au serveur. Ce qui est idéal pour les applications bancaires ou toutes autres
transactions sensibles à travers le réseau Internet.
L'utilisateur final  a en sa possession un logiciel client IPSec installé sur le site distant, qui peut se terminer avec un vis à vis côté réseau entreprise du type firewall à base de router ou un firewall type PIX appliance. Les solutions IPSec VPN, afin d'assurer une solution sécurisée totalement, peuvent supporter une architecture à clé publique
(IKE Internet Key Exchange).
L'autre architecture des VPNs d'accès définie des tunnels initialisés à partir du NAS.Dans ce scénario, les
utilisateurs distants appellent un POP (Provider Point Of Presence) d'un fournisseur d'accès local ou un numéro
libre accès (numéro vert par exemple), et le fournisseur de service initialise un tunnel crypté et sécurisé vers le
réseau de l'entreprise. Avec l'architecture initialisation à partir du NAS (NAS-initiated) les fournisseurs de services
authentifient l'utilisateur qui accède au réseau de l'entreprise; toutefois, les entreprises gardent le contrôle de leur
politique de sécurité, définnissent les privilèges utilisateurs autorisés, et l'information d'où l'utilisateur  à accèdè
au réseau. Cette authentification permet au fournisseur de service d'authentifier les utilisateurs qui accèdent à ses
NAS, et  à l'entreprise d'authentifier à nouveau  les utilisateurs sur son propre router et firewall.
Les premiers avantages du VPN d'accès à initialisation à partir du NAS sont la gestion de priorité, l'équilibrage de charge,
et la redondance. Les VPN d'accès à initialisation à partir du NAS révèlent aux compagnies les détails, implications
et la complexité de la supervision d'un réseau sécurisé, permettant au fournisseur de services de garder beaucoup
de détails qui ne sont pas le cœur de métier de l'entreprise.
Toutefois quelques applications peuvent nécessités un VPN d'accès à initialisation à partir du client, quand l'utilisateur
veut être sur que les données sont cryptées depuis la source jusqu'au serveur distant.
Avec les VPNs à initialisation à partir du NAS, les lignes RTC standards ou ISDN sont utilisées et la charge utile est
crypté seulement du NAS au routeur/firewall de l'entreprise, où l'intrusion est la plus probable.

L'accès VPN pour l' entreprise.

Que l'on ait à construire ou faire construire son propre réseau privé virtuel IP (IP Virtual Private Network VPN), qui offre la sécurité,
 la fiabilité et un accès distant économiquement viable et facilement évolutif pour coller au changement rapide du secteur
économique de l'entreprise, les responsables réseaux doivent continuellement trouver un moyen de connecter géographiquement
 les groupes de travail, agences dispersées cela de manière efficace et économique. L'accroissement des demandes dû à
l'enrichissement fonctionnel des applications utilisées largement par tous les employés dispersés a créé la nécessité de repenser toutes les stratégies réseaux. Les compagnies étendent leurs réseaux afin de relier les partenaires, et un nombre de
 télé travailleurs et d'utilisateurs distants continuellement en accroissement, construire une entreprise distribuée relève de plus
 en plus du challenge. Afin de relever ce challenge, les VPNs ont émergés, permettant aux organisations de sous-traiter les
 ressources réseaux en partageant les infrastructures réseaux. Les Accès VPNs en particulier permettent la mobilité, les
utilisateurs distants peuvent se connecter au réseau d'entreprise, au moment, comme et d’où ils le souhaitent L'association
 avec un fournisseur de service pour construire un accès VPN peut offrir un service sécurisé, privé et fiable, ce qui signifie
 réduire le coût d'immobilisation. Le fournisseur de service devient un expert en besoin de communication inter et intra entreprise
permettant à l'entreprise de se recentrer sur son secteur d'activités principales et son secteur d'expertise principale.

SLIP : Serial Line IP

Les familles de protocoles TCP/IP fonctionnent sur une grande variété de supports : les réseaux locaux IEEE 802.3 (Ethernet)
et 802.5 (Token Ring), les lignes X25, les liaisons satellites et série. La plupart des transmissions de données se font via des
interfaces séries. Une interface série est juste une interface qui envoie les données comme une série de bits sur un "seul fil"
en opposition à une interface parallèle qui envoie cette série de bits sur "plusieurs fils" simultanément. Cette description d'une
interface série convient pour la plupart des interfaces de communications (y compris Ethernet), mais ce terme désigne
habituellement une interface qui est liée à une ligne téléphonique au travers d'un modem.
Dans le monde TCP/IP, les liaisons séries sont utilisées pour créer des WAN (Réseau longue distance). Malheureusement,
un protocole standard au niveau de la couche physique pour les lignes séries n'a pas toujours existé concernant cette famille
de protocoles TCP/IP. En raison de cette carence, beaucoup de responsables informatiques ont choisi une même marque de
routeurs pour leur WAN afin d'assurer la communication au niveau de la couche physique.
La croissance des réseaux longue distance avec TCP/IP a ensuite suscité un vif intérêt pour la standardisation des
communications sur liaisons séries afin d'être indépendant de tout fournisseur. De même, l'arrivée de petits systèmes
abordables fonctionnant avec TCP/IP ainsi que des modems à haute vitesse ont renforcé cette demande.
Le besoin d'une standardisation pour les communications dans les WAN et celui d'accès TCP/IP par le RTC, ont abouti à
la création de deux protocoles de transmission sur ligne série : Serial Line IP (SLIP) et Point-to-Point Protocol ( PPP ).

Introduction

SLIP signifie Serial Line IP (IP sur liaison série). Il s'agit d'une forme simple d'encapsulation des datagrammes IP sur des
liaisons séries, qui est spécifiée dans la RFC 1055 (A Non Standard for Transmission of IP Datagrams Over Serial Lines).
SLIP définit une séquence de caractères qui encapsulent des paquets IP sur une ligne série, et rien d'autre. Il ne fournit
pas d'adressage, d'identification de paquets, de détection et de correction d'erreurs ou un mécanisme de correction.
Comme le protocole fonctionne de manière simple, il est très facile de le mettre en place. SLIP est devenu populaire
grâce à la connexion de systèmes domestiques à Internet, au travers du port série RS232 rencontré sur la plupart
des ordinateurs et des modems à grande vitesse.
SLIP puise ses origines au début des années 80 dans l'implémentation de 3COM UNET TCP/IP.
Aux alentours de 1984, Rick Adams mis en œuvre SLIP pour 4.2 Berkeley Unix et les stations de travail Sun
Microsystems. Bien qu'ayant été décrit comme non standard, il devint de plus en plus populaire pour finalement
être considéré comme la voie la plus simple pour connecter des serveurs TCP/IP et du RTC.

A. Caractéristiques

SLIP est communément utilisé sur des liaisons séries dédiées et sur des lignes dont la vitesse va de 1200 bits
par seconde et 19.2 KBits par seconde. Les configurations les plus courantes de connexion sous TCP/IP sont :
Host - Host
Routeur - Routeur
Host - Routeur
Les configurations ci-après décrivent un exemple de connexions SLIP possibles à un serveur utilisant l'interface V24 (RS232C).

Dans ce diagramme, les PC ont été connectés au serveur central mais il pourrait s'agir de n'importe quelle machine
pouvant fonctionner avec SLIP et TCP/IP.
Le serveur est ici en liaison avec un réseau local (LAN), et il peut être utilisé comme un routeur pour se connecter à partir
des PC au LAN pour obtenir d'autres services.

B. Protocole

Le protocole SLIP définit un mécanisme simple de "mise sous forme de trames" des diagrammes en vue de leur transmission
sur la ligne série sous la forme d'une série d'octets et utilise des caractères spéciaux pour indiquer qu'une série d'octets
devraient être regroupés pour former un datagramme.
Pour ce faire, SLIP définit deux séquences de caractères spéciaux :
La séquence de caractères SLIP END occupe un seul octet dont la valeur décimale est 192 (0xc0). Cette séquence
indique la fin d'un datagramme complet qu'il peut alors transmettre à IP.
La séquence de caractères SLIP ESC occupe un seul octet dont la valeur décimale est 219 (0xdb). Cette séquence est
utilisée pour "changer le code" des caractères de contrôle de SLIP. Si le SLIP émetteur met en évidence une valeur d'octet
équivalente à la valeur de la séquence de caractères SLIP END ou ESC dans le datagramme qu'il envoie, il convertit cette
séquence de caractères en une séquence constituée de deux caractères. Les séquences de deux caractères sont
ESC 220 (0xdc) pour le caractère END et ESC 221 (0xdd) pour le caractère ESC.

Phil Karn a suggéré d'insérer un caractère END au début du datagramme IP. Le datagramme IP se termine par le caractère spécial appelé END (0xc0).
Aussi, pour éviter à tout bruit de ligne avant ce datagramme d'être interprété comme faisant partie de ce datagramme,
la plupart des implémentations transmettent également un caractère END en tête du datagramme.
S'il y a du bruit sur la ligne, ce caractère END arrête la transmission erronée, permettant au datagramme courant d'être
envoyé. Le datagramme erroné sera rejeté par une couche supérieure lorsque son contenu sera reconnu comme non valide.
Parce qu'il n'y a pas de spécification de standard SLIP, il n'y a pas de taille maximum de paquet définie pour SLIP. Il est
probablement plus judicieux d'accepter la taille maximum de paquet définie par le pilote SLIP d'UNIX de Berkeley : 1006 octets
incluant le paquet IP et l'en-tête du protocole de transport (n'incluant pas les caractères d'encapsulation).
Aussi, n'importe quelle nouvelle version de SLIP devra être préparée à recevoir un datagramme de 1006 octets et à ne pas en
envoyer plus de 1006 dans un datagramme.

C. Faiblesses

Beaucoup de fonctions ne sont pas fournies avec SLIP, ce qui peut poser des problèmes aux utilisateurs.
En toute honnêteté, SLIP est un protocole très simple à mettre en œuvre. Il y a déjà longtemps quand ces problèmes n'étaient
pas réellement importants.
Les déficiences éventuelles de SLIP, se classent en plusieurs catégories :

Adressage

Le protocole SLIP ne définit pas les informations de contrôle de la liaison qui peuvent être utilisées pour contrôler
dynamiquement les caractéristiques d'une connexion. Par conséquent, les systèmes SLIP doivent adopter certaines
caractéristiques des liaisons. Etant donné cette restriction, SLIP peut être utilisé uniquement si les deux hôtes se sont
transmis leur adresse IP respective et si la transmission des datagrammes IP est en cours.

Identification du type de protocole

Détection et correction d'erreurs

SLIP ne compense pas le bruit détecté sur les lignes téléphoniques lentes. Le protocole n'assure pas la correction d'erreurs.
Les lignes téléphoniques bruyantes vont endommager un certain nombre de paquets pendant la transmission. La
retransmission est très coûteuse si la vitesse de la ligne est basse. Mais la correction et la détection d'erreurs n'est
absolument pas nécessaire au niveau de SLIP.
En effet, IP inclut toujours une somme de contrôles, de même que l'en-tête TCP et les données TCP. Dans l'en-tête UDP
et les données UDP, ceci est optionnel. Mais parce que la retransmission de paquets endommagés prend du temps,
il pourrait être utile de fournir une sorte de mécanisme de simples corrections d'erreurs avec SLIP.

Compression

Le protocole SLIP n'assure pas la compression de données. Si la ligne est assez lente, la compression de paquets peut
améliorer grandement les performances de transmission.
 

E. Remarques sur SLIP

Pour nombre d'applications, les faiblesses de SLIP s'avèrent sans importance. Il se peut que seule la transmission de
datagrammes IP soit intéressante pour l'utilisateur s'il connaît les adresses des deux hôtes impliqués dans la liaison
(il peut les spécifier manuellement ).
De plus, les modems commercialisés actuellement disposent de leurs propres algorithmes de compression de données
et de correction d'erreurs. Compte tenu de ces éléments, SLIP est généralement considéré comme étant approprié
pour assurer l'interconnexion d'hôtes isolés.
Toutefois, dans un environnement dynamique tel qu'un WAN de grande taille, les problèmes éventuels inhérents à
l'utilisation de SLIP sont généralement considérés comme constituant autant de faiblesses majeures. Celui-ci est
dès lors considéré comme étant un protocole inapproprié pour assurer l'interconnexion des routeurs.

CSLIP : une améliorations de SLIP

Puisque les lignes SLIP sont souvent lentes (19200 bits/sec ou moins), et fréquemment utilisées pour du trafic interactif
(comme Telnet et Rlogin, les deux utilisant TCP), elles tendent à être composées de petits paquets TCP échangés à
travers une ligne SLIP. La transmission d'un octet de données nécessite un en-tête IP de 20 octets et un en-tête TCP
de 20 octets, soit un overhead de 40 octets.
Pour résoudre ce problème de performance, une nouvelle version de SLIP, appelée CSLIP (pour Compressed SLIP),
a été spécifiée dans la RFC 1144 (Van Jacobson 1990). CSLIP réduit généralement l'en-tête de 40 octets à 3 ou 5 octets.
Il maintient l'état de plus de 16 connexions TCP à chaque extrémité de la liaison CSLIP, et tire partie du fait que certains
des champs des deux en-têtes ne changent pas pour une connexion donnée. En ce qui concerne les champs qui
changent, la plupart des changements se traduisent par de petits accroissements. Ces en-têtes plus petits procurent
une amélioration importante du temps de réponse des opérations interactives.

PPP : Point-to-Point Protocol

Introduction

PPP fut développé pour transférer des données sur des liens synchrones ou asynchrones entre deux points en utilisant
HDLC comme base d’encapsulation et un Frame Check Sequence (FCS) HDLC pour la détection des erreurs. Cette
liaison permet le full duplex et garantit l’ordre d’arrivée des paquets.
Une fonctionnalité intéressante de ce protocole est le multiplexage simultané de plusieurs protocoles de niveau 3 du
modèle OSI.
Ce protocole encapsule des paquets IP, IPX et NetBEUI, … dans des trames PPP, puis transmet ces paquets PPP
encapsulés à travers la liaison point à point. PPP est donc utilisé entre un client distant et un serveur d’accès distant.

Le protocole PPP est décrit dans la RFC 1331. 

Format de la trame PPP

Fanion  : séparateur de trame. Un seul drapeau est nécessaire entre 2 trames. 

Adresse : Le champ adresse correspond à une adresse HDLC, or PPP ne permet pas un adressage individuel des
stations donc ce champ doit être à 0xFF (toutes les stations), toute adresse non reconnue fera que la trame sera détruite.

contrôle : Le champ contrôle doit être à 0x03, ce qui correspond à une trame HDLC non numérotée. Toute autre
valeur fera que la trame sera détruite.

Protocole : La valeur contenue dans ce champ doit être impaire, l’octet de poids fort étant pair. Ce champ identifie
le protocole encapsulé dans le champ informations de la trame. Les différentes valeurs utilisables sont définies dans
la RFC « assign number » et représentent les différents protocoles supportés par PPP (OSI,IP,Decnet IV,IPX,…),
les NCP associés ainsi que les LCP.

Informations : De longueur comprise entre 0 et 1500 octets, ce champ contient le datagramme du protocole
supérieur indiqué dans le champ »protocole ». Sa longueur est détectée par le drapeau de fin de trame, moins
2 octets de contrôle

FCS (Frame Check Sequence) : Ce champ contient la valeur du checksum de la trame. PPP vérifie le contenu du
FCS lorsqu’il reçoit un paquet. Le contrôle d’erreur appliqué par PPP est conforme à X25.

Les familles de protocoles TCP/IP fonctionnent sur une grande variété de supports : les réseaux locaux
IEEE 802.3 (Ethernet) et 802.5 (Token Ring), les lignes X25, les liaisons satellites et série. La plupart des
transmissions de données se font via des interfaces séries. Une interface série est juste une interface qui envoie
les données comme une série de bits sur un "seul fil" en opposition à une interface parallèle qui envoie cette
série de bits sur "plusieurs fils" simultanément. Cette description d'une interface série convient pour la plupart
des interfaces de communications (y compris Ethernet), mais ce terme désigne habituellement une interface
qui est liée à une ligne téléphonique au travers d'un modem.
Dans le monde TCP/IP, les liaisons séries sont utilisées pour créer des WAN (Réseau longue distance).
Malheureusement, un protocole standard au niveau de la couche physique pour les lignes séries n'a pas toujours
existé concernant cette famille de protocoles TCP/IP. En raison de cette carence, beaucoup de responsables
informatiques ont choisi une même marque de routeurs pour leur WAN afin d'assurer la communication au
niveau de la couche physique.
La croissance des réseaux longue distance avec TCP/IP a ensuite suscité un vif intérêt pour la standardisation
des communications sur liaisons séries afin d'être indépendant de tout fournisseur. De même, l'arrivée de petits
systèmes abordables fonctionnant avec TCP/IP ainsi que des modems à haute vitesse ont appuyé cette demande.
Le besoin d'une standardisation pour les communications dans les WAN et celui d'accès TCP/IP par le RTC,
ont abouti à la création de deux protocoles de transmission sur ligne série : Serial Line IP ( SLIP ) et
Point-to-Point Protocol (PPP).

A. Généralités

Bien plus qu’un standard d’encapsulation de datagramme, les liaisons PPP résolvent certains problèmes des
protocoles réseaux, tel qu’assigner et gérer des adresses (IP, X.25 et autres..) . Ce qui est particulièrement difficile
à travers un réseau commuté.
Parallèlement, PPP permet l’encapsulation de trames asynchrones et synchrones orientées bit, de configurer la
liaison série, de tester la qualité de la liaison, de multiplexer les différentes couches réseau, détecter les
erreurs, et de ‘’ négocier ‘’ les options avec le site distant, tel que la compression de donnée, la vitesse de transfert...
PPP résout tout cela à travers un protocole de contrôle de liaison (LCP) et une famille de protocoles de contrôle
de réseaux pour ‘’négocier’’ les paramètres optionnels de la configuration.
PPP est composé de trois parties principales :
1 - Une méthode pour encapsuler les datagrammes sur la liaison série. PPP utilise le format de trame HDLC
( Hight Data Level Control ) de l’ISO ( International Standartization Organisation ).
2 - Un protocole de contrôle de liaison (LCP - Link Control Protocol ) pour établir, configurer et tester la
connexion de liaison de données.
3 - Plusieurs protocoles de contrôle de réseaux (NCPs - Network Control Protocol ) pour établir configurer les
différents protocoles de couche réseau.
PPP est recommandé pour l'utilisation simultanée de plusieurs protocoles de couche réseau. En effet, sa
structure permet d’utiliser différents NCP simultanément et donc de multiplexer simultanément différents
protocoles de couche réseau.

B. Les différentes phases d’une connexion PPP.

"Liaison morte"

Toute liaison commence et finit obligatoirement par cette phase. Lorsqu'un événement externe indique que la
couche Physique est prête, PPP passe à la phase suivante, établissement de la liaison.
Par exemple, une liaison retournera à cette phase après la déconnexion d'un modem.

"Etablissement de la liaison"

Dans l’optique d’être transportable sur un grand nombre d’environnements, PPP comprend un protocole de contrôle
de liens LCP (Link Control Protocol) qui est utilisé pour établir, configurer, tester, et terminer  la connexion à travers
l'échange d’options de configuration jusqu'à ce qu'un des hôtes modifie une des options pendant la phase.
LCP est utilisé pour manipuler les tailles variables des paquets, en effet selon le protocole d’encapsulation
sélectionné dans le champ protocole, la taille du champ options/données n’est pas la même. Ces fonctions de test
permettent de détecter un lien bouclé sur lui-même ou toute autre erreur classique de configuration. De plus,
seules les options qui sont indépendantes de tout type de réseau, telles que l'élimination du champ Fanion de la
trame PPP, sont configurées par le LCP (voir informations complémentaires pour LCP).
D’autres fonctionnalités optionnelles comme l’authentification d’identité des extrémités, et la détermination de l’état
du lien peuvent s’avérer intéressantes.

"Authentification"

Il est possible qu'un hôte doive s'authentifier avant tout envoi de messages. Celle-ci n'est pas obligatoire, et doit
être demandée dans la phase précédente, établissement de la liaison.
Elle doit se faire le plus rapidement possible après l'établissement de la connexion. Le passage à la phase
suivante, Protocole réseau, n'est possible qu'à la fin de l'authentification, en cas d'échec, passage à la phase
Terminaison de liaison.

"Protocole réseau"

Une fois les phases précédentes effectuées par PPP, chaque protocole réseau doit être configuré séparément
par le protocole de contrôle de réseau (NCP) approprié. En effet, PPP supporte plusieurs protocoles sur la
même liaison de données.
Le transfert de données est alors possible. Tant que la liaison est "ouverte", les NCPs (voir annexes pour explication)
peuvent ouvrir et fermer des connexions réseau.

"Terminaison de liaison"

PPP peut clore une liaison à tout moment, ceci peut être dû à une authentification qui a échoué, une mauvaise
qualité de la ligne...
Le LCP est utilisé pour la fermeture de la connexion à travers l'échange de paquets de terminaison.
Lorsque la liaison est close, PPP doit alors en informer les NCPs.

Le protocole de contrôle de liaison (LCP)

PPP utilise le LCP pour négocier une importante liste d'options de configuration dans une large variété d'environnements.
Ainsi, il est possible d'utiliser PPP entre des hôtes que les administrateurs réseau ont configuré différemment.
LCP négociera automatiquement les options de configuration.
Le protocole de contrôle de liaison de donnée (LCP - Link Control Protocol) fournit les informations concernant la
liaison série. Il est utilisé pour établir, négocier les paramètres de configuration, vérifier la qualité de liaison et
terminer une connexion point à point. LCP a été développé spécifiquement pour PPP.
LCP fonctionne à travers 4 phases distinctes :

Phase 1 : Etablissement et configuration de la liaison

Avant que les datagrammes de la couche réseau soit échangés, LCP doit d’abord confirmer l’ouverture de la
connexion par envoi et réception de paquets. Ces paquets sont émis par chacun des deux sites. Si ces
échanges sont effectués sans aucun problème - réception de l’acquittement de configuration
(Configure-Ack) - LCP accepte la connexion, sinon celle-ci est refusée.
Il est important de noter que LCP accepte la configuration de la liaison
et non celle de la couche réseau - effectuée par le protocole NCP. En effet, tous les paramètres indépendants
de la couche réseau sont configurés et testés à travers LCP. En cas d’erreur ou de mésentente sur les
options, celles-ci prennent une valeur par défaut.

Phase 2 : Détermination de la qualité de la liaison

Cette phase n’est pas obligatoire. Dans cette phase la liaison est testée afin de déterminer si la qualité
- débit par exemple - est suffisante pour assurer le transport des datagrammes de la couche réseau
correspondante. LCP peut retarder la transmission des paquets tant que cette phase n'est pas
complètement terminé.
La procédure pour déterminer la qualité n’est pas spécifiée et peut varier d’une implémentation
à l’autre, de plus elle dépend des souhaits de l’utilisateur. Une méthode est d’utiliser les paquets
LCP Echo-Request et Echo-Reply. Cette phase n’étant pas obligatoire, il est nécessaire de fixer un temps
maximum afin de ne pas bloquer la connexion.

Phase 3 : Négociation de la configuration du protocole de la couche réseau

Une fois que LCP a terminé les deux phases précédentes, le protocole de couche réseau est configuré
séparément par le protocole de contrôle de réseau approprié (NCPs), et peut être interrompu à n’importe
quel moment. Si LCP interrompt la connexion, il informe NCP qui pourra effectuer des actions appropriées.

Phase 4 : Fin de la liaison

LCP peut interrompre la liaison à n’importe quel moment, sur un temps de réponse trop élevé, un événement
physique, par exemple ou bien tout simplement par l’utilisateur.

Informations complémentaires sur LCP

Ce protocole de contrôle de liens est chargé de gérer les options et les liens créés. LCP est utilisé pour établir,
maintenir, et fermer la liaison physique.
L’en-tête est le suivant :

Code : Définit, sur un octet, le type de paquet LCP :
1 : Configure request - 2 : Configure Ack - 3 : Configure NAK - 4 : Configure Reject - 5 : Terminate Request
- 6 : Terminate Ack - 7 : Code Reject - 8 : Protocol Reject - 9 : Echo Request - 10 : Echo Reply
- 11 : Discard Request - 12 : Link quality report

Identifiant : Ce champ contient une valeur numérique qui sert à la gestion des requêtes et des réponses. 

Longueur : Longueur totale du paquet LCP. Ce paquet comprend le code, l’identifiant, la longueur et les données.
Données / Options : Ce champ de taille variable peut contenir une ou plusieurs configuration d’options. Le format
d’une configuration d’options LCP possède 3 champs : type, longueur et données.
- Longueur : Longueur de la configuration d’options, c’est à dire la longueur des trois champs : type, longueur et données.
- Type : Cet octet indique la configuration d’options ou de données choisie : Paquets de configurations, paquets de fin
de connexion, paquets détruits ou paquets de test.

Format des paquets

Les paquets LCP sont encapsulés dans le champ information de la trame PPP ou le champ Protocole de la
trame a pour valeur le type indiquant des datagrammes LCP c’est à dire la valeur C021.
Il existe trois classes distinctes de paquets LCP :
1. Les paquets de configuration de liaison, utilisées pour établir la connexion.
2. Les paquets de terminaison de liaison, utilisées pour clore une connexion.
3. Les paquets de maintenance de liaison, utilisées pour maintenir et résoudre certains problèmes sur la ligne.

Le champ Code est sur un octet et identifie le type du paquet LCP.
Les différentes valeurs de ce champ :
1 - Configure-Request
2 - Configure-Ack
3 - Configure-Nack
4 - Configure-Reject
5 - Terminate-Request
6 - Terminate-Ack
7 - Code-Reject
8 - Protocol-Reject
9 - Echo-Request
10 - Echo-Reply
11 - Discard-Request
Le champ identifiant est sur un octet. Son rôle est de faciliter la reconnaissance des réponses associer à la
requête correspondante.
Le champ Longueur est sur deux octets. Son rôle est indiquer la longueur du paquet LCP correspond en fait à
la longueur du champ information de la trame principale PPP (vu précédemment ) sans les bits de bourrage.
Le champ Data contient les données demandées par les différentes requêtes. Sa taille peut être nulle. Son format
est déterminé par la valeur du champ Code.
Il contient les différentes Options qui peuvent être négocier en réponse a certain paquet tel que Configure-Request,
Echo-Request, Terminate-Request ...
Par exemple, avec le paquet Code-Reject (Code ayant la valeur 7), Il contient le paquet LCP rejeter.

Les paquets de configuration

Ils servent à établir et configurer la liaison PPP. Ils sont au nombre de quatre : Configure-Request, Configure-Ack,
Configure-Nak, et Configure-Reject.
Pour ouvrir une connexion PPP, un paquet Configure-Request doit être envoyé. Le champ Data contient une liste
des options de configuration désirées.

Lorsqu'un hôte reçoit le paquet, il doit obligatoirement émettre une réponse. Si toutes les options sont acceptées,
le récepteur envoie un acquittement, paquet Configure-Ack. Le champ Data contient alors une copie exacte des
options de configuration demandées.
En revanche, si certaines des options désirées ne sont pas acceptables, le récepteur envoie un acquittement
négatif, paquet Configure-Nak. Le champ Data contient uniquement les options inacceptables.
En somme, l'hôte qui reçoit un Configure-Request peut demander des options supplémentaires quand il envoie
le Configure-Nak.
Les hôtes continuent d'envoyer des Configure-Request et Configure-Nak jusqu'à ce qu'ils se mettent d'accord
sur les mêmes options.
Si un hôte reçoit un paquet qui contient des options inconnues, il doit envoyer un Configure-Reject, dont le
champ Data contiendra uniquement les options rejetées.
La différence entre les options des paquets Configure-Nak et Configure-Reject, c'est que les options rejetées
ne sont pas négociables.
Les options de configuration seront étudiées ultérieurement.

Les paquets de terminaison

Pour négocier la fermeture d'une liaison PPP, il existe deux paquets :
Terminate-Request, et Terminate-Ack, dont le champ Data est inutilisé.
Dès qu'un hôte reçoit un Terminate-Request, il doit envoyer un Terminate-Ack.
Des paquets Terminate-Request doivent être transmis tant qu'un des trois événements suivants ne s'est pas produit :
- l'émetteur reçoit un Terminate-Ack,
- la couche inférieure n'est plus prête pour communiquer,
- l'émetteur a envoyé un certain nombre de Terminate-Request non acquittés.

3. Les paquets de maintenance

Ils servent à maintenir et résoudre certains problèmes sur la liaison. Il en existe cinq : Code-Reject, Protocol-Reject,
Echo-Request, Echo-Reply, Discard-Request.
Quand un hôte reçoit un paquet LCP avec une valeur inconnue dans le champ Code, il doit transmettre
un paquet Code-Reject, dont le champ de données Rejected-Packet contient une copie du paquet rejeté, mais
uniquement la partie donnée du champ Information de la trame PPP, pas les entêtes ni le FCS.

De même, un paquet Protocol-Reject est envoyé en réponse à une valeur inconnue dans le champ Protocol, et inclut
les champs Rejected-Protocol, qui contient la valeur inconnue du protocole, et Rejected-Information (similaire au
Rejected-Packet du paquet Code-Reject).

Les paquets Echo-Request et Echo-Reply sont utilisés pour surveiller la liaison de données PPP, dans les deux sens.
Quand un hôte reçoit un Echo-Request, il doit transmettre un paquet Echo-Reply.
Le paquet Discard-Request sert à surveiller la liaison dans un sens seulement (hôte local vers hôte distant).

Dans ces trois paquets, la zone de données contient un champ Magic Number, option LCP négociable, qui sert à
détecter les cycles dans les liaisons de données.

Les options de configuration de LCP

Les options de configurations LCP identifient les caractéristiques négociables de la liaison point à point. Chaque
option a une valeur par défaut.
PPP utilise la valeur par défaut quand un paquet Configure-Request n’inclut pas d’option durant la phase
d’établissement de liaison.
Dans une trame Configure-Request , on peut envoyer plusieurs options à négocier avec le site distant. Les options
n’étant pas incluses dans cette trame, ne sont pas négociées et leurs valeurs par défaut leur sont affectées.

Format général d’une option

Le champ Longueur indique la taille totale de l’option de configuration. Les champs Type, Longueur et Data étant inclus.
Le format et le contenu du champ Data sont spécifique à chaque option de configuration.
Le champ Type identifie le type de l’option de configuration à négocier.
Les différentes valeurs de ce champ sont :
0 - Réservé
1 - Maximum Receive Unit
3 - authentication Protocol
4 - Quality Protocol
5 - Magic Number
7 - Protocol Field Compression
8 - Adress and Contrtol Field Compression

Maximum Receive Unit (MRU)

Cette option permet de négocier la taille maximum d’un paquet. Sa valeur par défaut est de 1500 octets.
Les sites distants peuvent négocier des tailles plus grandes ou plus petites que la taille par défaut. Il n’est pas
nécessaire que les serveurs ajoutent des octets de bourrages pour atteindre la valeur du MRU, ils peuvent toujours
envoyer des paquets de longueur inférieure.

Le champ Longueur a toujours pour valeur 4.
Le champ MRU indique le nombre maximum d’octet du champ Information de la trame PPP. La taille du MRU
n’inclut donc pas les autres champs de la trame PPP.

Authentication Protocol

Les clients peuvent utiliser cette option pour négocier l’utilisation d’un protocole d’authentification particulier,
car certains réseaux incluent des protocoles d’authentification au niveau réseau.
Par défaut, celle-ci n’est pas nécessaire. Quand un hôte émet un paquet Configure-Request avec l’option
Authentication Protocol, il veut que le récepteur "s'authentifie". Quand le récepteur envoie la réponse
Configure-Ack avec l'option Authentication Protocol, il accepte l'authentification, en utilisant le protocole
d'authentification spécifié.
Ces hôtes peuvent ne pas utiliser les mêmes protocoles d'authentification dans les deux sens. Ils peuvent
négocier l'utilisation de protocoles différents pour chaque sens.

Le format de cette option est similaire a l'option précédente. A la place du champ MRU, cette option inclut
les champs Authentication Protocol, et Data qui peut contenir des informations supplémentaires sur le
protocole d’authentification demandé.

Quality Protocol

PPP fournit la possibilité de contrôler la qualité de la liaison. Cette option permet aux hôtes de négocier
l'utilisation d'un protocole spécifique qui sert à contrôler la quantité de données perdues sur la liaison.

De même que pour l'option précédente, les hôtes peuvent négocier l'utilisation de différents protocoles
de qualité dans chaque sens. L'option inclut aussi un champ Data qui peut contenir des informations
supplémentaires sur le protocole de qualité demandé.

Magic Number

Elle est utilisée pour détecter les éventuelles anomalies sur la liaison de données et les cycles de rebouclage.
Par défaut, cette option n'est pas négociée. A la place, un 0 est inséré dans le champ Magic Number.
Quand un hôte reçoit un paquet Configure-Request avec l'option Magic Number, il le compare au Magic Number
du dernier paquet Configure-Request. Si les deux nombres diffèrent, il n'y a pas de rebouclage. Sinon il est
possible qu'il y ait un rebouclage : l'hôte reçoit ses propres transmissions. Donc, pour lever le doute, un paquet
Configure-Nak doit être envoyé indiquant qu'il faut un autre Magic Number.
Si le Magic Number du Configure-Nak est différent de celui envoyé dans le dernier Configure-Nak, il n'y a pas
de cycle, et ce nombre est bien unique. Sinon il y a bien bouclage, et un nouveau Magic Number doit être déterminé.

Toutes les mises en oeuvre de PPP peuvent détecter les cycles. Cependant, le procédé que chaque application
utilise pour y remédier est spécifique à chacune.

Protocol Field Compression

Dans certains cas, les deux octets du champ Protocol peuvent être compressés et réduits à un octet. Cette
option permet aux hôtes de négocier la compression du champ Protocol de la trame PPP.
Quand un hôte envoie un paquet Configure-Request avec l'option Protocol Field Compression et reçoit un
paquet Configure-Ack en réponse, les deux hôtes peuvent utiliser un octet pour le champ Protocol.
Dans tous les cas, les applications PPP doivent toujours accepter le champ Protocol avec deux octets, même
si l'option a été négociée. Le FCS est alors calculé sur la trame compressée.

Address and Control Field Compression.

Puisque dans une trame PPP, les champs Address et Control ont des valeurs constantes, ils peuvent être
compressés. Cette option permet à un hôte de négocier la compression de ces deux champs.
Le FCS est alors calculé sur la trame compressée.

Les protocoles de controle réseau (NCPs)

Les protocoles de contrôle réseau (NCPs - Network Control Protocols) sont des protocoles séparés qui
fournissent les informations de configuration et de contrôle destinées aux protocoles de la couche réseau.
PPP est conçu pour transmettre des données pour une multitude de protocoles réseau. NCP autorise la
personnalisation de PPP de manière à exécuter uniquement cette tache. Chaque protocole de réseau
(DECnet, IP, OSI, etc. ...) possède son propre protocole NCP.

IPCP - Description

Le protocole de contrôle pour le protocole Internet (IPCP - IP Control Protocol ) se charge de configurer,
d’autoriser ou non l’utilisation de datagramme IP (Internet Protocol ) sur la liaison point à point .
Semblable au protocole LCP, cette phase s’effectue en échangeant des paquets. Les paquets IPCP
ne seront échangés seulement si le protocole LCP autorise la phase de négociation de configuration
de la couche réseau. De même, les datagrammes IP ne seront pas échangés tant que IPCP n’accepte
pas la connexion.

Fonctionnement de IPCP

Le protocole IPCP est très semblable au protocole LCP, à quelques exceptions près :
- Le Paquet IP est encapsulé dans le champ Information de la trame de couche de liaison de donnée ou le
champ protocole a la valeur hexadécimale 8021.
- Le champ Code utilise seulement un code parmi les sept disponible ( Configure-Request, Configure-Ack,
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack et Code-Reject). Les autres codes
sont traités comme des paquets inconnus et sont retournés au site distant - Paquet Code-Reject.
La longueur maximum d'un paquet IP transmis sur une liaison PPP est la même que la longueur
maximum du champ Information de la trame PPP. Les datagrammes de longueur plus importante
devront être fragmentés. Le rassemblement des datagrammes devra être assuré par la couche
transport du système. Il est possible de limiter la longueur de la trame IP à l'aide l'option Maximum
Segment Size de la couche TCP, Cette option favorisera la transmission puisque le rassemblement
des paquets n'est plus nécessaire.

Les adresses IP

Une option de configuration permet de négocier l'adressage IP de chaque site. Par défaut aucune
adresse n'est assignée. Une adresse désignée par la valeur zéro peut être négociée comme une
requête du site distant pour que celui-ci spécifie son adresse IP.

Type de compression

Cette option fournit un moyen de négocier le protocole de compression des paquets IP. Par défaut,
cette option n'est pas activée.

Le champ Type de compression contient une valeur correspondant à l'algorithme de compression à utiliser.
Pour la compression des entêtes TCP/IP de Van-Jacobson cette valeur correspond à 0037 en hexadécimal.

Informations complémentaires sur NCP

PAP -Password Authentication Protocol

Le protocole d'authentification par mot de passe (PAP) est une méthode simple pour établir l'identité du site
distant. Elle est semblable à la procédure login d'une session sur un serveur. Ceci est effectué seulement
après que la liaison a été établie.
Après que le protocole LCP, a accepté la liaison au site distant. Le client s'authentifie auprès du serveur
en lui envoyant un paquet Authentication-Request contenant l'identité du client et le mot de passe associé.
Le serveur compare ces données à celle contenu dans son fichier d'authentification.
L'inconvénient de cette technique est que le mot de passe transit "en clair" sur la liaison.
Exemple de fichier sur un site de type UNIX :
# /etc/ppp/pap-secrets
#
# User Server Secret Adresse
Vlager-pap c3po cresspahl vlager.vbrev.com
c3po vlager DonaldGNU c3po.lucas.com
Les deux premiers champs contiennent toujours l'adresse de l'utilisateur et du serveur associé. Le troisième
champ correspond au secret - Mot de passe - associe de façon unique à un utilisateur ou à un groupe
d'utilisateur. La première ligne est utilisée pour authentifier le serveur contenant ce fichier auprès du serveur
c3po. La seconde ligne décrit comment un utilisateur distant nomme c3po sera authentifié avec ce serveur.
Le quatrième est optionnelle, il contient l'adresse IP du client.
Sur un autre environnement, ce fichier n'a pas obligatoirement le même format.

CHAP - Challenge-Handshake Authentification Protocole

Si on veut éviter l'envoi de paquets contenant le mot de passe sur la liaison point à point, l'utilisation du
protocole d'authentification CHAP est plus que recommandée. Celui-ci permet ainsi d'accroître la sécurité du site.
Avec ce protocole le serveur envoi au client un paquet contenant un challenge - mot de 16 bits définit
aléatoirement - et son nom. Le client récupère dans sa table définit localement, à l'aide du nom du serveur,
le secret correspondant. Le client combine le secret approprié avec le challenge, crypte ce résultat. Le
résultat du cryptage est retourné au serveur avec le nom du client. Le serveur effectue les même opérations.
Si les deux résultats sont identiques la connexion du client est acceptée.
Exemple de fichier sur un site de type UNIX :
Le format de fichier contenant les mots de passe pour le protocole CHAP est semblable a pap-secret vu ci-dessus.
# /etc/ppp/chap-secrets
#
# Client Server Secret Adresse
Vlager-pap c3po.lucas.com cresspahl vlager.vbrev.com
c3po vlager.vbrew.com DonaldGNU c3po.lucas.com
CHAP permet d'effectuer l'authentification a n'importe quel moment durant la liaison afin d'être sur que
le client n'a pas était remplacé par un intrus.
L'implémentation des algorithmes de cryptage doit bien sur être identique sur les deux serveurs distants.
Il est possible a l'aide des options de configuration de LCP de choisir des algorithmes spécifiques
paquet - Authentication Protocol.
Remarque: Les datagrammes transmis après la procédure d'authentification ne sont pas cryptés. Il est
donc possible par écoute de la ligne de voir ces données. La sécurité n'est donc, sur une liaison
point à point, pas totale.
Si on désire crypter les données à transmettre, le cryptage s'effectue au niveau des datagrammes et doit
être assurer par la couche réseau.

L'authentification du site distant

Par soucis de sécurité, afin de permettre un accès privilégié à des données " sensibles" ou à des services
payants, il est nécessaire de connaître l'identité du site distant.
Le protocole PPP contient deux protocoles d’authentification, PAP et CHAP, qui sont négociés à l’aide du
protocole de couche liaison LCP. L’authentification auprès d’un site est, bien sûr, optionnelle.
L'authentification est effectuée, après que LCP a terminé la configuration des options. En cas d'échec
- l'identité du site distant non reconnue - la connexion est tout simplement interrompue.
L'authentification est demandée, soit par le demandeur de connexion (client), soit par l'offreur de connexion
(serveur).

Remarque sur PPP

PPP s'avère un protocole nettement plus puissant que SLIP. Les options de configurations étant nombreuses,
sa mise en œuvre est plus délicate ; Il est moins souvent utilisé. Cependant les avantages résultant de l'utilisation
de PPP en font le protocole de ligne série de l'avenir et le choix probable des distributeurs de routeurs à la recherche
d'un mécanisme standard de transmission sur des lignes série.

Conclusion : SLIP ou PPP ?

Nombre d'administrateurs réseau débattent du choix du meilleur protocole série. En réalité, l'utilisation du
"meilleur protocole" ne constitue pas toujours le choix correct ; il s'agirait plutôt de sélectionner le
"protocole approprié" à une situation particulière.
PPP constitue un meilleur choix puisqu'il permet le transport de datagrammes de nombreux protocoles de
couche réseau. Par conséquent, il assure l'interopérabilité entre les systèmes commercialisés par une large
palette de distributeurs. De plus, PPP possède plus d'options et est plus puissant que le protocole SLIP. Compte
tenu de ces éléments PPP constitue le choix approprié comme protocole non-propriétaire pour assurer la connexion
des routeurs sur les lignes série. Etant donné que SLIP a été le premier protocole série IP largement répandu, il est
par conséquent disponible pour un plus grand nombre de types de matériel que PPP.
L'accès commuté constitue l'une des applications les plus utilisées pour IP sur les lignes série. Le protocole SLIP
est plus souvent utilisé à cette fin que le protocole PPP, puisque nombre de système qui proposent l'accès commuté
supportent uniquement SLIP. SLIP est disponible pour la plupart des serveurs et dans majorité des mises en œuvre
PC de TCP/IP.
SLIP et PPP ne peuvent échanger des informations, il s'agit de protocole complètement différent. Dés lors, si vos
 serveurs utilisent uniquement SLIP, les hôtes à distance, interconnectés au travers de ces serveurs doivent
aussi utiliser SLIP. Etant donné le nombre de protocoles SLIP, celui-ci sera encore présent de nombreuses années.
 SLIP et PPP tombent aujourd'hui en désuétude remplacés par des protocoles offrant une meilleure garantie de
sécurité, la plupart basé sur PPP (PPTP, L2F, L2TP...)

Les Principaux protocoles de VPN

PPTP (Point to Point Tunnelling Protocol)

Introduction

L’intérêt de PPTP est de ne nécessiter aucun matériel supplémentaire car les deux logiciels d’extrémité
(le client et le serveur) sont intégrés dans NT4. Par contre, il ne fonctionne que sous NT pour le moment.

Le protocole d'authentification dans Microsoft PPTP est le protocole d'épreuve/réponse de Microsoft (MS-CHAP)
et le protocole de chiffrement est le chiffrement Point to Point de Microsoft (MPPE). Après la cryptanalyse de
Microsoft PPTP et la révélation publique de ses faiblesses importantes, Microsoft a mis à jour ses protocoles.
La nouvelle version s'appelle MS-CHAP version 2 (MS-CHAPv2); l'ancienne version a été renommée MS-CHAP
version 1 (voir annexe).

L2F (Layer Two Forwarding)

C’est un protocole qui a été développé par Cisco, Northern Telecom et Shiva. Il est décrit dans la RFC 2341
L2F est un protocole de niveau 2 qui permet à un serveur d’accès distant de véhiculer le trafic sur PPP et
transférer ces données jusqu’à un serveur L2F (routeur). Ce serveur L2F désencapsule les paquets et les
envoie sur le réseau.
Il faut noter que contrairement à PPTP et L2TP, L2F n’a pas besoin de client.
Fonctionnement :
·    Création d’un tunnel entre l’ISP et le serveur d’accès distant.
·    Connexion PPP entre le client et l’ISP que celui-ci fait suivre au serveur d’accès distant via le tunnel L2F.

Ce protocole est progressivement remplacé par L2TP qui est plus souple.

L2TP (Layer Two Tunnelling Protocol)

Le protocole L2TP (Layer 2 Tunneling Protocol), développé à partir du protocole point à point PPP, est sans conteste
l'une des pierres angulaires des réseaux privés virtuels d'accès. Il rassemble en effet les avantages de deux autres
protocoles de fractionnement en canaux : L2F (Layer 2 Forwarding), développé par Cisco Systems, et PPTP
( Point-to-Point Tunneling), de Microsoft. L2TP est une norme préliminaire de l'IETF (Engineering Task Force)
actuellement développée et évaluée conjointement par Cisco Systems, Microsoft, Ascend, 3Com et d'autres
acteurs clés du marché des réseaux.
L2TP est un protocole réseau qui encapsule des trames PPP pour les envoyer sur des réseaux IP, X25, relais
de trames ou ATM. Lorsqu’il est configuré pour transporter les données sur IP, L2TP peut être utilisé pour faire
du tunnelling sur Internet. Mais L2TP peut aussi être directement mis en œuvre sur des supports WAN
(relais de trames) sans utiliser la couche de transport IP.
On utilise souvent ce protocole pour créer des VPN sur Internet. Dans ce cas, L2TP transporte des trames
PPP dans des paquets IP. Il se sert d’une série de messages L2TP pour assurer la maintenance du tunnel
et d’UDP pour envoyer les trames PPP dans du L2TP.

Concepts clés de L2TP

Concentrateur d'accès L2TP (LAC) Les périphériques LAC peuvent être intégrés à la structure d'un réseau commuté comme
le réseau téléphonique commuté (RTC) ou encore associés à un système d'extrémité PPP prenant en charge le protocole L2TP.
Le rôle du concentrateur d'accès LAC se limite à fournir un support physique qui sera utilisé par L2TP pour transférer le trafic
vers un ou plusieurs serveurs réseau L2TP (LNS). Il assure le fractionnement en canaux pour tout protocole basé sur PPP.
Le LAC est l'émetteur des appels entrants et le destinataire des appels sortants. Dans le cadre du protocole L2F
(Layer 2 Forwarding), ce périphérique est connu sous le nom de serveur d'accès au réseau ou NAS.
C’est lui qui sera l’originaire du tunnel et le responsable de l’identification du VPN.

Serveur réseau L2TP (LNS) Les serveurs réseau L2TP ou LNS, peuvent fonctionner sur toute plate-forme prenant en
charge la terminaison PPP. Le LNS gère le protocole L2TP côté serveur. Le protocole L2TP n'utilise qu'un seul support,
sur lequel arrivent les canaux L2TP. C'est pourquoi les serveurs réseau LNS ne peuvent qu'avoir une seule interface de
réseau local (LAN) ou étendu (WAN). Ils sont cependant capables de terminer les appels en provenance de n'importe
laquelle des interfaces PPP du concentrateur d'accès LAC : async. , RNIS, PPP sur ATM ou PPP sur relais de trame.
Le LNS est l'émetteur des appels sortants et le destinataire des appels entrants. Dans le contexte du protocole L2F,
les serveurs réseau L2TP sont également connus sous le nom de " Home Gateway " ou HGW.
C’est le LNS qui sera responsable de l’authentification du tunnel.

Avantages de L2TP :

Fonctionnement indépendant du support
- La mise en ouvre de L2TP est opérationnelle sur n'importe quel réseau
supportant les trames IP. Elle accepte toutes les technologies de réseau fédérateur étendu, notamment le relais de
trame, ATM, X.25 ou SONET. Elle est également opérationnelle sur les réseaux locaux comme Ethernet, Fast
Ethernet, Token Ring et FDDI.

Sécurité
Le protocole de fractionnement de canaux L2TP prend en charge l'authentification des canaux et des
utilisateurs. Par ailleurs, il est possible d’utiliser les fonctions de PPP (PAP, CHAP, MPPE) et il est conseillé
de l’interfacer avec IPSEC.

Attribution et gestion des adresses :
le protocole L2TP offre un support complet des fonctions d'attribution
dynamique d'adresses IP à partir d'un pool d'adresses géré par l'entreprise. Ces fonctions incluent notamment
la prise en charge intégrale des adresses privées (cf. RFC 1918). Le protocole L2TP inclut également la prise
en charge de l'attribution dynamique d'adresses depuis le serveur DHCP.

Fiabilité :
L2TP donne accès à des fonctions de sauvegarde permettant de configurer plusieurs pairs LNS et
de les renforcer par des LNS de secours. Si une connexion vers le serveur LNS principal est indisponible pour
une raison quelconque, le serveur d'accès réseau NAS (concentrateur d'accès LAC) établit une connexion vers
le serveur LNS de secours.

Modularité :
L2TP supporte un nombre illimité de connexions sur chaque LAC et peut assurer plus de 2 000
sessions par LNS sur une plate-forme de routage Cisco.

Gestion :
afin d'optimiser la gestion des incidents, l'implémentation de L2TP inclut la prise en charge L2TP
des bases MIB SNMP même avant que ne soit homologuée la norme MIB de l'IETF. Le support MIB offre
une codification complète des incidents ainsi qu'un système exhaustif de diagnostic des motifs de déconnexion.
En outre, L2TP comporte un ensemble de messages pouvant être envoyés à un serveur syslog
(historique système). Cet ensemble de fonctionnalités offre aux réseaux privés virtuels d'accès basés sur
L2TP une solution complète de bout en bout de résolution des incidents.

L2TP étant un protocole standard, tous les clients (qu'ils soient fournisseurs d'accès Internet ou administrateurs
de réseaux d'entreprise) bénéficient d'une large gamme de solutions de services proposées par divers fournisseurs.
Cette compatibilité garantit la perspective d'un déploiement international rapide d'un service standard de réseaux
privés virtuels d'accès.

• facultatif : Le tunnel s’établit entre le poste du client et le NAS du réseau d’entreprise. Le client doit utiliser un protocole de tunneling installé sur son poste. L’appel à un ISP ( Internet Source Provider ) permet au client d’être connecté au réseau IP et d’initialiser ensuite son tunnel. Le tunnel s’établit entre le fournisseur d’accès Internet ( ISP ) et le NAS du réseau d’entreprise.  
• obligatoire : Le réseau d’entreprise doit dans ce cas être raccordé au réseau IP par un appareillage capable d’établir le tunnel. Selon les protocoles de tunneling cet appareillage ( ordinateur ou périphérique ) est appelé :
  o    - processeur frontal (FEP, Front End Processor) dans PPTP,
  o    - concentrateur d'accès L2TP (LAC, L2TP Access Concentrator) dans L2TP,
  o    - ou passerelle de sécurité IP dans IPSec
  Dans ce cas le tunnel peut être partagé par différents utilisateurs. Le tunnel sera fermé lorsque le dernier utilisateur se déconnectera.
  

IPSec : une architecture sécurisée pour IP

IPSec: Introduction et applications

L'Internet modifie rapidement la façon de travailler. Parallèlement la vitesse des communications s'accroît et
leurs coûts décroissent.
L'Internet permet de créer:
Des Extranets--- Les sociétés peuvent facilement établir une liaison avec leurs fournisseurs et partenaires. Aujourd'hui
 ce lien doit être réaliser soit au travers de lignes louées ou de liaison RTC/RNIS de faible vitesse. L'Internet permet
 la communication instantanée, à la demande, et à grande vitesse.
Les Intranets--- La plupart des grandes entreprises utilise un réseau global coûteux.
Tant que le coût des liaisons dédiées ne sera pas réduit, il est hors de question que la réduction de coût soit importante.
L'accès distant (Remote users) --- L’INTERNET fournit une alternative a faible coût permettant aux utilisateurs distants
d'accéder au réseau global de l'entreprise. Plutôt que d'utiliser des batteries de modems et une grosse note de
téléphone, l'entreprise peut utiliser le réseau Internet pour permettre à ces utilisateurs distants de se connecter.
Avec juste un appel local vers un ISP (Internet service provider), l'utilisateur peut accéder au réseau global de l'entreprise..
Ces et les nouvelles applications Internet vont changer la façon dont le monde des affaires communique. L’Internet fournit
une infrastructure de communication publique nécessaire et ouvert à toutes les utilisations possibles.
Toutefois, l’Internet à quelques lacunes importantes comme la sécurité, la qualité de service, la fiabilité, et la supervision.
IPSec est l'une de ces technologies qui fournit la sécurité que l'on peut attendre d'un service réseau.
Pour sécuriser les échanges ayant lieu sur un réseau TCP/IP, il existe plusieurs approches :
- niveau applicatif (PGP)
- niveau transport (protocoles TLS/SSL, SSH)
- niveau physique (boîtiers chiffrant).

IPsec vise à sécuriser les échanges au niveau de la couche réseau. Le réseau IPv4 étant largement déployé et la migration complète vers IPv6 nécessitant encore beaucoup  de temps, il est vite apparu intéressant de définir des mécanismes de sécurité qui soient communs à la  fois à IPv4 et IPv6. Ces mécanismes sont couramment désignés par le terme IPsec pour IP Security Protocols. IPsec fournit donc : - confidentialité et protection contre l'analyse du trafic, - authentification des données (et de leur origine), - intégrité des données (en mode non connecté), - protection contre le rejeu, - contrôle d'accès. IPsec est une extension de sécurité pour le protocole Internet IP. Il peut être mis en œuvre sur tous les équipements du réseau et de nombreux fournisseurs l'intègrent désormais dans leurs produits. Exemple d'utilisation : Les réseaux privés virtuels ou VPN ou bien la sécurisation des accès distants à un intranet

IPsec fonctionne autour de bases de données de politiques de sécurité dont le fonctionnement est décrit ci-après.

Principe du fonctionnement SA / SAD /SPD

SA :‘Security Association’. L’association de sécurité IPsec est une connexion qui fournit des services de sécurité au trafic qu’elle transporte. Il s’agit d’une structure de données servant à stocker l’ensemble des paramètres associés à une communication donnée. Une SA est unidirectionnelle ; en conséquence, protéger les deux sens d’une communication classique requiert deux associations, une dans chaque sens. Les services de sécurité sont fournis par l’utilisation soit de AH soit de ESP (vus plus loin). Le rôle d’une SA est donc de consigner, pour chaque adresse IP avec laquelle l’implémentation IPsec peut communiquer, les informations suivantes :
- index de la SA appelé SPI (pour Security Parameter Index) choisi par le récepteur
- un numéro de séquence, indicateur utilisé pour le service d’anti-rejeu
- une fenêtre d’anti-rejeu : compteur 32 bits
- dépassement de séquence
- paramètres d’authentification (algorithmes et clés)
- paramètres de chiffrement (idem)
- temps de vie de la SA
- mode du protocole IPsec (tunnel ou transport)
- …
Chaque association est identifiée de manière unique à l’aide d’un triplet composé de :
- l’adresse de destination des paquets
- l’identifiant du protocole de sécurité (AH ou ESP)
- le SPI 

SAD : ' Security Association Database ' . Pour gérer les associations de sécurité actives, on utilise une base de données des associations de sécurité. Elle contient tous les paramètres relatifs à chacune des SA et sera consultée pour savoir comment traiter chaque paquet reçu ou à émettre. 

SPD : ' Security Policy Database '. Les protections offertes par IPsec sont basées sur des choix définis dans une base de données de politique de sécurité. Cette base de données est établie et maintenue par un utilisateur, un administrateur ou une application mise en place par ceux-ci. Elle permet de décider, pour chaque paquet, s’il se verra apporter des services de sécurité, s’il sera autorisé à passer outre ou sera rejeté.
Ces services sont basés sur des mécanismes cryptographiques. Pour cela, IPsec fait appel à deux protocoles de sécurité qui viennent s'ajouter au protocole IP classique : il s'agit des protocoles AH et ESP. IPsec offre ainsi deux possibilités d'encapsulation distinctes. Toutefois, l'évolution de ce protocole fait que ESP assure désormais l'ensemble des fonctionnalités des deux mécanismes.
Au-delà de AH et ESP, l'IETF a jugé judicieux d'offrir un service supplémentaire appelé chiffrement en mode Fast Forward qui conserve la même taille de datagrammes et ainsi des performances optimales. Cependant, il protège en confidentialité uniquement. L'en-tête IP et la longueur du datagramme restent inchangés (sauf éventuellement le champ d'options IP qui peut être chiffré).
Les SA contiennent tous les paramètres nécessaires à IPsec, notamment les clés utilisées. La gestion des clés pour IPsec n’est liée aux autres mécanismes de sécurité de IPsec que par le biais des SA. Une SA peut être configurée manuellement dans le cas d’une situation simple, mais la règle générale consiste à utiliser un protocole spécifique qui permet la négociation dynamique des SA et notamment l’échange des clés de session.
Le protocole de négociation des SA, développé pour Ipsec, est le protocole de gestion des clés et des associations de sécurité pour Internet (Internet Security Association and Key Management Protocol, ISAKMP). ISAKMP est en fait inutilisable seul (il s’agit d’un cadre générique qui permet l’utilisation de plusieurs protocoles d’échange de clé). Dans le cadre de la standardisation de IPsec, ISAKMP est associé à une partie des protocoles SKEME et Oakley pour donner un protocole final du nom de Internet Key Exchange, IKE.
Reprenons maintenant le schéma précédent sur deux exemples :

Exemple 1 : trafic sortant

Lorsque la couche IPsec reçoit des données à envoyer, elle commence par consulter la base de données des politiques de sécurité (SPD) pour savoir comment traiter ces données. Si cette base lui indique que le trafic doit se voir appliquer des mécanismes de sécurité, elle récupère les caractéristiques requises pour la SA correspondante et va consulter la base des SA (SAD). Si la SA nécessaire existe déjà, elle est utilisée pour traiter le trafic en question. Dans le cas contraire, IPsec fait appel à IKE pour établir une nouvelle SA avec les caractéristiques requises. 

Exemple 2 : trafic entrant

Lorsque la couche IPsec reçoit un paquet en provenance du réseau, elle examine l’en-tête pour savoir si ce paquet s’est vu appliquer un ou plusieurs services IPsec et si oui, quelles sont les références de la SA. Elle consulte alors la SAD pour connaître les paramètres à utiliser pour la vérification et/ou le déchiffrement du paquet. Une fois le paquet vérifié et/ou déchiffré, la SPD est consultée pour savoir si l’association de sécurité appliquée au paquet correspondait bien à celle requise par les politiques de sécurité. Dans le cas où le paquet reçu est un paquet IP classique, la SPD permet de savoir s’il a néanmoins le droit de passer. Par exemple, les paquets IKE sont une exception. Ils sont traités par IKE, qui peut envoyer des alertes administratives en cas de tentative de connexion infructueuses.

Protocole AH (Authentication Header)

AH est conçu pour assurer l'intégrité en mode non connecté et l'authentification de l'origine des datagrammes IP sans chiffrement des données (pas de confidentialité). L'absence de confidentialité permet de s'assurer que ce standard pourra être largement répandu sur Internet, y compris dans les endroits où l'exportation, l'importation ou l'utilisation du chiffrement dans des buts de confidentialité est restreint par la loi. 

Son principe est d'adjoindre au datagramme IP classique un champ supplémentaire permettant à la réception de vérifier  l'authenticité des données incluses dans le datagramme. Ce bloc de données est appelé "valeur de vérification d'intégrité"  (Intégrity Check Value, ICV). La protection contre le rejeu se fait grâce à un numéro de séquence.

Mode transport et mode tunnel

Le mode transport prend un flux de niveau transport (couche de niveau 4 du modèle OSI) et réalise les mécanismes de signature et de chiffrement puis transmet les données à la couche IP. Dans ce mode, l'insertion de la couche IPsec est transparente entre TCP et IP. TCP envoie ses données vers IPsec comme il les enverrait vers IPv4.
L'inconvénient de ce mode réside dans le fait que l'en-tête extérieur est produit par la couche IP c'est-à-dire sans masquage d'adresse. De plus, le fait de terminer les traitements par la couche IP ne permet pas de garantir la non-utilisation des options IP potentiellement dangereuses. L'intérêt de ce mode réside dans une relative facilité de mise en œuvre.
Dans le mode tunnel, les données envoyées par l'application traversent la pile de protocole jusqu'à la couche IP incluse, puis sont envoyées vers le module IPsec. L'encapsulation IPsec en mode tunnel permet le masquage d'adresses.

Le mode tunnel est utilisé entre deux passerelles de sécurité (routeur, firewall, …) alors que le mode transport se situe entre deux hôtes.

Protocole ESP (Encapsulating Security Payload)

ESP peut assurer, au choix, un ou plusieurs des services suivants :
- confidentialité des données et protection partielle contre l'analyse du trafic si l'on utilise le mode tunnel
- intégrité des données en mode non connecté et authentification de l'origine des données, protection partielle contre le rejeu.

Contrairement à AH, où l'on se contentait d'ajouter un en-tête supplémentaire au paquet IP, ESP fonctionne suivant le principe de l'encapsulation : Les données originales sont chiffrées puis encapsulées.

Encapsulation

Limitation IPSec et NAT

NAT est incompatible avec le protocole AH (Authentication Header), que ce soit en mode transport ou tunnel. Un VPN IPsec utilisant le protocole  AH protocole ajoute une signature digitale au paquet sortant, incluant la charge utile et les entêtes, avec la valeur du "hash" rajoutée au paquet. Quand on utilise le protocole AH, le contenu du paquet (la charge utile) n'est pas crypté.
C'est cette caractéristique qui pose problème avec NAT: l'équipement NAT au milieu d'un lien bout à bout IPSec qui réécrit l'adresse de la source et/ou de la destination  et la remplace par une de son propre chef (donc variable et inconnue pour le lien IPSec). L'équipement VPN terminal qui reçoit va vérifier l'intégrité des paquets entrants en calculant la valeur du "hash", et s'apercevra  de la non-cohérence de la valeur de "as" calculée et de celle rajoutée au paquet. L'équipement VPN terminal qui ne reçoit aucune indication concernant le NAT effectué en cours de transport considérera que les données ont été altérées en cours de transmission et donc détectera une erreur de transport.
En utilisant IPsec ESP (Encapsulating Security Payload) en mode tunnel celui-ci encapsule le paquet original complet (incluant l'entête) dans un nouveau paquet IP. La nouvelle adresse source du paquet IP est celle de l'adresse de sortie de la passerelle VPN sortante, et son adresse de destination est l'adresse d'entrée de l'équipement terminal qui reçoit. Quand on utilise le protocole ESP avec l'authentification, le contenu du paquet est crypté ( dans ce cas: le paquet d'origine complet). Le contenu est crypté, mais  pas le nouvel entête qui n'est pas "signé " avec la valeur de "hash" précédemment rajoutée au paquet.
Ce mode (mode ESP avec authentification) est compatible avec NAT, car le contrôle d'intégrité est réalisé après la combinaison de l'entête original et de la charge utile d'origine, lesquelles ne sont pas modifiées par NAT. Le mode transport ESP avec authentification est aussi compatible avec NAT, mais il est peu utilisé. Tant que le hash est calculé au-dessus de la charge utile d'origine, l'entête d'origine peut être reconstitué.
De plus, NAT peut interférer avec IPSec (en mode ESP ou AH) en interdisant la négociation des certificats SAs utilisant ISAKMP/IKE entre deux passerelles VPN. Les certificats X.509 sont "signés" par un tiers ( trusted third party), appelé Autorité de Certification (CA en anglais, Certificate Authority) pour permettre de rattacher une clé publique utilisateur ou équipement à une identification caractéristique publique. Comme l'identification caractéristique publique utilise, pour les équipements de passerelle VPN, l'adresse externe IP. Si deux passerelles VPN échangent des certificats signés rattachés à l'identité de passerelle par rapport à son adresse IP, la réécriture par NAT de l'adresse générera une défaillance dans la négociation de IKE.
Altiga (Cisco) ont mis à jour leur version IPSec client qui permet une connexion à travers NAT. Ils appellent cela "IPsec over UDP". Cela ressemble à quelque chose de moins sécurisé que le "vrai" IPSec.IPSec Natif nécessite qu'il n'y ait aucun changement dans les entêtes et NAT évidement ne respect pas cette caractéristique. Mais IPSec over UDP d'Altiga  résout pratiquement ce problème - que beaucoup d'utilisateurs d'accès Internet demandent en tant que service à leur ISPs pour utiliser NAT.
PPTP dépend du type de NAT traversé. Il fonctionne à travers un firewall de type SonicWall. Mais PPTP traversant un routeur ou firewall NAT de Cisco pose problème (si  on fait du NAT sur une seule adresse IP routable, cela gère l'équivalent d'une surcharge du PAT serveur).

IPSec : Conclusions

Caractéristiques, forces et faiblesses résumé du cadre protocolaire IPsec
 

Caractéristique	Description - Commentaires	Avantages
Confidentialité, Integrit et Authenticité des données	IPSec fournit ces services réseaux gràce aux technologies de cryptage  et d'authentification.	Le sdonnées peuvent être transmissentà travers le réseau publique sans risque d'observation, modification, ou spoofing. Ce qui permet des applications telles que les VPNs, l'extranets, et l'accès distant.
Solution Intégrée	IPSec est disponible par seulement une mise à jour logicielle des équipements de l'infrastructure réseau.	La sécurité peut-être implementée sans implication au niveau des cuts de caque poste de travail, permettant une économie substansielle, car seul l'infrastructure doit d'être modifiée.
Support des certificats	Les équipement sont automatiquement authentifiés gràce  à l'utilisation des certificats numériques.	Cette caratéristique est applicable à l'echelle de grands réseaux qui nécéssite des connexions sécurisées entre un nombre important d'équipements.
IKE	Ce prôtocole est utilisé pour négocier automatiquement les associations de sécurité.	Cela permet des communications sécurisées sans pré configurations manuelles couteuses.
Souplesse et flexibilité des politiques de sécurité	Le traffic peut être sélectionné à partir du cryptage à base des access listes étendues.	Le traffic choisi peut-être crypté pour améliorer la performance global.    Différentes classifications de données peuvent être cryptées avce différentes clés ou différents algorythmes.
Solution Standard	IPSec est un standard IETF émergeant .	IPSec permet une interopérabilité multivendeur entre noeuds réseaux, PCs, et autres systèmes.

RFCs courantes et drafts Internet concernants IPSec et/ou IKE:

• ESP  draft-ietf-ipsec-esp-v2-04.txt
• AH draft-ietf-ipsec-auth-header-05.txt
• IKE draft-ietf-ipsec-ISAKMP/Oakley-07.txt
• L'implémentation complète d'IPSec est décrite dans draft-ietf-ipsec-arch-sec-04.txt (Security Architecture for the Internet Protocol)

Algorythmes de cryptage IPSec et IKE inclus:

• DES-CBC avec Explicit IV
• 40-bit DES-CBC avec Explicit IV
• DES-CBC avec Derived IV comme spécifié dans la RFC 1829

Algorythmes d'Authentification:

• HMAC-MD5
• HMAC-SHA
• Keyed MD5 comme spécifié dans la RFC 1828

Avantages :
- Modèle de sécurité flexible et non exhaustif basé sur une boîte à outils modulaire
- Possibilité d'instaurer plusieurs crans de sécurité : chiffrement faible ou fort et/ou authentification
- Services de sécurité totalement transparents pour les applications
Inconvénients :
- Mécanismes de sécurité trop nombreux, engendrant un système complexe
- IPsec interdit en mode AH la translation d'adresses (Network address translation, NAT)
- L'interaction du protocole IKE avec les infrastructures à clé publique (PKI) est possible mais il reste à normaliser
- Les outils d'administration centralisée des règles de sécurité (Security Policies) font défaut
- Entorses propriétaires nuisibles à l'interopérabilité
- IPsec est limité à l'instauration de VPN entre réseaux (passerelles-serveurs). Le protocole orienté client-serveur IPSRA (IPsec Remote Access) devra s'imposer face à PPTP ou L2TP. 

Exemple : échange IPSec dans un tunnel L2TP

Fichier ipsec l2tp au format libcap

Affichage du fichier dans ethereal :

Introduction à MPLS : Multiprotocol Label Switching

Définition

Multiprotocol Label Switching (MPLS) est une solution proposée pour répondre aux problèmes posés par les réseaux actuels. C’est apparu comme une solution permettant d’organiser la rencontre entre l’administration de bande passante et le besoin de services pour les nouveaux réseaux IP. MPLS propose des solutions liées à la scalabilité (adaptation à l’échelle du réseau) et au routage (basé sur la QoS et les mesures de la QoS). Il peut s’adapter aux réseaux ATM et Frame Relay. MPLS est un protocole de routage dérivé du protocole Tag Switching de CISCO.MPLS assure la commutation et le routage. Le routage à travers un VPN IP avec le protocole MPLS met en œuvre des routeurs d’extrémités et des routeurs internes. Les routeurs d’extrémités sont le point d’entrée dans le réseau public ou externe à l’entreprise. Ils suivent l’algorithme BGP et possèdent des tables de routage VPN. L’adresse VPNIP est composée de l’adresse IP et de l’adresse du Route distinguish. Les routeurs internes sont internes au réseau public. Ils utilisent l’algorithme IGP (OSPF ou ISIS ). Ils optimisent la route à travers le réseau MPLS. Ils créent une route LSP ( Label switched Path ) grâce au protocole LDP ( Label Distribution Path ). Le paquet transitant par un VPN IP a en fait deux labels :
-Un label de premier niveau comprenant les adresses du routeur d’extrémité source et l’adresse du routeur d’extrémité cible.
-Un label de second niveau indiquant l’appartenance du paquet à un VPN. Ce label de niveau réseau permet au MPLS de gérer dynamiquement le routage et permet le multicast.
MPLS permet le routage sans passer par des fonctions de translations d’adresses.

1. Introduction

Au cours de ces dernières années, Internet a évolué et a inspiré le développement de nouvelles variétés d’applications. Ces applications ont des besoins de garantie en terme de bande passante et de sécurité de service au sein des backbones. En plus des données traditionnelles, Internet doit maintenant transporter voix et données multimédia. Les ressources nécessaires pour ces nouveaux services, en terme de débit et de bande passante, ont entraînées une transformation de l’infrastructure d’Internet. Cette transformation du réseau, d’une infrastructure par paquets à une infrastructure en cellules, a introduit de l’incertitude dans un réseau jusque-là déterministe.
En plus de ces contraintes sur les ressources, un autre challenge est le transport des données sur le backbone en offrant différentes classes de services aux utilisateurs. La croissance exponentielle du nombre d’utilisateurs et le volume du trafic ajoute une nouvelle dimension au problème. Les classes de services (CoS) et la qualité de service (QoS) doit être prise en compte pour répondre aux différents besoins de chaque utilisateur du réseau.
En résumé, MPLS jouera un rôle important dans le routage, la commutation, et le passage des paquets à travers les réseaux de nouvelle génération pour permettre la rencontre entre les besoins de service et les utilisateurs du réseau.

2. Routage et commutation de paquet traditionnels

Le déploiement initial d’Internet répond au transfert de données sur le réseau. Pour cela, un simple routeur logiciel et des interfaces réseaux suffisaient. Au fur et à mesure que la possibilité de supporter des transmissions hauts débits a émergé, des éléments capables de commuter au niveau 2 et au niveau 3 ont du être déployés au niveau matériel (hardware).
Ces solutions répondent aux besoins de transfert rapide de paquets lors de la traversée du réseau, mais ne répondent pas aux besoins en terme de service pour les informations contenues dans les paquets. De plus, la majorité des protocoles de routage actuellement déployé se basent sur des algorithmes permettant d’obtenir le passage le plus rapide sur le réseau, mais ne prennent pas en compte d’autres mesures, comme les délais ou les congestions qui peuvent sérieusement diminuer les performances du réseau. La gestion du trafic est un objectif pour les administrateurs réseaux.

3. MPLS et ses composants

Qu’est-ce que MPLS?

MPLS est normalisé par l’IETF (Internet Engineering Task Force). Il assure les fonctions suivantes :
- Il spécifie les mécanismes pour administrer les flux de trafic de plusieurs types, comme les flux entre des matériels différents, des machines différentes ou même entre des applications différentes
- Il est indépendant des protocoles des couches 2 et 3.
- Il interagit avec des protocoles de routage existant, comme RSVP (ressource reservation protocol) et OSPF (open shortest path first).
- Il supporte les couches de niveau 2 des réseaux IP, ATM, et Frame Relay.
Dans MPLS, la transmission de données se fait sur des label-switched paths (LSP, Chemin à commutation de label). Les LSP sont une séquence de labels (ou étiquettes) à chaque nœud du chemin allant de la source à la destination. Les LSP sont établis en fonction du type de transmission des données (control-driven) ou après détection d’un certain type de données (data-driven). Les labels, qui sont des identifiants spécifiques au protocole des couches basses, sont distribués suivant le protocole LDP (Label Distribution Protocol), RSVP ou parfois par les protocoles de routage comme BGP (Border Gateway Protocol) ou OSPF.
Chaque paquet de données encapsule et transporte les labels pendant leur acheminement. La commutation haut débit est possible puisque les labels de longueur fixe sont insérés au tout début du paquet ou de la cellule et peuvent être utilisés par le hardware pour commuter plus rapidement.

LSR et LER

Les éléments qui participent aux mécanismes du protocole MPLS peuvent être séparés en Label Edge Routers (LER, Routeur d’extrémité supportant les labels ) et Label Switching Routers (LSR, routeur de commutation des labels).
Un LSR est un routeur haut débit au cœur d’un réseau MPLS qui participe à l’établissement des LSP. Un LER est un élément à l’extrémité du réseau d’accès ou du réseau MPLS. Les LER peuvent supporter plusieurs ports connectés à des réseaux différents (ATM, Frame Relay ou Ethernet) et qui font suivre le trafic sur le réseau MPLS après établissement des LSP. Le LER joue un rôle fondamental dans l’assignation et la suppression des labels, au fur et à mesure que le trafic entre et sort du réseau MPLS.

FEC

La Forward Equivalence Class (FEC) est la représentation d’un groupe de paquets qui ont en commun les mêmes besions quant à leur transport. Tous les paquets d’un tel groupe reçoivent le même traitement au cours de leur acheminement. Contrairement aux transmissions IP classiques, dans MPLS, un paquet est assigné à une FEC une seule fois, lors de son entrée sur le réseau. Les FEC sont basés sur les besoins en terme de service pour certains groupes de paquets ou même un certain préfixe d’adresses. Chaque LSR se construit une table pour savoir comment un paquet doit être transmis. Cette table est appelée Label Information Base (LIB, Base d’information sur les labels). 

Labels et association de labels  

Un label, dans sa forme la plus simple, identifie le chemin que le paquet doit suivre. Un label est transporté ou encapsulé dans l’en-tête de niveau 2 du paquet. Le routeur qui le reçoit examine le paquet pour déterminer le saut suivant selon son label. Une fois qu’un paquet est labellisé, le reste de son voyage est basé sur la commutation de labels. Les valeurs du label ont simplement une signification locale. Ces valeurs peuvent d’ailleurs directement déterminer un chemin virtuel (DLCI en Frame Relay ou VCI et VPI en ATM).
Les labels sont associés à un FEC suivant une logique ou une politique déterminant cette association. Cette décision peut se faire sur les critères suivants : Routage unicast vers la destination, gestion du trafic, multicast, Virtual Private Network (VPN) ou QoS.
Le format générique d’un label est illustré par la figure ci-dessous. Le label peut aussi se situer dans l’entête de la couche 2 ou entre les couches 2 et 3.

                                Format de base des labels MPLS

Label-Switched Paths (LSP)

Un ensemble d’éléments compatibles avec MPLS représente un domaine MPLS. Au sein d’un domaine MPLS, un chemin est défini pour un paquet donné à partir d’une FEC. MPLS propose les deux solutions suivantes pour implémenter un LSP :
Routage saut par saut : chaque LSP choisit indépendamment le saut suivant pour un FEC donné. Cette méthodologie est similaire à celle utilisé dans les réseaux IP courants. Le LSR utilise les protocoles de routage disponibles, comme OSPF, PNNI (ATM Private Network-to-Network Interface), etc…
Routage explicite : similaire au source routing. Le premier LSR détermine la liste des nœuds à suivre. Le chemin spécifié peut être non-optimal. Le long de ce chemin, les ressources peuvent être réservées pour assurer la QoS voulue au trafic.
Un LSP est unidirectionnel et le trafic de retour doit donc prendre un autre LSP.

Label Distribution Protocol (LDP)

LDP est un protocole nouveau permettant d’apporter aux LSR les informations d’association des labels dans un réseau MPLS. Il est utilisé pour associer les labels aux FEC, ce qui crée des LSP. Les sessions LDP sont établies entre deux éléments du réseau MPLS, qui ne sont pas nécessairement adjacents.
Ces éléments échangent les types suivants de messages LDP :
- Messages de découverte : annoncent et maintiennent la présence d’un LSR dans le réseau.
- Messages de session : Etablissent, maintiennent et terminent les sessions LDP.
- Messages d’avertissement : Créent, changent et effacent des associations entre FEC et labels.
- Messages de notification : Permettent d’apporter d’autres informations comme signaler une erreur.

NAT: Introduction

Routeurs et translation

TCP/IP est devenu rapidement le protocole standard des réseaux partout. Tous les principaux fournisseurs de systèmes d'exploitation (OS) le fournissent sous une forme ou une autre, l'Internet le nécessite et les utilisateurs le plébiscitent. 

La Pénurie d'adresses IP :
Constat et Solutions La pénurie d'adresses IP disponibles pour connecter de nouvelles machines à l'Internet est souvent pointée du doigt par les prophètes de la fin prochaine du réseau mondial comme l'un des problèmes techniques les plus critiques auquel doit faire face le réseau pour garantir la pérennité de son développement. Au-delà des problèmes chroniques d'engorgement et de leur répercussion au niveau des tables de routage, l'impossibilité de fournir suffisamment d'adresses aux nouveaux venus sur le réseau menacerait de donner un coup d'arrêt brutal à la croissance exponentielle de ce nouveau media. Mais quelle est la cause profonde de cette pénurie ? Comment fonctionne le système d'attribution des adresses ? Quelle est l'ampleur réelle du phénomène et quels sont les moyens d'y remédier ?

Le système de répartition des adresses sur Internet
Comme on le répète souvent, l'Internet est un réseau international dépourvu d'organe de contrôle ou de gouvernement : nul ne peut contenir son extension et sa croissance exponentielle, personne ne décide sur le réseau quel site ou quelle personne peut rejoindre l'Internet ou au contraire, qui doit en être exclu. Personne enfin, n'impose l'usage de tel protocole plutôt que tel autre, de façon impérative. Pourtant, de par sa structure même dont les fondements reposent dans le protocole originel IP (Internet Protocol), l'Internet comme tous les autres réseaux a besoin pour fonctionner qu'un certain nombre de paramètres parmi tous les paramètres indispensables au bon fonctionnement d'un réseau soient assignés impérativement de façon UNIQUE. Parmi ceux-ci, les noms de domaines (deux sites distincts ne peuvent partager le même nom de domaine), les numéros de ports TCP/UDP qui canalisent les informations vers les bonnes applications par défaut, les MIBs et bien sûr avant tout, les adresses IP des machines connectées. En effet, deux machines sur le réseau ne peuvent partager la même adresse IP puisque ce numéro est l'unique paramètre devant permettre aux paquets d'information de retrouver leur destination sur le réseau. Il est par conséquent capital pour la bonne marche du réseau que ces adresses IP soient assignées de façon concertée, et c'est pourquoi fut créée sous l'égide de l'IETF (la branche technique de l'Internet Society qui valide les différents protocoles et au tout premier lieu TCP/IP), l'IANA ou Internet Assigned Numbers Authority, centre de coordination pour la distribution de tous les paramètres à valeur unique sur l'Internet. Pour mener à bien sa tâche, l'IANA délègue ses fonctions à différents organismes régionaux, qui eux-mêmes cèdent le plus souvent une partie de leur activité à d'autres organismes, sur des bases régionales ou fonctionnelles. Ainsi, par exemple, l'InterNIC, géré par une société privée (Network Solution) est responsable des attributions de l'IANA pour l'ensemble du continent américain. Il tente cependant de déléguer la gestion de l'attribution des adresses IP à une nouvelle entité à but non-lucratif, l'ARIN ou American Registry for Internet Numbers, afin de séparer l'activité "rentable" que constitue l'enregistrement payant des noms de domaines et l'attribution des adresses IP que chacun souhaite conserver gratuite. Pour l'Europe, le découpage par pays de la hiérarchie des domaines du plus haut niveau (top-level domain : ". uk", ".fr", ".de", etc.) a abouti à une délégation finale de la gestion des noms de domaine à des organismes nationaux. Ainsi en France, c'est le NIC France qui gère le domaine.fr et attribue les différents noms de domaine selon des critères et à des prix qui lui sont propres. Par contre, les fonctions d'attributions des plages d'adresses IP restent entre les mains de l'organisme européen, le RIPE NCC qui gère également le Moyen-Orient et l'Afrique. Ce dernier n'attribue cependant pas directement les adresses aux utilisateurs finals, mais uniquement aux prestataires de service Internet, qui les répartissent ensuite entre leurs différents clients. Ces différents ISP (Internet Service Provider ou prestataires de service Internet) sont désignés par le RIPE comme des Local Internet Registries auxquelles les entreprises peuvent s'adresser pour se voir allouer un champ d'adresses IP correspondant à leurs besoins. Dans chaque pays, ces Local Internet Registries sont classés en trois catégories (Large, Medium et Small), selon leur degré de participation au budget du RIPE-NCC (participation dont le montant autrefois volontaire est depuis 1995 édicté par le RIPE-NCC de façon impérative). On dénombre 5 Large Local Internet Registries pour la France : notamment des opérateurs (France Telecom via sa filiale Transpac, AT&T et Cegetel), et de très gros prestataire d'accès Internet (UUNET et RENATER, cœur du réseau Internet académique et de la recherche en France). Onze sociétés proposent leurs services en tant que Medium Local Internet Registries pour la France (notamment des prestataire de service Internet professionnel comme Oleane ou Internet Way, ainsi que des opérateurs et prestataire de services étrangers souhaitant développer un réseau européen ou disposant de filiales en France). Enfin, on dénombre 44 SmallLocal Internet Registries. Notons également que deux autres prestataires peuvent attribuer des champs d'adresses sur la France de part leur statut de Supernational Internet Registries : il s'agit de IBM Global Network et de Eunet.
L'intérêt d'un tel système hiérarchique d'attribution des adresses reposant, à la base de la pyramide, sur la fourniture de l'accès physique au réseau et des adresses IP par un même Prestataire de Service est très sensible en terme de routage. Il permet en effet d'attribuer à un prestataire de service Internet un Provider Aggregatable Address Space, c'est à dire un espace d'adressage unique pour ses clients qui partageront tous le même début d'adresse IP (les x premiers bits de l'adresse). Ceci permet de diminuer de façon significative les tables de routages en routant automatiquement vers le provider toutes les adresses contenues dans son espace d'adresses agrégable, et en lui laissant alors la charge de router sur ses réseaux internes les paquets vers les réseaux de ses clients. La conséquence logique de cette technique d'attribution est de nécessiter un changement d'adresse lors de tout changement de prestataire d'accès puisque chaque préfixe d'adresse est propre à chaque prestataire. Seule l'attribution d'un Provider Independent Address Space , un espace d'adresses indépendant du Provider permet de changer l'accès physique à l'Internet d'un réseau sans modifier son adressage, mais au prix d'un gonflement inévitable des tables de routage mondiales de l'Internet. C'est pourquoi l'on cherche à limiter au maximum l'usage de tels champs d'adressages, en leur préférant ceux décrit au paragraphe précédent. 
Bien que tout site réseaux indépendant puisse utiliser les adresses IP qu'il souhaite, les sites qui veulent se connecter à l'Internet ou à un réseau distant doivent utiliser l'adressage Internet légal afin que les applications fonctionnent correctement. Quoique l'on puisse envoyer des paquets d'un système utilisant une adresse "illégale", la destination ne sera pas en mesure de renvoyer des paquets si l'adresse que l'on utilise pointe vers un autre réseau sur l'Internet.
A contrario, il n'est pas non plus aisé de déployé un plan d'adressage IP légal à l'intérieur d'un réseau. Peut-être aurez-vous trop de systèmes, rendant difficile voir impossible l'affectation (et la mise à disposition) d'une adresse IP Internet légale par machine étant donnée la pénurie d'adresse IP publique. Ou peut-être utilisez-vous des installations ou applications qui utilisent un adressage IP fantaisiste, demandant la remise à plat complète du plan d'adressage interne avant l'implémentation d'un vrai adressage sur tout le réseau.
Comment résoudre ce dilemme? Les sites qui utilisent leur propre plan d'adressage doivent pouvoir utiliser des adresses accessibles de l'extérieur afin d'accéder aux systèmes distants, mais tous les administrateurs réseaux ne peuvent se payer le luxe d'être complètement compatible avec l'adressage Internet légal. Les routeurs IP fournissent une solution en cachant les adresses IP des systèmes internes, faisant en sorte que les paquets générés en interne apparaissent comme venant d'un autre système qui utiliserait un adressage IP Internet légal. Le routeur IP fournit une connexion vers l'extérieur  sans nécessité un redéploiement d'adresses IP Internet légales sur tout le réseau interne.
 
 

Les solutions à la pénurie d'adresses IP

Subneting et CIDR

La première solution au problème de pénurie progressive des adresses IP est de tenter de mieux utiliser les adresses existantes, et notamment celles encore non attribuées. Une des grandes difficultés réside dans le fait que beaucoup de sociétés ont besoin de plus de 256 adresses (aussi une classe C se révèle-t-elle insuffisante), même si elles sont loin de pouvoir utiliser l'intégralité des adresses d'une Classe B. Deux choix sont alors possibles : attribuer un bloc de plusieurs classes C, mais ceci nécessite de découper le réseau d'entreprise en sous-réseaux de 255 machines reliées par des routeurs. Ou bien allouer une partie seulement d'une classe B en créant artificiellement un masque de sous-réseau découpant le bloc de 65000 adresses en des espaces d'adressages plus petit. Grâce au classless inter-domain routing ou CIDR, il est désormais possible pour les prestataires d'accès de découper à loisir les espaces d'adresses qui leurs sont alloués d'un seul bloc et de ne faire figurer dans les principaux routeurs de l'Internet qu'une unique adresse et un préfixe de sous-réseau permettant de router automatiquement vers le prestataire l'ensemble des paquets adressés à l'une quelconque des adresses contenu dans ce bloc. On s'affranchit ainsi du découpage arbitraire et peu flexible en classes : l'allocation des ressources est plus fine et les tables de routages sont allégées au cœur du réseau.
En ce sens, le subneting et CIDR ne sont pas de véritables solutions au problème de la rareté des adresses IP, mais en permettant une allocation plus fine des ressources, elles repoussent d'autant les conséquences de la raréfaction accélérée des adresses IP.

Les réseaux Privés et la Translation d'adresse

Il est également possible de bâtir un réseau d'entreprise en utilisant l'un des espaces d'adressage réservés aux réseaux privés coupés de l'Internet. Le réseau de classe A 10.0.0.0, les réseaux de classe B allant de 172.16.0.0 à 172.31.0.0, ainsi que ceux de classe C courant de 192.168.0.0 à 192.168.255.0 sont définis par la RFC (Request for Comment - publications de l'IETF) 1918 comme non attribués sur l'Internet et réservés aux réseaux privés déconnectés. Il est alors possible de relier ces réseaux à l'Internet public en utilisant les routeurs comme des NAT ou Network Address Translators, qui vont attribuer à la volée une adresse publique aux machines internes désireuses d'établir une connexion avec l'Internet public, et effectuer une traduction automatique des adresses IP dans l'en-tête des paquets.

Les réseaux privés et les proxys

Il est également possible de relier ces réseaux privés à l'Internet via des passerelles de plus haut niveau : si la translation d'adresse est une intervention au niveau 3 du protocole (couche OSI de niveau 3, c'est à dire IP), il est également possible d'utiliser des passerelles applicatives pour chacun des services auxquels on souhaite donner accès sur Internet. De telles passerelles appelées proxy établissent des connexions par procuration sur des serveurs publics de l'Internet et font suivre les communications jusqu'aux machines du réseau interne. Ainsi, un proxy HTTP sera doté d'une adresse IP sur le réseau privé interne, et d'une seconde adresse IP sur l'Internet : chaque fois qu'un poste interne souhaitera initier une requête sur le Web, il la dirigera sur le proxy qui se trouve sur son propre réseau, et donc accessible, et ce dernier se chargera d'effectuer la connexion HTTP vers le serveur Web ad-hoc, avant de faire suivre le résultat de la requête (une page HTML par exemple) jusqu'à l'application originaire de la demande. La session Web se passera pour l'utilisateur de la même manière que s'il était directement connecté à l'Internet, alors même qu'une seule machine du réseau est effectivement reliée au réseau public. Il est ainsi possible de faire accéder des centaines de machines aux principales ressources de l'Internet sans qu'elles soient directement reliées au réseau public, et en n'utilisant donc qu'une seule adresse IP publique.
De surcroît, on peut constater qu'un nombre croissant d'entreprises contraignent leurs employés à emprunter de tels proxys applicatifs pour accéder aux ressources externes, notamment pour des raisons de sécurité (le proxy est alors obligatoire pour contourner un firewall) ou bien d'efficacité (le proxy peut-être couplé à un cache qui améliore le rendement du réseau public) : dans ces conditions, l'attribution de plage d’adresses IP publiques à ces postes de facto coupés de l’Internet public par un accès indirect via proxy est un pur gâchis d’adresse. D’une manière générale, la volonté des directions informatiques de maîtriser le trafic de données vers le réseau public, ainsi que l’utilisation généralement bornée des ressources de l’Internet (c’est à dire limité à quelques applications ou service classiques comme le courrier électronique ou le Web) permet d’envisager pour la plupart des utilisateurs professionnels de l’Internet, l’utilisation d’adresses IP réservées aux réseaux internes et l’accès au réseau public via des proxys. C’est au contraire du côté du grand public et des usages domestiques de l’Internet que la nécessité de disposer d’une adresse publique propre lors de la connexion au réseau public est impérative : c’est bien l’utilisateur dans un contexte non-professionnel de l’Internet qui souhaitera accéder à des services originaux et non relayé par un proxy comme des serveurs de jeu en réseau, de nouvelles applications de vidéo à la demande ou de conférences textuelles temps réel. Mais jusqu’à présent, l’essentiel de ces utilisateurs font usage de connexions à la demande via un prestataire d’accès à l’Internet joint quelques heures pas jour par téléphone : nul n’est besoin d’attribuer à chacun d’entre eux une adresse IP fixe, celles-ci étant au contraire répartie entre les modems du prestataire et distribué à la demande lors de chaque connexion. Ainsi, une dizaine d’abonnés au moins de ces services d’accès à Internet partagent la même adresse IP fixe publique.

IPv6

Enfin, le dernier moyen de contrer la pénurie progressive d’adresses est de changer de protocole réseau, de mettre en œuvre un nouveau protocole doté d’un champ d’adressage plus vaste. Cette solution radicale a pour avantage indéniable de résoudre une fois pour toute le problème, si tant est que le nouveau champ d’adressage soit suffisamment large pour durer " indéfiniment " ou presque, et que la politique d’attribution des adresses soit contrôlée, afin d’éviter de gâcher inutilement de nouvelles adresses. La nouvelle spécification du protocole IP, la version 6 ou IPv6, a été conçue dans cette perspective. Dotée d’un système d’adressage sur 128 bits, elle permettrait théoriquement d’attribuer une adresse au moins à chaque atome de l’univers. En tout état de cause, chaque habitant de notre planète disposera de milliards d’adresses pour son usage personnel. Il sera ainsi bientôt possible d’attribuer des adresses IP à chaque ampoule électrique, chaque serrure, chaque appareil ménager etc., ouvrant ainsi la voie à toutes les applications domotiques du futur. En outre, cette nouvelle version de l’Internet Protocol corrige un certain nombre de faiblesses de la version 4 d’IP, en permettant par exemple de mieux discrétiser des flux d’informations de priorités différentes, facilitant notamment la diffusion de contenu temps réel sur le réseau. De surcroît, le nouvel adressage privilégie une structure hiérarchique sur l’ancien système des classes, facilitant ainsi le routage au cœur du réseau (toutes les adresses géographiquement localisées en Europe pourront ainsi débuter par le même bloc de bits).
La grande difficulté du passage à IPv6 qui sera en définitive la solution ultime au problème de la raréfaction es adresses IP, et accessoirement à la croissance exponentielle des tables de routage au cœur du réseau, est qu’il est nécessaire de mettre à jour l’ensemble des matériels et logiciels en vigueur sur le réseau. Cette tâche ne pourra être effectuée en une seule fois sur une période de temps limitée (un ou deux jours comme ce fut le cas lors de la précédente mise à jour du protocole, de la version 3 à la version 4). La migration sera progressive et difficile, même si l’on nous promet des solutions de compatibilité permettant d’encapsuler des paquets IPv6 dans des datagrammes IPv4 et vice versa, ainsi que des système de traduction automatique d’adresse permettant de faire cohabiter au sein du même réseau les deux protocoles. Cependant, toutes les difficultés technologiques liées à cette migration nécessaire ne sont pas encore résolues et personne ne sait exactement comment se déroulera cette période de transition, ni quelle sera a priori sa durée.
La pénurie d'adresses, notamment manifeste au niveau des champs d'adressage de taille moyenne - quelques milliers d'adresses - est bel et bien réelle et d'actualité. Néanmoins, un certain nombre de techniques parmi lesquelles CIDR pour les prestataires de service ou la translation d'adresses (NAT) pour les utilisateurs finals permettent de patienter efficacement jusqu'au déploiement progressif d'IPv6 dans les prochaines années. En outre, l'usage banalisé de l'Internet dans les entreprises requière de plus en plus l'utilisation de solutions de sécurité à base de firewalls : le passage contraint par des proxys ainsi induit peut s'accompagner d'un système d'adressage privé sur l'intranet de l'entreprise, l'accès aux ressources utiles de l'Internet via ces seuls proxys permettant une réduction drastique du nombre d'adresses visible depuis le réseau public.

  Qu'est-ce qu'une adresse IP ?

Le socle fondateur sur lequel repose l'Internet n'est pas une infrastructure élémentaire ou originelle. Ce n'est pas non plus un quelconque organisme régulateur, mais un protocole ou plutôt une pile de protocoles de niveau 3 et 4 qui représentent l’espéranto de l'interconnexion de réseaux et de la communication entre ordinateurs : TCP/IP. Parmi ces protocoles, IP ou internet protocol qui a donné son nom à l'Internet est celui chargé d'acheminer les paquets d'information qui lui sont confiés par les protocoles et applications de niveau supérieur à bon port. Pour ce faire, IP encapsule l'information dans un datagramme dont l'en-tête ne contient que l'adresse de l'ordinateur émetteur, celle de l'ordinateur destinataire de l'information, ainsi que quelques paramètres supplémentaires comme le numéro de version du protocole, la taille du paquet ou la notification de son éventuelle fragmentation. Le routage du paquet sur le réseau consistera alors à déterminer à chaque embranchement, quelle route devra emprunter le paquet pour atteindre sa destination, et ce compte tenu des éventuelles informations sur l'état ou l'encombrement du réseau échangées par les routeurs.
L'adresse IP est donc l'élément fondamental de désignation d'une machine sur le réseau. Elle est codée sur 32 bits, généralement représentés sous la forme de quatre nombres décimaux de trois chiffres séparés par des points (notation décimale pointée ou dotted decimal notation). Chacun de ces nombres pourra donc prendre une valeur comprise entre 0 et 255, soit un champ d'adressage théorique compris entre 0.0.0.0 et 255.255.255.255. Ainsi, il est possible d'adresser grâce à ces conventions plus de 4 milliards de machines différentes, soit beaucoup plus que les estimations les plus optimistes du nombre d'ordinateurs actuellement connectés au réseau. Cependant, à l'époque où l'Internet ne reliait que quelques centaines de gros ordinateurs, l'idée que le nombre de machines connectées puisse un jour dépasser le million paraissait suffisamment loufoque pour que l'on allouât les adresses de façon anarchiques et sans précautions. Résultat : à la fin de ce siècle, les adresses libres font de plus en plus cruellement défaut alors même que l'on est loin d'atteindre les 4 milliards de machine qu'autoriserait normalement l'espace d'adressage de 32 bits.
  

L'espace d'adressage est structuré en 5 classes d'adresses que l'on différencie par leurs premiers bits : 0 pour la classe A, 10 pour la classe B, et ainsi de suite jusqu'à 11110 pour la classe E. Les trois premières classes d'adressages représentent des champs d'adresses à attribuer à des réseaux de taille variable. Comme on peut le voir dans la figure ci-contre, les adresses de classes A comprennent un identificateur de réseau codé sur 7 bits (soit 128 réseaux différents de classes A), et un identificateur de machine dans le réseau codé sur 24 bits. Ainsi, un tel réseau de classe A peut comprendre jusqu'à 16 millions de machines. De la même façon, on pourra définir 16384 réseaux de classe B adressant chacun 65536 machines, et plus de deux millions de réseaux de classes C composés au maximum de 256 machines chacun. La classe d'adresses D est quant à elle réservée au multicast, c'est à dire à la communication de données en direction d'un groupe de machines disséminées mais partageant la même adresse multicast, sans qu'il soit nécessaire d'émettre un paquet différent pour chaque machine membre du groupe multicast. Enfin, la dernière classe d'adresse demeure inexploitée.
Notons enfin que certains espaces d'adressages des trois premières classes sont volontairement inutilisées sur l'Internet afin d'en laisser l'usage aux réseaux privés coupés de l'Internet public mais désireux d'utiliser IP et les technologies de l'Internet en interne.   

Les quatres types d'implémentations de NAT

Network Adress et Port Translation (NAPT)/IP Masquerading

 C'est l'utilisation la plus commune du NAT. Elle est souvent utilisée dans la situation où le réseau des adresses a seulement un IP assigné, comme une connexion à  un ISP.Dans ce cas, le réseau privé, 192.168..0 se cache derrière l'adresse publique, 130.102.1.1. Le routeur NAT ayant les adresses 130.102.1.1 et 192.168.1.1.
Toute demande provenant du réseau privé (192.168.1.0) fait remplacer leur IP ADDRESSE de source par le IP ADDRESSE public du routeur NAT, 130.102.1.1. Seulement 1 IP ADDRESSE est visible depuis le réseau public.

.   

Dynamic Network Address Translation ( Traduction dynamique d'adresses réseau)

Dans le NAT dynamique, seulement l'adresse (pas le port) est traduit, habituellement, le nombre d'adresses IP extérieurement visibles est plus petit que le nombre étant caché derrière le routeur NAT. Chaque fois qu'une demande est faite à partir d'une machine du réseau privé, le routeur NAT choisit une adresse IP externe qui n'est pas utilisée en ce moment, et exécute la traduction. Ce type de situation est seulement possible quand le nombre de demandes concurrentes au réseau externe est plus petit ou égal que le nombre d'adresses IP externes contenus sur le routeur NAT. 

Static Network Address Translation (Traduction statique d'adresses réseau)

Le NAT statique est seulement mis en application entre les réseaux privés (bien que d'autres possibilités existent également). Supposez qu'il y a 2 réseaux qui aient chacun la même plage d'adresses. 

De cette façon, le réseau supérieur adresse le réseau inférieur en utilisant les adresses 10.3.yy.zz et le network inférieur adresse le réseau supérieur en utilisant les adresses 10.2.ww.xx 

Port Mapping et Redirection
 
 

Les ports spécifiés sur l'interface externe sont redirigés vers les services à l'intérieur du réseau privé. La seule adresse visible depuis Internet est 130,102,1,1, mais comme elle n'a réellement aucun service qui fonctionne dessus (autre que le NAT ) elle est considérée un "Virtual Server". 

Ici, les demandes faites à 130.102.1.1:80 sont redirigées vers le webserver sur 192,168,1,2, les demandes faites au serveur de mail virtuel sont redirigés à 192,168,1,3. Dans des situations de charge élevée, il est possible (pourvu qu'il y ait plusieurs webserveurs sur le réseau privé), que le routeur NAT équilibre le chargement entre eux. Et ceci est également vrai pour la plupart des services. 

  Compatibilité et incompatibilité NAT

Présentation powerpoint "Le NAT"

Présentation powerpoint "Radius"