🛰️ BGP (Border Gateway Protocol)

2. EGP (Exterior Gateway Protocol) - Le Routage *Externe*

• Exemple : BGP (c'est le seul EGP utilisé aujourd'hui).
• Rôle : Gérer le routage **entre** des réseaux indépendants (entre des "Autonomous Systems").
• Analogie : C'est le **Service Postal Mondial**. Il ne sait pas comment aller au "Bureau B" de votre entreprise. Il sait seulement comment amener une lettre du "Siège Social d'Orange (Paris)" au "Siège Social de Google (Mountain View)".
• Philosophie : **Méfiance & Échelle.**
  • Méfiance : Vous ne faites **PAS** confiance à votre concurrent (Google). Vous ne voulez pas lui annoncer toutes vos routes internes. Vous ne lui annoncez que ce qui est nécessaire.
  • Échelle (Scalability) : BGP est conçu pour gérer la **"Table de Routage Globale" (DFZ - Default-Free Zone)**, qui contient plus d'1 million de préfixes (routes). Il est plus lent, mais incroyablement robuste et "léger" (il n'envoie que les mises à jour, pas des "hello" constants).

3. BGP = Routage par Politique (Policy-Based Routing)

C'est le concept le plus important à comprendre.

Un IGP (OSPF) prend des décisions basées sur la **technique** (Quel est le chemin le plus *rapide* ?).

Un EGP (BGP) prend des décisions basées sur la **politique (Policy)** (Quel est le chemin le plus *rentable* ou *stratégique* ?).

BGP n'est pas un protocole de "routage", c'est un protocole "d'accessibilité" (reachability). Il ne dit pas "voici le meilleur chemin", il dit "voici les chemins que je connais, et voici les *attributs* (les 'politiques') qui leur sont associés". C'est le "cerveau" (voir 3.2) qui applique ensuite ces politiques.

2. Peering (Relation de Partenariat)

• Relation : Deux AS de taille similaire (ex: Orange et Free) qui s'accordent pour échanger du trafic **gratuitement**.
• Contrat : "Je (Orange) t'envoie mon trafic (pour tes clients), tu (Free) m'envoies ton trafic (pour mes clients). Nous n'avons plus besoin de payer un Fournisseur de Transit (ex: Cogent) pour parler entre nous." C'est du "Settlement-Free Peering".
• Échange de Routes BGP :
  • Orange annonce à Free *uniquement* ses préfixes clients (et les siens).
  • Free annonce à Orange *uniquement* ses préfixes clients (et les siens).
• Règle d'Or : Orange n'annonce **PAS** à Free les routes qu'il a apprises de son *autre* peer (ex: Google) ou de son *propre* fournisseur de Transit. C'est une relation "non-transitive".

3. Le Lieu : IXP (Internet Exchange Point)

Où le "Peering" a-t-il lieu ? Dans un data center neutre appelé **IXP** (ex: France-IX à Paris, DE-CIX à Francfort).

• Concept : L'IXP est un simple **switch (commutateur) L2** (ou un ensemble de switches).
• Mécanisme : Au lieu de tirer 100 câbles (Orange-Free, Orange-Google, Free-Google...), les 100 AS se connectent (1 câble chacun) au switch de l'IXP.
• BGP (Route Server) : Ils établissent des sessions BGP (peering) entre eux, soit directement (N:N), soit (plus efficacement) en "peerant" tous avec le **Route Server** de l'IXP, qui agit comme un "Route Reflector" (voir 2.1) centralisé pour tous les membres.

2. iBGP (Internal BGP) - Le Problème (Full-Mesh)

• Objectif : Propager les routes (apprises par eBGP) **à l'intérieur** de son propre AS.
• Scénario :
  1. Mon AS (64512) a 3 routeurs de bordure : R1 (Paris), R2 (Londres), R3 (New York).
  2. R1 (Paris) apprend la route de Google (8.8.8.0/24) via eBGP (de son peer).
  3. R1 doit maintenant informer R2 (Londres) et R3 (New York) de cette route, au cas où le lien de R1 tombe.
  4. Cette communication (R1 -> R2, R1 -> R3) se fait en **iBGP**.
