Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Route-servers and how to make the most of it with manners

116 views

Published on

Presentació a càrrec de Manel Pérez i Maria Isabel Gandia, del CSUC, celebrada a la 38a reunió de la Comissió Tècnica del Punt Neutre d'Internet a Catalunya (CATNIX) el 22 de juny de 2018 a les instal·lacions del CSUC.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Route-servers and how to make the most of it with manners

  1. 1. Route Servers: What do they do and how to make the most of it with manners Manel Pérez España Maria Isabel Gandia Carriedo CSUC, Edifici Annexus, 22-06-2018
  2. 2. ¿Qué es un Route-Server?  Simplifica el intercambio de la tabla de rutas.  Acelera el proceso de nuevas altas y bajas.  El route-server participa en el plano de control y no en el plano de datos.
  3. 3. ¿Qué es un Route-Server?  El route-server envia el next hop, en este caso a cada uno de los miembros de CATNIX.  Tráfico no pasa por el route-server.
  4. 4.  Configuración de cada peer a razón de vs n peers en el route-server.  El route-server reduce la complejidad de la configuración.  Se minimizan los recursos utilizados.  Hacer peering con el route-server no significa recibir todas las rutas del punto neutro por las siguientes razones : • Media de miembros que hacen peering con el route-server es del 78%. • Dependiendo de la política del miembro de CATNIX con el route-server. Bilateral peering Vs Route-Server 2 )1(  nn
  5. 5. ¿Cómo funciona un Route-Server?  Para poder realizar todas las funciones de los bilaterals peerings (prepends, filtrado de redes , no anunciar a un peer...) hay que realizar la señalización vía communities.  Community son atributos transitivos y opcionales para poner una etiqueta y en este caso el route-server realizará una acción.
  6. 6. Estándar communities: RFC 1997  Creadas para facilitar y simplificar el control de la información de routing.  Una community “clasifica” rutas.  Cada AS puede definir a qué communities pertenece una red.  Un router (BGP speaker) puede modificar las communities de acuerdo con su política local.  Es habitual usarlas para indicar local-preferences. Listado de communities con información pública en https://onestep.net/communities/
  7. 7.  Conjuntos de 4 bytes: • En general, los 2 primeros son el número de AS. • Quedaban 2 para señalizar o clasificar la ruta. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <AS> | <Value> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Estándar communities: RFC 1997 Ejemplo de Communities RFC (caso NTT)
  8. 8. 2007: no hay suficientes AS, los RIR empiezan a asignar AS de 32 bits (RFC 4893)
  9. 9. Igual, pero más grande  Durante más de 10 años, los AS de 4 bytes no podían señalizar communities incluyendo su AS.  Hacía falta una solución equitativa.  Las extended communities no servían (aún teniendo 8 bytes, sólo permitían codificar el AS en 2).  En 2016 se tuvo la idea: lo mismo, pero mayor. Large BGP communities.
  10. 10. RFC 8092: Large BGP communities.  Un espacio único para AS de 16 y de 32 bits • Sin colisiones entre ASNs  Las large communities se codifican en 96 bits (12 bytes): “AS 32-bit:valor 32-bit:valor 32-bit”  La representación canónica es $Me:$Action:$You 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Data Part 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Data Part 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Operator-Defined Value (Action) Autonomous System Number (Me) Operator-Defined Value (You)
  11. 11. Ejemplos de BGP Large Community  No hay colisiones ni se usan AS reservados.  Permite usar AS de 32-bits en los campos $Me y $You. RFC 1997 BGP Large Communities Action 65400:peer-as 2914:65400:peer-as Do not Advertise to peer-as in North America (NTT) 43760:peer-as 43760:1:peer-as Announce a prefix to a certain peer (INEX) 0:43760 43760:0:peer-as Prevent announcement of a prefix to a certain peer (INEX) 65520:nnn 2914:65520:nnn Lower Local Preference in Country nnn (NTT) 2914:410 2914:400:10 Route Received From a Peering Partner (NTT) 2914:420 2914:400:20 Route Received From a Customer (NTT)
  12. 12. ¿Por qué es necesario un route-server en CATNIX?  Se decidió en la Comisión Técnica del CATNIX #35. • 82,5% de los puntos neutros tienen un route-server (en 2011 era un 50%). • 82% de los que proporcionan como servicio el route-server lo tienen redundado.  Crecimiento del número de miembros en CATNIX, en los últimos tres años del entorno al 40%.  Para simplificar el escenario en caso de que sea necesario.  Ofrecer dualidad en CATNIX.  Formar parte de MANRS.
  13. 13. Evaluación de posibilidades para los route-servers  Se estudiaron distintos tipos de plataforma • Es recomendable tener mas de un route-server en un punto neutro para garantizar la redundancia. • Se recomienda que los dos route-servers sean distintos para evitar vulnerabilidades y fallos.  Se decidió poner uno basado en una plataforma virtualizada linux y otro basado en equipo hardware.
  14. 14. Evaluación de software para los route-server  Menor tiempo de convergencia de las rutas.  Más consumo de memoría por cada ruta aprendida.  Menos complejidad al crear prefix filters.  Un solo proceso.  Menos carga de CPU.  Utilizado por el 78% de puntos neutros según la asociación EURO-IX.  Mas comunidad sobre Bird.  Mayor tiempo de convergencia de las rutas.  Menos consumo de memoría por cada ruta aprendida.  Más complejidad al crear prefix filters.  Tres procesos.  Mayor carga de CPU.  Utilizado por el 13% de puntos neutros según la asociación EURO-IX.  Menos información sobre OpenBGPD.
  15. 15. Bird  Internet routing Daemon es una herramienta open source, desarrollado en la universidad de Praga en la que Ondřej Filip fue uno de sus propulsores.  Actualmente Bird está desarrollado por cz.nic (administrador de dominios de la República Checa, .cz) y se utiliza en gran cantidad de puntos neutros (78%).  BGP, OSPF, RIP y tiene una compilación dual.  Se pueden utilizar variables y funciones.  En la primera puesta en marcha se puso la versión 1.6.3 que permiten las bgp large community y actualmente hemos actualizado a la 1.6.4 que soluciona vulnerabilidades de seguridad.  SO Centos 7, 4 vcpu y 8 GB de RAM.
  16. 16. Topología interna del Route-Server
  17. 17. Configuración Bird (I)  Un primer bloque de definición de parámetros AS, constantes (prefijos mínimos IPv4, prefijos máximos IPv4…).  En un segundo bloque los filtros de recepción y anuncio: • Recepción – Verificar RTS : Se asegura de sumarizar rutas BGP. – Longitud de prefijo válido. – /24 ≥ IPv4 ≥ /8 y /48 ≥ IPv6 ≥/12 – Longitud del AS-PATH. – Mayor 32 – Verificación del AS-PATH origen. – Verifica en la cadena un AS-PATH inválido. – Por ejemplo: 766 13335 65342 3356 – Verifica que la ruta no sea un bogon.
  18. 18. Configuración Bird (II) • Anuncios – Aplicación de prepends – No export – No anunciar a un peer • Configuración de la sesión BGP – Vecino – AS – Password – Aplicación de filtros de recepción y anuncios
  19. 19. Seguridad en el route-server  Para mejorar la seguridad del route-server: • Era necesario añadir en la ecuación los AS-SET. • Comprobar en las bases de datos de los IRR que las rutas pertenezcan al AS que los anuncia. • Automatización de la configuración para mejorar la gestión.  Aplicamos manualmente los filtros y empezamos a trabajar en una solución automática.
  20. 20. Arouteserver en el route-server  ¿Que es un arouteserver? • Es un proyecto git que automatiza la configuración del route-server.  CSUC tiene un repositorio interno gitlab, donde podemos realizar nuestros desarrollos.
  21. 21. Arouteserver en el route-server  Automatización de la configuración vía un script y recarga semi- automática.  Validación de filtros en IRRDB gracias a la herramienta bgpq3.  Verificación de AS-SET gracias a la peering-db y radb.
  22. 22.  Ejemplos: • Si se quiere anunciar solo al peer 13041, hay que enviar la community no anunciar a nadie (0:60082) y posteriormente anunciar a un peer (60082:13041). • Si se quiere añadir un prepend a todos los peers se añade la community 65501:60082 y en el caso que sea para solo para el AS13041 65511:13041. • Si se quiere hacer no export o no advertise a un solo peer, se tiene que utilizar una large community. Las well known communities se aplican a todos los miembros. Communities en CATNIX Acción BGP Standard Community (RFC 1997) BGP Extended Community (RFC 4360) BGP Large Community (RFC 8092) No export 65535:65281 rt:65281:peer_as 65535:65281:peer_as No advertise 65535:65282 rt:65282:peer_as 65535:65282:peer_as No anunciar a nadie 0:60082 rt:0:60082 60082:0:0 No anunciar a un peer 0:peer_as rt:0:peer_as 60082:0:peer_as Anunciar a un peer 60082:client_asn rt:60082:client_asn 60082:1:client_asn Prepend a un peer 65511:peer_as rt:65511:peer_as 60082:101:peer_as 2 prepends a un peer 65512:peer_as rt:65512:peer_as 60082:102:peer_as 3 prepends a un peer 65513:peer_as rt:65513:peer_as 60082:103:peer_as Prepend a todos 65501:60082 rt:65501:60082 60082:101:0 2 prepends a todos 65502:60082 rt:65502:60082 60082:102:0 3 prepends a todos 65503:60082 rt:65503 60082 60082:103:0
  23. 23. Uso del route-server en CATNIX  Actualmente hay establecidos 12 peerings IPv4 y 10 peerings IPv6.  Con alrededor de 724 rutas para IPv4 y 40 de IPv6.  Consumo de memoria dentro de los parámetros normales.
  24. 24. Redundancia de route-servers  Nuevo equipo físico, Cisco ISR4431/K9.  Cuatro puertos de 1 Gbps y 8 GB de memoria RAM.  Aplicar una local preference para preferir un route-server respecto al otro.  Se ha escogido un route-server físico para que el ecosistema sea completamente separado (sobre IOS, Bird).
  25. 25. CATNIX y MANRS Mutually Agreed Norms for Routing Security
  26. 26. Insecurity by Design  Cuando se desarrolló Internet, no se pensó en “Security bu design”  El objetivo era la resiliencia, la simplicidad y la facilidad de implementación  Esto permitió crear Internet como la red de redes interdependiente, de mayor propósito general, que apoya la innovación sin pedir permiso.  Aunque estas cualidades han hecho que Internet tenga tanto éxito, también contribuyen a muchos de sus problemas de seguridad.
  27. 27. The routing system is constantly under attack • 13,935 total incidents (either outages or attacks like route leaks and hijacks) • Over 10% of all Autonomous Systems on the Internet were affected • 3,106 Autonomous Systems were a victim of at least one routing incident • 1,546 networks caused at least one incident Source: https://www.bgpstream.com/
  28. 28. Routing Incidents Cause Real World Problems 28 Event Explanation Repercussions Example Prefix/Route Hijacking A network operator or attacker impersonates another network operator, pretending that a server or network is their client. Packets are forwarded to the wrong place, and can cause Denial of Service (DoS) attacks or traffic interception. The 2008 YouTube hijack Route Leak A network operator with multiple upstream providers (often due to accidental misconfiguration) announces to one upstream provider that is has a route to a destination through the other upstream provider. Can be used for traffic inspection and reconnaissance. September 2014. VolumeDrive began announcing to Atrato nearly all the BGP routes it learned from Cogent causing disruptions to traffic in places as far-flung from the USA as Pakistan and Bulgaria. IP Address Spoofing Someone creates IP packets with a false source IP address to hide the identity of the sender or to impersonate another computing system. The root cause of reflection DDoS attacks March 1, 2018. Memcached 1.3Tb/s reflection- amplificationattack reported by Akamai
  29. 29. Un sistema basado en el honor: cuestiones de seguridad  El protocolo Border Gateway Protocol (BGP) se basa en la confianza entre redes.  No existe una validación interna de que los updates son legítimos.  La cadena de confianza se expande por todo el mundo.  No hay un punto de referencia fiable
  30. 30. Estamos en esto juntos  Los Operadores de redes tienen la responsabilidad de asegurar que la infraestructura de red global es robusta y segura.  La seguridad de la red depende de una infraestructura de red que elimine a los malos actores y las configuraciones erróneas accidentales que causan estragos en Internet.  Cuantos más operadores de red trabajen juntos, habrá menos incidentes y menos daños pueden causar.
  31. 31. MANRS, manners, modales  Mutually Agreed Norms for Routing Security  MANRS mejora la seguridad y fiabilidad del sistema de routing global, basado en la colabioración entre participantes y la responsabilidad compartida de la infraestructura de Internet.  Cuatro acciones concretas que los operadores deben cumplir para estar en MANRS: Restricted Coordination Facilitate global operational communication and coordination between network operators Maintain globally accessible up-to-date contact information in common routing databases Anti-spoofing Prevent traffic with spoofed source IP addresses Enable source address validation for at least single-homed stub customer networks, their own end-users, and infrastructure Filtering Prevent propagation of incorrect routing information Ensure the correctness of your own announcements and announcements from your customers to adjacent networks with prefix and AS- path granularity Global Validation Facilitate validation of routing information on a global scale Publish your data, so others can validate
  32. 32. Everyone Benefits  Joining MANRS means joining a community of security-minded network operators committed to making the global routing infrastructure more robust and secure.  The more network operators apply MANRS actions, the fewer incidents there will be, and the less damage they can do.  MANRS is the minimum an operator should consider, with low risk and cost-effective actions.  MANRS is not a one-stop solution to all of the Internet’s routing woes, but it is an important step toward a globally robust and secure routing infrastructure. 32
  33. 33. MANRS is an Important Step  Security is a process, not a state. MANRS provides a structure and a consistent approach to solving security issues facing the Internet.  MANRS is the minimum an operator should consider, with low risk and cost- effective actions.  MANRS is not a one-stop solution to all of the Internet’s routing woes, but it is an important step toward a globally robust and secure routing infrastructure. 33
  34. 34. Why join MANRS? • Improve your security posture and reduce the number and impact of routing incidents • Join a community of security-minded operators working together to make the Internet better • Use MANRS as a competitive differentiator • You may already be a MANRS-compliant company! 34
  35. 35. MANRS Training Modules  6 training modules based on information in the Implementation Guide.  Walks through the tutorial with a test at the end of each module.  Working with and looking for partners that are interested in integrating it in their curricula. 35
  36. 36. MANRS Training Modules Module 1: Introduction to MANRS What is MANRS, and why should you join? MANRS is a global initiative to implement crucial fixes needed to eliminate the most common routing threats. In this module you will learn about vulnerabilities of the Internet routing system and how four simple steps, called MANRS Actions, can help dramatically improve Internet security and reliability. Module 2: IRRs, RPKI, and PeeringDB This module helps you understand the databases and repositories MANRS participants should use to document routing policy and maintain contact information. You’ll learn what database objects to use to document routing information related to your network and how to register information in the RPKI system. Finally, you will learn how to use the Peering DB and other databases to publish your contact information. Module 3: Global Validation: Facilitating validation of routing information on a global scale In this module, you will learn how to prevent incorrect routing announcements from your customers and your own network. The module explains how filters can be built, including the tools used to build them. It also shows how to signal to other networks which announcements from the network are correct. https://www.manrs.org/tutorials
  37. 37. MANRS Training Modules Module 4: Filtering: Preventing propagation of incorrect routing information This module will help you apply anti- spoofing measures within your network. After this module you will be able to identify points/devices in the network topology where anti-spoofing measures should be applied, identify adequate techniques to be used (for example, uRPF, or ACL filtering), configure your devices to prevent IP spoofing, and verify that the protection works. Module 5: Anti-Spoofing: Preventing traffic with spoofed source IP addresses This module is to understand how to create and maintain contact information in publicly accessible places. It explains why it is important to publish and maintain contact information, how to publish contact information to Regional Internet Registries (RIRs), Internet Routing Registries (IRRs), and PeeringDB, and what contact information you should publish to a company website. Module 6: Coordination: Global communication between network operators This module helps you understand how to enable others to validate route announcements originating from your network by documenting a Network Routing Policy. You’ll learn what a Network Routing Policy is, how to document your organization’s Network Routing Policy and make it publicly available in order to signal to other networks which announcements from your network are correct. https://www.manrs.org/tutorials
  38. 38. La Anella Científica ya está en MANRS  La mayoría de los requisitos ya se cumplían de entrada.  RIPE NCC, Verisign y NTT también forma parte de MANRS.  Bastantes miembros del norte de Europa. Faltan más del sur!!
  39. 39. MANRS IXP Programme  CATNIX también quiere formar parte de MANRS.  Se deben cumplir los siguientes requisitos: • Action 1. Facilitate prevention of propagation of incorrect routing information. (Mandatory) • Action 2. Promote MANRS in the IXP membership. (Mandatory) • Action 3. Protect the peering platform. • Action 4. Facilitate global operational communication and coordination between network operators. • Action 5. Provide monitoring and debugging tools to the members. 39
  40. 40. ¿Qué implica estar en MANRS como punto neutro?  Filtros basados en la información en las bases de datos de los RIR (RIPE, APNIC, ARIN, AFRINIC, LACNIC).  Ya implementada en el route-server en CATNIX con arouteserver.
  41. 41. Gracias por vuestra atención! Gracias también a: ¿Preguntas? mariaisabel.gandia@csuc.cat Greg Hankins (Nokia) Job Snijders (NTT Communications) Andrei Robachevsky (MANRS project) manel.perez@csuc.cat

×