Sécurisation des

échanges applicatifs:

Secure Layer
Socket SSL /
Transport Layer
Security TLS
SSL /
TLS
SSL (Secure Socket Layer) est un protocole à négociation (on parle
du « HandShake » SSL), développé à l'origine par Netscape.
Il a pour but de sécuriser les transactions Internet, par
authentification du client (Un navigateur la plupart du temps) et
du serveur, et par chiffrement de la session.

TLS (Transport Layer Security Protocol), développé par l'IETF, est

la version 3.1 de SSL. C’est un protocole qui assure
l’authentification, la confidentialité et l’intégrité des données entre
deux applications informatiques communicantes. Il s’agit du
protocole de sécurité le plus largement déployé à l’heure actuelle. Il
est utilisé pour les navigateurs web et d’autres applications qui
nécessitent l’échange sécurisé de données sur un réseau.

Les Services fournis sont les suivants :

 Intégrité des données transmises (md5, sha-1) ;

 Confidentialité des données transmises (rsa, des, 3des…) ;
 Authentification de l’identité des correspondants la
connexion est fiable (X509 et MAC)
TCP/IP

Pour comprendre SSL, il est utile de voir sur quoi il
repose.

IP (Internet Protocol) est le nom donné au protocole qui
déploie le trafic sur l’Internet. Le trafic est transmis par
petits paquets qui contiennent les adresses IP de
l’expéditeur et du destinataire.

TCP (Transmission Control Protocol) repose au-dessus de
IP. Il est orienté connexion, ce qui signifie que certains
types de paquets sont transmis et acceptés dans le but
d’ouvrir une connexion. Les paquets qui suivent peuvent
alors être reconnus comme appartenant à une connexion
établie précédemment.
IP et
TCPLe protocole IP est responsable du transport de paquets


d’une adresse internet à une autre. Chacun des petits

paquets sait où il va et d’où il vient (les adresses IP). Deux
paquets envoyés par le protocole IP ne sont pas
nécessairement reçus dans le même ordre.

Le protocole TCP utilise le protocole IP pour établir des
connexions. Ceci permet de réordonner les paquets dans
l’ordre d’expédition. S’il y a perte d’un paquet, celui-ci sera
demandé à nouveau.

TCP/IP est responsable de la communication à travers une
connexion entre deux adresses IP.

L’architecture de TCP/IP est par couches («layers»).
La pile
TCP/IP
Ensemble de services réseau faisant
l’interface entre le réseau et le système
d’exploitation. HTTP, FTP, SMTP.

Permet d’identifier les programmes

sur lesquels les données message entête
transportées roulent. Réalise les
protocoles TCP et UDP.
entête
segment
Responsable de l’intégration des
adresses IP. La transport de données datagramme entête
vers des machines distantes. Forme
des datagrammes qui contiennent les
données ainsi que les adresses IP... trame

Première couche de la pile.

Responsable de la transmission des
données via un réseau physique
arbitraire. Achemine les données,
coordonne la transmission, formate,
conversion analogique/numérique,
contrôle d’erreurs. Entre machines
voisines.
Trames-Datagrammes-Segments
2
Fragmentation (en
paquets d’environ
1500 octets)

1
Les protocoles SSL /
TLS : Généralités
 Repose sur un procédé de cryptographie à clef publique
 Indépendant du protocole utilisé
 Transactions Web (HTTP), connexions via FTP, POP ou
IMAP.
 Agit telle une couche supplémentaire, permettant d'assurer
la sécurité des données, située entre la couche application
et la couche transport
HTTP SMTP FTP
SSL/TLS

TCP/UDP

IP
Les protocoles SSL /
TLS: Généralités
Les protocoles SSL /
TLS: Connexion et
session
 ConnexionSSL :
 Offre certains services de sécurité entre deux entités.
 Éphémère mais établie dans le cadre d'une Session SSL
 Session :
 Association entre un client et un serveur
 Etabli lors du protocole de "Handshake"
 Un ensemble de paramètres de sécurité, dans chaque
sens, est négocié une seule fois et partagé par les
connexions
 L'état courant défini les paramètres courants, l'état en
attente ("Session pending state") défini les paramètres
suivants (cf. "Change Cipher Spec Protocol") Nota : il
peut y a avoir plusieurs sessions établies entre 2 mêmes
partenaires (rarement)
Les protocoles SSL /
TLS: Paramètres de la
session
 "Session identifier"
 "Peer certificate" :
 certificat X509 ou rien
 "Compression method"
 "Cipher specification" :
 algo. de chiffrement
et algo.
d'authentification et
leurs paramètres
 "Master secret"
 48 octets partagés
entre le client et le
serveur
 "Is resumable":
 Les paramètres de la session peuvent être utilisés pour établir une
connexion
Les protocoles SSL / TLS:
Paramètres de la
connexion
 "Server and client random" :
 Choisie à chaque nouvelle connexion.
 "Server write MAC secret" et "Client write MAC secret "
 Un secret utilisé pour vérifier l'intégrité des messages (un pour chaque
sens).
 "Server write key" et "Client write key" :
 Pour le chiffrement, dans le sens serveur-client et vice-versa.
 "Initialization vectors" :
 Utilisés en mode CBC. Le premier IV est issu du protocole
"Handshake", puis le dernier bloc chiffré sert d'IV pour la prochaine
transmission chiffrée, au sein de la même connexion.
 "Sequence numbers" :
 Un numéro de séquence est mémorisé, un pour chaque sens
de transmission.
Les protocoles SSL / TLS: Structure

SSL SSL cipher SSL alert Application

Handshak change protocol Protocol (eg.
e protocol HTTP)
protocol
SSL Record Protocol

TCP

IP
Les protocoles SSL /
TLS: Vue globale
SSL est composé des protocoles suivants :


Record Protocol : Responsable du transport des données brutes. Il
communique avec la couche transport. Il chiffre et authentifie (calcule
un CAM) l’information en utilisant le cipher_spec . Si le cipher_spec
est vide, alors l’information n’est ni chiffrée ni authentifiée.

Handshake Protocol : Responsable de l’échange de clés
authentifiées. Le but de ce protocole est d’amener le client et le
serveur qui ne partagent pas de clés à s’entendre sur un
cipher_spec , choisi parmi ceux voulus par le client, avant d’exécuter
l’échange de clés authentifiées.

ChangeCipher Protocol : Un message ou une entité annonce à
l’autre un changement de cipher_spec tel que négocié
précédemment.

