\documentclass{beamer}
%\documentclass[handout]{beamer}
%\usepackage{pgfpages}
%\pgfpagesuselayout{2 on 1}[a4paper,border shrink=5mm]
\usetheme{Afnic}
\usepackage[french]{babel}
\usepackage[latin1]{inputenc}
\usepackage{bortzmeyer-utils}

\title{RPKI + ROA, sécuriser enfin le routage BGP ?}
\author{Stéphane Bortzmeyer\\AFNIC\\\texttt{bortzmeyer@nic.fr}}
\date{FRnog, 31 mai 2012}

%\setlength{\parskip}{1ex plus 0.5ex minus 0.2ex} 
% \setlength{\parskip}{15pt} 
\setlength{\parskip}{15pt plus 10pt minus 10pt} 

\begin{document}

\maketitle

\begin{frame}
 \frametitle{Vide, exprès}  
\end{frame}

\begin{frame}
  \frametitle{Définir le problème}
  \begin{itemize}
  \item<2-> 24 février 2008, Pakistan Telecom prive la planète de YouTube,
    sans pirater un seul routeur,
  \item<3-> 8 avril 2010, China Telecom détourne une partie du trafic
    (FoxNews dit que c'est grave),
  \item<4-> 23 juin 2011, Open Transit annonce (entre autres) les routes
    de l'AFNIC.
  \end{itemize}
\only<5->{À noter que, quoi qu'en dise FoxNews, les trois cas étaient des erreurs.}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Rappel BGP}
  \begin{enumerate}
  \item<2->Le protocole standard d'échange des routes sur l'Internet,
  \item<3->Réseau de pairs configurés à la main : un pair transmet à
    son voisin les routes qu'il connait. Elles sont ensuite
    retransmises aux autres voisins.
   \item<4->Une annonce de route comprend un \emph{préfixe} IP et un
     \emph{chemin d'AS}. L'AS d'\emph{origine} est le plus à
     droite. (AS = \foreign{Autonomous System}, typiquement un opérateur)
   \item<5->Contrairement au DNS, ce n'est pas un arbre mais un graphe (bordélique).
  \end{enumerate}
\end{frame}

\begin{frame}
  \frametitle{Principes de la solution}
  \begin{enumerate}
  \item<2->Une infrastructure de distribution de \emph{certificats
    numériques} prouvant qu'on contrôle un préfixe IP : la \emph{RPKI} (\foreign{Resource Public Key Infrastructure}),
  \item<3->Des objets signés par le titulaire du préfixe, les
    \emph{ROA} (\foreign{Route Origin Authorizations}). Un ROA est une
    \emph{déclaration authentifiée} disant « Le préfixe
      \path{2001:db8:42::/48} peut être originé par l'AS 65584 ».
  \end{enumerate}
\only<4->{RFC 6480, \url{http://www.bortzmeyer.org/securite-routage-bgp-rpki-roa.html}}
\end{frame}

\begin{frame}
  \frametitle{RPKI}  
   La \foreign{Resource Public Key Infrastructure} est une
   infrastructure de distribution de :
   \begin{itemize}
   \item<1->Quoi ? Des certificats \emph{X.509}, utilisant les
     extensions du RFC 3779. Le sujet du certificat n'est pas
     important, ce qui compte est le \computer{IPAddrBlocks}.
   \item<2->Par qui ? [ IANA ->] RIR -> LIR -> Client (pas les AC
     traditionnels)
   \item<3->Comment ? \computer{rsync -av rsync://rpki.ripe.net/repository /var/RPKI}
   \end{itemize}

\only<4->{RFC 6487 et 6481}

\end{frame}

\begin{frame}
  \frametitle{ROA}  
  Test pour entretien d'embauche d'un admin' BGP : « savez-vous ce
    qu'est un ROA ? »
  \begin{block}<2->
    {\foreign{Route Origin Authorizations}}
    {Un fichier CMS signé avec la clé du certificat (ci-dessus), listant les AS
      qui peuvent être l'\emph{origine} d'un ou plusieurs préfixe(s).}
  \end{block}
 \only<3->{Émis par le titulaire du préfixe.}

\only<4->{RFC 6482}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Le ROA de l'AFNIC}
  \begin{info}
% certification-validator --print -f e6Y1dFuFnChdD1ZZ2AcNN_Xqp3I.roa
Object Type: Route Origin Authorisation object
Signing time: 2012-05-02T14:57:28.000Z
ASN: AS2486
Prefixes:
    2001:67c:2160::/48
    2001:67c:217c::/48
  \end{info}
\end{frame}

\begin{frame}
  \frametitle{Détails : RTR}
  \begin{enumerate}
  \item<2->Le routeur route, il vaut mieux ne pas trop le charger.
  \item<3->Charger les ROA, valider, etc, est bien lourd pour le petit
    processeur d'un Cisco.
  \item<4->On va donc découpler : 
    \begin{enumerate}
    \item<5->Un \emph{cache/validateur}, typiquement une machine Unix,
      le \emph{serveur} RTR,
    \item<6->Le routeur, le \emph{client} RTR.
    \end{enumerate}
    \only<7->{Entre les deux : RTR (\foreign{RPKI/Router Protocol})}
   \item<8->RFC pas encore publié mais presque.
   \item<9->RTR transmet juste des assertions (« l'AS 2486 peut
     originer \path{2001:67c:2160::/48} »), \emph{c'est le routeur qui décide}.
  \end{enumerate}
\end{frame}

\begin{frame}
  \frametitle{Détails : qui allez-vous appeler ?}
  \begin{itemize}
  \item<2->{Si on se fie à l'expérience de PGP/X.509/DNSSEC, il y aura
    des problèmes.}
  \item<3->Votre routeur rejette une route car signature invalide :
    \foreign{Who you gonna call?}
   \item<4->whois ? Qualité variable...
   \item<5->\foreign{Ghostbusters!}
   \item<6->Des vCard dans la RPKI
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Mises en \oe{}uvres, gestion des certificats}
  Mélange de logiciel d'une AC X.509 et d'une solution IPAM.
  \begin{itemize}
  \item<2->Il y en a sur le \foreign{cloud} (voir plus loin celui du
    RIPE-NCC)
  \item<3->Au moins deux logiciels libres (pas testés), rcynic et Local Certification Service
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Mises en \oe{}uvres, cache/validateur}
  \begin{itemize}
  \item<2->Solution du RIPE-NCC, en Java, RPKI Validator
  \item<3->Solution ISC/ARIN, en C, rcynic
  \item<4->D'autres apparaissent (BBN).
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Mises en \oe{}uvres, routeur}
  Rappel : il suffit au routeur d'être client RTR et d'avoir un
  mécanisme permettant d'utiliser les assertions dans son processus
  de décision.
  \begin{itemize}
  \item<2->Cisco IOS (publiée avec Classic 15.2(1)S et XE 3.5)
  \item<3->Juniper (pas officiellement publiée, pour la 12.2 quelque
    part en 2012 ?)
  \item<4->Quagga (patch disponible, nommé BGP-SRX)
  \item<5->Bibliothèque cliente RTR libre, RTRlib (utilisée par BIRD)
  \end{itemize}
Client RTR sur Juniper :
\begin{info}
rpki@lr1.ham1.de> show validation session 
Session                                  State   Flaps     Uptime #IPv4/IPv6 records
195.13.63.18                             Up       1015   00:53:27 1207/310
\end{info}
\end{frame}

\begin{frame}[fragile]
  \frametitle{RTR en action, avec RTRlib}
  \begin{info}
2012-05-29T09:07:22Z + 2800:38::   32 - 128  27808
2012-05-29T09:07:22Z + 2001:67c:2160::  48 -  48  2486
2012-05-29T09:07:22Z + 2001:1448:: 32 -  32   16245
2012-05-29T09:07:22Z + 2a02:d28::  32 - 120   5580
2012-05-29T09:07:22Z + 2a00:8640::  32 -  32  57771
2012-05-29T09:07:22Z + 2001:4190::  32 -  32    8246
  \end{info}
\end{frame}

\begin{frame}
\frametitle{Portail RIPE pour les LIR}
\includegraphics[scale=0.3]{certificat-afnic.png}
\end{frame}

\begin{frame}
\frametitle{Portail RIPE pour les LIR, suite}
\includegraphics[scale=0.3]{ressources-afnic.png}
\end{frame}

\begin{frame}
\frametitle{Portail RIPE pour les LIR, les ROA}
\includegraphics[scale=0.3]{roas-afnic.png}
\end{frame}

\begin{frame}
  \frametitle{Outils RIPE}
  RPKI Validator fournit un cache/validateur, des outils en ligne de
  commande, une interface Web
  conviviale-graphique-pour-zutilisateurs...

  \only<2->{Contrairement à tant d'outils en Java, ça semble tourner sur une
  machine 100 \% libre (Debian).}

\end{frame}

\begin{frame}
  \frametitle{RIPE RPKI Validator en local}
  \includegraphics[scale=0.3]{rpki-validator-roas.png}
\end{frame}

\begin{frame}
 \frametitle{Routeurs connectés au validateur du RIPE}
  \includegraphics[scale=0.3]{rpki-validator-sessions.png}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Outil ligne de commande du RIPE}
\begin{info}
% certification-validator  --print -f  roa-5574190.roa
Content type: 1.2.840.113549.1.9.16.1.24                        
Signing time: 2011-01-11T19:04:18.000Z
ASN: AS559
Prefixes:
    193.5.26.0/23 [24]
    193.5.152.0/22 [24]
    193.5.168.0/22 [24]
    193.5.22.0/24
    193.5.54.0/23 [24]
    193.5.58.0/24
    193.5.60.0/24
    193.5.80.0/21 [24]
\end{info}
\end{frame}

\begin{frame}
  \frametitle{Autre outil, rcynic}
rcynic fournit une AC RPKI (pas testée), un cache/validateur, des
outils en ligne de commande.

Dépend de OpenSSL : attention sur Debian où le OpenSSL standard n'a
toujours pas les extensions du RFC 3779 :-(
\end{frame}

\begin{frame}[fragile]
  \frametitle{Démos de rcynic}
\begin{info}
% find_roa  /var/rcynic 2001:660::/32
ASN 2200 prefix 2001:660::/32 \
       ROA /var/rcynic/data/authenticated.2012-05-02T13:35:03Z/rpki.ripe.net/repository/c7/a584e4-ccd4-4c4f-9d16-04a27c4d5453/1/9p3cFqSYEIWppQMeRKsKOCjJKpk.roa

% print_roa /var/rcynic/data/authenticated.2012-05-02T13:35:03Z/rpki.ripe.net/repository/c7/a584e4-ccd4-4c4f-9d16-04a27c4d5453/1/9p3cFqSYEIWppQMeRKsKOCjJKpk.roa
...
asID:           2200
...
 addressFamily: 2
     IPaddress: 2001:660::/32
\end{info}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Outils génériques}
  OpenSSL peut gérer les certificats de la RPKI
  \begin{info}
% openssl x509 -inform DER -text \
    -in ./q3C8zU6hYpb7zVqmpjlVY5BBWE.cer
...
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=5XxoZDVUZvaNYJcVATAgTQ2ifLQ
        Validity
            Not Before: Dec 14 15:26:48 2010 GMT
            Not After : Jul  1 00:00:00 2011 GMT
...
            sbgp-ipAddrBlock: critical
                IPv4:
                  85.118.184.0/21
                  93.175.146.0/23
                IPv6:
                  2001:7fb:fd02::/47
  \end{info}
\end{frame}

\begin{frame}[fragile]
 \frametitle{Outils non locaux}
 Le serveur whois de BGPmon
\begin{info}
Avant la création du ROA :

% whois -h whois.bgpmon.net " --roa 2486 2001:67c:2160::/48"
1 - Not Found

Après :

% whois -h whois.bgpmon.net " --roa 2486 2001:67c:2160::/48"
0 - Valid
------------------------
ROA Details
------------------------
Origin ASN:       AS2486
Not valid Before: 2012-05-01 00:00:00
Not valid After:  2012-06-30 00:00:00  Expires in 57d17h16m11s
Trust Anchor:     rpki.ripe.net
Prefixes:         2001:67c:217c::/48
                  2001:67c:2160::/48
\end{info}
\end{frame}

\begin{frame}
 \frametitle{Looking Glasses, voir la RPKI à distance}
 \begin{itemize}
 \item \url{http://www.labs.lacnic.net/rpkitools/looking_glass/}
 \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Configuration du routeur}
Configuration du client RTR sur un Cisco :
\begin{info}
bgp rpki server tcp 2001:db8:1000:2000::f00d port 8282 refresh 180

route-map test-rpki permit 10
 match rpki invalid
 set local-preference 50
\end{info}
État d'une route sur un Cisco (rappel : le routeur décide de ce qu'on
fait d'une route invalide) :
\begin{info}
rpki-rtr>show ip bgp 62.73.128.0
BGP routing table entry for 62.73.128.0/19, version 1865228
...
  12654 50300 15533
    193.0.4.1 from 193.0.4.28 (193.0.4.28)
      Origin IGP, localpref 110, valid, external, best
      path 58970BAC RPKI State valid
\end{info}
\end{frame}

\begin{frame}
  \frametitle{État du déploiement}
  \begin{itemize}
  \item<2->Tous les RIR sauf ARIN distribuent des certificats et des
    ROA,
  \item<3->Au 12 mai 2012, dans les 1200 ROAs (bancs de tests exclus),
    en croissance très rapide dans RIPEland,
  \item<4->Logiciels qui commencent à devenir stables mais peu de
    clients RPKI dans les images officielles des routeurs,
  \item<5->Quasiment aucun routeur de production ne valide. 
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Futur}
  \begin{enumerate}
  \item<2->Les ROAs n'authentifient que l'\emph{origine}. C'est
    largement suffisant contre les erreurs.
  \item<3->Mais un attaquant type Kapela\&Pilosov va respecter
    l'origine et ne sera pas détecté
  \item<4->Prochaine étape, déjà en cours à l'IETF, utiliser la RPKI
    et un nouvel attribut BGP pour signer le chemin d'AS
    complet. Cette fois, cela modifiera BGP.
    \begin{enumerate}
    \item IRR et systèmes d'alerte $\longrightarrow$ BGPbrut
    \item RPKI+ROA $\longrightarrow$ BGPdemisec
    \item Validation du chemin $\longrightarrow$ BGPsec
    \end{enumerate}
  \end{enumerate}
\end{frame}

\begin{frame}
  \frametitle{Critiques techniques}
    \begin{itemize}
    \item<2->Complexité, et dépendance vis-à-vis de nouvelles
      infrastructures pas maîtrisées,
    \item<3->Risques de faux positifs (comme avec les IRR, où beaucoup
      de routes seraient rejetées si on filtrait),
    \item<4->Les ROA protègent contre les accidents, pas contre les attaques.
    \end{itemize}
  \end{frame}

\begin{frame}[fragile]
  \frametitle{Rover}
  \begin{itemize}
  \item<2->La RPKI est la solution « officielle » à l'IETF et chez les
    RIR. Y a-t-il une alternative technique ?
  \item<3->ROVER propose de mettre la même information (AS d'origine
    et, demain, chemin) dans le DNS, signé avec DNSSEC. Même niveau de
    sécurité que la RPKI. Fini, X.509.
   \item<4->Réutilise logiciels et hiérarchies existantes.
   \item<5->Nettement moins testé et soutenu que la RPKI. Mais plus
     simple et moins risqué.
   \item<6->Beaucoup de problèmes (risques de faux positifs, problèmes
     politiques) sont les mêmes avec ROVER et la RPKI.
  \end{itemize}
\begin{info}
c.7.1.2.c.7.6.0.1.0.0.2.ip6.arpa. SRO AS2486 ; NIC-FR-DNS-UNICAST-PARIS2
\end{info}
\end{frame}

\begin{frame}
  \frametitle{Politique}
  \begin{itemize}
  \item<2->Autrefois, les RIR n'avaient qu'un rôle indicatif :
    n'importe qui pouvait annoncer n'importe quel préfixe. En criant
    assez fort, ça passait. Inversement, une annulation d'allocation
    par un RIR (RBN\ldots) n'avait pas d'importance pratique.
   \item<3->Si la RPKI+ROA est déployé, avec refus des annonces non ou
     mal signées, cela sera différent. Une
     révocation pourrait rendre un préfixe largement
     inaccessible. \emph{Les RIR auraient gagné un rôle opérationnel.}
   \item<4->Il va falloir réviser son code pénal néerlandais.
   \item<5->Les discussions policitiennes sur la gouvernance de
     l'Internet se focalisent sur l'excitant \url{.xxx} et oublient
     les problèmes concrets comme la RPKI.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Comparaison avec DNSSEC}
  \begin{enumerate}
  \item<2->Mêmes problèmes des faux positifs (bien plus nombreux que
    les vrais),
  \item<3->Mêmes optimistes jurant que tout ira bien (tu parles),
  \item<4->Même question fondamentale : « la sécurité vaut-elle une
    telle dépense ? »,
  \item<5->Même nécessité de montée en compétence et même résultat :
    éliminer les petits,
  \item<6->Moins de problèmes politiques : le DNS était déjà arborescent.
  \end{enumerate}
\end{frame}

  \begin{frame}{Observatoire de la r{\'e}silience de l'Internet}
    \begin{block}{Concepts :}
      \begin{enumerate}
        \item appr{\'e}hender la r{\'e}silience de l'Internet fran{\c c}ais ;
        \item promouvoir les bonnes pratiques ;
        \item d{\'e}finition et mesures d'indicateurs techniques repr{\'e}sentatifs de
        la r{\'e}silience.
      \end{enumerate}
    \end{block}
    Rapport 2011 : analyse sur les donn{\'e}es BGP \& DNS de janvier {\`a} novembre
    2011
    \begin{itemize}
      \item les co-auteurs sont pr{\'e}sents et disponibles ;
      \item des copies papier peuvent {\^e}tre r{\'e}cup{\'e}r{\'e}es.
    \end{itemize}
  \end{frame}
\end{document}
  
\end{frame}

\end{document}
