BGPSEC

Nous allons nous intéresser dans cet exercice aux méthodes pour sécuriser BGP. Dans un premier temps nous analyserons deux attaques puis nous verrons des solutions pour les éviter.

San Theodoros

Lors de l’attaque de la grande pyramide, le général Tapioca ordonne de bloquer les vidéos stockées sur Youtube montrant les combats. Pour cela, l’opérateur national STT (San Theodoros Telecom) a injecté sur le point d’échange (STIX) le préfixe 74.125.230/24 de youtube (filiale de Google). L’architecture des AS est représentée sur le schéma suivant:

Question 1 Qu’est ce qu’un GIX comme le STIX? pourquoi n’a-t-il pas de numéro d’AS?

Pour bloquer l’accés à YouTube, STT injecte dans le réseau le préfixe de YouTube 74.125.240/24 vers le GIX

Question 2 Sur le schéma, malgré que SST n’ai pas annoncé le préfixe à Sprint, expliquez pourquoi il s’est diffusé dans le réseau Internet.

Question 3 Pourquoi même les sites proche de YouTube (en nombre d’AS traversés) vont envoyer leur trafic vers San Theodoros ?

YouTube voyant son trafic drastiquement diminuer,  prend des mesures pour rendre ses annonces BGP prioritaires par rapport aux fausses annonces de STT.

Question 4 Quelles annonces doit faire YouTube ?

 

Syldavie

La Syldavie possède une des plus grande infrastructure IP surdimensionnée en terme de bande passante. Le schéma simplifilé montre une partie du réseau Internet.

Question 5 Quelles sont les annonces BGP que va recevoir San Theodoros Telecom (STT) pour un préfixe $latex \alpha$ connecté  à Khemed Infranstructure?

Question 6 Si on suppose qu’aucune politique de routage particulière n’a été mise en place, quelle route va être choisie par STT pour envoyer du trafic vers Khemed?

Question 7 Avec ces hypothèses; le routage est-il symétrique entre les sites connectés à  STT et à KI ?

Suite à une erreur de configuration Sylvanie Backbone, envoie une annonce BGP à STT en modifiant le chemin d’AS, faisant croire que KP lui est directement connecté.

Question 8 Quel impact sur le routage ?

Question 9 Sylvanie Backbone peut-elle renvoyer le trafic vers le bon destinataire ou y a-t-il création d’un trou noir ?

Question 10 Quel chemin retour prendra le trafic?

Question 11 Quels problèmes de sécurité liés à BGP montrent ces deux scénarii, d’où vient le problème ?

BGPSEC

Le draft draft-ietf-sidr-arch redéfinit les échanges BGP en introduisant des méanismes de cryptographie.

 1. Introduction

This document describes an architecture for an infrastructure to
 support improved security for BGP routing [RFC 4271] for the
 Internet. The architecture encompasses three principle elements:

. a resource public key infrastructure (RPKI)

. digitally-signed routing objects to support routing security

. a distributed repository system to hold the PKI objects and the
 signed routing objects

The architecture described by this document enables an entity to
 verifiably assert that it is the legitimate holder of a set of IP
 addresses or a set of Autonomous System (AS) numbers. As an initial
 application of this architecture, the document describes how a
 legitimate holder of IP address space can explicitly and verifiably
 authorize one or more ASes to originate routes to that address space.
 Such verifiable authorizations could be used, for example, to more
 securely construct BGP route filters. [...]

Le draft draft-ietf-sidr-bgpsec-pki-profiles décrit le format des certificats utilisées. La hiérarchie suivante est utilisée:

 2.  Describing Resources in Certificates