Alert Protocol : Un message indiquant une erreur.
L’anatomie de
SSL
Opérations du "SSL Record protocol »
Opérations du "SSL
Record protocol »
Données applicatives
Fragmentation :
 frontières messages clients peuvent
être déplacées
Frag 1 Frag 2
 fragments de 214 octets au plus
Compression (optionnelle) :
 ajoute au pire 1024 octets
 sans pertes Compressé
Sceau :
 HMAC(MAC_write_secret,seq_num+type
de protocole TLS+version TLS+taille du
fragment compressé+fragment compressé)
Compressé MAC
+ = concaténation
Chiffrement :
 le fragment peut être paddé (chiffrement
Fragment chiffré
par blocs)
 on chiffre le fragment compressé + MAC
 ajoute au pire 1024 octets
"Change Cipher Spec Protocol"

 Lorsque la "cipher suite" doit être changée :

 à la réception de ce message d'un octet, on
substitue à la spécification courante la spécification
en attente ("pending state").
"Alert Protocol "
 Transmission d'un message d'alerte aux entités.
 Ces messages peuvent être compressés
et chiffrés comme les autres messages
Niveau Description
de la même session.
 Le champ "Level" :
 "warning" = 1
 "fatal" = 2 : la connexion est close et il
PDU alerte
n'y aura plus de nouvelles connexions
pour cette Session
 Le champ "Alert" spécifie l'erreur :
 "unexpected_message", "bad_record_MAC",
"decompression_failure",
"handshake_failure", "illegal_parameter" //
"close_notify",
"Handshake Protocol
Serveur client hello
serveur Hello
certificat
échange de clé
fin hello
certificat
échange de clé
fini
serveur Hello : client Hello :
-sélection de version SSL fini -la version SSL maximale
-sélection d’algos échange de clé I : fini : -liste d’algos supportés
-un nonce Message -change cipher_spec -un nonce
certificat : complémentaire pour
certificat
-Transmet l’échange de clé
-certificat éventuel client
certificat X509 fini : -signature de la discussion
-Demande certificat -change cipher_spec
client (rare) échange de clé II :
clé pré-master chiffrée
SSL / TLS: Négociation de session

Déroulement habituel d'un

handshake SSL avec
authentification mutuelle :
en noir, les échanges initiés par
le serveur.
en rouge, les échanges initiés
par le client.
SSL / TLS: Négociation de
session
Phase 1 : Etablissement des paramètres de sécurité
 Client Hello
• heure
• tirage nbre aléatoire client.random (28 octets)
• session Id : vide = nouvelle session,
session Id : renseigné = utiliser session déjà
ouverte
• choix d’algorithmes de chiffrement
supportés
• méthode de compression supportés
• n° version du client SSL utilisé
 Server Hello
• le serveur sélectionne la version
• tirage nbre aléatoire : server.random (28
oct)
• session Id : renseigné = numéro nouvelle
session, ou session à réutiliser ,
session Id : vide = session à ne pas
mettre en
cache
• algorithme de chiffrement sélectionné
• méthode de compression à utiliser
 Si session réutilisée, passer en FINISH
SSL / TLS: Négociation de
session
Phase 2 : Authentification du serveur et échange des clés
 Server certificate
• envoyé si le serveur doit s’authentifier,
dès que Server Hello a été envoyé
• contient une chaîne de certificats X509
v3 (avec le certificat racine en dernier),
correspond à l’algo utilisé (RSA, DH,
>)
! le client dispose donc de la clé publique
du serveur

 Server key exchange

• envoyé uniquement si le client n’a pas
toutes les données nécessaires (ex: le
serveur n’a pas de certificat)
• paramètres de la clé de chiffrement
(modulo, exposant>)
• hash MD5/SHA (client.random +
server.random+paramètres)
SSL / TLS: Négociation de
session
Phase 2 : Authentification du serveur et échange des clés
 Certificate request
• envoyé uniquement si l’authentification
du client est requise
• types de certificats admis
• noms d’autorités de certification
reconnues
 Server hello done
• le serveur attend une réponse
du client
 Client certificate
• envoyé uniquement si le serveur a
réclamé une authentification du client
• certificat
• si le client ne possède pas de certificat,
une alerte est envoyée au serveur.
Suivant les cas, cela peut faire échouer
la négociation
SSL / TLS: Négociation de
session
Phase 3 : Authentification du client et échange des clés
Clé publique du
serveur
N° Version (2 bits) Pre Master Secret
RSA Key sécurisé
Pre Master Secret Key (46 bits)
Client Key Exchange
 Client key exchange
• dans le cas de l’algorithme RSA, le client génère un “pre-
master secret” de 46 octets + 2 octets n° version (pour
détecter les « rollback attacks »)
• il chiffre ce pre-master secret avec la clé publique du serveur
 Calcul des clés
• le pre-master secret, client.random et server.random permettent
au client et au serveur de calculer :
• 2 clés de sessions (une pour chaque sens), et
• 2 clés secrètes à utiliser pour les MACs.
SSL / TLS: Négociation de
session
 Certificate verify
 envoyé si le client a envoyé un certificat qui permet de signer
 hash MD5 et hash SHA de tous les messages de négociation
envoyés jusqu’ici
 Client Finish et Server Finish
 envoyé après un Change Cipher Spec et donc chiffré avec les
nouveaux algorithmes négociés.
 client et serveur doivent envoyer un “Finish” et vérifier celui qu’il
reçoive de la partie opposée.
 PRF(master_secret,finished_label, Hash MD5 +Hash SHA de
tous les messages de négociations envoyés jusqu’ici) sur 12
octets, finished_label = “client finished” ou “server finished”.
SSL sans authentification du client

Comme nous venons de le voir, un client SSL n’est
pas obligé de s’authentifier. SSL permet des sessions
où seulement le serveur s’authentifie au client mais
pas l’inverse.

Dans bien des situations, c’est la meilleure chose
possible, car les clients n’ont pas nécessairement de clés
publiques certifiées.

Dans cette situation, le client sait qu’il parle au bon
serveur, mais le serveur ne sait rien de l’identité du
client.

L’identification du client peut alors se faire (comme c’est
le cas dans la pratique) en demandant un mot de passe.
L’authentification du client
par mot de passe

Supposons qu’un serveur WEB détient une liste d’utilisateurs + mots de
passe mais les utilisateurs n’ont pas de clés publiques certifiées. Seul le
serveur possède une telle clé publique.

Le serveur veut authentifier un utilisateur qui se connecte.

Comment faire?

Ouvrir une session SSL,

Demander à l’utilisateur de fournir son mot de passe.

le mot de passe
est donc chiffré!

