A quoi servent les serveurs de routes ?

Qu'est-ce qu'un serveur de routes ?

Les serveurs de routes (ou SR / Route Servers abrégés en RS) sont des serveurs avec lesquels les clients peuvent établir des sessions BGP afin de centraliser les routes et de réduire la gestion du réseau.

Un serveur de routes n'est pas un routeur. Aucune donnée ne transite par le SR (ou RS) : il est uniquement utilisé pour agréger les informations BGP. Par exemple, même si deux clients n'établissent des sessions BGP qu'avec le SR (ou RS), ils pourront échanger des informations de routage par son intermédiaire, mais les données circuleront directement entre leurs routeurs car ils sont sur le même réseau local (LAN).

Comme vous pouvez le voir sur ce schéma, le plan de contrôle (Control-plane) et le plan de données (Data-plane) sont distincts.

Quels avantages ?

• Moins de sessions BGP à configurer.
• Un moyen simple et rapide pour obtenir une multitude de routes.
• Facilement paramétrable et ajustable grâce aux communautés BGP.
• Pas besoin de conclure de multiples accords d'appairage (peering) avec d'autres clients.

Cette approche « Une seule session pour les dominer toutes » (One session to rule them all) peut vous faire gagner beaucoup de temps !

Veuillez garder à l'esprit que certains réseaux préfèrent établir directement un appairage (peering) BGP bilatéral et peuvent ne pas utiliser le SR (ou RS). L'adoption du SR (ou RS) par les clients France-IX est indiquée dans la liste des clients de France-IX. Alternativement, vous devrez envoyer à chaque réseau une demande d'appairage (peering request) à leur adresse e-mail de contact pour l'appairage.

Fonctionnalités et sécurité

Les SR (ou RS) de France-IX présentent les fonctionnalités suivantes :

• Sélection et annonce du meilleur chemin BGP (BGP Path) pour chaque route.
• Ne pas modifier l'AS_PATH (l'ASN du SR (ou RS) n'est pas ajouté à l'AS_PATH).
• Ne pas modifier l'adresse IP du Next-Hop (le trafic circule directement entre les routeurs).
• Ne pas interpréter les communautés bien connues (well-known communities) : (NO-EXPORT, NO_ADVERTISE, etc.) ces communautés seront annoncées aux pairs.
• Prise en charge l'ADD-PATH (Transmission uniquement Tx-only), ce qui signifie que votre routeur recevra plusieurs routes pour la même destination réseau s'il utilise cette capacité.
• Prise en charge de l'annonce sélective (avec des communautés BGP spécifiques).
• Effectuer certains contrôles de sécurité (voir ci-dessous).
• Prise en charge des Rôles BGP (RFC9234) : Les routes ayant l'attribut BGP OTC (Only To Customer) sont rejetées.
• Prise en charge, sur demande, de BFD (Bidirectional Forwarding Detection - Détection de Transmission Bidirectionnelle).

ASN des Serveurs de Routes (ou RS) sur les Réseaux Locaux de peering France-IX

Signalisation des serveurs de routes et marquage de préfixes

Les peers peuvent utiliser des communautés BGP pour signaler une annonce sélective et les serveurs de routes utilisent des communautés BGP pour marquer diverses informations concernant les routes ré-annoncées.Les communautés BGP de style RFC8092 (également appelées « Large BGP communities ») sont la méthode de signalisation privilégiée et, à moyen-long terme, seront la seule méthode de signalisation entre les serveurs de routes et les peers. Nous suivons les lignes directrices d'Euro-IX pour l'utilisation des Large BGP communities : https://www.euro-ix.net/en/forixps/large-bgp-communities/Les communautés BGP de style RFC1997 (également appelées « Classic BGP communities ») sont toujours prises en charge sur les serveurs de routes ayant un ASN sur 16 bits (inférieur à 65535), et uniquement pour la signalisation concernant d'autres ASN sur 16 bits ainsi que la communauté « Blackhole » bien connue (65535:666, telle que spécifiée dans la RFC7999). Ce support est susceptible de disparaître dans le futur, merci donc de préférer l’utilisation des “Large BGP Communities” (RFC8092).

Annonces sélectives

Par défaut, lors de l'annonce d'une route à un SR (ou RS), chaque peer reçoit cette route. Alternativement, un peer peut choisir d'annoncer (ou non) cette route à des peers sélectionnés à l'aide de communautés BGP :

• RS-ASN:0:0 - N'ENVOYER la route à AUCUN pair, sauf indication contraire explicite
• RS-ASN:0:PeerASN - NE PAS ENVOYER la route à l'ASN de pair spécifié
• RS-ASN:1:0 - Comportement par défaut : ENVOYER la route à tous les peers
• RS-ASN:1:PeerASN - ENVOYER la route à l'ASN de pair spécifié, même si RS-ASN:0:0 a été spécifié

