La norme de sécurisation du routage Internet #BGPsec vient enfin d’être publiée. Il ne reste « plus qu’à » mettre en œuvre dans les routeurs et à déployer.
RFC 8205 BGPsec Protocol Specification
▻http://www.bortzmeyer.org/8205.html
RFC 8207 BGPsec Operational Considerations
▻http://www.bortzmeyer.org/8207.html
RFC 8210 The Resource Public Key Infrastructure (RPKI) to Router
Protocol (RTR), Version 1
▻http://www.bortzmeyer.org/8210.html
(Et quelques autres RFCs)
un commentaire sur Cloudflare et sa pub peu subtile via ▻https://isbgpsafeyet.com ?
@erratic Très bon service, et très utile pour sensibiliser les gens.
Oui, c’est dommage que ce soit Cloudflare qui le fasse, mais si on comptait sur la startup nation, la frenche tèche et le cloud souverain, on n’aurait toujours rien.
@stephane - Mais est-ce que RPKI est suffisant ? J’ai lu :
“a malicious party can easily work around RPKI by simply adding the AS number that’s authorized to originate a prefix to the end of the AS path in an otherwise fake BGP update. The RPKI mechanism won’t detect this; it simply trusts that the AS path is correct. And that’s where BGPsec comes in. The BGPsec protocol is intended to make sure that the AS path is indeed legitimate.”
▻https://www.noction.com/blog/bgpsec-protocol
@erratic Attention, l’auteur confond (c’est quand même assez nul de sa part) RPKI et ROA. ROA (le test fait par le site Web de Cloudflare) ne détecte en effet que les attaques les plus sommaires (et les erreurs de manipulation, qui sont quand même la grande majorité des détournements BGP). BGPsec est plus complet mais aussi bien plus compliqué.
BGPsec et ROA reposent, tous les deux, sur la #RPKI.
Internal Internet traffic routed outside Russia by a Chinese operator
The Russian Internet traffic in several circumstances has been re-routed outside the country, the incidents seem to be caused by routing errors made by China Telecom.
The news has been published by the Internet monitoring service Dyn in a blog post, which also reports that domestic traffic was re-routed apparently due to a networking fault caused by a weakness in the Border gateway protocol (#BGP).
However, as can often happen with these [peering] relationships, one party can leak the routes received from the other and effectively insert itself into the path of the other party’s Internet communications. This happened over a dozen times in the past year between these two providers. This is a general phenomenon that occurs with some regularity but isn’t often discussed in BGP security literature. In this blog post, we’ll explore the issue via the lens of this single example. In a follow-on blog, we’ll explore several additional examples.
The original article below gives a fairly comprehensive explanation of peering and what can go wrong. It also explains the #Vimpelcom and #China_Telecom peering agreement and shows how it went wrong on several occasions. (eg China Telecom announcing full tables)
▻http://research.dyn.com/2014/11/chinese-routing-errors-redirect-russian-traffic
http://research.dyn.com/wp-content/uploads/2014/11/normal_ops.gif 
http://research.dyn.com/wp-content/uploads/2014/11/leak_scenario1.gif 
http://research.dyn.com/wp-content/uploads/2014/11/leak_scenario2.gif The above article also references the following very good and self-explanatory read that explains BGP prefix hijacking, and available security measures:
Why Is It Taking So Long to Secure Internet Routing?
People have been aware of BGP’s security issues for almost two decades and have proposed a number of solutions, most of which apply simple and well-understood cryptography or whitelisting techniques. Yet, many of these solutions remain undeployed (or incompletely deployed) in the global Internet, and the vulnerabilities persist. Why is it taking so long to secure BGP?
▻http://queue.acm.org/detail.cfm?id=2668966
Thus, while we continue to make progress toward protocol-based defenses for routing security, the next frontier in routing security could very well be hardening the software and hardware used in Internet routers.
RFC 7353 : Security Requirements for BGP Path Validation
La sécurité du routage #BGP est un sujet de préoccupation sur l’Internet depuis de nombreuses années. Ce protocole ne dispose en effet par défaut d’aucune sécurité, n’importe quel opérateur pouvant annoncer une route vers n’importe quel préfixe, détournant, par exemple le trafic d’un service vital. Ce manque de sécurité ne vient pas d’une confiance naïve dans la nature humaine, mais plutôt de la nature même de l’Internet : il n’y a pas (heureusement !) de Haute Autorité Supérieure de l’Internet qui connaitrait tous les opérateurs et pourrait les autoriser et les surveiller. Un opérateur ne connait (et encore, pas toujours très bien) que ses voisins immédiats, et ne sait pas quelle confiance accorder aux autres. Dans ces conditions, la sécurisation de BGP est forcément un projet à long terme. La première grande étape avait été la normalisation et le déploiement de #RPKI et #ROA. L’étape suivante est la sécurisation du chemin entier (et pas uniquement de l’origine), dont ce nouveau #RFC est la cahier des charges. En route donc vers #BGPsec !
RFC 7132 : Threat Model for BGP Path Security
Tout le monde le sait, le système de #routage de l’Internet, fondé sur le protocole #BGP, n’est pas sûr. Il est trop facile d’y injecter des annonces de routes mensongères. Le premier pas vers une sécurité plus forte était de sécuriser la communication entre routeurs (RFC 5925). Un second pas a été réalisé avec le déploiement de la #RPKI. Un troisième pas avec la normalisation de la solution RPKI+ROA. Cette dernière protège uniquement l’origine d’une annonce BGP. Cela suffit à arrêter pas mal d’erreurs mais une attaque délibérée gardera probablement l’origine authentique et trichera sur le chemin d’AS présent dans l’annonce BGP. D’où la nécessité de continuer le travail. C’est le projet #PATHSEC (Path Security) pour lequel ce nouveau RFC énumère les motivations. (Le terme de #BGPSEC avait été utilisé dans le passé mais PATHSEC semble plus fréquent aujourd’hui.)