9. Considérations de sécurité
9. Considérations de sécurité
Comme le BFD peut être lié à la stabilité de l'infrastructure réseau (comme les protocoles de routage), les effets d'une attaque sur une session BFD peuvent être très graves : un lien peut être faussement déclaré comme étant down, ou faussement déclaré comme étant up ; dans les deux cas, l'effet est un déni de service.
Un attaquant qui a le contrôle complet de la liaison entre les systèmes peut facilement supprimer tous les paquets BFD mais transmettre tout le reste (provoquant la fausse déclaration de la liaison comme étant down), ou ne transmettre que les paquets BFD mais rien d'autre (provoquant la fausse déclaration de la liaison comme étant up). Cette attaque ne peut pas être empêchée par le BFD.
Pour atténuer les menaces d'attaquants moins capables, le BFD spécifie deux mécanismes pour empêcher l'usurpation de paquets de contrôle BFD. Le mécanisme de sécurité TTL généralisé [GTSM] utilise le temps de vie (TTL) ou le compte de sauts pour empêcher les attaquants hors liaison d'usurper des paquets. La section d'authentification authentifie les paquets de contrôle BFD. Ces mécanismes sont décrits plus en détail ci-dessous.
Lorsqu'une session BFD est directement connectée à travers un seul lien (physique, ou un tunnel sécurisé tel qu'IPsec), le TTL ou le compte de sauts DOIT être réglé au maximum lors de la transmission, et vérifié pour être égal à la valeur maximale lors de la réception (et le paquet supprimé si ce n'est pas le cas). Voir [GTSM] pour plus d'informations sur cette technique. Si le BFD est exécuté à travers plusieurs sauts ou un tunnel non sécurisé (tel que Generic Routing Encapsulation (GRE)), la section d'authentification DEVRAIT être utilisée.
Le niveau de sécurité fourni par la section d'authentification varie en fonction du type d'authentification utilisé. L'authentification par mot de passe simple n'est évidemment aussi sécurisée que le secret des mots de passe utilisés, et ne devrait être considérée que si la session BFD est garantie d'être exécutée sur une infrastructure non sujette à l'interception de paquets. Son principal avantage est qu'elle minimise l'effort de calcul requis pour l'authentification.
L'authentification MD5 avec clé est beaucoup plus forte que l'authentification par mot de passe simple car les clés ne peuvent pas être discernées en interceptant des paquets. Elle est vulnérable aux attaques par rejeu entre les incréments du numéro de séquence. Le numéro de séquence peut être incrémenté aussi rarement (ou aussi souvent) que souhaité, faisant un compromis entre la résistance aux attaques par rejeu et l'effort de calcul requis pour l'authentification.
L'authentification MD5 méticuleuse avec clé est encore plus forte, car elle exige que le numéro de séquence soit incrémenté pour chaque paquet. La vulnérabilité aux attaques par rejeu est réduite en raison de l'exigence que le numéro de séquence doit être incrémenté sur chaque paquet, la taille de la fenêtre des paquets acceptables est petite, et le numéro de séquence initial est randomisé. Il existe toujours une fenêtre d'attaque au début de la session pendant que le numéro de séquence est en cours de détermination. Ce schéma d'authentification nécessite un calcul MD5 sur chaque paquet transmis et reçu.
L'utilisation de SHA1 est supposée avoir des propriétés de sécurité plus fortes que MD5. Tous les commentaires sur MD5 dans cette section s'appliquent également à SHA1.
Les MD5/SHA1 avec clé et les MD5/SHA1 méticuleux avec clé utilisent tous deux la construction du "suffixe secret" (également appelée "append only") dans laquelle la clé secrète partagée est ajoutée aux données avant de calculer le hachage, au lieu de la construction HMAC (Hashed Message Authentication Code) plus courante [HMAC]. Cette construction est considérée comme appropriée pour le BFD, mais les concepteurs de tout mécanisme d'authentification supplémentaire pour le BFD sont encouragés à lire [HMAC] et ses références.
Si les deux systèmes randomisent leurs valeurs de discriminateur local au début d'une session, les attaques par rejeu peuvent être davantage atténuées, quel que soit le type d'authentification utilisé. Étant donné que le discriminateur local peut être modifié à tout moment pendant une session, ce mécanisme peut également aider à atténuer les attaques.
Les implications de sécurité de l'utilisation des paquets BFD Echo dépendent de la façon dont ces paquets sont définis, car leur structure est locale au système émetteur et en dehors de la portée de cette spécification. Cependant, puisque les paquets Echo sont définis et traités uniquement par le système émetteur, l'utilisation de l'authentification cryptographique ne garantit pas que l'autre système est réellement vivant ; un attaquant pourrait reboucler les paquets Echo (sans connaître de clés secrètes) et provoquer la fausse déclaration de la liaison comme étant up. Cela peut être atténué en utilisant un intervalle approprié pour les paquets de contrôle BFD. [GTSM] pourrait être appliqué aux paquets BFD Echo, bien que le TTL/compte de sauts sera décrémenté de 1 au cours de l'écho du paquet, donc l'usurpation est possible à partir d'un saut de distance.