• Configuration (Cisco) :

  router bgp 64512
   neighbor 2.2.2.2 remote-as 64512
   neighbor 3.3.3.3 remote-as 64512

  (Les "remote-as" sont mon *propre* ASN).
• Règle (Split-Horizon BGP) : Pour éviter les boucles de routage *internes*, BGP a une règle stricte :
  "Une route apprise d'un voisin iBGP ne sera **JAMAIS** propagée à un autre voisin iBGP."
• Problème (N² Full-Mesh) :
  • Si R1 (Paris) envoie la route à R2 (Londres) (via iBGP).
  • R2 **NE PEUT PAS** la re-propager à R3 (New York) (à cause du split-horizon).
  • Conséquence : Pour que R3 connaisse la route de R1, R1 doit avoir une session iBGP **directe** avec R3.
  • Conclusion : Dans un réseau iBGP, **tous les routeurs** doivent avoir une session iBGP **avec tous les autres routeurs** (une "Full-Mesh").
  • Scalabilité : 10 routeurs = 45 sessions (`n(n-1)/2`). 100 routeurs = 4950 sessions. C'est ingérable.

3. iBGP - La Solution (Route Reflectors)

Pour résoudre le problème de la "Full-Mesh", on utilise des **Route Reflectors (RR)** (Réflecteurs de Route).

• Concept : On désigne un (ou deux, pour la redondance) routeur(s) comme "Route Reflector".
• Règle : Le RR est le *seul* routeur qui est autorisé à **enfreindre la règle du split-horizon iBGP**.
• Architecture (Hub & Spoke) :
  • Les autres routeurs (les "Clients") n'ont plus besoin d'une "Full-Mesh".
  • Chaque routeur "Client" n'établit qu'**une seule** session iBGP : vers le Route Reflector.
• Flux de Route :
  1. R1 (Client) apprend une route eBGP.
  2. R1 l'annonce (via iBGP) au RR.
  3. Le RR reçoit la route (iBGP) de R1.
  4. Le RR **"reflète"** (re-propage) cette route (iBGP) à R2, R3, R4...

Attributs (Clustering) : Pour éviter les boucles *entre* les RRs (s'il y en a plusieurs), le RR ajoute deux attributs : `CLUSTER_ID` (l'ID du RR) et `ORIGINATOR_ID` (le Routeur-ID du Client qui a originé la route).

2. Le Protocole "Path Vector" (Vecteur de Chemin)

BGP n'est ni "Distance Vector" (RIP) ni "Link State" (OSPF).

• Distance Vector (Ex: RIP) : Ne connaît que la *métrique* (distance). "Pour aller à X, c'est 5 sauts. J'envoie à mon voisin." (Sujet aux boucles de routage).
• Link State (Ex: OSPF) : Connaît la *topologie complète* (la carte) de son propre réseau.
• Path Vector (BGP) : Ne connaît pas la topologie complète d'Internet (trop gros). Il connaît le **chemin complet des AS** pour atteindre une destination.

L'Attribut `AS_PATH`

C'est l'attribut le plus important de BGP. Il a deux fonctions :

Fonction 1 : La "Carte" (Policy)

L'AS_PATH est la liste (ordonnée) des ASNs qu'un paquet doit traverser. L'algorithme "Best Path" (voir 3.2) **préfère le chemin AS_PATH le plus court** (toutes choses étant égales par ailleurs).

R1# show ip bgp 8.8.8.0
BGP routing table entry for 8.8.8.0/24
  Paths: 2 available
  
  (Path 1)
    3356 15169
    From: 1.1.1.1 (Peer A)
    Metric: 100
  
  (Path 2)
    701 209 15169
    From: 2.2.2.2 (Peer B)
    Metric: 50

Ici, le routeur R1 choisira le "Path 1" car son `AS_PATH` (longueur 2) est plus court que le "Path 2" (longueur 3), *même si* le "Path 2" a une meilleure métrique (50 < 100).

