Groupe de travail Réseau	S. Sangli, E. Chen, Cisco Systems	
Request for Comments : 4724	R. Fernando, Juniper Networks	
Catégorie : Sur la voie de la normalisation	J. Scudder, Juniper Networks	
	Y. Rekhter, Juniper Networks	
Traduction Claude Brière de L'Isle	janvier 2007	

Mécanisme de redémarrage en douceur pour BGP

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The Internet Society (2006).

Résumé
Le présent document décrit un mécanisme pour BGP qui va aider à minimiser les effets négatifs sur l'acheminement causés par le redémarrage de BGP. Un marqueur Fin de RIB est spécifié et peut être utilisé pour porter les informations de convergence d'acheminement. Une nouvelle capacité BGP, appelée "Capacité de redémarrage en douceur", est définie qui va permettre à un locuteur BGP d'exprimer sa capacité à préserver l'état de transmission durant le redémarrage de BGP. Finalement, des procédures sont mentionnées pour conserver temporairement les informations d'acheminement à travers une terminaison/rétablissement de session BGP.

Les mécanismes décrits dans ce document sont applicables à tous les routeurs, à la fois avec la capacité de préserver l'état de transmission durant le redémarrage BGP et ceux qui ne l'ont pas (bien que ces derniers doivent mettre en œuvre seulement un sous ensemble des mécanismes décrits dans le présent document).
Table des matières
1. Introduction	1
1.1 Spécification des exigences	2
2. Marqueur de fin de RIB	2
3. Capacité de redémarrage en douceur	2
4. Fonctionnement	3
4.1 Procédures pour le locuteur qui redémarre	4
4.2 Procédures pour le locuteur receveur	4
5. Changements à l'automate à états finis de BGP	5
6. Considérations de déploiement	6
7. Considérations sur la sécurité	7
8. Remerciements	7
9. Considérations relatives à l'IANA	7
10. Références	7
10.1 Références normatives	7
10.2 Référence pour information	8
Adresse des auteurs 	8
Déclaration complète de droits de reproduction	8

 	1.	Introduction

Généralement quand BGP redémarre sur un routeur, tous les homologues BGP détectent que la session s'est arrêtée et à redémarré. Cette transition "arrêt/redémarrage" résulte en un "flottement d'acheminement" et cause un nouveau calcul des chemins de BGP, générant des mises à jour d'acheminement de BGP, et d'inutiles changements des tableaux de transmission. Cela pourrait s'étendre sur plusieurs domaines d'acheminement. De tels flottements d'acheminement peuvent créer des trous noirs transitoires d'acheminement et/ou des boucles transitoires de transmission. Cela consomme aussi des ressources sur le plan de contrôle des routeurs affectés par le flottement. À ce titre, ils nuisent aux performances globales du réseau.

Le présent document décrit un mécanisme pour BGP qui aiderait à minimiser les effets négatifs sur l'acheminement causés par le redémarrage de BGP. Un marqueur End-of-RIB (fin de RIB) est spécifié et peut être utilisé pour porter les informations de convergence d'acheminement. Une nouvelle capacité BGP, appelée "Capacité de redémarrage en douceur", est définie qui va permettre au locuteur BGP d'exprimer sa capacité à préserver l'état de transmission durant le redémarrage de BGP. Finalement, des procédures sont mentionnées pour conserver temporairement les informations d'acheminement à travers une terminaison/rétablissement d'une session TCP.

 	1.1	Spécification des exigences
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	2.	Marqueur de fin de RIB

Un message UPDATE sans informations d'accessibilité de couche réseau (NLRI, Network Layer Reachability Information) accessibles et des NLRI retirées vides est spécifié comme le marqueur "Fin de RIB" qui peut être utilisé par un locuteur BGP pour indiquer à son homologue l'achèvement de la mise à jour d'acheminement initial après l'établissement de la session. Pour la famille IPv4 d'adresses en envoi individuel, le marqueur Fin de RIB est un message UPDATE avec la longueur minimum [RFC4271]. Pour toute autre famille d'adresses, c'est un message UPDATE qui contient seulement l'attribut MP_UNREACH_NLRI [RFC2858] sans chemins supprimés pour ce couple <AFI, SAFI>.

