10. Considérations de sécurité (Security Considerations)
o Numéros de protocole Internet attribués [IANA-PN]
o Identifiants de réseau ONC RPC (netids) [IANA-NI]
o Identifiants de protocoles de couche réseau (NLPID) d'intérêt
[IANA-NL]
o Registres de protocoles [IANA-PR]
L'IANA a mis à jour ces références pour pointer vers ce document.
- Considérations de sécurité
Du point de vue du format de base et de la transmission des paquets, IPv6 présente des propriétés de sécurité similaires à IPv4. Ces problèmes de sécurité incluent :
o Écoute clandestine, où des éléments situés sur le chemin peuvent
observer l'intégralité du paquet (contenu et métadonnées) de chaque
datagramme IPv6.
o Rejeu, où l'attaquant enregistre une séquence de paquets et la
rejoue à la partie qui les avait initialement reçus.
o Insertion de paquets, où l'attaquant forge un paquet avec un
ensemble de propriétés choisies et l'injecte sur le réseau.
o Suppression de paquets, où l'attaquant retire un paquet du réseau.
o Modification de paquets, où l'attaquant retire un paquet du réseau,
le modifie et le réinjecte.
o Attaques de type homme du milieu (MITM), où l'attaquant détourne
le flux de communication afin de se faire passer pour l'expéditeur
auprès du destinataire et inversement.
o Attaques par déni de service (DoS), où l'attaquant envoie de grandes
quantités de trafic légitime à une destination pour la saturer.
Les paquets IPv6 peuvent être protégés contre l'écoute clandestine, le rejeu, l'insertion, la modification et les attaques MITM grâce à la « Security Architecture for the Internet Protocol » [RFC4301]. De plus, les protocoles de couche supérieure tels que TLS (Transport Layer Security) ou SSH (Secure Shell) peuvent être utilisés pour protéger le trafic applicatif s'exécutant au-dessus d'IPv6.
Aucun mécanisme ne permet de se protéger des attaques DoS. Se défendre contre ce type d'attaques sort du périmètre de cette spécification.
Les adresses IPv6 sont nettement plus longues que les adresses IPv4, ce qui rend bien plus difficile le balayage de l'espace d'adressage à travers Internet, voire sur un seul lien réseau (par exemple un réseau local). Voir [RFC7707] pour plus d'informations.
Les adresses IPv6 des nœuds devraient être plus visibles sur Internet qu'en IPv4, en raison de la réduction de l'usage des techniques de traduction d'adresse. Cela engendre des problèmes de confidentialité supplémentaires, comme la facilité accrue à distinguer les points d'extrémité. Voir [RFC7721] pour plus d'informations.
La conception de l'architecture des en-têtes d'extension d'IPv6, bien qu'elle ajoute beaucoup de flexibilité, crée également de nouveaux défis de sécurité. Comme indiqué ci-dessous, les problèmes liés à l'en-tête d'extension Fragment ont été résolus, mais il est clair que pour tout nouvel en-tête d'extension conçu à l'avenir, les implications de sécurité doivent être examinées en profondeur ; cela inclut la manière dont le nouvel en-tête d'extension interagit avec les en-têtes d'extension existants. Voir [RFC7045] pour plus d'informations.
Cette version de la spécification IPv6 résout un certain nombre de problèmes de sécurité identifiés dans la version précédente [RFC2460] de la spécification IPv6. Citons notamment :
o Révision du texte pour traiter le cas des fragments qui sont des
datagrammes complets (c'est-à-dire à la fois le champ Fragment
Offset et le drapeau M valant zéro). S'ils sont reçus, ils doivent
être traités comme un paquet réassemblé. Tout autre fragment
correspondant doit être traité indépendamment. Le processus de
création des fragments a été