POPULARITY
7 episodes with rpki
3 episodes with rpki
3 episodes with rpki
2 episodes with rpki
2 episodes with rpki
2 episodes with rpki
2 episodes with rpki
2 episodes with rpki
2 episodes with rpki
In this episode, Job Snijders discusses RPKIViews, his long term project to collect the "views" of RPKI state every day, and maintain an archive of BGP route validation states. The project is named to reflect route views, the long-standing archive of BGP state maintained by the University of Oregon, which has been discussed on PING. Job is based in the Netherlands, and has worked in BGP routing for large international ISPs and content distribution networks as well as being a board member of the RIPE NCC. He is known for his work producing the Open-Source rpki-client RPKI Validator, implemented in C and distributed widely through the OpenBSD project. RPKI is the Resource PKI, Resource meaning the Internet Number Resources, the IPv4, IPv6 and Autonomous System (AS) numbers which are used to implement routing in the global internet. The PKI provides cryptographic proofs of delegation of these resources and allows the delegates to sign over their intentions originating specific prefixes in BGP, and the relationships between the AS which speak BGP to each other. Why rpkiviews? Job explains that there's a necessary conversation between people involved in the operational deployment of secure BGP, and the standards development and research community: How many of the worlds BGP routes are being protected? How many places are producing Route Origin Attestations (ROA) which are the primary cryptographic object used to perform Route Origin Validation (ROV) and how many objects are made? Whats the error rate in production, the rate of growth, a myriad of introspective "meta" questions need to be asked in deploying this kind of system at scale, and one of the best tools to use, is an archive of state, updated frequently, and as for route views collected from a diverse range of places worldwide, to understand the dynamics of the system. Job is using the archive to produce his annual "RPKI Year in review" report, which was published this year on the APNIC blog (it's posted to operations, research and standards development mailing lists and presented at conferences and meetings normally) and products are being used by the BGPAlerter service developed by Massimo Candela
We doen het even helemaal anders! Randal vertelt zelf over zijn nieuwe functie als directeur van Freedom Internet. Samen met collega's Bibi van Alphen en Twan Welboren bespreekt hij hoe hij ondanks zijn voornemens tóch weer bij een internetprovider terecht kwam. Jurian gooit zijn journalistieke skills in de strijd om er achter te komen waarom Randal de vraag om voor Freedom aan het werk te gaan heeft ervaren als een roeping waar je geen nee tegen kunt zeggen.Deze aflevering is een diepgaand kijkje in de missie van Freedom: een internet zonder inmenging van grote techbedrijven en zonder onnodige dataverzameling.Freedom Internet ontstond uit protest tegen het verdwijnen van XS4ALL. Twan legt uit hoe XS4ALL-werknemers en -gebruikers in actie kwamen toen KPN besloot het merk op te heffen. Inmiddels heeft Freedom een sterke ideologische basis met een focus op privacy en vrijheid van informatie, en werkt het bedrijf aan bewustwording over de invloed van Big Tech. Ook praten de nerds over juridische uitdagingen, waaronder Freedom's rechtszaak tegen de EU over de blokkering van Russische media tijdens de oorlog in Oekraïne.ShownotesFreedom InternetXS4ALL moet blijvenBibi van AlphenTwan WelborenFairphone als duurzaam alternatiefTrined als strategische partnerInternet.nl voor ISP-testenJob Snijders over RPKI en internetveiligheidFreedom's rechtszaak over Russia TodayTijdschema0:00:00 Reclame: ICT Group0:00:46 Waarom het belangrijk is dat een ISP vecht0:03:07 Over de opkomst van Freedom Internet0:06:31 De doorstart als Freedom Internet0:10:14 Het telefoontje dat alles veranderde0:12:22 De speerpunten van Freedom Internet0:13:28 Strijd tegen gesloten internet0:15:47 De rol van public affairs0:19:59 Bewustwording bij klanten0:24:22 Uitdagingen voor kleine providers0:26:38 Toekomstverwachtingen bij Freedom0:30:09 De rol van Bibi in Freedom0:35:53 Rechtszaak tegen Europese instellingen0:39:04 Maatschappelijk debat over censuur0:42:03 De rol van democratie en macht0:44:52 Effectiviteit van internetblokkades0:49:45 Marketingstrategieën van Freedom0:52:46 Het steward ownership model0:56:31 De invloed van commercie1:03:04 De biologische internetvergelijking1:04:52 Certificaten en aandelen bij Freedom1:08:56 Afsluiting en bedankjes aan de gastnerdsZie het privacybeleid op https://art19.com/privacy en de privacyverklaring van Californië op https://art19.com/privacy#do-not-sell-my-info.
The White House recently announced plans to boost Internet routing security in the US through better RPKI coverage. So how does RPKI help secure BGP? How easy is it to boost coverage on a national level? And what's the future potential of the infrastructure? Our guest Tim Bruijnzeels shares his views.Tim is Principal Software Engineer for RPKI at the RIPE NCC and has worked in standards development and software implementation around RPKI for well over a decade. He talked to us about where RPKI is at today, how governments can and have aided its adoption, and how work being done on ASPA and BGPsec promise a more secure future for the Internet.Show notes:02:40 - The Dublin IETF meeting back in 2008.03:17 - Tim has contributed to a number of RFCs over the years.03:40 - NLnet Labs develops free, liberally licensed, open-source software for DNS and BGP routing.03:50 - Krill is a free, open source RPKI Certificate Authority developed by NLnet Labs that lets you run delegated RPKI under one or multiple RIRs.07:24 - You can read more on how the Internet routes around damage on RIPE Labs.10:47 - Get more information on how to manage ROAs through the RPKI Dashboard.11:36 - Check out the RIPE NCC's Routing Information Service (RIS).12:17 - Alex Band's article on the launch of the RIPE NCC Resource Certification Service back in 2011.13:51 - There are a number of RPKI validators to choose from, including Routinator from NLnet Labs.17:32 - Here's a nice explainer article on ASPA.22:07 - Plans to support ASPA and BGPsec router certificates in RIPE NCC Quarterly Planning.24:42 - Press Release: White House Office of the National Cyber Director Releases Roadmap to Enhance Internet Routing Security.26:47 - More on Dutch government measures for ensuring RPKI coverage. Hosted on Acast. See acast.com/privacy for more information.
Today on Packet Protector we get into BGP security. BGP is an essential protocol for directing traffic across the Internet, but it wasn't designed with bad actors in mind, not to mention plain old configuration mistakes. Without additional controls in place, BGP is susceptible to issues such as route leaks and route hijacks that can... Read more »
Today on Packet Protector we get into BGP security. BGP is an essential protocol for directing traffic across the Internet, but it wasn't designed with bad actors in mind, not to mention plain old configuration mistakes. Without additional controls in place, BGP is susceptible to issues such as route leaks and route hijacks that can... Read more »
Host Philip Gervasi talks with Doug Madory and Job Snijders about the importance of RPKI in securing Internet routing. They explore the recent milestone of RPKI covering 50% of IPv4 routes, the process of route origin validation (ROV), and the role of ROAs. They also discuss the impact of ROA expirations and future advances in Internet routing security. Tune in to learn how RPKI contributes to a more stable and secure Internet.
This time on PING Doug Madory from Kentik discusses his recent measurements of the RPKI system worldwide, and it's visible impact on the stability and security of BGP. Doug makes significant use of the Oregon RouteViews repository of BGP data, a collection maintained continuously at the University of Oregon for decades. It includes data from back to 1997, originally collected by the NLANR/MOAT project and has archives of BGP Routing Information Base (RIB) dumps taken every two hours from a variety of sources, and made available in both human-readable and machine readable binary formats. This collection has become the de-facto standard for publicly available BGP state worldwide, along with the RIPE RIS collection. As Doug discusses, research papers which cite Oregon RouteViews data (over 1,000 are known of, but many more exist which have not registered their use of the data) invite serious appraisal because of the reproducibility of the research, and thus the testability of the conclusions drawn. It is a vehicle for higher quality science about the nature of the Internet through BGP. Doug presented on RPKI and BGP, at the APOPS session held in February at APRICOT/APNIC57 Bangkok, Thailand
This time on PING we have Amreesh Phokeer from the Internet Society (ISOC) talking about a system they operate called Pulse, available at https://pulse.internetsociety.org/. Pulse's purpose is to assess the “resiliency” of the Internet in a given locality. Similar systems we have discussed before on Ping include APNIC's DASH service, aimed at resource holding APNIC members, and the MANRS project. Both of these take underlying statistics like resource distribution data, or measurements of RPKI uptake or BGP behaviours and present them to the community, and in the case of MANRS there's a formalised “score” which shows your ranking against current best practices. The Pulse system measures resilience in four pillars: Infrastructure, Quality, Security and Market Readiness. Some of these are “hard” measures analogous to MANRS and DASH, but Pulse in addition to these kinds of measurements includes “soft” indicators like the economic impacts of design decisions in an economy of interest, the extent of competition, and less formally defined attributes like the amount of resiliency behind BGP transit. This allows the ISOC Pulse system to consider governance-related aspects of the development of Internet, and has a simple scoring model which allows a single health metric analogous to the use of pulse and blood pressure by a physician to assess your condition, but this time applied to the Internet.
El hackeo a un gran operador más ingenioso de la historia: Orange España y el RPKI. Capítulo grabado sobre la marcha, espero sepáis perdonarme!
In this episode Carlos Martínez and Tim Bruijnzeels discussed the pros and cons of Krill, a free, open source RPKI Certificate Authority that lets you run delegated RPKI under one or multiple Regional Internet Registries (RIRs). Ideas were also shared regarding the importance and challenges faced by organizations implementing open-source tools.
In june of this year, the Dashboard for AS Health or DASH, a service operated by APNIC saw a leak of approximately 260,000 BGP routes from a vantage point in Singapore, and sent alerts to around 90 subscribers to our routing mis-alignment notification service which is part of DASH. BGP is the state of announcements made and heard worldwide, calculated by every BGP speaker for themselves and although its globally connected and represents “the same” network, not everyone sees all things, as a result of filtering and configuration differences around the globe. BGP also should align with two external information systems, the older Internet Routing Registry (IRR) system which uses a notation called RPSL to represent routing policy data, including the “route” object, and Resource Public Key Infrastructure or RPKI, which represents the origin-AS (in BGP, who originates a given prefix) in a cryptographically signed objected called a ROA. The BGP prefix and origin (the route) should align with whats in an IRR route object and an RPKI ROA, but sometimes these disagree. Thats what DASH is designed to do: tell you when these three information sources fall out of alignment. I discussed this incident, and the APNIC Information Product family (DASH, a collaboration with RIPE NCC called NetOX, and the delegation statistics portal called REX) with Rafael Cintra, the product manager of these systems, and with Dave Phelan who works in the APNIC Academy and has a background in Network Routing Operations. You can find the APNIC Information products here: (note that the DASH service needs a MyAPNIC login to be used) https://dash.apnic.net the DASH portal login page (MyAPNIC resource login needed) https://netox.apnic.net NetOX the Network Observatory web service https://rex.apnic.net Resource Explorer: delegation statistics for the world
"Any country that intervenes in Taiwan will face serious consequences, including cyber attacks."This statement in January by the Chinese Ministry of Foreign Affairs made clear that the United States must be ready to defend itself in what many assume to be an inevitable conflict over Taiwan's independence. It begs the question, how will we defend ourselves from such a powerful adversary with one of the best cyber armies in the world?At the heart of the answer is the United States infrastructure: an interconnected web of both government and for profit companies that provide core services to the citizens. This public / private partnership is most evident where it matters most: energy and communications. Mary Haynes, Group Vice President of Charter Communications and industry cybersecurity veteran, has worked with presidential administrations across her multi-decade career to serve the twin goals of protecting her customers and making the country more resilient to attacks. Our 72 minute conversation with Mary starts with how our communications industry is responding to the threat and the Biden administration's somewhat unique approach. We explore two critical areas to mounting a credible defense: 1) Ensuring the security of consumer managed connectivity hardware and 2) Addressing traffic hijacking and route misadvertisements by shoring up BGP with RPKI. Throughout the conversation, we get a clear view into the combination of big picture thinking, technical acumen and diplomacy that have taken Mary to one of the top roles in defending the U.S. communications backbone.While the first part of the conversation discusses her and the communications industry's readiness to defend against nation state adversaries, the remainder of our interview serves as a brief career retrospective for Mary as she plans to start her transition into retirement later this year. On the topic of dealing with seismic technology shifts, she reflects on our response to the public cloud and how that should inform the cybersecurity industry's response to the current advancements in artificial intelligence. As we wrap up, Mary explains where we've made progress with regards to diversity and her advice for women considering a career in cybersecurity. Mary's optimism and clarity of vision leave a strong impression throughout the dialogue; we wish her the very best as she moves from leader and practitioner to advisor and board member later this year.
BGP is the Internet's de facto routing protocol - but it's also one with many vulnerabilities and is only deeply understood by a relatively small fraction of people. Delving into the threats posed by misconfigurations and prefix hijacks, Lefteris Manassakis looks at the history and evolution of BGP and discusses the importance of mitigation, monitoring and detection as provided by ARTEMIS and CodeBGP.00:51 - ARTEMIS is a system that enables network operators to monitor, detect and mitigate the effects of BGP prefix hijacking events. Read up on ARTEMIS on RIPE Labs or read other blog posts and academic papers on the ARTEMIS website.01:00 - Code BGP01:07 - Lefteris presenting on CodeBGP at RIPE 8504:10 - An example of other research from Lefteris and Fontas.04:42 - BGP version 1 in RFC 110504:50 - BGP version 4 in RFC 427107:21 - A profile on Christos Papadimitriou08:18 - OSPF16:22 - The ARTEMIS paper17:11 - Stable Internet Routing Without Global Coordination by Lixin Gao and Jennifer Rexford19:22 - RFC 790821:40 - Rogers outage26:38 - Sharon Goldberg and others on the use of maxlength in RPKI.27:57 - RFC 931934:00 - RIPE NCC Community Projects Fund35:00 - The Code BGP team41:10 - RIS Live48:33 - MANRS and Code BGP Hosted on Acast. See acast.com/privacy for more information.
FTX, CISA, Apple, RPKI, Circle, NEXX, MSI, Jason Wood, and more on this edition of the Security Weekly News. Visit https://www.securityweekly.com/swn for all the latest episodes! Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly Show Notes: https://securityweekly.com/swn288
Netherlands to adopt RPKI Widespread backdoor installed on WordPress sites Tracing leaked Pentagon documents And now a word from our sponsor, AppOmni Can you name all the third party apps connected to your major SaaS platforms, like Salseforce, Microsoft 365, or Google Workspace? What about the data these apps can access? After all, one compromised 3rd party app could put your entire SaaS ecosystem at risk. With AppOmni, you get visibility to all third party apps and SaaS-to-SaaS connections — including which end users have enabled them, and the level of data access they've been granted. Visit AppOmni.com today to request a free risk assessment.
FTX, CISA, Apple, RPKI, Circle, NEXX, MSI, Jason Wood, and more on this edition of the Security Weekly News. Visit https://www.securityweekly.com/swn for all the latest episodes! Show Notes: https://securityweekly.com/swn288
FTX, CISA, Apple, RPKI, Circle, NEXX, MSI, Jason Wood, and more on this edition of the Security Weekly News. Visit https://www.securityweekly.com/swn for all the latest episodes! Follow us on Twitter: https://www.twitter.com/securityweekly Like us on Facebook: https://www.facebook.com/secweekly Show Notes: https://securityweekly.com/swn288
FTX, CISA, Apple, RPKI, Circle, NEXX, MSI, Jason Wood, and more on this edition of the Security Weekly News. Visit https://www.securityweekly.com/swn for all the latest episodes! Show Notes: https://securityweekly.com/swn288
Infosec Decoded Season 3 #28: RPKI With @sambowne@infosec.exchange Links: https://samsclass.info/news/news_040723.html
Conversamos con Carlos Martínez, CTO de LACNIC, y Gerardo Rada, Líder de Desarrollo de Sistemas sobre LACNIC Tools, una solución integrada donde consultar y conocer oportunidades de mejoras en la configuración de sus organizaciones en los distintos sistemas de LACNIC. Sus reportes provienen de información que ya es pública: información de los repositorios de RPKI, consultas a RDAP, WHOIS y preguntas directas a servidores de nombres, entre otras fuentes. P https://tools.labs.lacnic.net/tools/home
APNIC's Chief Scientist, Geoff Huston, joins PING for his monthly chat, to share his thoughts on the associated trust with routing security and whether it can hold up as a sustainable model. We'll talk about the history of trust in communication and associated challenges within routing security and the rise and future of Resource Public Key Infrastructure (RPKI) and BGP security. Read more about PKI and routing security on the APNIC Blog. The views expressed by the featured speakers are their own and do not necessarily reflect the views of APNIC.
APNIC's Chief Scientist, Geoff Huston, joins PING for his monthly chat, to share his thoughts on the associated trust with routing security and whether it can hold up as a sustainable model. We'll talk about the history of trust in communication and associated challenges within routing security and the rise and future of Resource Public Key Infrastructure (RPKI) and BGP security. Read more about PKI and routing security on the APNIC Blog. The views expressed by the featured speakers are their own and do not necessarily reflect the views of APNIC.
If you advertise routes through a provider to the global Internet, you might be wondering if you should go through the trouble of registering in the RPKI and advertising ROAs. What is the tradeoff for the work involved in what seems like a complex process? Cecelia Testart joins Jeremy White and Russ White to discuss recent work in measuring the value of the RPKI.
Deze aflevering is de terugkeer van Job Snijders, die ons drie jaar geleden alles vertelde over BGP en NLNOG. Naast BGP-guru en OpenBSD-enthousiast is Job hardcore programmeur voor rpki-client.org. Hij revancheert zich niet alleen, want hij heeft Wouter Prins bereid gevonden bij ons aan tafel te komen nerden over RPKI. Wouter Prins is senior netwerk-engineer en tester voor KPN en bijna eigenhandig verantwoordelijk voor het implementeren van RPKI bij de grootste provider van Nederland.Resource Public Key Infrastructure is zo'n techniek die saai zou moeten zijn omdat je hem eigenlijk niet nodig hoopt te hebben. Of anders is het wel zo'n protocol waarvan de implementatie als internetprovider nooit op nummer één van de prioriteitenlijsten komt te staan. Toch kan RPKI het verschil maken bij de betere BGP-hijacks of de meest gewiekste phishing-aanval. Wouter Prins weet er alles van, want hij implementeerde de techniek bij KPN. Een provider waar het door de wet van de grote getallen vast een keer van pas komt.Reclame: BamigoDeze aflevering wordt mede mogelijk gemaakt door Bamigo. Krijg nu 25% korting op je eerste bestelling met de code ‘NERDS25‘.Tijdschema00:00:00 Reclame: ICT Group00:00:33 De Avondvierdaagse00:01:57 Voortellen: Job Snijders00:02:50 Voorstellen: Wouter Prins00:04:04 De raketvlucht van RPKI in drie jaar tijd00:06:48 Hoe Wouter Prins RPKI bij KPN voor elkaar kreeg00:09:27 Opfrisser: wat is RPKI ook alweer?00:15:29 Hoe de Russen BGP gebruiken om banken af te luisteren00:24:07 BGP en RPKI in de blockchain?00:33:46 Validators als kern van veiligheid00:42:35 Uitzoeken, documenteren en monitoren00:51:00 De knop omzetten01:01:10 Hoe bouwt Job Snijders een RPKI validator?01:11:29 Origin validation en path validation01:20:51 Reclame: Bamigo01:22:46 Vragen van de luisteraars01:49:31 Tips02:01:06 AfkondigingTipsRandal PeelenBoekestijn en de Wijk (BNR) - Als Poetin de gaskraan dichtdraaitHet Tweakers-interview met ASML's technische topman Martin van den BrinkWouter PrinsKeep it simpleBuitenantennes goed aardenKevin Mittnick - Ghost in the WiresRussian-controlled telecom hijacks financial services' Internet trafficJob SnijdersThe Diamond Age - Neal StephensonZie het privacybeleid op https://art19.com/privacy en de privacyverklaring van Californië op https://art19.com/privacy#do-not-sell-my-info.
In our fourteenth episode, we're taking a closer look at Resource Public Key Infrastructure (RPKI) in Australia and New Zealand with Terry Sweetser. Terry recently worked on an Internet Society project to measure RPKI adoption in Australia and New Zealand among its government services and critical infrastructure. We've invited him on to discuss the results and research methodology, including the challenges of working with public sources of data. Watch Terry's presentation on this project at APRICOT 2022 and check out the RPKI@APNIC portal for more information on RPKI as well as useful deployment case studies, how-to posts and links to hands-on APNIC Academy lessons and labs.
In our twelfth episode, we're talking all things Resource Public Key Infrastructure (RPKI) with Job Snijders, Principal Engineer at Fastly. Job shares his thoughts on the benefits of managing an RPKI publication point, including the experience and insights it can give you. We also touch on a recent IETF proposal he has assisted with that seeks to provide clearer, authenticated proof of the intent by address delegates and the future of routing securing including IRR and BGPsec. Check out RPKI @ APNIC portal for more information on RPKI as well as useful deployment case studies, how-to posts and links to hands-on APNIC Academy lessons and labs. The views expressed by the featured speakers are their own and do not necessarily reflect the views of APNIC.
No episódio de hoje do Camada 8, descubra o que é o protocolo BGP, sua importância para a Internet e como ele pode estar ligado com a indisponibilidade temporária do Facebook, WhatsApp e Instagram. Acompanhe os nossos especialistas do Ceptro.br|NIC.br em um bate papo descontraído sobre como a Internet funciona, protocolos utilizados na rede, como o BGP funciona, alguns problemas e limitações do BGP (roubo de prefixos e vazamento de rotas) e como solucionar esses problemas de segurança por meio do MANRS e ferramentas como o RPKI. Confira agora no Camada 8! Links citados no episódio: Semana de Infraestrutura da Internet no Brasil: https://nic.br/semanainfrabr/ GTER 50 | GTS 36: https://gtergts.nic.br/ IX Fórum: https://forum.ix.br/ IGF 2021: https://www.intgovforum.org/en/content/igf-2021 Cidadão na Rede: https://cidadaonarede.nic.br/pt/ Live Intra Rede: https://intrarede.nic.br/live-novos-padroes-2021/ Curso BCOP EaD: https://cursoseventos.nic.br/curso/curso-bcop/ Redes Sociais: https://www.youtube.com/nicbrvideos/ https://www.twitter.com/comunicbr/ https://www.telegram.me/nicbr/ https://www.linkedin.com/company/nic-br/ https://www.instagram.com/nicbr/ https://www.facebook.com/nic.br/ https://www.flickr.com/NICbr/ Contato: Equipe Ceptro.br cursosceptro@nic.br Veja também: https://nic.br/ https://ceptro.br/
Den senaste tiden har internets infrastruktur drabbats allvarligt. I april skruvade några oaktsamma tekniker i ryska Rostelecom så att en stor mängd av internets trafik gick igenom Ryssland. en så kallad BGP hijack var ett faktum! Utöver detta har Mattias Jadesköld och Erik Zalitis Facebook-haveriet färskt i minnet (ja, det var ju bara en vecka sedan) och diskuterar om det möjligen hänger ihop. 16:09 börjar vi prata om Facebook, efter att ha diskuterat BGP. Och nu en kavalkad av några förkortningar som nämns i programmet - BGP, ISP, DNS, ROV och RPKI. Show notes: https://www.itsakerhetspodden.se/138-nar-facebook-var-nere/
Our community has been talking about BGP security for over 20 years. While MANRS and the RPKI have made some headway in securing BGP, the process of deciding on a method to provide at least the information providers need to make more rational decisions about the validity of individual routes is still ongoing. Geoff Huston joins Alvaro, Russ, and Tom to discuss how we got here and whether we will learn from our mistakes.
Our community has been talking about BGP security for over 20 years. While MANRS and the RPKI have made some headway in securing BGP, the process of deciding on a method to provide at least the information providers need to make more rational decisions about the validity of individual routes is still ongoing. Geoff Huston joins Alvaro, Russ, and Tom to discuss how we got here and whether we will learn from our mistakes.
Neste episódio falamos sobre uma solução para alguns dos principais problemas de segurança no roteamento da Internet, o RPKI. Explicamos o que é RPKI e seu funcionamento básico, o motivo dele ser muito importante para o roteamento BGP, a maneira como ele atua para evitar o vazamento de rotas e Roubo de prefixos e muito mais. Venha ouvir essa conversa descontraída e aprender com os instrutores do CEPTRO.br. Ouça agora no Camada 8! Registro.br https://registro.br/ IX.br https://ix.br/ RPKI Tools https://nlnetlabs.nl/projects/rpki/ Cloudflare's RPKI Toolkit https://blog.cloudflare.com/cloudflares-rpki-toolkit/ Projeto FORT https://fortproject.net/pt/home [#SemanaCap On-line] Curso "Segurança no roteamento com RPKI" https://www.youtube.com/watch?v=jSvMCjPoFME [GTER 48 | GTS 34] RPKI no Brasil https://www.youtube.com/watch?v=6HSrGXSe4cM [GTER 48 | GTS 34] Introducing Krill: Routing security with RPKI (Inglês) https://www.youtube.com/watch?v=j54Fk5Zrz8w [GTER 49] Um ano de RPKI no Brasil - Experiência e Novidades do Krill (Áudio em Inglês) https://www.youtube.com/watch?v=y0DHvlRzKLY Redes Sociais: https://www.youtube.com/nicbrvideos/ https://www.twitter.com/comunicbr/ https://www.telegram.me/nicbr/ https://www.linkedin.com/company/nic-br/ https://www.instagram.com/nicbr/ https://www.facebook.com/nic.br/ Contato: Equipe Ceptro.br cursosceptro@nic.br Direção e edição de áudio: Equipe de comunicação do NIC.br You Project Veja também: https://nic.br/ https://ceptro.br/
In this episode, Mattias Fridström and Tom ‘The Networking Nerd' Hollingsworth discuss if 5G will change the enterprise networks, weather enterprises understand how the cloud is connected, using the public Internet, DDoS and RPKI, and sustainability in networking.
On this episode of the MODEM Podcast, Nick and Chris C. bring on a special guest, Kevin Myers, to talk about the latest software updates from one of the underdogs of networking—MikroTik. MikroTik RouterOS v7 is the next version of MikroTik's routing software that promises to solve a lot of the longest-standing requests from users. Kevin and his consulting firm IP ArchiTechs have been hands-on users of MikroTik since the early days, so come and listen to us discuss multi-threaded BGP, IS-IS, RPKI, and maybe even a few war stories! Links Mentioned IP ArchiTechs Kevin's Blog RouterOS v7 First Look RouterOS v7 Performance Testing MikroTik IS-IS Forum Thread MANRS
"On this week’s episode of The Internet Report, Archana and I are thrilled to be joined by Martin Levy, who is a distinguished engineer at Cloudflare focused on BGP route security and expanding Cloudflare's global network footprint. Check out this week’s episode to hear his thoughts on BGP security, best practices such as using RPKI and some recent routing incidents. After speaking with Levy and hearing his perspective, we jump over to a discussion around some notable outages this past week, particularly one at Virgin Media that affected connectivity for users in the UK for several hours. After going through these events, we cover off on our usual health check of ISP, cloud, and collaboration service providers."
On this week’s episode, we discuss a recent BGP-related outage at a major public cloud provider, as well as a recent announcement that Cogent Networks has rolled out RPKI in an effort to strengthen its BGP route security. We’re also joined by Kemal Sanjta, principal engineer on our customer success team and our resident expert on Internet routing and security, to chat about these events. Catch this week’s episode here to dive into BGP with us.
RPKI permite a los titulares de direccionamiento público IP declarar sus recursos de forma verificada gracias a una cadena de certificados. El motivo de utilizar RPKI es conseguir que el encaminamiento en Internet sea más … La entrada Resource Public Key Infrastructure (RPKI) se publicó primero en Eduardo Collado.
NLnet Labs is a not-for-profit foundation with a long heritage in research and development, Internet architecture and governance, as well as stability and security in the area of DNS and inter-domain routing. In this episode you will hear all about doing good for the internet with open source, DNS and RPKI.
This week we have Greg, Mike Dave, and Wilson…all the familiar faces coming back! **Sponsors** Sonar.software Cambium ePMP Bundle **/Sponsors** This week we talk about: WISP Virtual Summit July 28th Save Dave’s brain RIP Ubiquiti Unifi Video – EOL 1/1/2021 zwift.com Cloudflare DNS outage David – Arduino, PHP programming, cycling and weight loss, new(More)…
On this week's episode, we discuss a recent BGP-related outage at a major public cloud provider, as well as a recent announcement that Cogent Networks has rolled out RPKI in an effort to strengthen its BGP route security. We're also joined by Kemal Sanjta, principal engineer on our customer success team and our resident expert on Internet routing and security, to chat about these events. Catch this week's episode here to dive into BGP with us.
On this week's episode of The Internet Report, Archana and I are thrilled to be joined by Martin Levy, who is a distinguished engineer at Cloudflare focused on BGP route security and expanding Cloudflare's global network footprint. Check out this week's episode to hear his thoughts on BGP security, best practices such as using RPKI and some recent routing incidents. After speaking with Levy and hearing his perspective, we jump over to a discussion around some notable outages this past week, particularly one at Virgin Media that affected connectivity for users in the UK for several hours. After going through these events, we cover off on our usual health check of ISP, cloud, and collaboration service providers.
Apple/Google Contact Tracing, Best VPNs to protect you.Apple/Google Contact Tracing UpdateiOS 0-Day Alert! Update Apple MailBest VPNs to protect you from the Five EyesTypoSquatting attacksVitamin D linked to COVID-19 mortalityResource Public Key InfrastructureHow BGP can break the InternetWe invite you to read our show notes at https://www.grc.com/sn/SN-764-Notes.pdf Hosts: Steve Gibson and Leo Laporte Download or subscribe to this show at https://twit.tv/shows/security-now. You can submit a question to Security Now! at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Sponsors: Wasabi.com offer code SECURITYNOW expressvpn.com/securitynow
Apple/Google Contact Tracing, Best VPNs to protect you.Apple/Google Contact Tracing UpdateiOS 0-Day Alert! Update Apple MailBest VPNs to protect you from the Five EyesTypoSquatting attacksVitamin D linked to COVID-19 mortalityResource Public Key InfrastructureHow BGP can break the InternetWe invite you to read our show notes at https://www.grc.com/sn/SN-764-Notes.pdf Hosts: Steve Gibson and Leo Laporte Download or subscribe to this show at https://twit.tv/shows/security-now. You can submit a question to Security Now! at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Sponsors: Wasabi.com offer code SECURITYNOW expressvpn.com/securitynow
Apple/Google Contact Tracing, Best VPNs to protect you.Apple/Google Contact Tracing UpdateiOS 0-Day Alert! Update Apple MailBest VPNs to protect you from the Five EyesTypoSquatting attacksVitamin D linked to COVID-19 mortalityResource Public Key InfrastructureHow BGP can break the InternetWe invite you to read our show notes at https://www.grc.com/sn/SN-764-Notes.pdf Hosts: Steve Gibson and Leo Laporte Download or subscribe to this show at https://twit.tv/shows/security-now. You can submit a question to Security Now! at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Sponsors: Wasabi.com offer code SECURITYNOW expressvpn.com/securitynow
Apple/Google Contact Tracing, Best VPNs to protect you.Apple/Google Contact Tracing UpdateiOS 0-Day Alert! Update Apple MailBest VPNs to protect you from the Five EyesTypoSquatting attacksVitamin D linked to COVID-19 mortalityResource Public Key InfrastructureHow BGP can break the InternetWe invite you to read our show notes at https://www.grc.com/sn/SN-764-Notes.pdf Hosts: Steve Gibson and Leo Laporte Download or subscribe to this show at https://twit.tv/shows/security-now. You can submit a question to Security Now! at the GRC Feedback Page. For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6. Sponsors: Wasabi.com offer code SECURITYNOW expressvpn.com/securitynow
Nathalie Trenaman is the Routing Security Programme Manager at RIPE NCC. Rick & Melchior ask her everything about what RIPE NCC does, why should we care about Routing Security, RPKI and of course we talk about if and how we can get IPv4 address space.
La certificación de recursos numéricos de internet se realiza a través del protocolo RPKI, el cual es un protocolo que permite validar el ASN que originó una ruta o prefijo IP en internet. Modo hosted en el cual LACNIC emite los certificados de recursos y almacena tanto claves públicas como privadas. Los certificados se emiten a demanda de las organizaciones y las operaciones se realizan a través de interfaz web. Modo delegated, en el cual aplica el estándar updown RPKI, protocolo de aprovisionamiento de certificados RPKI -interacción request / response; cliente ‘down’ / servidor ‘up'- envía solicitudes que se procesan, generan y envían la respuesta. GITHUB: https://github.com/LACNIC/hackathon-2019/tree/master/updown
Job Snijders stond aan de wieg van de stichting NLNOG, de Nederlandse Network Operator Group. NLNOG staat bekend als plek waar kennis en kunde omtrent het draaien van het internet wordt uitgewisseld in een informele sfeer. Daar wil je bijhoren als jouw bedrijf een AS-nummer heeft, of als je anderszins betrokken bent bij het reilen en zeilen van ons favoriete internationale netwerk.We krijgen tijdens deze aflevering een spoedcursus in de werking van BGP, en hoe we ons internet veilig kunnen houden voor lekken en fuckups door middel van RPKI. Een leerzaam gesprek voor iedereen die beter wil begrijpen hoe ons internet nou eigenlijk werkt.Tijdschema0:00:00 Start0:00:30 Aankondiging Job Snijders0:02:15 NLNOG0:12:41 Alles over BGP0:45:48 Alles over RPKI1:21:20 Vragen van de luisteraars1:41:02 Tips1:48:43 AfkondigingTipsJob SnijdersRPKI testInternet Historianop YoutubeRandalSideshift.aiDe TweedeFlorisYouTube Music
Долго и обстоятельно про как всеобщее доверие в BGP обернулось бедой и что с этим можно делать. А главное, хочет ли кто-то что-то с этим делать. Кто: Сергей Колобов. Системный инженер крупного вендора. Про что: Опасности BGP, RPKI, DISCO. Скачать файл подкаста Полезные ссылкиRPKI Documentation — rpki.readthedocs.io/en/latest/index.html NIST Special Publication — nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189-draft.pdf DISCO — www.researchgate.net/publication/328896238_Perfect_is_the_Enemy_of_Good_Setting_Realistic_Goals_for_BGP_Security An Infrastructure to Support Secure Internet Routing — tools.ietf.org/html/rfc6480 NANOG74 Security Track — pc.nanog.org/static/published/meetings/NANOG74/1760/20181003_Tzvetanov_Security_Track_Bgp_v1.pdf BGP Prefix Origin Validation — tools.ietf.org/html/rfc6811 The Resource Public Key Infrastructure (RPKI) to Router Protocol — tools.ietf.org/html/rfc6810 Signaling Prefix Origin Validation Results from a Route Server to Peers — tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-02 BGP Prefix Origin Validation State Extended Community — tools.ietf.org/html/rfc8097 RPKI — The required cryptographic upgrade to BGP routing — blog.cloudflare.com/rpki/ Bamboozling Certificate Authorities with BGP — www.usenix.org/conference/usenixsecurity18/presentation/birge-lee Mutually Agreed Norms for Routing Security (MANRS) Implementation Guide — www.manrs.org/wp-content/uploads/2018/03/MANRS-BCOP-20170125.pdf Will the SIDR model succeed where the IRR model failed? (Part I) — blog.apnic.net/2015/06/01/will-the-sidr-model-succeed-where-the-irr-model-failed-part-i/ BGPsec and Reality — rule11.tech/bgpsec-and-reality/ How Secure are Secure Interdomain Routing Protocols? — www.cs.yale.edu/homes/schapira/BGPAttack.pdf Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization — datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-verification/ Добавить RSS в подкаст-плеер. Подкаст доступен в iTunes. Скачать все выпуски подкаста вы можете с яндекс-диска. Url podcast:https://dts.podtrac.com/redirect.mp3/fs.linkmeup.ru/podcasts/telecom/linkmeup-V074(2019-04).mp3
Долго и обстоятельно про как всеобщее доверие в BGP обернулось бедой и что с этим можно делать. А главное, хочет ли кто-то что-то с этим делать. Кто: Сергей Колобов. Системный инженер крупного вендора. Про что: Опасности BGP, RPKI, DISCO. Скачать файл подкаста Полезные ссылкиRPKI Documentation — rpki.readthedocs.io/en/latest/index.html NIST Special Publication — nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189-draft.pdf DISCO — www.researchgate.net/publication/328896238_Perfect_is_the_Enemy_of_Good_Setting_Realistic_Goals_for_BGP_Security An Infrastructure to Support Secure Internet Routing — tools.ietf.org/html/rfc6480 NANOG74 Security Track — pc.nanog.org/static/published/meetings/NANOG74/1760/20181003_Tzvetanov_Security_Track_Bgp_v1.pdf BGP Prefix Origin Validation — tools.ietf.org/html/rfc6811 The Resource Public Key Infrastructure (RPKI) to Router Protocol — tools.ietf.org/html/rfc6810 Signaling Prefix Origin Validation Results from a Route Server to Peers — tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-02 BGP Prefix Origin Validation State Extended Community — tools.ietf.org/html/rfc8097 RPKI — The required cryptographic upgrade to BGP routing — blog.cloudflare.com/rpki/ Bamboozling Certificate Authorities with BGP — www.usenix.org/conference/usenixsecurity18/presentation/birge-lee Mutually Agreed Norms for Routing Security (MANRS) Implementation Guide — www.manrs.org/wp-content/uploads/2018/03/MANRS-BCOP-20170125.pdf Will the SIDR model succeed where the IRR model failed? (Part I) — blog.apnic.net/2015/06/01/will-the-sidr-model-succeed-where-the-irr-model-failed-part-i/ BGPsec and Reality — rule11.tech/bgpsec-and-reality/ How Secure are Secure Interdomain Routing Protocols? — www.cs.yale.edu/homes/schapira/BGPAttack.pdf Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization — datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-verification/ Добавить RSS в подкаст-плеер. Подкаст доступен в iTunes. Скачать все выпуски подкаста вы можете с яндекс-диска.
Долго и обстоятельно про как всеобщее доверие в BGP обернулось бедой и что с этим можно делать. А главное, хочет ли кто-то что-то с этим делать. Кто: Сергей Колобов. Системный инженер крупного вендора. Про что: Опасности BGP, RPKI, DISCO. Скачать файл подкаста Полезные ссылкиRPKI Documentation — rpki.readthedocs.io/en/latest/index.html NIST Special Publication — nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189-draft.pdf DISCO — www.researchgate.net/publication/328896238_Perfect_is_the_Enemy_of_Good_Setting_Realistic_Goals_for_BGP_Security An Infrastructure to Support Secure Internet Routing — tools.ietf.org/html/rfc6480 NANOG74 Security Track — pc.nanog.org/static/published/meetings/NANOG74/1760/20181003_Tzvetanov_Security_Track_Bgp_v1.pdf BGP Prefix Origin Validation — tools.ietf.org/html/rfc6811 The Resource Public Key Infrastructure (RPKI) to Router Protocol — tools.ietf.org/html/rfc6810 Signaling Prefix Origin Validation Results from a Route Server to Peers — tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-02 BGP Prefix Origin Validation State Extended Community — tools.ietf.org/html/rfc8097 RPKI — The required cryptographic upgrade to BGP routing — blog.cloudflare.com/rpki/ Bamboozling Certificate Authorities with BGP — www.usenix.org/conference/usenixsecurity18/presentation/birge-lee Mutually Agreed Norms for Routing Security (MANRS) Implementation Guide — www.manrs.org/wp-content/uploads/2018/03/MANRS-BCOP-20170125.pdf Will the SIDR model succeed where the IRR model failed? (Part I) — blog.apnic.net/2015/06/01/will-the-sidr-model-succeed-where-the-irr-model-failed-part-i/ BGPsec and Reality — rule11.tech/bgpsec-and-reality/ How Secure are Secure Interdomain Routing Protocols? — www.cs.yale.edu/homes/schapira/BGPAttack.pdf Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization — datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-verification/ Добавить RSS в подкаст-плеер. Подкаст доступен в iTunes. Скачать все выпуски подкаста вы можете с яндекс-диска. Url podcast:https://dts.podtrac.com/redirect.mp3/fs.linkmeup.ru/podcasts/telecom/linkmeup-V074(2019-04).mp3
DragonflyBSD 5.4 has been released, down the Gopher hole with OpenBSD, OpenBSD in stereo with VFIO, BSD/OS the best candidate for legally tested open source Unix, OpenBGPD adds diversity to the routing server landscape, and more. Headlines DragonflyBSD 5.4 released DragonFly version 5.4 brings a new system compiler in GCC 8, improved NUMA support, a large of number network and virtual machine driver updates, and updates to video support. This release is 64-bit only, as with previous releases. The details of all commits between the 5.2 and 5.4 branches are available in the associated commit messages for 5.4.0rc and 5.4.0. Big-ticket items Much better support for asymmetric NUMA (Non-Uniform Memory Access) configurations. In particular, both the memory subsystem and the scheduler now understand the Threadripper 2990WX’s architecture. The scheduler will prioritize CPU nodes with direct-attached memory and the memory subsystem will normalize memory queues for CPU nodes without direct-attached memory (which improves cache locality on those CPUs). Incremental performance work. DragonFly as a whole is very SMP friendly. The type of performance work we are doing now mostly revolves around improving fairness for shared-vs-exclusive lock clashes, reducing cache ping-ponging due to non-contending SMP locks (i.e. massive use of shared locks on shared resources), and so forth. Major updates to dports brings us to within a week or two of FreeBSD’s ports as of this writing, in particular major updates to chromium, and making the whole mess work with gcc-8. Major rewriting of the tty clist code and the tty locking code, significantly improving concurrency across multiple ttys and ptys. GCC 8 DragonFly now ships with GCC 8.0, and runs as the default compiler. It is also now used for building dports. GCC 4.7.4 and GCC 5.4.1 are still installed. 4.7.4 is our backup compiler, and 5.4.1 is still there to ensure a smooth transition, but should generally not be used. buildworld builds all three by default to ensure maximum compatibility. Many passes through world sources were made to address various warnings and errors the new GCC brought with it. HAMMER2 HAMMER2 is recommended as the default root filesystem in non-clustered mode. Clustered support is not yet available. Increased bulkfree cache to reduce the number of iterations required. Fixed numerous bugs. Improved support on low-memory machines. Significant pre-work on the XOP API to help support future networked operations. Details Checksums MD5 (dfly-x86_64-5.4.0_REL.img) = 7277d7cffc92837c7d1c5dd11a11b98f MD5 (dfly-x86_64-5.4.0_REL.iso) = 6da7abf036fe9267479837b3c3078408 MD5 (dfly-x86_64-5.4.0_REL.img.bz2) = a77a072c864f4b72fd56b4250c983ff1 MD5 (dfly-x86_64-5.4.0_REL.iso.bz2) = 4dbfec6ccfc1d59c5049455db914d499 Downloads Links DragonFly BSD is 64-bit only, as announced during the 3.8 release. USB: dfly-x86_64-5.4.0_REL.img as bzip2 file ISO: dfly-x86_64-5.4.0_REL.iso as bzip2 file Uncompressed ISO: dfly-x86_64-5.4.0_REL.iso (For use with VPS providers as an install image.) Down the Gopher hole with OpenBSD, Gophernicus, and TLS In the early 2000s I thought I had seen the worst of the web - Java applets, Macromedia (>Adobe) Flash, animated GIFs, javascript snow that kept you warm in the winter by burning out your CPU, and so on. For a time we learned from these mistakes, and started putting the burden on the server-side - then with improvements in javascript engines we started abusing it again with JSON/AJAX and it all went down hill from there. Like cloud computing, blockchains, machine learning and a tonne of other a la mode technologies around today - most users and service providers don’t need websites that consume 1GB of memory processing JS and downloading 50MB of compressed data just to read Alice’s one-page travel blog or Bob’s notes on porting NetBSD to his blood-pressure monitor. Before the HTTP web we relied on Prestel/Minitel style systems, BBS systems, and arguably the most accessible of all - Gopher! Gopher was similar to the locally accessed AmigaGuide format, in that it allowed users to search and retrieve documents interactively, with links and cross-references. Its efficiency and distraction-free nature make it attractive to those who are tired of the invasive, clickbait, ad-filled, javascript-laden web2/3.x. But enough complaining and evangelism - here’s how to get your own Gopher Hole! Gophernicus is a modern gopher daemon which aims to be secure (although it still uses inetd -_-); it’s even in OpenBSD ports so at least we can rely on it to be reasonably audited. If you need a starting point with Gopher, SDF-EU’s wiki has a good article here. https://sdfeu.org/w/tutorials:gopher Finally, if you don’t like gopher(1) - there’s always lynx(1) or NCSA Mosaic! https://cryogenix.net/NCSA_Mosaic_OpenBSD.html I’ve added TLS support to Gophernicus so you don’t need to use stunnel anymore. The code is ugly and unpolished though so I wouldn’t recommend for production use. https://github.com/0x16h/gophernicus https://github.com/0x16h/gophernicus/blob/master/INSTALL.openbsd News Roundup OpenBSD in Stereo with Linux VFIO I use a Huawei Matebook X as my primary OpenBSD laptop and one aspect of its hardware support has always been lacking: audio never played out of the right-side speaker. The speaker did actually work, but only in Windows and only after the Realtek Dolby Atmos audio driver from Huawei was installed. Under OpenBSD and Linux, and even Windows with the default Intel sound driver, audio only ever played out of the left speaker. Now, after some extensive reverse engineering and debugging with the help of VFIO on Linux, I finally have audio playing out of both speakers on OpenBSD. VFIO The Linux kernel has functionality called VFIO which enables direct access to a physical device (like a PCI card) from userspace, usually passing it to an emulator like QEMU. To my surprise, these days, it seems to be primarily by gamers who boot Linux, then use QEMU to run a game in Windows and use VFIO to pass the computer’s GPU device through to Windows. By using Linux and VFIO, I was able to boot Windows 10 inside of QEMU and pass my laptop’s PCI audio device through to Windows, allowing the Realtek audio drivers to natively control the audio device. Combined with QEMU’s tracing functionality, I was able to get a log of all PCI I/O between Windows and the PCI audio device. Using VFIO To use VFIO to pass-through a PCI device, it first needs to be stubbed out so the Linux kernel’s default drivers don’t attach to it. GRUB can be configured to instruct the kernel to ignore the PCI audio device (8086:9d71) and explicitly enable the Intel IOMMU driver by adding the following to /etc/default/grub and running update-grub With the audio device stubbed out, a new VFIO device can be created from it Then the VFIO device (00:1f.3) can be passed to QEMU I was using my own build of QEMU for this, due to some custom logging I needed (more on that later), but the default QEMU package should work fine. The events.txt was a file of all VFIO events I wanted logged (which was all of them). Since I was frequently killing QEMU and restarting it, Windows 10 wanted to go through its unexpected shutdown routine each time (and would sometimes just fail to boot again). To avoid this and to get a consistent set of logs each time, I used qemu-img to take a snapshot of a base image first, then boot QEMU with that snapshot. The snapshot just gets thrown away the next time qemu-img is run and Windows always starts from a consistent state. QEMU will now log each VFIO event which gets saved to a debug-output file. With a full log of all PCI I/O activity from Windows, I compared it to the output from OpenBSD and tried to find the magic register writes that enabled the second speaker. After days of combing through the logs and annotating them by looking up hex values in the documentation, diffing runtime register values, and even brute-forcing it by mechanically duplicating all PCI I/O activity in the OpenBSD driver, nothing would activate the right speaker. One strange thing that I noticed was if I booted Windows 10 in QEMU and it activated the speaker, then booted OpenBSD in QEMU without resetting the PCI device’s power in-between (as a normal system reboot would do), both speakers worked in OpenBSD and the configuration that the HDA controller presented was different, even without any changes in OpenBSD. A Primer on Intel HDA Most modern computers with integrated sound chips use an Intel High Definition Audio (HDA) Controller device, with one or more codecs (like the Realtek ALC269) hanging off of it. These codecs do the actual audio processing and communicate with DACs and ADCs to send digital audio to the connected speakers, or read analog audio from a microphone and convert it to a digital input stream. In my Huawei Matebook X, this is done through a Realtek ALC298 codec. On OpenBSD, these HDA controllers are supported by the azalia(4) driver, with all of the per-codec details in the lengthy azalia_codec.c file. This file has grown quite large with lots of codec- and machine-specific quirks to route things properly, toggle various GPIO pins, and unmute speakers that are for some reason muted by default. The azalia driver talks to the HDA controller and sets up various buffers and then walks the list of codecs. Each codec supports a number of widget nodes which can be interconnected in various ways. Some of these nodes can be reconfigured on the fly to do things like turning a microphone port into a headphone port. The newer Huawei Matebook X Pro released a few months ago is also plagued with this speaker problem, although it has four speakers and only two work by default. A fix is being proposed for the Linux kernel which just reconfigures those widget pins in the Intel HDA driver. Unfortunately no pin reconfiguration is enough to fix my Matebook X with its two speakers. While reading more documentation on the HDA, I realized there was a lot more activity going on than I was able to see through the PCI tracing. For speed and efficiency, HDA controllers use a DMA engine to transfer audio streams as well as the commands from the OS driver to the codecs. In the output above, the CORBWP=0; size=256 and RIRBRP=0, size=256 indicate the setup of the CORB (Command Output Ring Buffer) and RIRB (Response Input Ring Buffer) each with 256 entries. The HDA driver allocates a DMA address and then writes it to the two CORBLBASE and CORBUBASE registers, and again for the RIRB. When the driver wants to send a command to a codec, such as CORB_GET_PARAMETER with a parameter of COP_VOLUME_KNOB_CAPABILITIES, it encodes the codec address, the node index, the command verb, and the parameter, and then writes that value to the CORB ring at the address it set up with the controller at initialization time (CORBLBASE/CORBUBASE) plus the offset of the ring index. Once the command is on the ring, it does a PCI write to the CORBWP register, advancing it by one. This lets the controller know a new command is queued, which it then acts on and writes the response value on the RIRB ring at the same position as the command (but at the RIRB’s DMA address). It then generates an interrupt, telling the driver to read the new RIRBWP value and process the new results. Since the actual command contents and responses are handled through DMA writes and reads, these important values weren’t showing up in the VFIO PCI trace output that I had gathered. Time to hack QEMU. Logging DMA Memory Values in QEMU Since DMA activity wouldn’t show up through QEMU’s VFIO tracing and I obviously couldn’t get Windows to dump these values like I could in OpenBSD, I could make QEMU recognize the PCI write to the CORBWP register as an indication that a command has just been written to the CORB ring. My custom hack in QEMU adds some HDA awareness to remember the CORB and RIRB DMA addresses as they get programmed in the controller. Then any time a PCI write to the CORBWP register is done, QEMU fetches the new CORB command from DMA memory, decodes it into the codec address, node address, command, and parameter, and prints it out. When a PCI read of the RIRBWP register is requested, QEMU reads the response and prints the corresponding CORB command that it stored earlier. With this hack in place, I now had a full log of all CORB commands and RIRB responses sent to and read from the codec: An early version of this patch left me stumped for a few days because, even after submitting all of the same CORB commands in OpenBSD, the second speaker still didn’t work. It wasn’t until re-reading the HDA spec that I realized the Windows driver was submitting more than one command at a time, writing multiple CORB entries and writing a CORBWP value that was advanced by two. This required turning my CORB/RIRB reading into a for loop, reading each new command and response between the new CORBWP/RIRBWP value and the one previously seen. Sure enough, the magic commands to enable the second speaker were sent in these periods where it submitted more than one command at a time. Minimizing the Magic The full log of VFIO PCI activity from the Windows driver was over 65,000 lines and contained 3,150 CORB commands, which is a lot to sort through. It took me a couple more days to reduce that down to a small subset that was actually required to activate the second speaker, and that could only be done through trial and error: Boot OpenBSD with the full list of CORB commands in the azalia driver Comment out a group of them Compile kernel and install it, halt the QEMU guest Suspend and wake the laptop, resetting PCI power to the audio device to reset the speaker/Dolby initialization and ensure the previous run isn’t influencing the current test (I’m guessing there is an easier to way to reset PCI power than suspending the laptop, but oh well) Start QEMU, boot OpenBSD with the new kernel Play an MP3 with mpg123 which has alternating left- and right-channel audio and listen for both channels to play This required a dozen or so iterations because sometimes I’d comment out too many commands and the right speaker would stop working. Other times the combination of commands would hang the controller and it wouldn’t process any further commands. At one point the combination of commands actually flipped the channels around so the right channel audio was playing through the left speaker. The Result After about a week of this routine, I ended up with a list of 662 CORB commands that are needed to get the second speaker working. Based on the number of repeated-but-slightly-different values written with the 0x500 and 0x400 commands, I’m guessing this is some kind of training data and that this is doing the full Dolby/Atmos system initialization, not just turning on the second speaker, but I could be completely wrong. In any case, the stereo sound from OpenBSD is wonderful now and I can finally stop downmixing everything to mono to play from the left speaker. In case you ever need to do this, sndiod can be run with -c 0:0 to reduce the channels to one. Due to the massive size of the code needed for this quirk, I’m not sure if I’ll be committing it upstream in OpenBSD or just saving it for my own tree. But at least now the hardware support chart for my Matebook is all yeses for the things I care about. I’ve also updated the Linux bug report that I opened before venturing down this path, hoping one of the maintainers of that HDA code that works at Intel or Realtek knew of a solution I could just port to OpenBSD. I’m curious to see what they’ll do with it. Why BSD/OS is the best candidate for being the only tested legally open UNIX Introduction The UNIX® system is an old operating system, possibly older than many of the readers of this post. However, despite its age, it still has not been open sourced completely. In this post, I will try to detail which parts of which UNIX systems have not yet been open sourced. I will focus on the legal situation in Germany in particular, taking it representative of European law in general – albeit that is a stretch, knowing the diversity of European jurisdictions. Please note that familiarity with basic terms of copyright law is assumed. Ancient UNIX The term “Ancient UNIX” refers to the versions of UNIX up to and including Seventh Edition UNIX (1979) including the 32V port to the VAX. Ancient UNIX was created at Bell Laboratories, a subsidiary of AT&T at the time. It was later transferred of the AT&T UNIX Support Group, then AT&T Information Systems and finally the AT&T subsidiary UNIX System Laboratories, Inc. (USL). The legal situation differs between the United States of America and Germany. In a ruling as part of the UNIX System Laboratories, Inc. v. Berkeley Software Design, Inc. (USL v. BSDi) case, a U.S. court found that USL had no copyright to the Seventh Edition UNIX system and 32V – arguably, by extension, all earlier versions of Ancient UNIX as well – because USL/AT&T had failed to affix copyright notices and could not demonstrate a trade secret. Due to the obsessive tendency of U.S. courts to consider themselves bound to precedents (cf. the infamous Pierson v. Post case), it can be reasonably expected that this ruling would be honored and applied in subsequent cases. Thus under U.S. law, Ancient UNIX can be safely assumed to belong in the public domain. The situation differs in Germany. Unlike the U.S., copyright never needed registration in order to exist. Computer programs are works in the sense of the German 1965 Act on Copyright and Related Rights (Copyright Act, henceforth CopyA) as per CopyA § 2(1) no. 1. Even prior to the amendment of CopyA § 2(1) to include computer programs, computer programs have been recognized as copyrightable works by the German Supreme Court (BGHZ 112, 264 Betriebssystem, no. 19); CopyA § 137d(1) rightly clarifies that. The copyright holder at 1979 would still have been USL via Bell Labs and AT&T. Copyright of computer programs is transferred to the employer upon creation under CopyA § 69(1). Note that this does not affect expiry (Daniel Kaboth/Benjamin Spies, commentary on CopyA §§ 69a‒69g, in: Hartwig Ahlberg/Horst-Peter Götting (eds.), Urheberrecht: UrhG, KUG, VerlG, VGG, Kommentar, 4th ed., C. H. Beck, 2018, no. 16 ad CopyA § 69b; cf. Bundestag-Drucksache [BT-Drs.] 12/4022, p. 10). Expiry occurs 70 years after the death of the (co-)author that died most recently as per CopyA § 65(1) and 64; this has been the case since at least the 1960s, meaning there is no way for copyright to have expired already (old version, as per Bundesgesetzblatt Part I No. 51 of September 16, 1965, pp. 1273‒1294). In Germany, private international law applies the so-called “Territorialitätsprinzip” for intellectual property rights. This means that the effect of an intellectual property right is limited to the territory of a state (Anne Lauber-Rönsberg, KollisionsR, in: Hartwig Ahlberg/Horst-Peter Götting (eds.), ibid., pp. 2241 et seqq., no. 4). Additionally, the “Schutzlandprinzip” applies; this means that protection of intellectual property follows the lex loci protectionis, i.e. the law of the country for which protection is sought (BGH GRUR 2015, 264 HiHotel II, no. 25; BGH GRUR 2003, 328 Sender Felsberg, no. 24), albeit this is criticized in parts of doctrine (Lauber-Rönsberg, ibid., no. 10). The “Schutzlandprinzip” requires that the existence of an intellectual property right be verified as well (BGH ZUM 2016, 522 Wagenfeld-Leuchte II, no. 19). Thus, in Germany, copyright on Ancient UNIX is still alive and well. Who has it, though? A ruling by the U.S. Court of Appeals, Tenth Circuit, in the case of The SCO Group, Inc. v. Novell, Inc. (SCO v. Novell) in the U.S. made clear that Novell owns the rights to System V – thus presumably UNIX System III as well – and Ancient UNIX, though SCO acquired enough rights to develop UnixWare/OpenServer (Ruling 10-4122 [D.C. No. 2:04-CV-00139-TS], pp. 19 et seq.). Novell itself was purchased by the Attachmate Group, which was in turn acquired by the COBOL vendor Micro Focus. Therefore, the rights to SVRX and – outside the U.S. – are with Micro Focus right now. If all you care about is the U.S., you can stop reading about Ancient UNIX here. So how does the Caldera license factor into all of this? For some context, the license was issued January 23, 2002 and covers Ancient UNIX (V1 through V7 including 32V), specifically excluding System III and System V. Caldera, Inc. was founded in 1994. The Santa Cruz Operation, Inc. sold its rights to UNIX to Caldera in 2001, renamed itself to Tarantella Inc. and Caldera renamed itself The SCO Group. Nemo plus iuris ad alium transferre potest quam ipse habet; no one can transfer more rights than he has. The question now becomes whether Caldera had the rights to issue the Caldera license. I’ve noted it above but it needs restating: Foreign decisions are not necessarily accepted in Germany due to the “Territorialitätsprinzip” and “Schutzlandprinzip” – however, I will be citing a U.S. ruling for its assessment of the facts for the sake of simplicity. As per ruling 10-4122, “The district court found the parties intended for SCO to serve as Novell’s agent with respect to the old SVRX licenses and the only portion of the UNIX business transferred outright under the APA [asset purchase agreement] was the ability to exploit and further develop the newer UnixWare system. SCO was able to protect that business because it was able to copyright its own improvements to the system. The only reason to protect the earlier UNIX code would be to protect the existing SVRX licenses, and the court concluded Novell retained ultimate control over that portion of the business under the APA.” The relevant agreements consist of multiple pieces: the base Asset Purchase Agreement “APA” (Part I) the base Asset Purchase Agreement “APA” (Part II) the Operating Agremeent and Amendment 1 to the APA the Amendment 2 to the APA The APA dates September 19, 1995, from before the Caldera license. Caldera cannot possibly have acquired rights that The Santa Cruz Operation, Inc. itself never had. Furthermore, I’ve failed to find any mention of Ancient UNIX; all that is transferred is rights to SVRX. Overall, I believe that the U.S. courts’ assesment of the facts represents the situation accurately. Thus for all intents and purposes, UNIX up to and including System V remained with Novell/Attachmate/Micro Focus. Caldera therefore never had any rights to Ancient UNIX, which means it never had the rights to issue the Caldera license. The Caldera license is null and void – in the U.S. because the copyright has been lost due to formalities, everywhere else because Caldera never had the rights to issue it. The first step to truly freeing UNIX would this be to get Micro Focus to re-issue the Caldera license for Ancient UNIX, ideally it would now also include System III and System V. BSD/OS Another operating system near UNIX is of interest. The USL v. BSDi lawsuit includes two parties: USL, which we have seen above, and Berkeley Software Design, Inc. BSDi sold BSD/386 (later BSD/OS), which was a derivative of 4.4BSD. The software parts of the BSDi company were acquired by Wind River Systems, whereas the hardware parts went to iXsystems. Copyright is not disputed there, though Wind River Systems ceased selling BSD/OS products 15 years ago, in 2003. In addition, Wind River System let their trademark on BSD expire, though this is without consequence for copyright. BSD/OS is notable in the sense that it powered much of early internet infrastructure. Traces of its legacy can still be found on Richard Stevens’ FAQ. To truly make UNIX history free, BSD/OS would arguably also need to see a source code release. BSD/OS at least in its earliest releases under BSDi would ship with source code, though under a non-free license, far from BSD or even GPL licensing. System V The fate of System V as a whole is difficult to determine. Various licenses have been granted to a number of vendors (Dell UNIX comes to mind; HP for HP-UX, IBM for AIX, SGI UNIX, etc.). Sun released OpenSolaris – notoriously, Oracle closed the source to Solaris again after its release –, which is a System V Release 4 descendant. However, this means nothing for the copyright or licensing status of System V itself. Presumably, the rights with System V still remain with Novell (now Micro Focus): SCO managed to sublicense rights to develop and sell UnixWare/OpenServer, themselves System V/III descendants, to unXis, Inc. (now known as Xinuos, Inc.), which implies that Xinuos is not the copyright holder of System V. Obviously, to free UNIX, System V and its entire family of descendants would also need to be open sourced. However, I expect tremendous resistance on part of all the companies mentioned. As noted in the “Ancient UNIX” section, Micro Focus alone would probably be sufficient to release System V, though this would mean nothing for the other commercial System V derivatives. Newer Research UNIX The fate of Bell Labs would be a different one; it would go on to be purchased by Lucent, now part of Nokia. After commercial UNIX got separated out to USL, Research UNIX would continue to exist inside of Bell Labs. Research UNIX V8, V9 and V10 were not quite released by Alcatel-Lucent USA Inc. and Nokia in 2017. However, this is merely a notice that the companies involved will not assert their copyrights only with respect to any non-commercial usage of the code. It is still not possible, over 30 years later, to freely use the V8 code. Conclusion In the U.S., Ancient UNIX is freely available. People located everywhere else, however, are unable to legally obtain UNIX code for any of the systems mentioned above. The exception being BSD/OS, assuming a purchase of a legitimate copy of the source code CD. This is deeply unsatisfying and I implore all involved companies to consider open sourcing (preferably under a BSD-style license) their code older than a decade, if nothing else, then at least for the sake of historical purposes. I would like to encourage everybody reading this to consider reaching out to Micro Focus and Wind River Systems about System V and BSD/OS, respectively. Perhaps the masses can change their minds. A small note about patents: Some technologies used in newer iterations of the UNIX system (in particular the System V derivatives) may be encumbered with software patents. An open source license will not help against patent infringement claims. However, the patents on anything used in the historical operating systems will certainly have expired by now. In addition, European readers can ignore this entirely – software patents just aren’t a thing. OpenBGPD - Adding Diversity to the Route Server Landscape Introduction As of last year, there was effectively only a single solution in the Route Server vendor market: the BIRD Internet routing daemon. NIC.CZ (the organisation developing BIRD) has done fantastic work on maintaining their BGP-4 implementation, however, it’s not healthy to have virtually every Internet Exchange Point (IXP) in the RIPE NCC service region depend on a single open source project. The current situation can be compared to the state of the DNS root nameservers back in 2002 - their dependence on the BIND nameserver daemon and the resulting development of NSD as an alternative by NLnet, in cooperation with the RIPE NCC. OpenBGPD used to be one of the most popular Route Server implementations until the early 2010s. OpenBGPD’s main problem was that its performance couldn’t keep up with the Internet’s growth, so it lost market share. An analysis by Job Snijders suggested that a modernised OpenBGPD distribution would be a most viable option to regain diversity on the Route Server level. Missing features in OpenBGPD The following main missing features were identified in OpenBGPD: Performance In previous versions of OpenBGPD, the filtering performance didn’t allow proper filtering of all EBGP sessions. Current best practice at IXP Route Servers is to carefully evaluate and validate of all routes learned from EBGP peers. The OpenBGPD ruleset required to do correct filtering (in many deployment scenarios) was simply too lengthy - and negatively impacted service performance during configuration reloads. While filtering performance is the biggest bottleneck, general improvements to the Routing Information Base were also made to improve scalability. IXP Route Servers with a few hundred peering sessions are commonplace and adding new sessions shouldn’t impact the Route Servers’ service to other peers. We found that performance was the most pressing issue that needed to be tackled. Lack of RPKI Origin Validation As we’ve seen, Internet operators are moving to adopt RPKI based BGP Origin Validation. While it was theoretically possible to emulate RFC 6811-style Origin Validation in previous versions of OpenBGPD, the required configuration wasn’t optimised for performance and wasn’t user friendly. We believe that BGP Origin Validation should be as easy as possible - this requires BGP-4 vendors to implement native, optimised routines for Origin Validation. Of course, enabling Origin Validation shouldn’t have an impact on performance either when processing BGP updates or when updating the Route Origin Authorisation (ROA) table itself. Portability OpenBGPD is an integral part of OpenBSD, but IXPs may prefer to run their services infrastructure on an operating system of their choice. Making sure that there’s a portable OpenBGPD version which follows the OpenBSD project release cycle will give IXPs this option. Development steps By addressing the issues mentioned above, we could bring back OpenBGPD as a viable Route Server implementation. Since I was one of the core OpenBGPD developers, I was asked if I wanted to pick up this project again. Thanks to the funding from the RIPE NCC Project Fund, this was possible. Starting in June 2018, I worked full time on this important community project. Over the last few months, many of the problems are already addressed and are now part of the OpenBSD 6.4 release. So far, 154 commits were made to OpenBGPD during the 6.4 development cycle - around 8% of all commits ever to OpenBGPD! This shows that due to funding and dedicated resources, a lot of work could be pushed into the latest release of OpenBGPD. OpenBGPD 6.4 The OpenBGPD version, as part of OpenBSD 6.4 release, demonstrates great progress. Even though there have been many changes to the core of OpenBGPD, the released version is as solid and reliable as previous releases and the many bug fixes and improvements make this the best OpenBGPD release so far. The changes in the filter language allow users to write more efficient rulesets while the introduction of RPKI origination validation fixes an important missing feature. For IXPs, OpenBGPD now is an alternative again. There are still open issues, but the gap is closing! Feature highlights The following changes should be highlighted: Introduction of background soft-reconfiguration on config reload. Running the soft-reconfiguration task in the background allows for new updates and withdraws to be processed at the same time. This improves convergence time - one of the key metrics for Route Servers. BGP Origin Validation when a roa-set is configured Every EBGP route announcement is validated against the locally configured VRP table entries. Depending on the validation process’s outcome, the validation state is set to valid, invalid or not found. The filter language has been extended to allow checking for the origin validation state, and thanks to this, it is possible to deny invalid prefixes or regard valid prefixes different to the ones that aren’t found. The roa-set table is read from the configuration file and updated during configuration reloads. On production systems reloading the roa-set and applying it to all prefixes is done in a couple of seconds. Fast prefix-set lookups In OpenBSD 6.3 prefix-sets got introduced in OpenBGPD. A prefix-set combines many prefix lookups into a single filter rule. The original implementation wasn’t optimised but now a fast trie lookup is used. Thanks to this, large IRR DB prefix tables can now be implemented efficiently. Introduction of as-sets Similar to prefix-sets, as-sets help group many AS numbers into a single lookup. Thanks to this, large IRR DB origin AS tables can be implemented efficiently. Introduction of origin-sets Looking at the configurations of Route Servers doing full filtering, it was noticed that a common lookup was binding a prefix to an origin AS - similar to how a roa-set is used for RPKI. These origin-set tables are used to extend the IRR prefix lookup and generated from alternative sources. Improving third party tools Users can only benefit from the changes introduced in OpenBGPD 6.4 when the surrounding 3rd party tools are adjusted accordingly. Two opensource projects such as bgpq3 and arouteserver are frequently used by network operators and IXPs to generate BGP configurations. Thanks to our contributions to those projects, we were able to get them ready for all the new features in OpenBGPD. bgpq3 was extended to create as-set and prefix-set tables based on IRR DB entries. This is replacing the old way of doing the same with a large amount of filter rules. Thanks to the quick response from the bgpq3 maintainer, it was possible to ship OpenBSD 6.4 with a bgpq3 package that includes all the new features. arouteserver was adjusted to implement RPKI roa-set, as-set, prefix-set, and origin-set to generate a much better-performing configurations for the 6.4 version. With the v0.20.0 release of arouteserver, IXPs are able to generate an OpenBGPD configuration which is a ton faster but also implements the new functionalities. Looking at YYCIX (the resident IXP in Calgary, Canada) the ruleset generated by arouteserver was reduced from 370,000 rules to well under 6,000 rules. This resulted in the initial convergence time dropping from over 1 hour to less than 2 minutes, and subsequent configuration reloads are hitless and no longer noticeable. What still needs to be done A sizeable chunk of work still left on the table is the rework of the RIB data structures in OpenBGPD - these haven’t been changed since the initial design of OpenBGPD in 2003. There’s currently ongoing work (in small steps, to avoid jeopardising the stability of OpenBGPD) to modernise these data-structures. The goal is to provide better decoupling of the filter step from storing RIB database changes, to pave the way to multi-threaded operations at a later point. Looking forward Job Snijders oversaw this year’s fundraising and project management, he adds: It’s been incredibly productive to create an environment where a core developer is allowed to work full time on the OpenBGPD code base. However, it’s important to note there still is room for a number of new features to help improve its operational capabilities (such as BMP, RFC 7313, ADD_PATH, etc). It’d be beneficial to the Internet community at large if we can extend Claudio Jeker’s involvement for another year. Open source software doesn’t grow on trees! Strategic investments are the only way to keep OpenBGPD’s roadmap aligned with Internet growth and operator requirements. Beastie Bits DragonFly - git: annotated tag v5.5.0 created Torchlight 2 on NetBSD Older, but still good USENIX Login Article on Capsicum The Super Capsicumizer 9000 Dedicated and Virtual Server PXE provisioning tool Cirrus CI have announced FreeBSD support NetBSD PineBook Gameplay BSDCan 2019 CfP is out Allan’s first ZFS array, Zulu, turned 7 years old on Nov 29th Feedback/Questions Malcom - Installing Drivers in Development Samir - Introduction to ZFS Newnix - Drive Failures Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv
We break down Firecracker Amazon’s new open source kvm powered, virtual machine monitor, and explore what makes it different from the options on the market now. Plus some good news for OpenBGP and the wider internet community, and a handy tool for inspecting docker images.
Wes is joined by special guest Jim Salter to discuss Google's recent BGP outage and the future of HTTP. Plus the latest router botnet, why you should never go full UPnP, and the benefits of building your own home router. Special Guest: Jim Salter.
Últimamente se habla mucho de secuestro de direccionamientos, para evitar que nos secuestren un rango o al menos enterarnos RIPE pone a nuestra disposición la certificación de recursos (RPKI), obviamente esta no es la única … La entrada Ataque a myetherwallet, como se podría haber minimizado se publicó primero en Eduardo Collado.
In part 3 of our deep dive into BGP operations, Nick Russo and Russ White join us again on Network Collective to talk about securing BGP. In this episode we cover topics like authentication, advertisement filtering, best practices, origin security, path security, and remotely triggered black holes. We would like to thank Cumulus Networks for sponsoring this episode of Network Collective. Cumulus is offering you, our listeners, a completely free O'Reilly ebook on the topic of BGP in the data center. You can get your copy of this excellent technical resource here: http://cumulusnetworks.com/networkcollectivebgp Show Notes: Authentication Classic MD5 Enhanced Authentication extensions (EA). Supported by IOS XR and allows for SHA1 as well, along with key-chain rotations. Doesn't appear commonly used GTSM, and how it can be better than the previous option in some cases Basic prefix filtering: From your customers: allow any number of their own AS prepended From the Internet: block bogons (RFC1918, class D/E, etc) To your peers: only your local space (ie, your customers) From your peers: only routes originating from their AS (any # of prepends) BCP38 Techniques for spoofing prevention Describe with a simple snail mail analogy Usually uRPF strict or loose, depending Sometimes ACLs with specific IPs as sources are used too Best suited for true customer edge, not transit/peering edge (performance) Origin Security Try to prevent the hijacking of routes Hijacking is often used by spammers, etc., to source junk The main idea is — is this AS number really tied to this address block? The RPKI Signed x.500 certificates Carried around through a synchronized database (rsync) The certificates are rooted in the RIRs Which means that if you don't pay your bill, your certificate is withdrawn — you lose the ability to route MANRS As your provider, I should know what addresses you plan to source services from If you try to source something from a space you didn't tell me about, and I can't verify, I should block it To some degree, relies on uRPF — Not always realistic, so deployed on a case by case basis Path Security BGPsec Onion signing of all BGP updates This isn't ever going to happen according to Russ Kills performance — packing, per hop public key crypto Either you have a timer in the update, converting BGP to RIP, or you have permanent replay attacks — there's no clear solution to this problem OpenBMP, IRRs Community and history information Can be as accurate as the information gathered and stored First hop, graph overlay Validate first hop in RPKI or some other system Removes many of the real world problems, but not all of them All of these are active research Remotely triggered blackhole (RTBH) Some router is the trigger Add a static route with specific community ASBRs match on this community and set next-hop to some TEST-NET IP ASBRs have static route to this TEST-NET IP pointing to null → fast path drops Pair it with uRPF at the ASBR for source-based RTBH too Remote static route from trigger router when DoS/DDoS attack ends BGP flowspec QPPB on steroids More granular than RTBH QoS and security policy distribution and enforcement over BGP Russ White Guest Nicholas Russo Guest Jordan Martin Co-Host Eyvonne Sharp Co-Host Outro Music: Danger Storm Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/ The post Episode 22 – Securing BGP appeared first on Network Collective.
© 2020-2025 Ivy Podcast Discovery LLC