Bien que le marqueur Fin de RIB soit spécifié pour les besoins du redémarrage en douceur de BGP, on note que la génération d'un tel marqueur à l'achèvement de la mise à jour initiale serait utile pour la convergence de l'acheminement en général, et donc cette pratique est recommandée.

De plus, il serait bénéfique pour la convergence de l'acheminement qu'un locuteur BGP puisse indiquer à son homologue d'en face qu'il va générer le marquer Fin de RIB, sans considération de sa capacité à préserver son état de transmission durant le redémarrage BGP. Cela peut être fait en utilisant la capacité de redémarrage en douceur décrite dans la section suivante.

 	3.	Capacité de redémarrage en douceur

La capacité de redémarrage en douceur est une nouvelle capacité BGP [RFC3392] qui peut être utilisée par un locuteur BGP pour indiquer sa capacité à préserver son état de transmission durant le redémarrage de BGP. Elle peut aussi être utilisée pour faire connaître à son homologue son intention de générer le marqueur Fin de RIB à l'achèvement de ses mises à jour initiales d'acheminement.

Cette capacité est définie comme suit :
Code de capacité : 64
Longueur de capacité : variable
Valeur de capacité : consiste en les champs "Fanions de redémarrage", "Temps de redémarrage", et 0 à 63 des triplets <AFI, SAFI, Fanions de famille d'adresse> comme suit :

Fanions de redémarrage (4 bits)	
Temps de redémarrage en secondes (12 bits)	
Identifiant de famille d'adresses (16 bits)	
Identifiant suivant de famille d'adresses (8 bits)	
Fanions pour la famille d'adresses (8 bits)	
...	
Identifiant de famille d'adresses (16 bits)	
Identifiant suivant de famille d'adresses (8 bits)	
Fanions pour la famille d'adresses (8 bits)	

L'utilisation et la signification des champs est la suivante :

Fanions de redémarrage :
Ce champ contient des fanions de bits relatifs au redémarrage.

 0 1 2 3
+-+-+-+-+
|R|Résv.|
+-+-+-+-+

Le bit de poids fort est défini comme bit d'état de redémarrage (R) qui peut être utilisé pour éviter une impasse possible causée par l'attente du marqueur Fin de RIB quand plusieurs locuteurs BGP en relation de pair à pair redémarrent l'un et l'autre. Lorsque établi (valeur 1) ce bit indique que le locuteur BGP a redémarré, et son homologue NE DOIT PAS attendre le marquer Fin de RIB de la part du locuteur avant d'annoncer les informations d'acheminement au locuteur.

Les bits restants sont réservés et DOIVENT être réglés à zéro par l'envoyeur et ignorés par le receveur.

Temps de redémarrage  : C'est le temps estimé (en secondes) que prendra le rétablissement de la session BGP après un redémarrage. Ce peut être utilisé pour accélérer la convergence de l'acheminement par son homologue au cas où le locuteur BGP ne revient pas après un redémarrage.

Identifiant de famille d'adresse (AFI, Address Family Identifier), Identifiant suivant de famille d'adresse (SAFI, Subsequent Address Family Identifier) : le AFI et le SAFI, pris en combinaison, indiquent que le redémarrage en douceur est pris en charge pour les chemins qui sont annoncés avec les mêmes AFI et SAFI. Les chemins peuvent être explicitement associés à un AFI et SAFI particuliers en utilisant le codage de la [RFC2858] ou implicitement associés à <AFI=IPv4, SAFI=Unicast> si on utilise le codage de la [RFC4271].

Fanions pour famille d'adresses : ce champ contient des bit de fanions relatifs aux chemins qui ont été annoncés avec les AFI et SAFI donnés.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|   Réservé   |
+-+-+-+-+-+-+-+-+