SSL
Limites de l’approche par mot
de passe

Le client ne peut s’authentifier qu’au serveur qui connaît un mot
de passe pour celui-ci.

La sécurité d’une telle session est plus difficile à établir, puisque
la gestion des mots de passe n’est pas intégrée au protocole
mais arrive plus tard.

De tels systèmes sont aussi sûrs que le mot de passe. Donc, il
semble qu’un système qui établirait l’identité d’un client basé sur
un mot de passe dès le départ serait au moins aussi bon :

Plus précisément, nous pourrions avoir un protocole
d’établissement de liaison qui ne puisse être compromis plus
rapidement que le temps nécessaire pour deviner le mot de
passe en ligne.

Rien de mieux ne peut être obtenu.

Un tel échange de clés est dit « échange de clés authentifié
par mots de passe ».
Échange de clés authentifié par mot de
passe
Ceci semble facile. Les deux parties connaissent un secret pw :


Nous n’avons qu’à dériver une clé secrète directement à partir de pw ou même utiliser pw
directement pour le chiffrement et le calcul de CAM...


L’utilisation à long terme sur beaucoup de données cause des problèmes desécurité.


Les mots de passe doivent être assez courts pour être faciles à mémoriser. Le nombre de mots
de passe possibles est donc beaucoup plus petit que le nombre de possibilités pour la clé secrète
d’un chiffrement symétrique.


L’adversaire, ayant intercepté un cryptogramme, peut donc tenter le déchiffrement en essayant
les mots de passe possibles hors ligne...tandis que deviner le mot de passe en ligne peut résulter
en une désactivation du compte après quelques essais infructueux.

Ce problème difficile a des solutions connues (p.ex. Bellare et al. Eurocrypt’2000) . Quelques-uns
(sans preuve formelle de sécurité) sont considérés pour standardisation par l’Internet Engineering
Task Force et IEEE Ne sont pas utilisés par les produits commerciaux...
SSL versus
TLS
 Le même format de message.
 L'un est propriétaire, l'autre publique
(IETF).
 Les différences mineures résident dans :
 version number
 message authentication code
 pseudorandom function (TLS : fonction PRF)
 alert codes (TLS en ajoute plusieurs)
 cipher suites
 client certificate types
 certificate_verify and finished message
 cryptographic computations
HTTP
S
HTTPs = HTTP standard sur le port 443
(à la place de 80) + TLS + TCP/IP
Généralement le driver SSL/TLS est intégré
au navigateur
Applications

Secure HTTP est le nom donné à l’utilisation de SSL ou TLS pour établir une
connexion sûre entre un serveur WEB et son client. Le résultat est un tunnel entre
le client et le serveur, par lequel chaque transmission est chiffrée sans que
l’application ait à s’en soucier :


https://www.abc.def.com


VPN (Virtual Private Network) permet d’établir des connexions sûres entre un client
distant et un réseau local. Durant la phase d’initialisation entre le client et la passerelle VPN,
celui-ci se voit attribuer une adresse IP comme s’il était membre du réseau local.


Une fois initialisées, toutes les communications sont chiffrées et authentifiées. Pour ce
faire, un échange de clé est nécessaire. Des VPN le réalisent avec leurs propres méthodes
tandis que d’autres utilisent IPSec ou SSL/TLS. VPN permet de travailler comme si le
client faisait partie du réseau local. Des employés peuvent travailler à la maison avec les
mêmes privilèges qu’au bureau.
Applications de haut
niveau

Les protocoles que nous avons rencontrés sont de bas niveau. Ils ne sont pas
bien adaptés aux humains!

SSL ne peut être utilisé pour signer des courriels ou documents, car SSL ne
reconnaît pas le concept de document.


La cryptographie appliquée à des objets de plus haut niveau est offerte par
d’autres solutions.

MIME : un standard pour la transmission des courriels. S/MIME est un standard avec
des champs supplémentaires pour la signature et le chiffrement de courriels.


XML : un standard qui propose une extension de HTML qui, en particulier, permet de
chiffrer et de signer des pages Web.


PGP (Pretty Good Privacy) : permet de signer et de chiffrer des courriels. Au lieu
de baser la sécurité sur des CA, il utilise un concept de toile de confiance («web of
trust»). Votre ami(e) peut vous envoyer une clé publique d’une troisième personne
qui déclare que ceux-ci font confiance à cette clé. Vous pouvez décider de faire
confiance à cette clé si suffisamment de vos amis l’ont recommandée.
SSL / TLS:
Attaques
Attaques sur les mise en œuvres des protocoles
 Comme toute appli logicielle, les MeV de SSL/ TLS peuvent présenter

vulnérabilités permettant à un utilisateur mal intentionné d'exécuter du

code arbitraire à distance ou de provoquer un DoS.
 Appliquer CORRECTIFS correspondants aux MAJ de ces applis
Attaques rollback (sur anciennes versions)
 l'attaquant cherche à modifier le choix des algos d'échanges de clés de

façon à ce que les 2 entités n'utilisent pas les mêmes (RSA et DH par
exemple).
 cet attaquant pourra déchiffrer le message car les paramètres fournit

par le serveur dans le cas d'un algorithme n'offrent aucune sécurité si

on les applique à un autre...
 Cette attaque peut-être réalisée si une session 3.0 est résumée en

session 2.0 par exemple.

SSL / TLS:
Attaques
Attaque de type "man in th
 intercepter trafic entre deux parties avant qu'elles ne débutent
une session SSL. L'intercepteur négocie alors une session
avec chaque partie et fait suivre le trafic en le déchiffrant et
rechiffrant à la volée.
 E.g., dans le cas de l'utilisation du protocole HTTPS par un client
web pour authentifier un serveur, l'intercepteur crée un
certificat ressemblant au certificat légitime du serveur et
détourne le trafic.
 Si, malgré l'avertissement du navigateur sur le certificat, le
client poursuit sa session, l'intercepteur obtiendra toutes les
infos que le client envoie au serveur sans que ce dernier ne s'en
rende compte.
 ++ outils qui reproduisent cette attaque sont disponibles
sur l'Internet.
SSL / TLS: Solutions
Vérifier correctement le certificat présenté par le serveur. C'est Vérifier
correctement le certificat présenté par le serveur. C'est la seule manière
de s'assurer que la connexion ne sera pas la seule manière de s'assurer
que la connexion ne sera pas interceptée par un éventuel attaquant.
interceptée par un éventuel attaquant.
 Dans les navigateurs, les certificats racine de certaines autorités de

