12. Security Considerations (Considérations sur la sécurité)
12. Security Considerations (Considérations sur la sécurité)
On pense que lorsque des processus de plan de contrôle sont utilisés pour obtenir des mappages EID vers RLOC, la plupart des mécanismes de sécurité feront partie du service de base de données de mappages. Pour les mappages déclenchés par le plan de données décrits dans cette spécification, la protection contre l'usurpation d'ETR est fournie par l'utilisation d'un mécanisme de routabilité de retour (voir section 3), prouvé par l'utilisation d'un champ 'Nonce' de 24 bits dans l'en-tête d'encapsulation LISP et d'un champ 'Nonce' de 64 bits dans les messages de contrôle LISP.
Le nonce, plus le fait que l'ITR n'accepte que les Map-Replies demandés, fournit un niveau de sécurité de base qui est similaire à bien des égards à la sécurité expérimentée dans le système de routage Internet actuel. Il est difficile pour un attaquant hors chemin de lancer des attaques contre ces mécanismes LISP car il n'a pas la valeur du nonce. L'envoi d'un grand nombre de paquets pour trouver accidentellement la valeur de nonce correcte est possible, mais c'est en soi une attaque par déni de service (DoS). Les attaquants en chemin peuvent mener des attaques plus graves, mais les attaquants en chemin peuvent également lancer de graves attaques dans l'Internet actuel, notamment l'écoute, le blocage ou la redirection du trafic. Pour plus de discussion sur ce sujet, voir la section 6.1.5.1.
LISP ne s'appuie pas sur une PKI ou un système d'authentification plus lourd. Ces systèmes défient l'un des principaux objectifs de conception de LISP - l'évolutivité.
La prévention des attaques DoS dépendra des implémentations limitant le débit du nombre de Map-Requests et Map-Replies du plan de contrôle ainsi que des Map-Replies déclenchées par les données.
Un ITR implémenté de manière incorrecte ou malveillante peut choisir d'ignorer les Priority et Weight fournis par un ETR dans son Map-Reply. Cette direction du trafic sera limitée au trafic envoyé par le site de cet ITR et n'est pas plus grave qu'un site lançant une attaque DoS de bande passante sur l'un des liens d'entrée de l'ETR. Le site de l'ITR ne bénéficiera généralement pas du non-respect du Weight et pourrait obtenir un meilleur service en les respectant.
Pour traiter les tentatives d'épuisement du map-cache dans les ITRs/PITRs, les implémentations devraient envisager de définir une limite supérieure maximale sur le nombre d'entrées stockées et de conserver une liste pour les sites spéciaux ou fréquemment accédés. Cela devrait être contrôlé par une politique de configuration définie par l'administrateur réseau qui gère les ITRs et PITRs. Lorsqu'il existe des EID-Prefixes qui se chevauchent sur plusieurs entrées Map-Cache, l'intégrité de l'ensemble doit être entièrement maintenue. Par conséquent, si une entrée plus spécifique ne peut pas être ajoutée en raison du dépassement de la limite supérieure maximale, aucune entrée moins spécifique ne devrait être stockée dans le map-cache.
Étant donné que les ITRs/PITRs maintiennent un cache de mappages EID vers RLOC, la taille et la maintenance du cache sont des problèmes à garder à l'esprit pendant l'implémentation. L'installation d'instruments pour détecter le battement de cache est une bonne idée. L'expérimentation de l'implémentation sera utilisée pour déterminer quelles politiques de gestion de cache fonctionnent le mieux. En général, il est difficile de se défendre contre les attaques de battement de cache. Il convient de noter qu'un cache trop petit dans les ITRs/PITRs affectera non seulement négativement le site ou la zone qu'il prend en charge, mais peut également entraîner une augmentation de la charge de Map-Request sur le système de mappages.
Les données de mappage "Piggybacked (transportées)" discutées dans la section 6.1.3 spécifient comment traiter de tels mappages et incluent la possibilité pour un ETR d'accepter temporairement de tels mappages avant vérification lorsqu'il fonctionne dans un environnement "de confiance". Dans ce cas, il existe une menace potentielle qu'un faux mappage puisse être inséré (même si seulement pour une courte période) dans le map-cache. Comme décrit dans la section 6.1.3, un ETR doit être spécifiquement configuré pour fonctionner dans un tel mode et peut ne considérer que certains ITRs spécifiques comme fonctionnant également dans le même environnement de confiance.
Il existe un risque de sécurité dans le fait que les ETRs génèrent l'EID-Prefix pour lequel ils répondent. Un ETR peut revendiquer un préfixe plus court qu'il n'est réellement responsable. Divers mécanismes pour améliorer ou résoudre ce problème seront étudiés à l'avenir [LISP-SEC].
L'usurpation des adresses d'en-tête interne des paquets de données encapsulés LISP est possible, comme avec tout mécanisme de tunnelisation. Un ITR doit vérifier que l'adresse source d'un paquet avant encapsulation est un EID appartenant à la plage EID-Prefix du site. Un ETR ne doit désencapsuler et transférer que les datagrammes dont la destination de l'en-tête interne correspond à l'une de ses plages EID-Prefix. Si, lors de la réception et de la désencapsulation, l'EID de destination du datagramme ne correspond pas à l'un des EID-Prefixes configurés de l'ETR, l'ETR DOIT abandonner ce datagramme. Si un paquet de données encapsulé LISP arrive à un ETR, il devrait comparer l'adresse EID source de l'en-tête interne et l'adresse RLOC source de l'en-tête externe avec les mappages existant dans la base de données de mappages. Ensuite, lorsqu'une attaque d'usurpation se produit, l'adresse RLOC source de l'en-tête externe peut être utilisée pour retracer l'attaque jusqu'au site source en utilisant les outils opérationnels existants.
Cette spécification expérimentale n'aborde pas la gestion automatique des clés (AKM). Le BCP 107 [RFC4107] fournit des orientations dans ce domaine. De plus, au moment de la rédaction, un travail considérable est en cours pour améliorer la sécurité du système de routage [RFC6518] [RFC6480] [BGP-SEC] [LISP-SEC]. Les travaux futurs sur LISP devraient aborder les problèmes discutés dans le BCP 107 ainsi que d'autres considérations de sécurité ouvertes, ce qui pourrait nécessiter des modifications à cette spécification.