Le bit de poids fort est défini comme bit d'état de transmission (F) qui peut être utilisé pour indiquer si l'état de transmission pour les chemins qui ont été annoncés avec les AFI et SAFI donnés a bien été préservé durant le précédent redémarrage BGP. Quand il est établi (valeur 1) ce bit indique que l'état de transmission a été préservé.

Les bits restants sont réservés et DOIVENT être réglés à zéro par l'envoyeur et ignorés par le receveur.

Quand un envoyeur qui a cette capacité n'inclut aucun <AFI, SAFI> dans la capacité, cela signifie que l'envoyeur n'est pas capable de préserver son état de transmission durant le redémarrage BGP, mais qu'il prend en charge les procédures pour le locuteur receveur (comme défini au paragraphe 4.2 du présent document). Dans ce cas, la valeur du champ "Temps de redémarrage" annoncée par l'envoyeur n'est pas pertinente.

Un locuteur BGP NE DOIT PAS inclure plus d'une instance de la capacité de redémarrage en douceur dans l'annonce de capacités [RFC3392]. Si plus d'une instance de la capacité de redémarrage en douceur est portée dans l'annonce de capacités, le receveur de l'annonce DOIT ignorer toutes les instances de capacité de redémarrage en douceur sauf la dernière.

Inclure <AFI=IPv4, SAFI=unicast> dans la capacité de redémarrage en douceur n'implique pas que les informations d'acheminement IPv4 en envoi individuel devraient être portées en utilisant les extensions multi protocoles BGP [RFC2858] – elles pourraient être portées dans le champ NLRI du message BGP UPDATE.

 	4.	Fonctionnement