certification sont pré-installés.

 Lorsque le certificat présenté par un serveur n'a pas été signé par l'une de ces

autorités, le navigateur demande confirmation avant d'accepter le certificat. Il

faut alors s'assurer que le certificat présenté par le serveur est le bon
certificat.
 Cette vérification peut se faire à l'aide de deux champs du certificat : le

numéro de série et l'empreinte numérique (empreinte md5 ou sha1). Pour

vérifier la concordance des informations, il faut disposer d'un moyen de
communication de confiance (téléphone, courrier, diffusion de la main à la
main, ...) par lequel pourront être comparés les numéros de série et les
empreintes. De même, il ne faut installer un certificat d'autorité qu'après s'être
assuré que le certificat est correct.
SSL / TLS: Limites
SSL/TLS servent à sécuriser les échanges d'informations entre un client et un serveur et à
obtenir une authentification mutuelle.
Une session SSL/TLS correctement établie va donc protéger les échanges entre les parties,
mais ne sera en protéger les échanges entre les parties, mais ne sera en aucun une garantie
de sécurité pour les systèmes client aucun une garantie de sécurité pour les systèmes client ou
serveur. ou serveur.
Ainsi, si un pirate installe par exemple un enregistreur de frappe (ou keylogger) sur le poste
client, il sera en mesure frappe (ou keylogger) sur le poste client, il sera en mesure de
récupérer les mots de passe ou toute information de récupérer les mots de passe ou toute
information confidentielle, même si celle-ci a été émise lors d'une confidentielle, même si celle-
ci a été émise lors d'une session SSL/TLS. session SSL/TLS.
De même, un serveur qui utilise des sessions SSL/TLS pour récupérer des données sensibles
peut être compromis et récupérer des données sensibles peut être compromis et les données
recueillies pourront être volées. les données recueillies pourront être volées.
ll est donc primordial d'utiliser les protocoles SSL/TLS en prenant certaines précautions, et ne
pas leur prêter une prenant certaines précautions, et ne pas leur prêter une trop grande
garantie de sécurité sur l'ensemble de la trop grande garantie de sécurité sur l'ensemble de la
chaîne d'information chaîne d'information.
Sécurisation des
échanges applicatifs:

SSH (Ou Secure

Shell)
Le protocole SSH
Le protocole Telnet : simple mais
dangereux
Un protocole très simple, très
basique, a été créé dans les années
80 : c'est Telnet. Il sert juste à
échanger des messages simples
d'une machine à une autre.
En théorie donc, on peut
communiquer avec un serveur à
l'aide du protocole Telnet. Le
problème de ce protocole… c'est
justement qu'il est trop simple : les
données sont transférées en clair
sur le réseau. Il n'y a aucun
chiffrement
Le protocole SSH: Généralités

SSH (Ou Secure Shell) est un protocole servant à créer une

connexion sécurisée entre deux systèmes.

 Mesures de sécurité offertes :

 Assurance du client de la connexion au même serveur lors des
sessions suivantes ;
 Transmission de ses données d'authentification au serveur, telles
que son nom d'utilisateur et son mot de passe, en format crypté ;
 Transfert de façon chiffrée des données envoyées et reçues à
lire ;
 Possibilité pour le client d’utiliser des applications X11 lancées à
partir de l'invite Shell. Cette technique fournit une interface
graphique sécurisée (appelée retransmission X11).
Le protocole SSH: Généralités

 Création d’une couche transport sécurisée ;

 Chiffrement de la communication au moyen d'un chiffre symétrique ;
 authentification, une fois la connexion sécurisée établie avec le serveur et
client ;
 Utilisation de nombreux services différents de façon sécurisée, tels
qu'une session Shell interactive, des applications X11 et des ports TCP/IP
Tunnellisés.

L'ensemble du processus de connexion se fait sans que le système local

n'ait à faire de nombreuses opérations supplémentaires.
Le protocole SSH: Mode de
fonctionnement
Lorsqu'un client communique avec un serveur au moyen d'un protocole SSH, de
nombreux éléments importants sont négociés afin que les deux systèmes puissent
créer correctement la couche transport :
 L'échange des clés ;
 L'algorithme de clé publique à utiliser ;
 L'algorithme de chiffrement symétrique à utiliser ;
 L'algorithme d'authentification de message à utiliser ;
 L'algorithme repère (Hash) à utiliser.
Le protocole SSH: Mode de
fonctionnement
Permet de créer un tunnel chiffré vers un réseau ;

Etapes :

Exécution d’un script qui à l ’aide d’une session SSH, lance PPP sur la
passerelle et redirige les entrées/sorties de façon à faire ; passer PPP
dans SSH ;

Routage des données à destination du réseau interne vers l’interface PPP

résultante ;

Passerelle joue le rôle de Proxy-Arp pour le nomade, qui semble ainsi

appartenir au réseau interne.
Le protocole SSH: Démo

 Se connecter via SSH à partir

d'une machine Windows
 Se connecter via SSH à partir
d'une machine Linux
 L'identification automatique par
clé
Sécurisation des
échanges applicatifs:

Virtual Private Network

VPN
VPN: Généralités

UN VPN (Virtual Private Network) est une liaison sécurisée

entre deux parties via un réseau public, en général Internet.
Cette technique assure l’authentification des deux parties,
l’intégrité des données et le chiffrage de celles-ci.

Permet à 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 ;

Permet à l’entreprise d’échanger des données en toute sécurité avec ses

sites distants ou ses partenaires ;
VPN: Généralités

 Un VPN est un réseau privé virtuel.

 Il permet de créer un lien entre deux réseaux LAN distants.
 Un VPN host-to-lan se crée entre un PC et un réseau LAN.
 Un VPN lan-to-lan se crée entre deux LAN.
 Pour créer un VPN, on envoie les paquets au travers d'un
tunnel.
 Un tunnel permet, grâce à plusieurs protocoles :
• L'authentification
• l'intégrité des données
• La sécurité des données
VPN: Généralités

Caractère virtuel :
 C’est la technique du tunneling qui permet d’étendre de façon
« virtuelle » le réseau privé à travers un réseau public

Caractère privé :
 C’est le cryptage qui confère son caractère privé aux données
puisqu’elles ne peuvent être décodées que par les interlocuteurs
d’extrémité

Réseau Virtuel : tunneling

Réseau Privé : cryptage

VPN: Généralités

Méthode utiliser pour faire transiter des informations privées sur un

réseau public ;
Garantit la confidentialité et l’intégrité des données ainsi que
l ’authenticité des deux parties ;
Chaque paquet est complètement chiffré et placé à l’intérieur d’un
nouveau paquet.
VPN: Généralités

