Mon blog

BGP 4 est aujourd'hui l'unique protocole d'échange de routes entre les opérateurs Internet. Il joue donc un rôle central dans le subtil routage d'une machine à l'autre. Un nouveau RFC vient de remplacer l'ancienne norme, sans guère de changements.

BGP est à la fois peu connu de la majorité des utilisateurs d'Internet et en même temps un outil indispensable. Il y a belle lurette que l'Internet est trop complexe pour que les tables de routage soient mises à jour à la main. Il faut donc un protocole pour échanger l'information de routage entre routeurs et pour calculer ensuite la route nécessaire pour acheminer un paquet d'une machine à l'autre. Il existe deux familles de tels protocoles, pour le routage interne à un opérateur (où les différents routeurs ont, par définition, la même politique) et pour le routage externe, entre '''systèmes autonomes''', c'est-à-dire entre opérateurs. BGP est de cette deuxième famille.

BGP fonctionne entre '''pairs''', deux pairs étant des routeurs qui ont été configurés pour s'échanger des routes. Notre RFC décrit le modèle de table de routage, tel que BGP le considère, les messages que peuvent échanger deux pairs et la façon de représenter l'information sur les routes que ces messages contiennent. Le RFC est relativement complexe (plus de cent pages en tout, ce qui est rare pour un RFC) mais le protocole est riche, car il doit pouvoir être utilisé entre machines gérées par des organismes différents, et il doit permettre l'application de politiques de routage complexes.

Tout ceci était déjà dans le prédécesseur de notre RFC, le RFC 1771. Les nouveautés ultérieures comme les extensions multi-protocoles (spécifiées dans le RFC 4760, elles sont notamment indispensables pour IPv6, décrit dans le RFC 2545) ou comme les capacités (RFC 5492) n'ont pas été incluses, contrairement à ce qui a été fait pour SMTP où le RFC 2821 avait incorporé beaucoup de RFC publiées postérieurement au RFC 822 qu'il remplaçait. Il faut donc toujours lire plusieurs RFC si on veut développer une mise en œuvre de BGP (un défi non trivial).

Les principales nouveautés de notre RFC par rapport à son prédécesseur de mars 1995 sont :

• L'option d'authentifcation et d'intégrité par signature TCP MD5, spécifiée dans le RFC 2385, devient obligatoire. Elle est très contestée, soit parce qu'elle viole le modèle en couches, soit parce que certains auraient préféré IPsec. Mais il ne fait pas de doute qu'elle est très largement utilisée. Peut-être, depuis la publication du RFC 5925, sera t-elle remplacée par TCP-AO (TCP Authentication Option).
• Formalisation de ''trucs'' très employés comme la répétition de son propre numéro de système autonome dans le chemin d'AS ou comme la coupure d'une session BGP lorsqu'un pair annonce un nombre de routes supérieur à une certaine limite (ce qui indique en général que ledit pair est mal configuré).

En même temps que notre RFC ont été publiés plusieurs autres RFC liés à BGP, le RFC 4272 sur la sécurité, le RFC 4273 sur la MIB de gestion, le RFC 4274 qui analyse le protocole, le RFC 4275 qui étudie les mises en œuvres de la MIB, le RFC 4276 qui examine les logiciels qui mettent en œuvre BGP, le RFC 4277 qui tire les leçons de la longue expérience de l'Internet avec BGP, et enfin le RFC 4278 sur des détails de la signature TCP MD5.