Un locuteur BGP PEUT annoncer la capacité de redémarrage en douceur pour une famille d'adresses à son homologue si il a la capacité de préserver son état de transmission pour la famille d'adresses quand BGP redémarre. De plus, même si le locuteur n'a pas la capacité de préserver son état de transmission pour toute famille d'adresses durant le redémarrage BGP, il est quand même recommandé que le locuteur annonce la capacité de redémarrage en douceur à son homologue (comme mentionné précédemment, ceci est fait en n'incluant aucun <AFI, SAFI> dans la capacité annoncée). Il y a deux raisons pour faire cela. La première est d'indiquer son intention de générer le marqueur Fin de RIB à l'achèvement de ses mises à jour initiales d'acheminement, car le faire serait utile pour la convergence d'acheminement en général. La seconde est d'indiquer sa prise en charge pour un homologue qui souhaite effectuer un redémarrage en douceur.

Le marqueur Fin de RIB DOIT être envoyé par un locuteur BGP à son homologue une fois qu'il a achevé la mise à jour initiale d'acheminement (incluant le cas où il n'y a pas de mise à jour à envoyer) pour une famille d'adresses après l'établissement de la session BGP.

On note que les procédures BGP normales DOIVENT être suivies quand la session TCP se termine du fait de l'envoi ou la réception d'un message BGP NOTIFICATION.

Une valeur par défaut suggérée pour l'heure de redémarrage est inférieure ou égale au HOLDTIME (temps de garde) porté dans OPEN.

Dans les paragraphes qui suivent, "le locuteur qui redémarre" se réfère à un routeur dont le BGP a redémarré, et "locuteur receveur" se réfère à un routeur qui échange du trafic avec le locuteur qui redémarre.

On considère que la capacité de redémarrage en douceur pour une famille d'adresses est annoncée par le locuteur qui redémarre, et est comprise par le locuteur receveur, et qu'une session BGP entre eux est établie. Les paragraphes qui  suivent détaillent les procédures qui DOIVENT être suivies par le locuteur qui redémarre ainsi que par le locuteur receveur une fois que le locuteur qui redémarre a redémarré.

 	4.1	Procédures pour le locuteur qui redémarre
Quand le locuteur qui redémarre redémarre, il DOIT conserver, si possible, l'état de transmission pour les chemins BGP dans la Loc-RIB et DOIT les marquer comme périmés. Il NE DOIT PAS faire de différence entre les informations périmées et les autres durant la transmission.

Pour rétablir la session avec son homologue, le locuteur qui redémarre DOIT établir le bit "État de redémarrage" dans la capacité de redémarrage en douceur du message OPEN. Sauf permis via configuration, le bit "État de transmission" pour une famille d'adresses dans la capacité ne peut être établi que si l'état de transmission a été préservé pour cette famille d'adresses durant le redémarrage.

Une fois rétablie la session entre le locuteur qui redémarre et le locuteur receveur, le locuteur qui redémarre va recevoir et traiter les messages BGP provenant de ses homologues. Cependant, il DOIT différer le choix de chemin pour une famille d'adresses jusqu'à ce que (a) il ait reçu le marqueur Fin de RIB de tous ses homologues (à l'exclusion de ceux dont le bit "État de redémarrage" est établi dans les capacités reçues et de ceux qui n'annoncent pas la capacité de redémarrage en douceur) ou que (b) le temporisateur de retard de choix Selection_Deferral_Timer auquel on se réfère ci-dessous, soit arrivé à expiration. On note qu'avant le choix de chemins, le locuteur n'a pas de chemin à annoncer à son homologue et pas d'état de transmission de chemins à mettre à jour.

Dans des situations où le protocole de routeur intérieur (IGP, Interior Gateway Protocol) et BGP ont tous deux redémarré, il peut être avantageux d'attendre que IGP converge avant que le locuteur BGP effectue le choix de chemin.

Après que le locuteur BGP a effectué le choix de chemin, l'état de transmission du locuteur DOIT être mis à jour et toutes les informations d'état précédemment marquées périmées DOIVENT être supprimées. Le Adj-RIB-Out peut alors être annoncé à ses homologues. Une fois que la mise à jour initiale est achevée pour une famille d'adresses (incluant le cas où il n'y a pas de mise à jour d'acheminement à envoyer) le marqueur Fin de RIB DOIT être envoyé.

Pour mettre une limite supérieure à la durée pendant laquelle un routeur diffère de choisir sa route, une mise en œuvre DOIT prendre en charge un temporisateur (configurable) qui impose cette limite supérieure. Ce temporisateur est appelé "temporisateur de retard de choix". La valeur de ce temporisateur devrait être assez grande pour qu'elle fournisse à tous les homologues du locuteur qui redémarre assez de temps pour lui envoyer tous les chemins.

Si on veut n'appliquer le redémarrage en douceur que quand le redémarrage est planifié (par opposition à des redémarrages à la fois planifiés et non planifiés) une façon de le faire serait de régler le bit État de transmission à 1 après un redémarrage planifié, et à 0 dans tous les autres cas. Les autres approches pour faire cela sortent du domaine d'application de ce document.

 	4.2	Procédures pour le locuteur receveur
Quand le locuteur qui redémarre redémarre, le locuteur receveur peut détecter ou non la terminaison de la session TCP avec le locuteur qui redémarre, selon la mise en œuvre sous-jacente de TCP, si la [RFC2385] est utilisée ou non, et les circonstances spécifiques du redémarrage. Au cas où il ne détecte pas la terminaison de la vieille session TCP et considère que la session BGP est toujours établie, il DOIT traiter la connexion ouverte suivante avec l'homologue comme l'indication de la terminaison de la vieille session TCP et agir en conséquence (quand la capacité de redémarrage en douceur a été reçue de l'homologue). Voir à la Section 8 la description de ce comportement en termes d'automate à états finis BGP.

"Agir en conséquence" dans ce contexte signifie que la session TCP précédente DOIT être close, et la nouvelle conservée.  Noter que ce comportement diffère du comportement par défaut, comme spécifié au paragraphe 6.8 de la [RFC4271]. Comme la connexion précédente est considérée être terminée, aucun message NOTIFICATION ne devrait être envoyé – la session TCP précédente est simplement close.

Quand le locuteur receveur détecte la terminaison de la session TCP pour une session BGP avec un homologue qui a annoncé la capacité de redémarrage en douceur, il DOIT conserver les chemins reçus de l'homologue pour toutes les familles d'adresses qui ont été précédemment reçues dans la capacité de redémarrage en douceur et DOIT les marquer comme des informations d'acheminement périmées. Pour traiter des redémarrages consécutifs possibles, un chemin (provenant de l'homologue) précédemment marqué périmé DOIT être supprimé. Le routeur NE DOIT PAS différencier entre informations d'acheminement périmées et les autres durant la transmission.

Dans le rétablissement de session, le bit "État de redémarrage" dans la capacité de redémarrage en douceur du message OPEN envoyé par le locuteur receveur NE DOIT PAS être établi sauf si le locuteur receveur a redémarré. La présence et l'établissement du bit "État de transmission" pour une famille d'adresse dépend de l'état et de la configuration réels de transmission.

Si la session n'est pas rétablie dans le "Temps de redémarrage" que l'homologue a annoncé précédemment, le locuteur receveur DOIT supprimer tous les chemins périmés provenant de l'homologue qu'il conservait.

Un locuteur BGP pourrait avoir un moyen de déterminer si l'état de transmission de son homologue est toujours viable, par exemple par la détection de transmission bidirectionnelle [RFC5880] ou par les informations de surveillance de couche 2. Les spécificités de tels mécanismes sortent du domaine d'application de ce document. Dans le cas où il détermine que l'état de transmission de son homologue n'est pas viable avant le rétablissement de la session, le locuteur PEUT supprimer tous les chemins périmés qu'il conservait en provenance de l'homologue.

Une fois la session rétablie, si le bit "État de transmission" n'est pas établi pour une famille d'adresses spécifique dans la capacité de redémarrage en douceur nouvellement reçue, ou si une famille d'adresses spécifique n'est pas incluse dans la capacité de redémarrage en douceur nouvellement reçue, ou si la capacité de redémarrage en douceur n'est pas reçue du tout dans la session rétablie, le locuteur receveur DOIT alors immédiatement supprimer tous les chemins périmés qu'il conservait en provenance de l'homologue pour cette famille d'adresses.

Le locuteur receveur DOIT envoyer le marqueur Fin de RIB une fois qu'il a achevé la mise à jour initiale pour une famille d'adresses (incluant le cas où il n'y a pas de chemin à envoyer) à l'homologue.

Le locuteur receveur DOIT remplacer les chemins périmés par les mises à jour d'acheminement reçues de l'homologue. Une fois le marqueur Fin de RIB reçu de l'homologue pour une famille d'adresses, il DOIT immédiatement supprimer tous les chemins provenant de l'homologue qui sont encore marqués périmés pour cette famille d'adresses.

Pour mettre une limite supérieure à la durée pendant la quelle un routeur conserve les chemins périmés, une mise en œuvre PEUT prendre en charge un temporisateur (configurable) qui impose cette limite supérieure.

 	5.	Changements à l'automate à états finis de BGP

Comme mentionné ci-dessus dans "Procédures pour le locuteur receveur", la présente spécification modifie l'automate à états finis de BGP.

Les modifications spécifiques de l'automate à états au paragraphe 8.2.2 de la [RFC4271] sont les suivantes  :

Dans l'état Repos, faire les changements suivants  :

Remplacer ce texte :
-	initialiser toutes les ressources BGP pour la connexion homologue,
par
-	initialiser toutes les ressources BGP pour la connexion homologue, autres que les ressources exigées pour conserver les chemins conformément à la Section "Procédures pour le locuteur receveur" de cette spécification (de redémarrage en douceur),

Dans l'état Établi, faire les changements suivants  :
Remplacer ce texte :
En réponse à une indication que la connexion TCP est établie avec succès (événement 16 ou 17) la seconde connexion DEVRA être tracée jusqu'à ce qu'elle envoie un message OPEN.
par
Si la capacité de redémarrage en douceur avec un ou plusieurs AFI/SAF n'a pas encore été reçue pour la session, alors en réponse à une indication qu'une connexion TCP est établie avec succès (événement 16 ou 17) la seconde connexion DEVRA être tracée jusqu'à ce quelle envoie un message OPEN.

Cependant, si la capacité de redémarrage en douceur avec un ou plusieurs AFI/SAFI a été reçue pour la session, alors en réponse à l'événement 16 ou 17 le système local  :
-	conserve tous les chemins associés à cette connexion conformément à la Section "Procédures pour le locuteur receveur" de cette spécification (redémarrage en douceur),
-	libérer toutes les autres ressources BGP,
-	éliminer la connexion TCP associée à la session ESTABLISHED,
-	initialiser toutes les ressources BGP pour la connexion homologue, autres que celles nécessaires pour conserver les chemins conformément à la Section "Procédures pour le locuteur receveur" de cette spécification,
-	régler le compteur d'essais de connexion à zéro,
-	lancer le temporisateur d'essais de connexion à sa valeur initiale, et
-	changer son état en Connect.

Remplacer ce texte :
Si le système local reçoit un message NOTIFICATION (événement 24 ou 25) ou un TcpConnectionFails (événement 18) du TCP sous-jacent, le système local:
-	règle le temporisateur d'essais de connexion à zéro,
-	supprime tous les chemins associés à cette connexion,
-	libère toutes les ressources BGP,
-	élimine la connexion TCP,
-	incrémente de 1 le compteur d'essais de connexion,
-	change son état en Repos.
par
Si le système local reçoit un message NOTIFICATION (événement 24 ou 25) ou si le système local reçoit un TcpConnectionFails (événement 18) du TCP sous-jacent et si la capacité de redémarrage en douceur avec un ou plusieurs AFI/SAFI n'a pas été reçue pour la session, le système local :
-	règle le temporisateur d'essais de connexion à zéro,
-	supprime tous les chemins associés à cette connexion,
-	libère toutes les ressources BGP,
-	élimine la connexion TCP,
-	incrémente de 1 le compteur d'essais de connexion,
-	change son état en Repos.

Cependant, si le système local reçoit un TcpConnectionFails (événement  18) du TCP sous-jacent, et si la capacité de redémarrage en douceur avec un ou plusieurs AFI/SAFI a été reçue pour la session, le système local :
-	règle le temporisateur d'essais de connexion à zéro,
-	conserve tous les chemins associés à cette connexion conformément à la Section "Procédures pour le locuteur receveur" de cette spécification (redémarrage en douceur),
-	libère toutes les autres ressources BGP,
-	élimine la connexion TCP,
-	incrémente de 1 le compteur d'essais de connexion, et
-	change son état en Repos.

 	6.	Considérations de déploiement

Bien que les procédures décrites dans ce document aident à minimiser les effet du flottement d'acheminement, il est noté que quand un routeur BGP à capacité de redémarrage en douceur redémarre, ou si il redémarre sans préserver son état de transmission (par exemple à cause d'une panne d'alimentation) il y a un potentiel de boucles transitoires d'acheminement ou de trou noir dans le réseau si les informations d'acheminement changent avant que les routeurs impliqués ait achevé les mises à jour et la convergence de l'acheminement. Aussi, selon la topologie du réseau, si tous les locuteurs IBGP n'ont pas la capacité de redémarrage en douceur, il pourrait y avoir une exposition accrue aux boucles transitoires d'acheminement ou aux trous noirs lorsque les procédures de redémarrage en douceur sont appliquées.

L'heure de redémarrage, la limite supérieure pour la conservation des chemins, et la limite supérieure pour différer le choix de chemin devront être réglées lorsque on aura plus d'expérience de déploiement.

Finalement, on note que les avantages du déploiement du redémarrage en douceur de BGP dans un système autonome dont les IGP et BGP sont étroitement couplés (c'est-à-dire, BGP et les IGP vont tous redémarrer) et les IGP qui n'ont pas de capacité de redémarrage en douceur similaire sont réduits par rapport au scénario où les IGP ont bien la capacité de redémarrage en douceur.

 	7.	Considérations sur la sécurité

Dans la mesure où avec cette proposition une nouvelle connexion peut causer la terminaison d'une vieille, elle peut être vue comme ouvrant la porte aux attaques de déni de service. Cependant, on notera que BGP non authentifié est déjà connu pour être vulnérable aux dénis de service par des attaques sur le transport TCP. Le transport TCP est couramment protégé par l'utilisation de la [RFC2385]. Une telle authentification protège également contre le déni de service par des nouvelles connexions parasites.

Si un attaquant est capable de réussir à ouvrir une connexion TCP en se faisant passer pour un homologue légitime, la connexion de l'attaquant va remplacer la connexion légitime, donnant éventuellement à l'attaquant la possibilité d'annoncer des chemins fallacieux. On note cependant, que la fenêtre pour une telle attaque d'insertion de chemin est petite car par le fonctionnement normal du protocole, l'homologue légitime va ouvrir une nouvelle connexion, causant à son tour la terminaison de la connexion de l'attaquant. Donc cette attaque se réduit à une forme de déni de service.

On en conclut que cette proposition ne change pas le modèle de sécurité sous-jacent (et les problèmes) de BGP-4.

On note aussi que les mises en œuvre peuvent permettre l'utilisation du redémarrage en douceur sous le contrôle de la configuration. Si le redémarrage en douceur n'est pas activé, le modèle de sécurité sous-jacent de BGP-4 n'est naturellement pas changé.

 	8.	Remerciements

Les auteurs tiennent à remercier Bruce Cole, Lars Eggert, Bill Fenner, Eric Gray, Jeffrey Haas, Sam Hartman, Alvaro Retana, Pekka Savola Naiming Shen, Satinder Singh, Mark Townsley, David Ward, Shane Wright, et Alex Zinin de leur relecture et commentaires.

 	9.	Considérations relatives à l'IANA

Le présent document définit une nouvelle capacité de BGP – capacité de redémarrage en douceur. Le code de capacité pour la capacité de redémarrage en douceur est 64.

 	10.	Références
 	10.1	Références normatives

[IANA-AFI]	http://www.iana.org/assignments/address-family-numbers 

[IANA-SAFI]	http://www.iana.org/assignments/safi-namespace 

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2385]	A. Heffernan, "Protection des sessions de BGP via l'option de signature MD5 de TCP", août 1998. (P.S. ; MàJ par la RFC6691) ; remplacée par RFC5925)

[RFC2858]	T. Bates et autres, "Extensions multi protocoles pour BGP-4", juin 2000. (Obsolète, voir RFC4760) (P.S.)

[RFC4271]	Y. Rekhter, T. Li et S. Hares, "Protocole de routeur frontière version 4 (BGP-4)", janvier 2006. (D.S.) (MàJ par RFC6608, RFC8212)

 	10.2	Référence pour information

[RFC5880]	D. Katz, D. Ward, "Détection de transmission bidirectionnelle (BFD)", juin 2010. (P. S. ; MàJ par RFC7880)

 	Adresse des auteurs 

Srihari R.  Sangli	Yakov Rekhter	Rex Fernando	
Cisco Systems, Inc.	Juniper Networks, Inc.	Juniper Networks, Inc.	
mél : rsrihari@cisco.com 	mél : yakov@juniper.net 	mél : rex@juniper.net 	

John G.  Scudder	Enke Chen	
Juniper Networks, Inc.	Cisco Systems, Inc.	
mél : jgs@juniper.net 	mél :  enkechen@cisco.com 	

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2007).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administatif (IASA) de l'IETF.