Changement des propriétés de la route

• RS-ASN:101:PeerASN - Préfixer 1 fois lors de l'annonce à PeerASN
• RS-ASN:102:PeerASN - Préfixer 2 fois lors de l'annonce à PeerASN
• RS-ASN:103:PeerASN - Préfixer 3 fois lors de l'annonce à PeerASN
• RS-ASN:901:PeerASN - Définir le MED à 50 lors de l'annonce à PeerASN
• RS-ASN:902:PeerASN - Définir le MED à 100 lors de l'annonce à PeerASN
• RS-ASN:903:PeerASN - Définir le MED à 200 lors de l'annonce à PeerASN

Communautés définies par les serveurs de routes

Les serveurs de routes marquent les routes avec des communautés BGP large/RFC8092 afin de signaler le résultat des contrôles effectués. Les communautés suivantes sont définies par les serveurs de routes :

Sur les routes ré-annoncées aux peers :

• RS-ASN:1000:1 - RPKI_VALID : ROA valide trouvé
• RS-ASN:1000:2 - RPKI_NOTFOUND : Aucun ROA trouvé
• RS-ASN:1001:1 - IRR_VALID : ASN d'origine dans le Peer AS-Set et validation de l'origine (IRR ou RPKI) réussie
• RS-ASN:1001:6 - Aucun objet IRR « Route: » présent. Si vous recevez la route, elle possède une signature ROA valide

Uniquement sur le looking-glass, pour les routes filtrées :

• RS-ASN:1000:4 - RPKI_INVALID : ROA trouvé, mais ne correspond pas à l'ASN d'origine ou à la taille du préfixe
• RS-ASN:1001:4 - Non trouvé dans la base de données IRR (générique)
• RS-ASN:1001:5 - ASN d'origine non trouvé dans l'AS-SET des pairs annonçants
• RS-ASN:1011:9 - FILTERED : IRR non trouvé ou invalide
• RS-ASN:1011:10 - FILTERED : ASN d'origine non trouvé dans l'AS-SET des pairs annonçants
• RS-ASN:1011:11 - FILTERED : Aucun objet IRR « route: » et aucune ROA valide
• RS-ASN:1011:13 - FILTERED : RPKI_INVALID
• RS-ASN:1011:14 - FILTERED : ASN « Never via RS » trouvé dans l'AS-Path

Sécurité

Afin d'atténuer certaines erreurs dues à des doigts maladroits (grosses ou petites erreurs de configuration), les SR (ou RS) de France-IX effectuent les vérifications suivantes :

• Longueur de préfixe : Le masque de réseau IPv4 doit être ≥ /8 et ≤ /24 ; le masque de réseau IPv6 doit être ≥ /19 et ≤ /48.
• RFC5735 : Filtrage des préfixes martiens/bogon pour IPv4.
• RFC5156 : Filtrage des préfixes martiens/bogon pour IPv6.
• RFC6996 : ASN privé : aucun ASN privé dans l'AS_PATH.
• Mauvais NEXT_HOP : Vérification que l'IP du next-hop dans la mise à jour BGP est l'IP du pair annonçant.
• Imposer le premier AS (Enforce First AS) : Vérification que le premier AS de l'AS-PATH est l'AS du pair.
• RFC9234 : Notre rôle est RS_Server, le rôle des peers est RS_Client, et nous filtrons les routes contenant déjà l'attribut OTC (Only To Customer).
• Max-prefix : Limite le nombre de préfixes appris par pair sur le SR (ou RS) (interrompt la session BGP si le seuil est dépassé)

Toute route non conforme est rejetée.

Blackholing

Afin d'aider nos clients à lutter contre les attaques DDoS (Distributed Denial of Service - Déni de service distribué), un service de BLACKHOLING est disponible. Ce service permet aux peers d'annoncer des routes avec des communautés BGP spécifiques afin de bloquer le trafic malveillant.

Pour l'utiliser, configurez la communauté 65535:666 dans votre politique d'exportation pour les routes concernées (voir RFC7999).

Veuillez noter que toute route marquée avec la communauté de BLACKHOLING doivent aussi respecter les règles suivantes:

• La taille du préfixe doit être entre /24 et /32 (IPv4) et entre /64 et /128 (IPv6)
• L’ASN qui l’annonce doit être autorisé à annoncer une route moins spécifique couvrant le préfixe BLACKHOLE.

Filtrage RPKI / ROA et IRR

La définition des ROA et l'enregistrement des préfixes sont expliqués sur la page RIPE de gestion et de certification des ressources.

Les serveurs de routes de France-IX filtrent les routes en fonction de leur statut de validation IRR et RPKI/ROA. La validation RPKI/ASPA sera active dès que les documents de référence côté IETF seront stabilisés. Nous utilisons plusieurs IRR en plus de la base de données RIPE et plusieurs instances locales des validateurs RPKI pour garantir l'exactitude des données.