Exemples de protocoles de tunneling :

 GRE (Generic Routing Encapsulation)
 L2TP (Layer 2 Tunneling Protocol)
 IPSec
VPN: Scénarios
Qui crée des VPN ?
Les administrateurs réseaux des entreprises :
 ils créent des VPN LAN to LAN aussi bien que des VPN d’accès

distant, pour les besoins des personnels et des partenaires de

l’entreprise
Les opérateurs téléphoniques et les fournisseurs d’accès à
Internet :
 ils créent des VPN LAN to LAN « clefs en main » qu’ils proposent

aux entreprises
 ces offres de VPN s’accompagnent souvent de services comme :

 l’accès à Internet
 l’hébergement de serveurs
 le filtrage de paquets
 la fonction FireWall
 l’antivirus
 la détection d’intrusions
VPN: Choix de Technologie

Application
Couches (5-7)

Couche Réseau

Ré se a u / IPSec L2F
Transport L2TP
Couches GRE
(3-4) PPTP
Ph ys i q u e/
Liaison
Couches
(1-2)
Protocoles VPN Description Standard
L2TP Layer 2 tunneling Protocol RFC 2 6 6 1
GRE Generic Routing RFC 1 7 0 1 et 2 7 8 4
Encapsulation
IPSec Unternet Protocol RFC 2 4 0 1
Security
IPSec

IPSec est un ensemble de protocoles qui accomplit des
fonctions semblables à SSL mais situé à un autre endroit de
la pile TCP/IP.

SSL

IPSec


IPSec est de plus bas niveau que SSL/TLS. Le résultat est ce qui est
appelé une association de sécurité entre deux adresses IP.

Étant de plus bas niveau implique que même les informations de
contrôle, les numéros de séquences utilisés pour gérer la connexion TCP,
sont chiffrés.
IPsec: Principe de fonctionnement
Créez un tunnel avec IPsec
Différents cas d’usage d’IPsec

Interconnexion de deux sites PC à Routeur/Concentrateur VPN

Interconnexion de plusieurs sites avec PC à Firewall / Routeur à Firewall

routage
IPsec: Principe de fonctionnement

IPSec

ESP AH

Encryption Integrity Integrity

DES, 3DES, AES MD5, SHA1, SHA2, SHA3

Sécurité et IP

 Mécanismes cryptographiques :
 Authenticité = Code d’authentification de message (MAC)
authentification de message (MAC)
 Confidentialité = Chiffrement
 Protection contre le Protection contre le rejeu = Numéro
de séquence
 Deux en-tête d’extension :
 En-tête d'extension d'authentification (Authentification
Header, AH)
 En-tête d'extension de confidentialité (Encapsulating
Security Playload Header, ESP)
 Mécanismes ci-dessus font appel à la cryptographie et utilisent donc
un certain nombre de paramètres (algorithmes utilisés, clefs,
mécanismes sélectionnés …).
IPsec: Modes Transport et Mode
tunnel
 Deux modes

IPSec en mode transport

En-tête En-tête En-tête Données

IP TCP
IPSec
IPSec en mode tunnel
Nouvel En-tête En-tête En-tête Données
En-Tête IP D’origine TCP
IP IPSec
IPsec: Mode Transport

 En mode transport, on chiffre/authentifie la partie data d'un

paquet IP excepté les champs variables de l’en-tête
(TTL,
….)
 En mode tunnel, on protège le paquet complet (y
compris
l’en-tête IP) et on l'encapsule dans un nouveau paquet,
avec un nouvel en-tête IP qui sert à transporter le paquet
jusqu'à la fin du tunnel, où l’en-tête d’origine est rétablie.

 Offre une protection plus importante contre l’analyse du trafic, car il

analyse du trafic, car il masque les adresses de la source et de la
destination finale. masque les adresses de la source et de la
destination finale.
Comparaison avec
SSL

IPSec demande qu’un client soit installé sur chaque unité pour permettre le
chiffrement. Sa configuration est plus difficile que pour SSL (transparent).

SSL est inclus dans les navigateurs, ce qui ne nécessite pas l’installation de
clients.

SSL fonctionne plutôt pour des applications Web, ce qui n’est pas le cas
d’IPSec.

IPSec est utilisé pour les communications site à site qui ne sont pas de
type client-serveur.

Certains routeurs NAT (Network Adress Translation) ont de la difficulté avec
IPSec. SSL n’a pas ce problème.

Certains fournisseurs d’accès Internet demandent d’être payés pour des
communications IPSec. C’est impossible à faire avec SSL.

Si IPSecv6 devenait supporté par les applications, alors SSL pourrait
devenir
inutile.
IPSec : protocoles
 Authentication Header (AH)
 Encapsulation Payload (ESP)
 Security Association (SA)
 Security Association Database (SAD)
 Security Policy Database (SPD)
 Internet Key Exchange (IKE)
Internet Security Association Key
Management Protocol (ISAKMP)
Ipsec: Mode de fonctionnement

 ESP : Encapsulating Security Payload ; Assure 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 connecté et authentification de
l’origine des données, protection partielle contre le Rejeu.

 AH : Authentification Header.
 Assure l’intégrité en mode non connecté et l’authentification de
l’origine des datagrammes IP sans chiffrement des données
 contient tout les paramètres relatifs à chaque SA ;
 La confidentialité assure que ce standard pourra être le plus
répandu
sur Internet.
Ipsec: Mode de fonctionnement

 SAD : Security Association Database.

 Gère les associations de sécurité actives ;
 Contient tout les paramètres relatifs à chaque SA ;
 Consultée pour savoir comment traiter chaque paquet reçu ou à
émettre.
 SPD : Security Policy Database.
 Etablie et maintenue en place par un utilisateur, un administrateur
ou
une application mise en place par ceux-ci.
 IKE : Internet Key Exchange ;
 Authentifie chaque correspondant ;
 Négocie la stratégie de sécurité ;
 Gère l’échange des clés de session ;
 Protocole hybride combinant différentes parties des protocoles
suivants : ISAKMP, OAKLEY, SKEME.
 IPSec : Authentification Header
E n- E n-tê te Charge utile IP
tête IPSec sécurisé Internet
IP ou Réseau Privé

Sy t è m e
avec IPsec

Payload
Next Header Length RESERVED
Security Parameters Index (SPI)
Seq uence Number

Donn ées auth entifiées

(Variable)

E n-
Charge utile IP
tête
IP

En -
Charge utile IP
tête
IP

AH (Authentication Header) - Protocole de sécurité qui