Fonction 2 : L'Anti-Boucle (Loop Prevention)

C'est le mécanisme anti-boucle **fondamental** de BGP.

1. AS 64512 annonce son préfixe `192.0.2.0/24`. L'attribut est `AS_PATH: [64512]`.
2. AS 65001 le reçoit (via eBGP). Il le propage à son voisin, AS 65002. L'attribut est maintenant `AS_PATH: [65001, 64512]`.
3. AS 65002 le reçoit. Il le propage... (le chemin s'allonge).
4. ... Finalement, la route revient (par erreur) à l'AS 64512.
5. Le routeur de l'AS 64512 reçoit l'UPDATE. Il inspecte l'AS_PATH : `[..., 65002, 65001, 64512]`.
6. Il voit son **propre ASN (64512)** dans la liste. Il sait que c'est une **boucle**.
7. Il **rejette (discard)** immédiatement cette annonce.

3. Les 4 Catégories d'Attributs

L'attribut `AS_PATH` n'est qu'un des nombreux "attributs" BGP. Ils sont classés par priorité :

2. Influencer son trafic ENTRANT (Inbound)

C'est plus difficile. Vous ne pouvez pas *forcer* le reste du monde à vous envoyer du trafic d'une certaine manière. Vous ne pouvez que le *suggérer* en modifiant les attributs que vous leur envoyez (via eBGP).

A. MED (Multi-Exit Discriminator)

Scénario : J'ai deux liens (Lien A, Lien B) vers le *même* voisin (AS 200). Je veux qu'AS 200 m'envoie le trafic sur le Lien A (grosse capacité) et non le Lien B (petit backup).

Mécanisme :

1. Sur Lien A (eBGP), j'annonce mes routes avec un `MED` (métrique) bas : set metric 100.
2. Sur Lien B (eBGP), j'annonce mes routes avec un `MED` élevé : set metric 500.
3. Le routeur d'AS 200 reçoit les deux annonces.
4. Algorithme (Étape 6) : Il voit que `MED 100` < `MED 500`. Il préférera le Lien A pour m'envoyer du trafic. (Note : cet attribut est "Non-Transitif", AS 200 ne le propage pas).

B. AS_PATH Prepending (Allongement)

Scénario : J'ai deux fournisseurs (AS 200 et AS 300). Je veux que le *monde entier* préfère m'envoyer du trafic via AS 200 (mon lien principal).

Mécanisme :

1. Quand j'annonce mes routes à AS 200 : `AS_PATH: [100]` (normal).
2. Quand j'annonce mes routes à AS 300 (le backup) : j'ajoute (prepend) mon propre ASN 3 fois : AS_PATH: [100, 100, 100].
3. Un routeur distant (AS 500) apprend deux chemins pour m'atteindre :
   • Chemin 1 (via AS 200) : `AS_PATH: [200, 100]` (Longueur 2)
   • Chemin 2 (via AS 300) : `AS_PATH: [300, 100, 100, 100]` (Longueur 4)
4. Algorithme (Étape 4) : Il voit que `Longueur 2` < `Longueur 4`. Il préférera le Chemin 1.

3. COMMUNITY (Les "Tags" de Politique)

Les attributs (LOCAL_PREF, MED) sont rigides. Les "Communities" (Optionnel, Transitif) sont des "tags" numériques (ex: 65001:100) que vous attachez à une route pour *signaler* une politique à vos voisins (ou à vos propres routeurs).

Cas d'Usage 1 (Politique Interne) : J'attache le tag 100:200 à une route apprise. Mes routeurs iBGP voient ce tag et (via une route-map) le traduisent en `LOCAL_PREF 200`.

Cas d'Usage 2 (Politique Externe) : Un fournisseur (ex: Cogent) peut définir un "contrat" public :

• "Si vous m'annoncez une route avec le tag 174:90, je mettrai la LOCAL_PREF à 90 pour vous."
• "Si vous m'annoncez une route avec le tag 174:0, je n'annoncerai PAS cette route à mes pairs (NO_EXPORT)."

Cas d'Usage 3 (DDoS - BLACKHOLE) :

Je (AS 100) suis victime d'une attaque DDoS sur mon IP `1.2.3.4`. Mon lien est saturé.

1. J'annonce à mon Fournisseur (AS 200) la route `1.2.3.4/32` (très spécifique).
2. J'y attache la "Community" BLACKHOLE (ex: 65535:666).
3. Le routeur d'AS 200 voit ce tag. Sa politique (pré-configurée) est : "Si je reçois une route taguée 'BLACKHOLE', je mets son `NEXT_HOP` à Null0 (la poubelle)."
4. Résultat : AS 200 *rejette (drops)* tout le trafic d'attaque *avant* qu'il n'atteigne mon lien. (Je perds aussi le trafic légitime, mais je sauve mon infrastructure).

2. Route Leak (Fuite de Route)

Une "fuite" est différente d'un "hijack". Ce n'est (généralement) pas malveillant, mais c'est tout aussi catastrophique. C'est une **violation de la politique de routage (Peering/Transit)**.

Scénario :

[ Provider A (Tier-1) ] <--> [ MOI (AS 64512) ] <--> [ Provider B (Tier-1) ]
     (Transit 1)                 (Client)                 (Transit 2)

1. État Normal :
   • Je paie A et B pour m'envoyer la "DFZ" (le monde).
   • J'annonce mes préfixes (`1.2.3.0/24`) à A et B.
   • A et B s'annoncent leurs routes (peering) *directement*.
2. La Fuite (L'Erreur) :
   • Je reçois (via iBGP) toutes les routes de A (ex: 500k routes).
   • Mon routeur (mal configuré) **ré-annonce (via eBGP)** ces 500k routes à B.
3. La Conséquence :
   • Le Provider B voit maintenant *deux* chemins pour atteindre les routes de A :
     1. Le chemin normal (via son peering avec A).
     2. Un *nouveau* chemin (via moi, AS 64512).
   • Si ce nouveau chemin (via moi) est (par erreur) *plus spécifique* ou a un *AS_PATH plus court*, B (et tous ses clients !) va maintenant essayer de joindre A en passant **par mon AS (64512)**.
4. Résultat : Mon petit AS (conçu pour 1 Gbit/s) reçoit soudainement 1 Tbit/s de trafic destiné à A. Mon réseau s'effondre (devient un "trou noir") et cause une panne massive.

C'est la violation de la "Règle d'Or" du Transit (voir 1.3).

2. Le Processus : ROV (Route Origin Validation)

Maintenant que cette base de données (ROAs) existe, comment les routeurs l'utilisent-ils ? Ils utilisent le **ROV (Route Origin Validation)**.

Un FAI (ISP) moderne (ex: Orange) installe un logiciel "Cache RPKI" (ou "Validator", ex: Routinator). Ce cache télécharge tous les ROAs du monde (ex: toutes les 5 minutes).

Ensuite, chaque routeur BGP (de bordure) d'Orange est configuré pour parler à ce cache.

Le Flux de Décision (Prévention du Hijack)

Scénario : Le routeur d'Orange reçoit une annonce BGP (un `UPDATE`).

Annonce Reçue :
  Préfixe : 192.0.2.0/24
  AS_PATH : [ 666, ... ]  (Origine = AS 666, le Hacker)

Processus de Validation (ROV) :

1. 1. Requête : Le routeur demande au "Cache RPKI" : "Que sais-tu sur 192.0.2.0/24 ?".
2. 2. Réponse (ROA) : Le cache répond : "J'ai un ROA valide pour ce préfixe. Il dit : `{ asn: 64512, maxLength: 24 }`".
3. 3. Comparaison : Le routeur compare l'Annonce (Origine = 666) au ROA (Origine = 64512). C'est un **mismatch**.
4. 4. État : Le routeur marque cette route comme **"RPKI-Invalid" (Invalide)**.
5. 5. Action : La politique BGP standard est de **REJETER (Discard/Drop)** *toutes* les routes "Invalid".

Les 3 États RPKI