8. Considérations de sécurité
Les considérations de sécurité pour UDP et SCTP sont fournies dans les RFC référencées.
8.1. Contrôle de la fréquence de sondage
Pour éviter une charge excessive, l'intervalle entre les paquets de sondage individuels DOIT être d'au moins un RTT, et l'intervalle entre les cycles de sondage est déterminé par le PMTU_RAISE_TIMER.
8.2. Protection de la confirmation des paquets de sondage
L'émetteur PL doit s'assurer que la méthode utilisée pour confirmer la réception des paquets de sondage est capable de protéger contre les attaquants hors chemin injectant des paquets dans le chemin. Cette protection est fournie dans les protocoles définis par l'IETF (par exemple, TCP, SCTP) utilisant un numéro de séquence initialisé aléatoirement. La section 5.1 de [BCP145] fournit une description d'une façon de le faire lors de l'utilisation d'UDP.
8.3. Validation des messages PTB
Il existe des cas où les messages Packet Too Big (PTB) ne sont pas livrés en raison de la politique, de la configuration ou de la conception de l'équipement (voir Section 1.1). Cette méthode ne repose donc pas sur la réception de messages PTB mais est capable de les utiliser lorsqu'ils sont reçus par un émetteur.
Protection contre les attaques par messages PTB
Les messages PTB pourraient être utilisés pour amener un nœud à réduire de manière inappropriée le PLPMTU. Un nœud prenant en charge DPLPMTUD DOIT valider de manière appropriée la charge utile des messages PTB pour s'assurer qu'ils sont reçus en réponse à des datagrammes réellement envoyés par la couche PL (c'est-à-dire correspondre à une condition d'erreur rencontrée pour un datagramme réellement envoyé, voir Section 4.6.1).
Atténuation des attaques sur le chemin
Un attaquant sur le chemin capable de créer des messages PTB pourrait forger des messages PTB incluant un paquet IP cité valide. Une telle attaque pourrait être utilisée pour réduire le PLPMTU. Un dispositif sur le chemin pourrait de même forcer une réduction du PLPMTU en mettant en œuvre une politique pour supprimer les paquets plus grands qu'une taille configurée.
Méthodes d'atténuation:
-
Protection de base: S'assurer qu'un émetteur PL ne réduit jamais le PLPMTU en dessous de la taille de base uniquement en réponse à la réception d'un message PTB. Ceci est réalisé en entrant d'abord dans l'état BASE lorsqu'un tel message est reçu.
-
Validation par sondage: Conçu pour ne pas nécessiter le traitement des messages PTB ; un émetteur PL peut suspendre le traitement des messages PTB (par exemple, dans un mode de robustesse après avoir détecté que le sondage ultérieur confirme en fait qu'une taille supérieure au PTB_SIZE est prise en charge par le chemin).
8.4. Protection contre le déni de service
Limitation de la surcharge de traitement
L'analyse du paquet cité à l'intérieur d'un message PTB peut introduire un traitement supplémentaire par paquet au niveau de l'émetteur PL. Ce traitement DEVRAIT être limité pour éviter une attaque par déni de service lorsque des en-têtes arbitraires sont présents. La limitation du débit de traitement pourrait empêcher le PL de recevoir des messages PTB ; cependant, la méthode DPLPMTUD est robuste face à une telle perte.
Traitement des messages ICMP
Le traitement réussi d'un message ICMP peut déclencher un sondage lorsque la taille PTB signalée est valide, mais cela ne met pas directement à jour le PLPMTU pour un chemin. Cela empêche les messages qui tentent de mettre en trou noir les données en indiquant une taille supérieure à celle prise en charge par le chemin.
8.5. Instabilité des informations de chemin
Les informations sur un chemin peuvent être instables. Cela pourrait résulter du transfert sur plusieurs chemins avec des PMTU réels différents ou d'un chemin unique présentant un PMTU variable.
Atténuation: La conception d'une implémentation DPLPMTUD DEVRAIT considérer comment atténuer les effets des informations de chemin variables. Une atténuation possible consiste à fournir une robustesse (voir Section 5.4) dans la méthode pour éviter l'oscillation du MPS.
8.6. Sécurité des données de rembourrage
La méthode DPLPMTUD peut introduire des données de rembourrage pour gonfler la longueur du datagramme à la taille totale requise pour un paquet de sondage. La taille totale d'un paquet de sondage comprend tous les en-têtes et le rembourrage ajoutés aux données de charge utile envoyées (par exemple, y compris les champs liés à la sécurité tels que les balises AEAD et le rembourrage de la couche d'enregistrement TLS). La valeur des données de rembourrage n'affecte pas l'algorithme de recherche DPLPMTUD et doit donc être définie d'une manière cohérente avec la politique du PL.
Exigences de protection par chiffrement
Si le PL est capable d'utiliser un mécanisme cryptographique de confidentialité ou d'intégrité des données, la conception doit éviter d'ajouter quoi que ce soit aux paquets de sondage DPLPMTUD (par exemple, le rembourrage) qui n'est pas également protégé par ces mécanismes cryptographiques.
8.7. Résumé des meilleures pratiques de sécurité
- Valider tous les messages PTB: Valider l'origine et le contenu des messages PTB avant utilisation
- Limiter le débit de traitement: Prévenir l'épuisement des ressources du traitement des messages PTB
- Protéger la confirmation de sondage: Utiliser des identifiants difficiles à deviner
- Chiffrer les données de rembourrage: S'assurer que toutes les données des paquets de sondage sont protégées par chiffrement
- Surveiller la stabilité du chemin: Détecter et répondre aux changements inhabituels des informations de chemin
- Implémenter la limitation du débit: Contrôler la fréquence d'envoi des paquets de sondage
Ces considérations de sécurité garantissent que DPLPMTUD peut fonctionner de manière sûre et fiable, même en présence d'attaquants malveillants.