fournit l'authentification, l'intégrité des données
AH est dans la charge utile du paquet
IPSec : Authentification Header
IPSec : Authentification Header
IPSec : Encapsulated Security
Payload
IPv4 En- t ê te
TCP Donn é e s
IP original
(a) Paquet IP original

Authentifié

Crypté

IPv4 En- t ê t e En- t ê te Que ue Auth

TCP Do nn é e s
IP original ESP ESP ESP

(b) Mode Transport

Authentifié

Crypté

IPv4 Nouveau En- tê t e En- t ê t e Q ue ue Auth

TCP Do nn é e s
En- tê t e ESP IP original ESP
IP ESP
(c) Mode Tunne l

 ESP (Encapsulation Security payload) - Protocole de sécurité qui

fournit la confidentialité (entre autres)
 ESP encapsule les données à protéger
IPSec : Encapsulated Security
Payload
IPsec, AH et ESP en
mode transport
 Indépendamment du choix entre AH et ESP, il est possible d’utiliser IPsec dans
deux modes distincts : le mode tunnel et le mode transport. Le mode tunnel
rend le service attendu dans la majorité des cas
 En mode transport, les en-tête IP d’origine sont conservés
 Il est utilisé pour sécuriser la communication entre deux postes ayant des
adresses publiques
 Ce n’est donc pas ce mode qui sera utilisé pour réaliser un VPN, puisque
nous souhaitons adresser des machines privées
 On peut utiliser cette technique pour sécuriser la communication entre
une machine publique sur Internet (l’administrateur depuis son domicile
par exemple) et un serveur publique (pour du paramétrage à distance
par exemple), mais pour ce cas, il existe d’autres techniques comme SSH
(Secure Shell)
AH et ESP en mode
transport
IP En-tête IP DATA

IPsec En-tête IP AH ESP DATA ESP

crypté (ESP)
authentifié (AH)

Utilisation de AH et de ESP
en mode transport

 AH et ESP peuvent, dans ce mode, être vus comme un protocole

intermédiaire entre TCP et IP
 L’en-tête IP doit porter des adresses publiques pour voyager à travers
Internet
AH et ESP en mode
tunnel
 En mode tunnel, les en-tête d’origine sont cryptés, et un autre
en-tête IP sera ajouté (on encapsule de l’IP dans de l’IP)
 Il est utilisé pour sécuriser la communication entre deux
équipements d’interconnexion (entre des routeurs ou des
firewalls)
 C’est le mode qui sera utilisé pour réaliser un VPN, puisque
nous souhaitons adresser des machines privées
 C’est la technique la plus répandue pour faire du LAN to
LAN VPN
AH et ESP en mode
tunnel
En-tête IP(ancienne) DATA
IP
IPsec En-tête IP(nouvelle) AH ESP En-tête IP (ancienne) DATA ESP

crypté (ESP)
authentifié (AH)

Utilisation de AH et de ESP en mode tunnel

 ESP crypte le paquet d’origine, en-tête IP compris
 AH assure l’authentification et l’intégrité de l’ensemble
 L’en-tête IP initiale peut contenir des adresses privées puisqu’elle n’est pas
utilisée par les routeurs d’Internet
 L’en-tête IP ajouté portera les @ IP des routeurs (ou
firewalls) d’interconnexion, qui sont forcément publiques
IPSec : Security Policy
 Le terme « Security Policy » désigne, dans le contexte
IPsec, le choix pour un lien unidirectionnel donné :
 de l’utilisation obligatoire ou facultative ou de la non-
utilisation d’IPsec ;
 de l’utilisation du mode tunnel ou transport ;
 de l’utilisation d’AH ou d’ESP.

 L’ensemble des SP est regroupé dans une SPD : « Security

Policy Database ». À l’image des règles de flux d’un pare-
feu, les SP ont pour but de spécifier les flux que l’on veut
autoriser et ceux que l’on veut interdire.
Etablissement d’un lien IPsec
 Les mécanismes cryptographiques utilisés pour la protection
en intégrité ou en confidentialité sont paramétrés par une
ou plusieurs clés.
 Ces éléments doivent être partagés par les différents hôtes
employant IPsec.
 Deux approches sont possibles :
 mettre en place manuellement des clés sur chaque
hôte
 ou utiliser le mécanisme d’échange de clés IKE pour que
les hôtes puissent négocier ces clés.
IPSec : Security Association SA

 SA (Security Association) : c’est l’ensemble de principes

(politiques) et de clés utilisés pour protéger l'information
 Plusieurs SA sont utiles pour « monter » un tunnel
IPSec
 Il faut une SA pour IKE (tunnel de service, on dit aussi SA
ISAKMP)
 Il faut une SA pour IPSec (tunnel de données)

 Les SAs ISAKMP sont bidirectionnelles

 Les SAs IPSec sont unidirectionnelles
 Les équipements VPN stockent leurs SAs dans une base de
données locale appelée la SA Database (SAD)
IPSec : Security Association SA
 Les informations Les informations
échangées sont :
 index de la SA appelé (pour Security Parameter
Parameter Index)
 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
 mode du protocole mode du protocole IPsec
(tunnel ou transport)

Attention : un SA est Attention : un SA est

Unidirectionnelle: protéger les deux sens d'une ger
les deux sens d'une communication classique
requiert communication classique requiert deux
associations.
IPSec : Security Association SA
IPSec : Security Association SA
1. IPSec reçoit les données à envoyer ;

2. Consulte la base de données des politiques de sécurité (SPD) ;

3. Si indication d’application 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) ;

4. Si la SA existe déjà, elle est utilisé pour traiter le trafic ;

5. Dans le cas contraire, IPSec fait appel à IKE pour etablir une
nouvelle

SA.
IPSec : Security Association SA
1. IPSEC reçoit les données en provenance du réseau ;

2.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 ;

3.Consulte alors la SAD pour connaître les paramètres à utiliser pour la

vérification et/ou le déchiffrement du paquet ;

4.Consultation de la SPD pour savoir si l’association de sécurité appliquée

au paquet correspondait bien à celle requise ;

5. Dans le cas où le paquet reçu serait un paquet IP classique, la SPD

permet de savoir s ’il a néanmoins le droit de passer.

IPSec : SA
IKE
Host Host B
A Router Router B
A

10.0.1.3 Negotiate IKE Proposals

10.0.2.3

Transform Transform
10 DES 15 DES
MD5 MD5
pre-share IKE Policy Sets pre-share
DH1 DH1
lifetime lifetime