Processus de validation des routes:

• Le premier ASN dans le chemin doit etre l’AS du peer qui annonce la route
• Le “next-hop” doit etre l’adresse IP (v4 ou v6) du peer sur le LAN de peering
• La taille du prefixe est verifie comme suit:
  • Routes IPv4 : entre /8 et /24 (inclus)
  • Routes IPv6 : entre /19 et /48 (inclus)
  • Blackhole IPv4 : entre /24 et /32 (inclus)
  • Blackhole IPv6 : entre /64 et /128 (inclus)
• Les routes ne doivent PAS contenir des ASN privés ou “bogon” dans le chemin (RFC6996)
• Les “bogons” ne sont pas autorisés (RFC5735, RFC1918, RFC6598, RFC5156)
• Les routes ne doivent PAS contenir dans l’AS-path des ASN s'étant déclarés comme “Never via RS” dans PeeringDB
• RPKI : Les routes doivent être ROA “valide” ou “inconnu”. Les routes ROA “Invalide” ne sont pas autorisées.
• IRR : L’ASN d’origine (dernier dans l’AS-path) doit être dans l’AS-Set du peer qui l’annonce (ou être l’ASN du peer lui-même)
• IRR : Les routes avec statut ROA “Inconnu” doivent avoir des objets “route:” ou “route6:” dans la base IR associée (faisant autorité).

Pour les test IRR, les sources suivants sont utilises:

• Ceux associes aux IRR, faisant autorité : RIPE, APNIC, LACNIC, AFRINIC, ARIN
• Les IRR “nationaux” : JPIRR, IDNIC
• Pour des raisons historiques encore d'actualité, RADB est encore utilisé dans certains cas.

Best practices

• Veuillez spécifier « no bgp enforce-first-as » (pour IOS et IOS-XE) ou « bgp enforce-first-as disable » (pour IOS-XR) lors de la configuration avec le SR (ou RS) (uniquement si vous utilisez des équipements Cisco, car les SR n'ajoutent pas leur ASN dans l'AS_PATH).
• Définissez la limite de préfixes maximale avec des valeurs appropriées (et n'oubliez pas de les mettre à jour régulièrement, le nombre de routes continue d'augmenter). Utilisez les entrées PeeringDB des ASN des serveurs de routes.
• Si vous souhaitez filtrer la longueur des préfixes, veuillez noter que les préfixes avec la communauté BLACKHOLE sont acceptés jusqu'à /32 en IPv4 et /128 en IPv6 sur nos SR (ou RS).
• Filtrez nos préfixes IXP (37.49.232.0/24, 37.49.236.0/22, 77.95.71.0/24, 77.95.66.0/23, 185.1.144.0/24, 193.105.232.0/24, 91.213.236.0/24, 2001:7f8:54::/48, 2001:7f8:47::/48 et les plus spécifiques) de tous les pairs/transits BGP et n'annonce PAS ces routes vous-mêmes.
• Créez des ROA pour vos préfixes sur votre portail LIR (par exemple, https://dashboard.rpki.ripe.net/#overview pour les réseaux européens).
• Remplissez et maintenez à jour votre objet ASN / AUT-NUM (et éventuellement AS-SET).
• Créez si nécessaire et maintenez à jour dans vos entrées PeeringDB les valeurs du max-prefix et l’AS-Set.

Voici quelques exemples qui devraient être définies dans votre objet AUT-NUM (ASxxxx peut être votre numéro d'AS ou le nom de votre AS-SET) :

• Pour les familles d'adresses IPv4 et IPv6 (choisir un seul):
  • export: to AS51706 announce ASxxxx
  • export-via: AS51706 to AS-ANY announce ASxxxx
  • mp-export: afi ipv4.unicast,ipv6.unicast to AS51706 announce ASxxxx
• Pour la famille d'adresses IPv4 uniquement (choisir un seul):
  • export-via: afi ipv4.unicast AS51706 to AS-ANY announce ASxxxx
  • mp-export: afi ipv4.unicast to AS51706 announce ASxxxx
• Pour la famille d'adresses IPv6 uniquement (choisir un seul):
  • export-via: afi ipv6.unicast AS51706 to AS-ANY announce ASxxxx
  • mp-export: ipv6.unicast to AS51706 announce ASxxxx

Pour les serveurs de routes des autres peering LANs, remplacez AS51706 par l'ASN approprié (précédé de « AS » - au format ASnnnnn).

Si vous souhaitez filtrer les routes collectées à partir des SR (ou RS) de France-IX, vous pouvez filtrer les préfixes en utilisant les AS-Sets spécifiés ci-dessus dans le tableau avec les ASN des serveurs de routes.