11. Security Considerations
11. Security Considerations (Considérations de sécurité)
Les problèmes de sécurité associés au NAT sont documentés depuis longtemps. Voir [RFC2663] et [RFC2993].
Toutefois, le déplacement de la fonction NAT du CPE vers le cœur du réseau du fournisseur de services et le partage d'adresses IPv4 entre clients créent des exigences supplémentaires lors de la journalisation des données en cas d'abus. Dans toute architecture où une adresse IPv4 ne représente pas de manière unique un hôte final, les adresses IPv4 et les horodatages ne suffisent plus à identifier un client haut débit particulier. L'AFTR DEVRAIT pouvoir journaliser l'identifiant de tunnel (tunnel-id), le protocole, les ports/adresses IP et l'heure de création de la liaison NAT afin d'identifier de manière unique les sessions utilisateur. Les détails exacts de ce qui est journalisé dépendent de l'implémentation et sont hors du périmètre du présent document.
L'AFTR effectue des fonctions de traduction pour les hôtes IPv4 intérieurs utilisant des adresses RFC 1918 ou la plage réservée IANA (192.0.0.0/29). Dans certaines circonstances, un FAI peut provisionner des politiques dans l'AFTR et ordonner à l'AFTR de contourner les fonctions de traduction sur la base du triplet <IPv4 Address, port number, protocol>. Lorsque l'AFTR reçoit un paquet dont les informations correspondent à la politique en provenance de l'hôte intérieur, l'AFTR peut simplement transférer le paquet sans traduction. Les adresses, ports et informations de protocole doivent être provisionnés sur l'AFTR avant la réception du paquet. Le mécanisme de provisionnement est hors du périmètre de cette spécification.
Lors de la désencapsulation des paquets, l'AFTR NE DOIT transférer que les paquets émis depuis des adresses RFC 1918, une plage réservée IANA ou toute autre adresse préautorisée hors bande. L'AFTR DOIT abandonner tous les autres paquets. Cela empêche des équipements malveillants de lancer des attaques par déni de service en utilisant des adresses IPv4 publiques non autorisées dans le champ d'adresse source IPv4 de l'en-tête IPv4 ou une plage de ports de transport non autorisée dans l'en-tête de transport IPv4. Par exemple, des équipements malveillants pourraient bombarder un serveur Web public en lançant une attaque TCP SYN ACK [RFC4987]. La victime recevrait des SYN TCP depuis des adresses IPv4 aléatoires à un rythme élevé et refuserait les services TCP aux utilisateurs légitimes.
Lorsque des adresses IPv4 sont partagées par plusieurs utilisateurs, les ports deviennent une ressource critique. Il convient donc de mettre en place des mécanismes sur un AFTR pour limiter l'utilisation des ports, soit en limitant le débit des nouvelles connexions, soit en imposant une limite stricte au nombre maximal de ports utilisables par un seul utilisateur. Si ce nombre est suffisamment élevé, cela ne devrait pas perturber l'usage normal tout en offrant une protection raisonnable du pool partagé. D'autres réflexions sur le partage d'adresses IPv4 figurent dans [RFC6269]. D'autres considérations et recommandations sur la journalisation figurent dans [RFC6302].
Les AFTR DEVRAIENT prendre en charge des moyens de limiter le service aux seuls clients enregistrés. Une option simple consiste à implémenter un filtre d'entrée IPv6 sur l'interface tunnel de l'AFTR pour n'accepter que la plage d'adresses IPv6 définie dans le filtre.