Transform
20 3DES
SHA
pre-share
DH1
lifetime

 Exemple de SA IKE (on dit aussi SA

ISAKMP)
IPSec : IKE
IPSec IPSec

Routeur A Routeur B

IKE IKE
Tunnel IKE

 IKE est un protocole utile pour négocier une partie de la politique de

sécurité (Security Association : SA) qui servira pour l’échange des
données
 IKE est orienté gestion des clés
 IKE est issu des anciens protocoles de gestion de clés SKEME et
Oakley
 IKE fonctionne dans le cadre de ISAKMP
 IKE n’est pas le seul protocole de gestion de clés disponible, mais il est
le seul utilisé en pratique pour IPSec
IPSec :
ISAKMP A B

Accès Accès
Backbone
c li e nt Opérateur c li e nt
SADB SADB

A vers B A vers B
ESP / DES/ SH A- ESP/ DES/ SH A-
1 Keys K1,K2,... 1 Keys K1,K2,...
lifetime= 3600 s lifetime= 3600 s

B vers A B vers A
ESP / DES/ SH A- ESP/ DES/ SH A-
1 1
k e y s K6,K7,... k e y s K6,K7,...
lifetime= 3600 lifetime= 3600
s s
 La négociation des SAs ne concerne pas que la gestion des clés
 ISAKMP est le protocole « cadre » qui va permettre à IKE de fonctionner, mais il
sert aussi à négocier les autres paramètres des SAs
 ISAKMP sert à négocier les SAs, mais n’impose rien quant aux paramètres qui
composent ces SAs
 ISAKMP définit les procédures et les formats de paquets pour créer, gérer,
détruire des SAs
186
 ISAKMP permet aussi d’authentifier les partenaires d’une SA
IPSec : les 5
étapes
Host A Host B

Routeur A Routeur B

1. A reconnait des informations à transmettre vers le B par le VPN

2. Les routeurs A e t B n é g o c i e n t u n e s e s s i o n IKE Phase 1

IKE SA IKE Phase 1 IKE SA

3. Les routeurs n é g o c i e n t u n e s e s s i o n IKE Phas e

2
IKE SA IKE Phase 2 IKE SA

4. Les information s o n t é c h a n g é e s via le Tunne l

IPSec

5 . Le t u n n e l IPSec e s t libéré.

 On distingue 5 étapes lors de l’utilisation d’un tunnel VPN

IPSec : les 5
étapes Host A Host B

Routeur A Routeur B

1. A reconnait des informations à transmettre vers le B par le VPN

2. Les routeurs A e t B n é g o c i e n t u n e s e s s i o n IKE Phase 1

IKE SA IKE Phase 1 IKE SA

3. Les routeurs n é g o c i e n t u n e s e s s i o n IKE Phase

2
IKE SA IKE Phase 2 IKE SA

4. Les information s o n t é c h a n g é e s via le Tunne l

IPSec

5. Le tunnel IPSec est libéré.

 Etape 1 : A reconnaît des informations à transmettre vers le B par le VPN

 le trafic est dit "intéressant" quand l'équipement VPN reconnaît que les données doivent
être protégées : définition d’une ACL
IPSec : les 5
étapes Host A Host B

Routeur A Routeur B

1. A reconnait des informations à transmettre vers le B par le VPN

2. Les route urs A e t B n é g o c i e n t u n e s e s s i o n IKE P hase 1

IKE SA IKE Phase 1 IKE SA

3 . Les routeurs n é g o c i e n t u n e s e s s i o n IKE Ph ase

2
IKE SA IKE Phase 2 IKE SA

4 . Les information s o n t é c h a n g é e s via le Tunne l

IPSec

5. Le tunnel IPSec est libéré.

 Etape 2 :
 IKE Phase 1 authentifie les extrémités IPSec et négocie la SA IKE
(ou SA ISAKMP)
 Ceci crée un canal sécurisé pour négocier les SAs IPSec en Phase
2
IPSec : les 5
étapes Host A Host B

Routeur A Routeur B

1. A reconnait des informations à transmettre vers le B par le VPN

2. Les routeurs A e t B n é g o c i e n t u n e s e s s i o n IKE Phase 1

IKE SA IKE Phase 1 IKE SA

3 . Les routeurs n é g o c i e n t u n e s e s s i o n IKE Ph ase

2
IKE SA IKE Phase 2 IKE SA

4 . Les information s o n t é c h a n g é e s via le Tunne l

IPSec

5. Le tu nnel IPSec est libéré.

 Etape 3 :
 IKE phase 2 négocie les SAs IPSec en cherchant une
correspondance entre les SAs IPSec des extrémités
IPSec : les 5
étapes Host A Host B

Routeur A Routeur B

1. A reconnait des informations à transmettre vers le B par le VPN

2. Les routeurs A e t B n é g o c i e n t u n e s e s s i o n IKE Phase 1

IKE SA IKE Phase 1 IKE SA

3. Les routeurs n é g o c i e n t u n e s e s s i o n IKE Phase

2
IKE SA IKE Phase 2 IKE SA

4. Les information s o n t é c h a n g é e s via le Tunne l

IPSec

5. Le tun nel IPSec est libéré.

 Etape 4 :
 Le transfert de données est effectué entre les extrémités IPSec
sur la base des paramètres IPSec et des clés stockées dans les
SAs négociées en étape 3
IPSec : les 5
étapes Host A Host B

Routeur A Routeur B

1. A reconnait des informations à transmettre vers le B par le VPN

2. Les routeurs A e t B n é g o c i e n t u n e s e s s i o n IKE Phase 1

IKE SA IKE Phase 1 IKE SA

3 . Les routeurs n é g o c i e n t u n e s e s s i o n IKE Ph ase

2
IKE SA IKE Phase 2 IKE SA

4 . Les information s o n t é c h a n g é e s via le Tunne l

IPSec

5. Le tun nel IPSec est libéré.

 Etape 5 :
 La libération du tunnel IPSec survient quand la session qui a motivé
le montage du VPN se termine ou sur « time out »
Critique d’IPSec
 Les performances sur le lien IPSec sont réduites à cause du chiffrement
 IPSec ne supporte pas le multicast : AH et ESP l’autorisent, mais IKE
ne prévoit pas de négocier des SAs entre plus de deux firewalls
 La complexité de IKE conduit à des incompatibilités entre les différents
constructeurs
 Le trafic est suspendu pendant le renouvellement des SAs
 La gestion des messages ICMP n’est pas triviale : si un message ICMP