Figure 1 depicts some of the entities in the RPKI and some of the
 products generated by RPKI entities.  IANA issues a Certification
 Authority (CA) to a Regional Internet Registries (RIR).  The RIR, in
 turn, issues a CA certificate to an Internet Service Providers (ISP).
 The ISP in turn issues End-Entity (EE) Certificates to itself as
 well as CRLs.  These certificates are referred to as "Resource
 Certificates", and are profiled in [ID.sidr-res-cert-profile].  The
 [ID.sidr-arch] envisioned using Resource Certificates to generate
 Manifests [ID.sidr-rpki-manifests] and Route Origin Authorizations
 (ROAs) [ID.sidr-rpki-roa-format].  ROAs and Manifests also include
 the Resource Certificates used to sign them.

 

Question 12 A quelle autre hiérarchie correspond cette hiérarchie de certification?

Les certificats sont données par les autorités supérieures, ils contiennent les préfixes allouées à ce niveau. Un certificat spécial E-E (End-Entity) ne peut pas être utilisé pour signer d’autres CA. Ils servent principalement à signer les object ROA (Route Origination Authorizations) faisant le lien entre les préfixes du site et son numéro d’AS. L’ensemble de ces enregistrements (CA, EE, ROA,…) sont stockés (repository en anglais) dans des dépôts synchronisés entre eux. Un routeur pourra interroger le plus proche pour vérifier l’annonce.

Le draft draft-ietf-sidr-pfx-validate précise comment un préfixe est validé en fonction de son origine.

 The RPKI system is based on resource certificates that define
 extensions to X.509 to represent IP addresses and AS 
identifiers [RFC3779], thus the name RPKI.  Route Origin 
Authorizations (ROA) [I-D.ietf-sidr-roa-format] are separate 
digitally signed objects that define associations between 
ASes and IP address blocks.  Finally the repository system 
is operated in a distributed fashion through the IANA, RIR 
hierarchy, and ISPs.

In order to benefit from the RPKI system, it is envisioned that
 relying parties either at AS or organization level obtain a local
 copy of the signed object collection, verify the signatures, and
 process them.  The cache must also be refreshed periodically.  The
 exact access mechanism used to retrieve the local cache is beyond the
 scope of this document.

Individual BGP speakers can utilize the processed data contained in
 the local cache to validate BGP announcements.  The protocol details
 to retrieve the processed data from the local cache to the BGP
 speakers is beyond the scope of this document (refer to
 [I-D.ietf-sidr-rpki-rtr] for such a mechanism).  This document
 proposes a means by which a BGP speaker can make use of the processed
 data in order to assign a "validity state" to each prefix in a
 received BGP UPDATE message.

Note that the complete path attestation against the AS_PATH attribute
 of a route is outside the scope of this document.

[...]  any given BGP Route learned from an EBGP
 peer will be found to have one of the following "validation states":

o  Not found: No ROA Covers the Route Prefix.

o  Valid: At least one ROA Matches the Route Prefix.

o  Invalid: At least one ROA Covers the Route Prefix, but no ROA
 Matches it.

 Question 13 Pourquoi ce traitement ne concerne que les routes apprises par EBGP ?

et le draft précise le traitement:

As origin validation will be rolled out incrementally, coverage will
be incomplete for a long time.  Therefore, routing on NotFound
validity state SHOULD be done for a long time.  As the transition
moves forward, the number of BGP announcements with validation state
NotFound should decrease.  Hence an operator's policy SHOULD NOT be
overly strict, preferring Valid announcements, attaching a lower
preference to, but still using, NotFound announcements, and dropping
or giving very low preference to Invalid announcements.

Question 14 Le protocole BGP doit-il être modifié pour prendre en compte les ROA ?

Question 15 Que se passe-t-il, (comme dans le premier scénario que nous avons étudié) , si STT crée un ROA pour le lier à son AS ?

Nous plaçons dans la situation d’attaque de You Tube présentée au chapitre 1.

Question 16 Que se passe-t-il si STT ne crée pas de ROA, comment va réagir Tapioca Communication ?

Question 17 Le mécanisme de ROA protège-t-il dans le cas d’une modification de chemin d’AS comme dans le deuxième scénario (Syldavie)