Security Considerations (Considérations de sécurité)

Une implémentation BGP doit (MUST) prendre en charge le mécanisme d'authentification spécifié dans RFC 2385 [RFC2385]. L'authentification fournie par ce mécanisme pourrait être effectuée par pair.

BGP utilise TCP pour le transport fiable de son trafic entre les routeurs pairs. Pour fournir une intégrité orientée connexion et une authentification de l'origine des données sur une base point à point, BGP spécifie l'utilisation du mécanisme défini dans RFC 2385. Ces services sont destinés à détecter et rejeter les attaques d'écoute active contre les connexions TCP inter-routeurs. En l'absence de l'utilisation de mécanismes qui réalisent ces services de sécurité, les attaquants peuvent perturber ces connexions TCP et/ou se faire passer pour un routeur pair légitime. Parce que le mécanisme défini dans le RFC ne fournit pas d'authentification d'entité pair, ces connexions peuvent être sujettes à certaines formes d'attaques par rejeu qui ne seront pas détectées au niveau de la couche TCP. De telles attaques pourraient entraîner la livraison (depuis TCP) de messages BGP "cassés" ou "usurpés".

Le mécanisme défini dans RFC 2385 augmente la somme de contrôle TCP normale avec un code d'authentification de message (MAC) de 16 octets qui est calculé sur les mêmes données que la somme de contrôle TCP. Ce MAC est basé sur une fonction de hachage à sens unique (MD5) et l'utilisation d'une clé secrète. La clé est partagée entre les routeurs pairs et est utilisée pour générer des valeurs MAC qui ne sont pas facilement calculées par un attaquant qui n'a pas accès à la clé. Une implémentation conforme doit (MUST) prendre en charge ce mécanisme et doit (MUST) permettre à un administrateur réseau de l'activer par pair.

RFC 2385 ne spécifie pas de moyen de gérer (par exemple, générer, distribuer et remplacer) les clés utilisées pour calculer le MAC. RFC 3562 [RFC3562] (un document informatif) fournit quelques conseils dans ce domaine et fournit une justification pour soutenir ces conseils. Il note qu'une clé distincte devrait être utilisée pour la communication avec chaque pair protégé. Si la même clé est utilisée pour plusieurs pairs, les services de sécurité offerts peuvent être dégradés, par exemple en raison d'un risque accru de compromission sur un routeur qui affecte négativement d'autres routeurs.

Les clés utilisées pour le calcul MAC doivent être changées périodiquement, pour minimiser l'impact d'une compromission de clé ou d'une attaque cryptanalytique réussie. RFC 3562 suggère une période crypto (l'intervalle pendant lequel une clé est employée) de, au plus, 90 jours. Des changements de clé plus fréquents réduisent la probabilité que les attaques par rejeu (comme décrit ci-dessus) soient réalisables. Cependant, en l'absence d'un mécanisme standard pour effectuer de tels changements de manière coordonnée entre pairs, on ne peut pas supposer que les implémentations BGP-4 conformes à ce RFC prendront en charge des changements de clé fréquents.

Évidemment, chaque clé devrait également être choisie pour être difficile à deviner pour un attaquant. Les techniques spécifiées dans RFC 1750 pour la génération de nombres aléatoires fournissent un guide pour la génération de valeurs qui pourraient être utilisées comme clés. RFC 2385 demande aux implémentations de prendre en charge des clés "composées d'une chaîne d'ASCII imprimable de 80 octets ou moins". RFC 3562 suggère que les clés utilisées dans ce contexte soient de 12 à 24 octets de bits aléatoires (pseudo-aléatoires). Ceci est assez cohérent avec les suggestions pour des algorithmes MAC analogues, qui emploient généralement des clés dans la plage de 16 à 20 octets. Pour fournir suffisamment de bits aléatoires à l'extrémité inférieure de cette plage, RFC 3562 observe également qu'une chaîne de texte ASCII typique devrait être proche de la limite supérieure pour la longueur de clé spécifiée dans RFC 2385.

L'analyse des vulnérabilités BGP est discutée dans [RFC4272].