vient d’un équipement par lequel transite le tunnel, il ne peut remonter
que jusqu’au firewall d’origine. Il faut alors que ce firewall sache
prévenir la vraie source des données pour lui faire comprendre que le
VPN est indisponible
 Il ne doit pas y avoir de NAT au dessus de VPN (le NAT en dessous
de VPN est courant, voire obligatoire sur un firewall)
OpenVPN

 OpenVPN cumule de nombreux avantages car il est :

 open source et fiable ;
 gratuit au niveau logiciel ;
 multi-plates-formes (c'est-à-dire compatible Windows, Linux,
Mac OS X...) ;
 très répandu ;
 capable de tourner sur n'importe quel port en écoute côté
serveur (y compris 80 ou 443).
OpenVPN

 OpenVPN cumule de nombreux avantages car il est :

 open source et fiable ;
 gratuit au niveau logiciel ;
 multi-plates-formes (c'est-à-dire compatible Windows, Linux,
Mac OS X...) ;
 très répandu ;
 capable de tourner sur n'importe quel port en écoute côté
serveur (y compris 80 ou 443).
DMVPN
D’un point de vue High-level, il s’agit de “Point to Multipoint overlay
VPN Tunneling” ou Overlay veut dire que le DMVPN fonctionne au
dessus d’autres protocoles (GRE /
IPsec).
D’un point de vue Low-level, il s’agit de tunnels GRE over IPsec site-to-
site tunnels – Gérables dynamiquement et évolutifs.
High-level design & operations
–Les sites distants (spokes) montent des tunnels statiques vers un
central (Hub & spoke).
–Les Spokes échangent des informations de routage avec les hub au
travers du tunnel statique (EIGRP, OSPF, RIP…).
–Le trafic Spoke to hub est routé directement dans le tunnel statique.
–Le trafic Spoke to Spoke est routé dynamiquement avec des tunnels à
la demande.
DMVPN
La gestion de la configuration est simple (les spokes utilisent un template
standard) et celà facilite le provisioning (Aucune configuration supplémentaire
sur le Hub quand
on ajoute d’autres spokes).
Le DMVPN supporte le transport de nombreux protocoles (IPv4, v6, unicast,
multicast, static & dynamic routing) et utilise n’importe quel transport IP
(DSL, Cable,
Différents ISPs..). Il fonctionne aussi au travers du NAT.
IPsec statique
L’IPsec statique est difficile à faire évoluer d’un point de vue “management”,
ajouter des nouveaux sites requière beaucoup de configuration. Ce type de
VPN ne supporte pas le routage dynamique ou le Multicast (de base).
MPLS L3 VPN
Ajoute une complexité de routage supplémentaire, ils ne supportent pas
forcément IPv6 or IPv4/v6 Multicast.
L’Interopérabilité avec les fournisseurs d’accès pour le MPLS L3VPN est
difficile à mettre en place, et besoin de circuits séparés pour l’accès internet.
DMVPN
IPsec statique
L’IPsec statique est difficile à faire évoluer d’un point de vue
“management”, ajouter des nouveaux sites requière beaucoup de
configuration. Ce type de VPN ne supporte pas le routage dynamique
ou le Multicast (de base).
MPLS L3 VPN
Ajoute une complexité de routage supplémentaire, ils ne supportent
pas forcément IPv6 or IPv4/v6 Multicast.
L’Interopérabilité avec les fournisseurs d’accès pour le MPLS L3VPN est
difficile à mettre en place, et besoin de circuits séparés pour l’accès
internet.
Fonctionnement du DMVPN
Il s’agit d’un réseau Full mesh de tunnels IPsec à la demande, avec un
minimum de configuration grâce aux protocoles suivants :
–Multipoint GRE Tunnels (mGRE)
–NHRP (Permet au Hub de retrouver les adresses IP des Hub
dynamiquement).
–IPsec crypto profiles (Encryption).
–Routage (underlay/overlay)
La technologie DMVPN réduit le besoin de configurer un full mesh
(n*(n-1)/2) de tunnels statiques, ici nous n’avons qu’un seul tunnel
mGRE sur le Hub pour tous. Les tunnels sont ensuite montés à la
demande entre les différents nœuds, selon le trafic, entre les spokes.
Le chiffrement via IPsec est optionnel.
Deux IGP sont requis:
Underlying: Pour la connectivité IP publique et monter les tunnels
GRE.
Overlay: Pour s’échanger des routes privées une fois le tunnel monté.
Fonctionnement du DMVPN
Fonctionnement du DMVPN
Fonctionnement – Hub to spoke
2 composants:
–DMVPN Hub / NHRP Servers (NHS).
–DMVPN Spokes / NHRP Clients (NHC).
Les Spokes (Clients) s’enregistrent avec le Hub (Serveur).
–Ils spécifient manuellement l’adresse du Hub dans le Tunnel GRE
(tunnel destination…).
–Ils envoient cela via le NHRP Registration Request
–Les Hub apprennent dynamiquement les adresses VPN (Privées)
et adresses NBMA (Publiques).
Les Spokes établissent les tunnels vers les Hub, puis ils échangent
ensuite les infos de routage IGP au travers du Tunnel.
Fonctionnement du DMVPN
Fonctionnement – Spoke to Spoke
Le Spoke 1 connait les routes du Spoke 2 via un IGP.
–Les routes sont connues via le tunnel vers le hub.
–Le Next-hop est l’adresse VPN du Spoke 2 pour le DMVPN Phase 2.
–Le Next-hop est l’adresse VPN du Hub pour le DMVPN Phase 3.
Le Spoke 1 demande l’adresse IP réelle du Spoke 2
–Il mappe l’IP du next-hop (VPN) à l’IP source du tunnel (NBMA).
–Adresse demandée via le NHRP resolution request
Le Spoke to Spoke tunnel est enfin formé
–Le Hub effectue le control-plane seulement.
–Le Spoke to spoke data plane peut aussi passer par le hub dans
certains cas, mais la plupart du temps, les data ne passent plus par
le Hub pour le trafic Spoke
to Spoke.
Fonctionnement du DMVPN
NHRP Important messages

1 NHRP Registration Request

–Les Spokes enregistrent leurs IP NBMA et VPN au NHS (Hub)
–Requis pour construire le spoke-to-hub tunnels

2 NHRP Resolution REquest

–Les Spokes demandent les mappings NBMA-to-VPN des autres spokes
–Requis pour construire les spoke-to-spokes tunnels

3 NHRP Redirect
–NHS (hub) répond à un spoke-to-spoke data plane packet via ce message.
–Similaire aux IP redirect
–Utilisé seulement en phase 3 pour construire les spoke-to-spoke tunnels.