>> Hola a todos. Mi nombre es Macarena. Hay más de 85 participantes, bienvenidos a todos. El objetivo es de este evento online es mantener el espíritu. Antes de continuar, quisiera avisarles que comenzamos a grabar la sesión, de esta forma cualquier persona interesada podrá ver la sesión. De querer realizar preguntas sobre el contenido de la presentación, por favor enviarlas por el panel de preguntas y respuestas. Si quieren hacer comentarios generales o logísticos, les pedimos que por favor los hagan por el chat. Vamos a ofrecer transcripción simultánea de esta sesión en español. Ahora nos gustaría presentarles al staff de LACNIC. Guillermo y Mariela, que además de ser instructores, apoyarán este tutorial. De tener inconvenientes con mi conexion, continuaré con el rol de maestro de ceremonio. Ahora sí, damos paso al tutorial de enrutamiento. Se haría un repaso de las últimas herramientas y mejores prácticas en la seguridad del ruteo. En particular se presentará el tema de Route-leaks. entre otros temas, se verá: introducción a los probremas actuales, mejores prácticas para los operadores de red, BGP, cómo controlar los anuncios. RPKI. Contaremos con tres instructores. Bienvenidos. Erika se desempeña como gerente de cuenta, forma parte del directorio de la comunidad de operadores de redes de América Latina y Caribe en LACNIC. Mariela es ingeniera de sistemas de información, actualmente es especialista de capacitación en LACNIC. Ha dictado numerosas capacitaciones en infraestructura de redes, gestión de redes, entre otras para universidades, organismos públicos y privados. Doy la palabra a Guillermo, que además de instructor, coordinará el tutorial. >> Gracias, Maca. Les voy a contar un poco de cómo va a hacer el tutorial. La iidea es que nosotros podamos hacer unas presentaciones cada uno, que tarde 20 minutos. Después daremos espacio para preguntas y comentarios. Para darle más continuidad a la presentación, lo vamos a hacer con las preguntas, que las vamos a responder al final. Recuerden hacer las preguntas por la sección de QyA. Sección de preguntas y respuestas abajo. Al final, si tienen dudas, lo pueden ir preguntando. La primera parte del tutorial, tiene que ver con una parte más teórica, quzá se van a aburrir un poco ahí. La idea es dar los fundamentos de lo que vamos a utilizar después. Luego de eso, las presenptación que siguen están basadas en ejemplos, la idea es hablar de estos mismos temas, pero con referencia a un ejemplo concreto. Vamos a mostrar un caso, un esquema de tránsito IP para que vean cómo se aplicarían estas técnicas en ese ejemplo. Lo que quería mencionarles para empezar, queríamos mostrar por qué estamos hablando de este tema, cuál es el problema que tenemos con la seguridad de los incidentes del ruteo en la región. Acá en este gráfico, es parte de un informe para LACNIC, acerca de los incidentes de seguridad de 2017 a 2018. Lo que muestra es el reporte de incidentes en la región y en el mundo. Las cifras que están acá más que nada se refieren a la región. En 2018, 3286. En 2019, 2900 incidentes. Es una proyección, porque no se analizó todo el año. Fue al final. Si miran los gráficos, van a notar que la mayoría de los incidentes son desconexiones, sistemas autónomos que dejan de anunciar esos prefijos por alguna razón. Después hay otros que son hijaks. Como dato a nivel global, en la región hay cerca de 5 mil incidentes, 2017, hubo 12 mil a nivel glabol. Entre 2018 y 2017 ha habido menos incidentes, es decir, ha habido un progreso. No tanto así en 2019, bueno, un poco la idea de este tipo de capacitaciones es tratar de bajar este tipo de incidentes que afectan a la Internet global. Acá hay una tabla con los principales países de la región con incidentes, como no podría ser de otra manera, Brasil, por la cantidad de sistemas, es de mayor tamaño en la región, por tanto tiene más incidentes. Acá, en estas columnas, la primera columna son organizaciones de Brasil responsables de hijaks. Otros países que aparecen en la tabla, Argentina, Panamá. Esa tabla se les dejo para que la analicen. Lo que voy a explicar ahora, de qué hablamos cuando hablamos de este tipo de incidentes, el secuestro de rutas es la acción de anunciar prefijos que no estamos aturizados a anunciar por BGP. Puede ser intencional o por error. BGP no tiene mecanismos intrínsecos de autenticar quién puede anunciar un prefijo, a quién le corresponde y a quién no. Entonces, eso hace que si hay errores en la operación o si hay mala intención, un sistema autónomo pueda anunciar un prefijo que no le corresponda. Supongan acá que este equipo quiere acceder a una dirección, ¿Cómo iría normalmente? Está conectado el sistema autónomo 65501, de ahí una ruta que tiene que ir a través de de esto y llegaría al destino. Eso nunca son normal. De repente, otro sistema autónomo empieza a propagar un rango de direcciones más específico que este, está dentro de esto. Por ejemplo aquí está propagando un /48 en vez de /40, con lo cual es específico y le va a ganar al otro. Si el sistema autónomo lo toma y no tiene filtros, lo va a propagar, y va a llegar al 65.501. No va a usar esta ruta, sino que usará las más específicas. Bueno, ahí, entonces va a llegar el tráfico al sistema autónomo 65.509 en vez al que debería ir. Es básicamente lo que se llama un secuestro de rutas. ¿Habré es un Leak? Es una fuga de rutas, es decir, un anuncio que no debería dejarse pasar. Cuando nosotros tenemos ciertas relaciones, cuando nosotros configuramos BGP con las organizaciones, tenemos algún tipo de relación en el sentido que somos pares, o relación de tránsito para el acceso al norte, o, bueno, puede ser cliente, que tenemos. Una cosa que no debemos hacer es que los prefijos que aprendemos de un proveedores no deben anunciarse a otro proveedor. Lo mismo, los prefijos aprendido solo se deben mantener dentro del sistema autónomo, cada sistema autónomo le anuncia al otro en conjunto de rodos, pero no debería propagarse. Entonces, si yo prendo de este sistema autónomo, si aprendo una ruta, no la tengo que enseñar más arriba. Yo, a los clientes, sí debería anuncir. Bueno, este es el caso, por ejemplo, el sistema autónomo 65.536 está anunciando la red /40 hacia internet, y bueno, cada anuncia, esta es la red y la anuncia al otro. Si no hay filtros configurados, y eso es un leaks. Esto era así hasta hace un tiempo, ahora queda cambiado esto, pero muchas implementaciones de BGP siguen teniendo esta política. ¿Cómo evitamos esto? ¿Qué técnicas hay para prevenir los incidentes de seguridad? Una de las formas que tenemos , lo que necesitamos es teclear que la información que recibimos por BGP es correcta, no tiene mecanismos intrínsecos, cualquiera que tiene que se conecta a internet puede anunciar una red que no es de él. Entonces, podría estar anunciando prefijos que no corresponden, necesitamos chequear esto y hay dos formas que son los IRR y RPKI. Entonces, qué nos provee esto, hay una gran cantidad de ellos, el más conocido es RADB Son bases de datos donde las organizaciones definen las políticas de ruteo y los operadores pueden usar esta información para generar filtros de BGP para esto se usan herramientas bgpq3/4 ahora LACNIC tiene también esta funcionando el internet propio. Esto es un ejemplo en registro, lo que es importante de esto que vean es que lo que asocia esto, esto es una ruta con un sistema autónomo de origen, es lo principal que tienen que tener en cuenta y permite hacer un validación de origen, un ejemplo donde uno de los sistemas autónomos anunciaba un prefijo que no era de él no se podría hacer porque si uno está chequeando esto tendría que la red /18 solo puede ser originada por el sistema autónomo 6057 ¿Qué es el RPKI? Define un infraestructura de clave pública especializada para ser aplicada al renrutamiento, Además le dará un certificado digital que es un certificado del tipo que ustedes conocen 509. Esto lo que da es una prueba verificable de la posesión de un recurso, solo el que tiene este recurso va a tener este certificado y así poder firmar. La solución RPKI tiene dos partes, una son los ROAs y el mecanismo de validación, primero es definir los ROAs que son equivalentes a los route o route 6 de un IRR lo que permite es definir los ROAs es definir el sistema autónomo de origen de nuestros prefijos, y la gran diferencia con un IRR es que los ROAs pueden ser firmados con la clave privada del certificado y todo esto bueno, está almacenado en un sitio público, mientras que en un IRR normal cualquier organización puede crear un route o route 6 no hay mecanismos fuertes de autoriización de esto, en el caso de RPKI solo quien tiene los recursos y direcciones IPv4 o IPv6 puede crear los ROAs y firmarlos, de esta manera tenemos que es bastante más. ¿Qué es la validación de origen? Simplemente consiste en obtener los datos del repositorio que normalmente está y en este caso hay un software que se corre aquí, supongamos que esos la red d un representador, ASN y son los validadores que trae los datos del repositorio RPKI donde están los ROAs y certificados y otra información la valida criptográficamente y la alimenta y abre un protocolo donde el router obtiene la tabla de los ROAs y qué le dice, cuál es el sistema automo autoriizado a originar un prefijo y entonces el router chequea contra la tabla y Update dice si corresponde con lo que definió el ROAs o no. Una vez que los router reciben la información de los caches reciben una tabla y un sistema. Esto es básicamente un ROAs. Esto está firmado criptográficamente y repositorios y además, pero tanto el IRR como el RPKI una de la principalmente cosas que definen es esto, en el RPKI permite un largo máximo. Si lo que recibimos coincide con lo que es el ROAs por ejemplo 210, 212: 0/23 estaría dentro del mínimo y el máximo y si bien el sistema autónomo sería válido porque coincide, si viene de otro sistema autónomo o la longitud es más larga la información del ROAs no coincide. Si tenemos un estado no encontrado, por lo tanto hay muchos prefijos en estado No Encontrado. Hay dos modos de utilizar RPKI. Normalmente hay una estructura jerárquica y con esto el RIR emite un certificado, y a su vez se hace un modo delegado, en el modo hosteado que es el más utilizado en LACNIC todo el mantenimiento de las operaciones criptográficas, y además es hecho de forma automática y se hace en LACNIC, todo es depositado en el repositorio de LACNIC. Los certificados y ROAs son publicados en el repositorio de RUR.si vamos u tener una nueva publicación vamos a cambiar el sistema autónomo de origen tenemos que actualizar los ROAs. En el modo delegado una organización puede tener su correspondencia CA detende del RIR. Este modo es sutil para organizagmente que tienen espacio de direcciones de diferentes RIR Organizaciones de muchos recursos que los quieren manejar con un sistema de manejo IP y automatizarlo y en el caso de registro. Concretamente en la región NIC Brasil trabaja en modo delegado con respecto a LACNIC y a sus organizaciones. Entonces ellos usan el Up Down para comunicarse con la CA y hay software disponibles para esto, está el Krill que es el software más nuevo que usa NIC Brasil. Bueno, voy terminando con esto. Una forma de atacar estos incidentes, de mitigar, acá expliqué dos técnicas IRR y RPKI. Pero cómo podemos hacer para mitigar estos incidentes , hay una serie de normas acordadas y vamos a usar para este tutorial pasarnos a MANRS que es un conjunto de normas acordadas para la seguridad de enrutamiento, propuestos por algunos operadores, con reglas para respetar para tener un mejor ruteo en internet. Hay un conjunto de acciones propuestas por MANRS, hay programas específicos para IXPs y CDNs Vamos a centrarnos en Filtrado y Validación global. Y quizá son más simples y para un tutorial corto como este no lo tuvimos en cuenta. Con esto yo finalizo hasta acá mi parte y no sé si hay consultas. >> Sí, hay consultas, Guillermo. Hay unas cuantas, vamos a responder, vamos mirando entre vos y yo vamos mirando el tiempo y el resto de las preguntas las vamos a dejar para que te las puedan enviar por mail. Rodolfo creo se refiere al 82: 12, lo que implementar filtros. >> Sí, no recuerdo el número. >> 82: 12, es uno de los datos. >> Bueno seguimos con otra "quién es la CA principal que firma o en cada RIR es independiente? >> Cada RIR Es independiente y de ahí depende de cada RIR va otorgando los certificados segú recursos que tenga asignados. >> Después tenemos una pregunta de José. Adquirió un pool este año. ¿Es necesario generar el RPKI para la publicación del pool? entiendo que generar los ROAs para entregarselo al ISP. >> En realidad, cuando uno recibe direcciones nuevas y las empiespa a publicar debería generar ROAs para cubrirlas. La idea de RPKI es que uno tenga lo que publicidad cubierto por un ROAs, de esta manera va a tener protegido contra secuestro lo que va a estar anunciando. Entonces, sí, cuando alguien recibe, debería generar los ROAs para las publicaciones que va a hacer. Cuando empieza a publicar en Internet. >> Bueno, excelente. Decime cuántas preguntas que podemos dar. Organic>> Dejemos dos más. Los que no pasan la variación de RPKI. Entonces, hay muchos operadores que lo están haciendo. De hecho, hay operadores grandes como Google, proveedores de tránsito importante, con lo cual es importante tener en cuenta estas cosas. A medida que más operadores comienzan a tener en cuenta, ha pasado consultas que no podían llegar. Y era por esto. >> Excelente. Quedaron más de diez preguntas. ¿Se puede implementar la validación de origen RPKI en los routers en modo informativo? Que aún aplique el filtrado hasta verificar los válidos. >> En los routers sí, se puede también. Si ustedes... justo había unas slide que las sascamos, tiene que ver con que el operador decide qué es lo que va a hacer. Los prefijos que llegan, pueden ser varios inválidos, alguno de los tres estados, pero es el operador quien tiene que decidir qué va a hacer con eso. No está descartado. Es algo que pueden ir viéndolo, por un lado pueden descartarlos o pueden ponerles una preferencia más baja, o pueden no hacer nada. Pero podrían, por ejemplo, pueden clasificarlos según sean válidos, por ejemplo con una comunidad, que vamos a ver después, sería una forma, clasificarlos como válidos, inválidos. Otra cosa que se puede hacer es instalar el validador, no configurar, el validador va en un servidor, instalan el validador . FORD es el validador, es un proyecto, el validador fue validado por NIC México. Es muy efectivo, muy liviano. Erika después va a comentar sobre esto. Ver el reporte de ROAs sin tener necesidad de implementar. Las dos cosas son posibles, uno puede tener validador externo y con base a eso hacer reportes, o puede tener configurado en el router, pero no estar descartando nada todavía. Tener solo para analizar. Yo diría que pasemos a la siguiente presentación, porque si no, no nos va a dar tiempo. >> Genial. Antes de pasar a la próxima presentación. Estaría bueno que dijeras dónde pueden contactarte en caso de tener una pregunta más. De todas maneras, estamos tomando nota de las preguntas que quedaron en cola. >> Mi dirección está en la presentación, en la primera slide. Ahí nos pueden contacautores. >> Perfecto. Bueno, entonces sigo yo. >> Vale. Filtros en BGP. >> Voy a compartir pantalla. No sé si me están viendo. >> Sí, te vemos y te escuchamos. >> Bueno. Hasta ahora, venimos viendo con Guillermo qué es lo que sucede en Internet respecto al enrutamiento, hay varias cuestiones de seguridad a tener en cuenta y que hay muchas herramientas que se pueden utilizar para ir mitiigando todos esdos problemas de seguridad de ruteo en Internet. Lo que les voy a hablar es acerca de cómo que podemos trabajar para lidiar con estas cuestiones de la seguridad del ruteo, pero desde el BGP mismo. Para eso me parece que es interesante, esta slide me gusta, los que conocen los tutoriales saben que me gusta empezar con este tipo de sslide, porque es muy estemática. Tratamos de reflejar cómo trabaja BGP. Trabaja básicamente aprendiendo y anunciando rutas. Vemos la conexión, la sección BGP puede darse entre sistemas autónomos diferentes o dentro del mismo sistema autónomo. ¿Qué es lo importante aquí? Que cuando anuncia prefijos significa que le está diciendo a su vecino cuáles son los prefijos que puede alcanzar a través de él. Así es como básicamente BGP. ¿Qué es otra cosa muy importante? Muy importante saber que BGP todo lo que aprende lo intenta anunciar. Siempre lo que vaya a incorporar en su tabla de BGP va a tratar de anunciarlo. Basados en esto, pasamos a un ejemplo que nos mencionaba Guillermo. ¿Qué pasa en estos casos de peering? Mi pantalla la ven completa? Perfecto. Ahora sí. Esto es un ejemplo de peering. Es una topología gráfica, dos routers están conectados simplemente para hacer intercambio de prefijos, por lo que se ve han hecho un acuerdo de peering, un acuerdo propiamente dicho, en el cual se anunciará al otro ASN estos dos prefijos. Prefijo IPv4 /24, lo propio hace también, dice que la va a anunciar este prefijo IPv6 y que también la va anunciar hacia este otro ASN. La pregunta es, el acuerdo está hecho, la configuración también, ¿Cómo se asegura un router de un sistema autónomo que las rutas que dice que va a recibir son realmente las acordados? ¿Cómo asegura eso? Hay varias formas de hacerlo. Entonces, una de las formas de hacerlo es a través de lo que llamamos filtros por prefijos, que son filtros que se construyen con las sentencias de peer, pueden ser implementados en la entrada o salida de la sesión BGP. En la entrada va a efactar todo lo que aprende del vecino. Si se implementa a la salida de la sesión BGP, afectará todo lo que ese peer quiere enseñar a su vecino. Este es el mismo ejemplo de peering que vimos atrás, lo único que hice fue agregarles las direcciones de la conexión punto a punto para poder mostrarles cómo sería un ejemplo de configuración. Esto es una configuración típica de lo que podría ser un router con los que trabajamos, lo van a encontrar muy familiar. En las slide no van a tener resaltado esto último en amarillo, lo quise poner así para dar el tutorial más fácil. Tenemos una sesión BGP, es importante que se los aclare, esta configuración es la configuración del router que se encuentra en el ASN 65501. Levanto una sesión BGP con este, fíjense que es este, una sesión BGP con este otro, que se encuentra en el ASN 65502. Entonces yo voy a decir que en esa sesión BGP voy a aplicar un filtro por prefijo que se llama peer IPv6, y lo voy a aplicar en la entrada de la sesión. Quiere decir que lo voy a aplicar para todo lo que aprendo. En el 65501 si lo aplico en la entrada quiere decir que es todo lo que aprendo del 65502. ¿Qué dice? Que solo deja pasar la 2001DV810 /48 es la que él me tiene que enseña pesar del. No hay una sentencia más. Quiere decir que está implícito que la última sentencia me niega todo lo que está permitido. Con eso me aseguro que lo que voy a recibir sea lo que acordé. Analogamente está la parte de la salida, también pueden revisar después tranquilos toda la confitranquilamente. Esto sería un filtro por prefijos para asegurarme que el acuerdo de Peeer que hice con el otro sistema autónomo y que recibo las rutas acordadas y anuncio las rutas que acordé. Vamos a otro ejemplo que es de tránsito. Acá cambia es que no hay dos routers conectados entre sí, sino que además, acá hay un sistema autónomo que está siendo de tránsito, por ejemplo, para que estos tres clientes puedan llegar a internet, el ASN65502 da tránsito a otros tres para que leguen al ASN65501 Bueno, qué quiero que veamos acá. Nosotros vimos filtros por prefijos, tenemos que ir poniendo uno a uno cada prefijo que queremos confirmar que anunciamos o que aprendemos, existen otros tipos de prefijos que son los prefijos por AS-Path es el mismo ejemplo solo que agreue las direcciones punto a punto tienen la particularidad que no filtran según prefijos sino que filtran según el camino que estos prefijos hicieron hasta llegar al último sistema autónomo, filtran por camino, por AS-Path y es más práctico porque vamos a ver cuánto k reduce en configuración. Para ver este ejemplo nos vamos a centrar en el ASN65502, pero vamos a imaganar que decide no darle transito, sino a los otros dos tránsitos, al 65511 y 65509. y fíjense que en la sesión que tengo con el asiento con 1985110022 en esta sesión voy a aplicar un filtro 11 y le enseño a este Neighboor dice que permito todo lo que viene del SASN65511 al que decidí darle tránsito. Saben que los AS-Path del sistema autónomo se construió de atrás para adelante. El primer sistema autónomo que inició la cadena es el que termina en signo pesos porque es el último. Esto significa todos los prefijos de la ASN65511 todos los que se originaron en el 65509 y todos los prefijos originados en el mismo sistema autónomo porque la cadena está vacía. Entonces, fíjense que no hay ninguna sentencia para el 65510 ¿Por qué? Porque lo que permito pasar en la salida hacia la ASN65501 y lo que no esté explicitado acá por omisión se deniega. Ahora qué pasa, supongamos que esto funciona y yo voy darle tránsito a los sistemas autónomos que efectivamente acordé que le daré tránsito, ahora qué pasa si el ASN65511 tengo permitido pasar sus prefijos me anuncia un prefijo a través de la sesión BGP que tiene conmigo ASN65502 pero que no le pertenece, que es lo que comentaba Guillermo hoy. Esto nos abre un poco los ojos a que sí bién, la configuración de este Path es prolija y recomendada en el salida de la sesión que hay entre estos dos sistemas autónomos lo bueno sería combinar en filtros por Prefix-List y además de controlar y pasar todo lo que viene del sistema autónomo también en estas sesiones con cada cliiente poner filtros por prefijo y poner los prefijos que acordamos me iban a anunciar. Otro recurso para trabajar desde BGP es el trabajo de comunidades, las comunidades son recursos o atributos que permiten agrupar de alguna manera, armar comunidades que comparten las mismas características, en el caso que vemos nosotros, por ejemplo, la misma característica podría ser todos los prefijos de sistemas autónomos que les doy tránsito. Es importante esto solo a comentario, que existen dos tipos de comunidades, estas las Community y Large community, la diferencia es que las Comminity el formato es el sistema autónomo cuando eran de 16 bits tenían un formato y al pasar a 32 bits nacieron las Large Community si queren más información de esto pueden verlo en las slide y ver como se usa el campo. Me interesa en este tutorial que se entienda el concepto de cómo se trabaja con comunidades. Vamos a hacer un análisis. >> Mariela, quizá es mejor dejar el tema de comunidades para después del break. Por así arrancas con esto. >> Bueno. >> Le damos el paso a Maca. >> Excelente, gracias Guillermo. >> Gracias Mariela, como bien decías, pasamos a tomar un brake de cinco minutos, agradecemos a más de los 250 participantes y los esperamos nuevamente. . >> Bienvenidos a todos de nuevo. Les recordamos que pueden coordinar consultas en nuestro staff virtual. Tengan presente que pueden hacer sus preguntas por el panel de preguntas y respuestas. Tenemos el servicio de transcripción simultánea en español. Dada la cantidad de preguntas realizadas y poder atenderlas, les compartiremos en el chat una URL para que puedan colocar las preguntas que no han sido contestadas. Adelante, Mariela. >> Gracias, Maca. Volvemos. Voy a poner un video, voy a compartir pantalla. Un segundo. Acá estamos. Bien. Ahí habíamos dejado. ¿Verdad? Bueno, seguimos ¿Me escuchan bien? >> Sí, te confirmo que te escuchamos y vemos bien. >> Estábamos antes del break con un ejemplo de tránsito, íbamos a imaginar que la ASN 652 le daba tránsito, también dijimos que otra de las formas que poder realizar estos filtros es trabajar con comunidades. Cuando hablamos de comunidades, definimos las comunidades que son, las comunidades sirven para agrupar prefijos que tienen características iguales y poder trabajarlo de una manera más óptiba. Estábamos prontos a hacer un análisis del ejemplo que veníamos trabajando. El AS65502 este con el que yo trabajo, el del medio, que da tránsito, puede definiir una comunidad para clientes a los que les da tránsito. Este es el formato que les mostré en el slide 2. La primer parte del atributo es el sistema autónomo que la define. La segunda parte es un número arbitrario que decide el administrador. El sistema autónomo aplicará esta comunidad a las rutas que recibe del 65509 y del 655012, ¿Por qué de estos? Porque comparten las características de ser los sistemas autónomos a los que se les da tránsito. Tienen alguna característica. Podría ser una comunidad para todos aquellos prefijos a los que se les da tránsito. Entonces, en el enlace que tiene hacia 65501, aquí, solo permitirá publicar las rutas que tienen esta comunidad. ¿Cómo es que funciona esto? De esta manera. Cuando trabajamos con comunidades, lo que hacemos es poner una suerte de tiqueta a determinados prefijos. En este caso, lo que hacemos es. Si viene del 65511 le seteo la comunidad, acá en la éntrada de la sesión BGP, la defino, si viene del sistema autónomo 65509 también la seteo esta comunidad. Todos estos prefijos quedan con esa comunidad setea. Si viene de este sistema autónomo, que dije que no le iba a dar tránsito, no lo seteo la comunidad. ¿Qué anuncio? solo lo que tiene esa comunidad seteada. Entonces, para seguir con la misma forma de trabajo que venimos teniendo, les voy a mostrar cómo sería una configuración muy simple de lo que nombramos. En primer lugar, la definición de las diferentes sesiones BGP, no están todas. Definiir con esta sentencia por ejemplo lo que estamos haciendo, que es crear la comunidad. A partir de esta sentencia, la comunidad ya existe 65502 1000 Sobre la nesión BGP que tengo, ¿Quién es? En la sesión que tengo con la 198511002 la sesión BGP que tengo acá, voy a aplicar tránsito en la entrada de esa sesión BGP. El 65502 lo va a aplicar a la entrada. Vamos a darlo, dice que cuando un prefijo, le setea a la comunidad esta, la comunidad cree que todo lo que venga, porque está en la entrada, le voy a aplicar la comunidad 65502, y lo mismo voy a hacer en la sesión BGP que tengo con el otro. Todo lo que venga de aquí, en la entrada, le voy a setear la comunidad tránsito a través de del roupe map tránsito. Luego, tengo una sentencia que dice que en la sesión BGP que tengo con el 1985110022, cuál era, acá, en la sesión BGP que este router tiene con este otro router, pero en la salida, le voy a aplicar un roupe map que se llama anuncio a 65501. ¿Qué dice? que solamente va a dejar pasar todo aquello que machee con la comunidad 1. Esta es la forma que tenemos de trabajar con comunidades. Se trabaja mucho con comunidades, es un atributo transitivo, los distintos administradores se ponen de acuerdo en los números a utilizar con esas comunidades, bueno, es un ejercicio excelente porque facilita el filtrado de rutas. Me gusta que tengamos en cuenta la combinación de los diferentes tipos de filtros que tenemos para poder ayudar que lo que aprendemos es lo que queremos aprender, lo que anunciamos es lo que acordamos anunciar, pero, además, que sea de una forma que escale en las redes. Era lo que tenía para comentarles. No sé si hay preguntas. >> Creo que no hay preguntas todavía sobre este tema. Aprovecharía para responder las pendientes de RPKI. Si aparecen... Comentario, una de las cosas que tiene importancia esto que hablaba Mariela, tiene que ver con esta que dijimos que de alguna manera obliga a configurar filtros o políticos de ruteo en los router... que si ustedes no tienen configurado filtros, el BGP, cuando levantan un BGP y no tienen política de rotuo de distintos filtros configurados, no va a anunciar ni recibir nada. Es un cambio que ha habido. El otro comentario, esto es el primer punto, una de las acciones que había dicho, si quieren certificar MANRS tienen que implementar filtros, algo para tener en cuenta. >> Tenemos unas preguntas sobre comunidades. Vamos a tratar de responderlas jno con Guillermo. "no me queda claro, para establecer la conexión de comunidades, los peers deben estar conectados en común?". Entienedo que no, es una sesión BGP, uno puede establecer, la comunidad se define en el router local y luego es un atributo transitivo. Las comunidades se pueden configurar con nuestro BGP. Es muy bueno ponerse de acuerdo con el peer porque cuando la reciben, la reciben con el número que nosotros recibimos. Entonces, sí, acordarlos con ellos es muy importante. Dicen "al hablar de comunidades, ¿Pueden ser las estándar o extendidas?". Utilizamos en el ejemplo las comunes. >> Hay mencionaste un tema que vale la pena aclararlo, hubo varias propuestas de comunidades, las extendidas y otras, a lo largo del tiempo, las comunidades del ejemplo son las más viejas, 1900 y algo, luego de eso hubo propuestas para extender a 32 bits. Las que Mariela presenta son en realidad, como decía, hubo comunidades y otras que tenían diferentes formas de uso. Estas se aprobaron bastante rápido y son las han tenido más éxito, entonces son las que hay para sistemas autónomos de 32 bits. >> Excelente, no sé como estamos de tiempo Guillermo, dos preguntas más. >> Un par más. >> Dice Ricardo "veo que aunque se usa la comunidad se marca 1000 a todo lo que entra del sistema extremo derecho lo que quiere permitir el ADS de tránsito de comunidades funciona igual con Prefix-List? No sé si llegó a comprender la pregunta. >> El número 1000 es un número arbitrario, es como una marca nada más. El primer número es el sistema autónomo que define la comunidad, generalmente, y el segundo número es un número cualquiera. En los ejemplos que puso Mariela, no sé si está el link, ejemplos de Largue Community se muestra. >> Sí, en el caso de uso está justamente en esa RFC está descrito cómo utilizar el campo funtion para setear otras y con qué número se setea vendría a ser como una suerte de convención. >> Bien, una cosa, los ISP muchas veces tienen una lista en alguna página donde dice si ustedes por ejemplo setean una comunidad anuncian un prefijo a ISP a determinada comunidad dice qué hace explícitamente cada uno de estos números y como aquí es el 1000 podría tener otros números que tienen que ver con ponerle prefijo distinto, anunciar determinados clientes y peer y demás. Vamos con la última. >> Bueno, lo que digas. De tú tema o del mío, como quieras. >> Vamos con una que había quedado ahí "los principales secuestros de ruta se puede determinar esto? " >> Es muy difícil determinar la intencionalidad de un secuestro de ruta, se puede determinar que hay un anuncio que no se corresponde ya sea con los ROAs creados o con quien debería estar autorizado a hacer Anuncio. En el caso de usar RPKI es fácil de determinar, uno puede determinar rápidamente si un anuncio corresponde o no con la base de datos de RPKI. Si la organización no usa RPKI es más difícil de determinar porque un anuncio puede estar hecho en función de otra organización el caso por ejemplo de una organización que tiene IP y no tiene sistema autónomo y pide a su ISP que publique su conjunto con el sistema proveedor, esto es válido, ahí no se puede determinar si es un hijacks o si es intencional o un error de operación. Eso no tiene que ver con algo técnico sino de comportamiento humano, el que hace el hijacks puede decir que fue un problema sin intención y demás, no es fácil de determinar, casi cercano a imposible porque la organización que hace el hijacks siempre puede decir que no lo hizo. Bueno, cuanto esto, entonces terminamos esta sección y doy paso a Erika si te parece Mariela. >> Me parece bien, pero bueno vamos a ver tengan en cuenta nuestras direcciones de mail para seguir. >> Si nos queda tiempo después seguimos con algunas preguntas. Gracias. >> A vos. >> Hola a todos ¿Me escuchan bien? >> Sí. >> Perfecto. Ya voy a compartir la pantalla entonces. La ven completa? >> Sí. >> Bueno, listo, un saludo a todos. A todos los que están conectados el día de hoy a nuestra tutorial, creo que también pueden haber personas conectadas que han estado en tutoriales anteriores en eventos presenciales, este temes extenso y estamos haciendo lo mejor posible, el RPKI en la práctica, iniciamos con Guillermo donde nos explicó todos los problemas que hay a nivel de seguridad con todo el tema de secuestros de rutas, luego nos comentó un poco del tema de validación de origen, cómo funciona, luego pasamos con Mariela para saber cómo protegernos hacia a esto con todos los atributos y temas desde BGP de hecho ahora vamos ejemplos de RPKI en el práctica, Mariela explicó ejemplos del filtrado que se hace en estas rutas. Bueno, si recuerdan cuando estábamos con Guillermo hablamos de los ROAs que son las firmas, recursos que hacemos digitalmente vamos a iniciar explicando los cosas que debemos tener presentes para crear estos certificados digitales la responsabilidad dee finir los ROAs es de todas las personas o de todas las instituciones que tienen recursos propios IPv4 o IPv6 o números de sistema autónomo vamos a hablar de nuestra región, latinoamérica, la plataforma MiLACNIC. qué cosas hay que tener opiniones, si no tenemos número de sistema autónomo tenemos que crear los ROAs, pero algo que debemos tener presente es cuál es sistema autónomo que genera el anuncio, es importante tener esto presente, cuál es el sistema autónomo que genera el auncio, en caso que no seamos dueños de un sistema autónomo tenemos que crear nuestro ROAs permitiendo a nuestro ISP crear los ROAs basándonos en esto, vamos a ver esto con más detalle con más ejemplos. Bueno ¿Qué tener en cuenta? Vimos con los ROAs al inicio también, Guillermo hablaba de una tabla de se genera y debemos ver cómo hacemos la publicación de nuestros anunción, si la publicamos sumarizada, si recibimos, en este caso, un anuncio, de una red IPv4 /22 si la publicación lo hacemos desde ese prefijo /22 o la desagregamos, o si somos ISP y le entregamos a cada cliente mostrar cómo se están desagregando estas rutas para conocer cómo generar los ROAs. Otra cosa importante es cuál es Sistema autónomo de origen, conocer si lo hacemos desde nuestro pnpo sistema autónomo propio de origen, si tenemos y si lo estamos desagregando y cuál es Sistema autónomo de origen es el encargado de hacer la publicación. Algo importante para resaltar acá es que en este aspecto, esta política, digamos desde la creación de ROAs es responsabilidad de cada integrante que tienen estos segmentos de red asignados. Iniciamos con el ejemplo de peering, vamos a usar el mismo ejemplo de Mariela. Tenemos los dos sistemas autónomos 65501 y 502 redes que se publican de un sistema a otro. ¿Qué ROAs necesita crear en este caso el sistema autónomo 65501 que fue el que vimos inicialmente? si este sistema recibió de parte de LACNIC un /22 pues este es el ejemplo de cómo se debería crear el ROAs, esto es exactamente cómo se vería desde MiLACNIC. Vamos a tener aquí que llenar en la información se darán cuenta que es muy fácil generar estos ROAs. La información del Nombre que vamos a poner a estos nombres, a qué podemos hacer alusión, a qué ruta y qué vamos a poner en el caso de ASN Número de sistema autónomo de origen que genera la ruta y aquí pide la información de fechas, la informamente de validez del ROAs que vamos a generar. Después que pongamos en la validez de ROAs el tiempo que nosotros creamos que este prefijo se esté validando donde llegáramos a dehabilitar el prefijo /22 tenemos que agregar estos ROAs. En un prefijo /24 que es el que estamos publicando hacia el otro sistema autónomo. Luego vamos a indicar cómo se desagrega, en este caso tenemos aquí la creación de la desagregación del ROAs donde indicamos que es un prefijo 22 y que el máximo en la desagraeción es un 24 y lo mismo hacemos en este caso con el direccionamiento IPv6 que en este caso sí solamente publicamos un prefijo 48 y decimos que esté se recibió desde el RIRs y es el que estamos publicando en este momento. Bueno, por favor me avisan si voy muy rápido, tal vez hablo muy rápido y no quiero confundirlos con mi formde hablar tan rápida. >> Erika, lo único es hablar un poco más lenta para que la transcripción se haga con mayor facilidad. >> Listo, ahora vamos a validar cuáles son los ROAs que necesita crear el sistema autónomo 65502 en este caso vamos a hacer el mismo ejemplo. En un prefijo 24 como lo vimos en el ejemplo , como vimos en el ejemplo anterior. Ahí vamos a crear el ROAs prefijo 22. Indicamos cuál es el sistema autónomo de origen y hacemos la creación de igual forma para el ROAs prefijo 48. >> Disculpa. Estamos escuchando un dispositivo móvil. Si lo puedes silenciar, porque se escucha. Gracias. >> Ya. Gracias. Bueno. Tenemos el ejemplo de tránsito acá, en este caso tenemos la conexión entre varios sistemas autónomos, acá tenemos cinco diferentes, tenemos que conocer que ROAs debe generar cada uno de ellos, tenemos el 65501 y 65502, ROAs generados con los ejemplos anteriores. Detrás de este sistema autónomo, vamos a tener otros anuncios en otros sistemas autónomos. ¿Qué ROAs debemos crear aquí para cada sistema autónomo? Para el 65501 tenemos los mismos ROAs, tal cual como en el ejemplo anterior. Para el sistema autónomo, luego entran los otros sistemas autónomos. Tenemos todos los sistemas cada uno con los publicaciones puntuales de sus rutas. Vamos a decir que recibieron el prefijo como se está anunciando dentro del escenario del ejemplo. ¿Qué información es la que recibe el sistema autónomo 65501 si se están haciendo estas publicaciones y tenemos esta esquema de conexión en este escenario de ejemplo? Se está recibiendo toda la información, va a ser esta interfaz, vamos a revisar cómo se arma la tabla de validación. Estamos iniciando con un escenario en donde en este momento ningún sistema autónomo está haciendo validación, hasta el impuesto solamente estamos creando ROAs. Vamos a iniciar entonces con la publicación que hace el sistema autónomo 601562, el sistema autónomo de origen que es la información que va a aparecer, el atributo en BGP que nos dice cuál es el sistema autónomo de origen es la información que vamos a tener ahí. La entrega, el direccionamiento IPv6 y luego la del IPv4, de igual forma con sistema autónomo. Luego vamos a ver cómo lo hacen las publicaciones los otros sistemas autónomos. En este caso hace la publicación al 65502 con su sistema autónomo de origen. Y cuando hace el anuncio al 501, vemos que aquí aparece otro sistema autónomo que es el del 502, pero se mantiene el que dio origen. Cada uno va a entregar al sistema autónomo de tránsito, y este entrega la información al destino 65501 poniendo la información por los sistemas autónomos que ha pasado esta ruta. Recuerden que siempre la generación de los ROAs, lo que tenemos que tener presente es cuál es el sistema autónomo que está generando la publicación. Aquí tenemos en el último escenario la última publicación. Bueno. De esta forma tendríamos, aquí tenemos una tabla BGP simplificada, vamos a tener la información que nos importa para este ejercicio. Tenemos la red que fue conocida por el sistema autónomo 501, gracias al ASN de tránsito, por cuál vecino fue que tuvo la información de esta ruta. En este caso no estamos haciendo ninguna validación y vamos a tener la información con toda la información de los sistemas autónomos por las que pasaron estos prefijos y estas rutas. Recordemos que cuando estamos armando la tabla de enrutamiento siempre se elige el camino más corto. Si hay redes contenidas en otros paquetes, siempre se envía la ruta más específica. Esto lo tenemos que tener presente. Ahora, en este ejemplo vamos a tener un sistema de validación, un servidor donde vamos a tener el validador, este servidor se va a conectar con los RIR, donde vamos a tener la información de todos los ROAs generados a nivel mundial, y este entrega la información por el protocolo a todos los routers de nuestra red con la información de estas rutas. El sistema autónomo 65501 va a empezar u conocer estados de validez en su tabla BGP. Aparece otro actor en este ejemplo, vamos a tener un cliente conectado, va a tener prefijos que ha recibido desde LACNIC, prefijos propios, un direccionamiento IPv4, pero no tendrá número de sistema autónomo para realizar su publicación. ¿Cómo debe crear el sistema autónomo este cliente? ¿Cómo debe crear ese ROA para poder hacer la publicación? Vamos a ver. En este momento, 65501 está haciendo la validación, todos han generado sus ROAs para para 65509 y los demás. ¿Qué ve en este momento el sistema autónomo? El destino en su tabla BGP. Va a encontrar y ver todos los estados de validez que ha conocido como válidas. Ha conocido un anuncio con un prefijo IPv4, pero no ha generado ROAs. Lo verá como una ruta no encontrada. Hasta el momento con esto no tenemos mucho problema, pueden aparecer inválidas cuando el máximo del prefijo lo estamos desagregando de una forma como no se ha desagregado esta ruta o con un sistema de origen que no es el que tiene realmente el permiso. Vamos a generar el ROAs del prefijo IPv4. Como el cliente no tiene sistema autónomo propio, el sistema autónomo de origen al que dará el permiso para la publicación, será con el que está haciendo la conexión en este momento. La publicación que está haciendo no está más desagregado y la va a conocer el repositorio de todos los RIR. Ya conocen este nuevo ROAs que ha ingresado a este sistema de validación. Ya tiene todas las redes conocidas, fueron conocidas estas redes, ya todas estarán válidas. Y la información de los AS-Path de origen. ¿Qué información vamos a tener nosotros en el servidor validador que tiene el sistema autónomo 65501? La informace de los prefijos que se han estado publicando. Cuál es el máximo y cuál es el sistema autónomo de origen por el que se reconoce esta ruta. Tenemos nuestro esquema de validación, todo funciona perfectamente, vemos en nuestra tabla BGP los estados de validación, todos válidos sin ningún problema. ¿Pero qué pasa en el caso donde tenemos todos los ROAs creados? Que este sistema autónomo empiece a publicar el ruta que tiene el cliente. Este sistema autónomo le va a entregar la información directamente al sistema autónomo 65502, vamos a decir que el propietario es malintecionado y quiere hacer robo de esta ruta, y lo va a publicar directación al 65502. en la tabla de enrutamiento tenemos presente, damos privilegio al camino más corto, pues vamos a ver que en la ilformación de nuestra tabla simplificada, él va a conocer la ruta, pero desde otro sistema autónomo de origen, que no es el válido. ¿Qué pasa aquí? Él ya va a tener la información que esta ruta que está recibiendo es de un lugar que él no ha permitido, que no tiene en su radar, en su tabla de enrutamiento para conectarse. Que ese estado de validez en este momento es inválido, porque es una red que pertenece a otro sistema autónomo. En nuestra red no estamos haciendo ningún tipo de filtrado en los routers, él recibe la información que ha llegado de este atacante y ahí nos va a cambiar todo nuestro esquema de enrutamiento. Bueno, aquí quiero pasar a comentarles varias herramientas útiles que tenemos para apoyarnos con la creación de estos ROAs, información de cómo se están publicando nuestras rotas. Tenemos la herramienta del portal de MiLACNIC. Empezar a generarlos. Y otras herramientas desarrolladas desde LACNIC, herramientas que nos ayudan para esta tarea y vamos a poder ver de qué forma hemos desagregado nuestras rutas y cómo lo estamos haciendo. Vamos a poder tener información de los ROAs creados, poderlos descargar, información a nivel global de cómo se está viendo todas estas tablas de enrutamiento y estas rutas que están a nivel mundial anunciándose por cada uno de estos RIS. Cómo tenemos anunciados para cada uno de ellos. Este es un validador, un proyecto, una iniciativa conjunta entre NIC México y LACNIC. Es un proyecto que tiene tres enfoques, en este caso vamos a hablar solamente del validador, sería una herramienta que nos ayudaría para tener en nuestro servidor. Nos ayudará a entregar la información de los routers, de cuáles son esos ROAs que se han generado, se conectará con los RIS y tener al día para entregar en la red. Información de documentación general del validador, aquí está todo muy explicado. Van a poder descargarlo desde allí también para poder hacer Al final este validador qué nos va a dar, herramienta para conocer la información de enrutamiento de esta red y protegernos de este tipo de ataques. Creo que aquí terminamos el tema de RPKI en la práctica, espero haber hablado muy rápido y espero sus preguntas. >> Gracias, Sí hablaste superrápido. Bueno, espero que se haya entendido, Hay algunas preguntas para vos. "en qué parte de la plataforma se hace este proceso" me imagino que es desde MiLACNIC, vos tenías ahí unos gráficos. >> ¿Cómo es la pregunta? >> ¿En qué parte de la plataforma se hace este proceso? >> Ahora sí, me devuelves a responder la pregunta. >> Bueno, vamos a ingresar a la plataforma de MiLACNIC lo importante es tener usuario y contraseña para tener los permisos de administrador y vamos a encontrar RPKI y vamos a encontrar la información, qué ROAs hemos generado y cuáles no. Esto es para la creación de ROAs y las otras herramientas van a ser para la validación de cómo se están publicando estas rutas. >> Está bien. Es necesario hacer alguna configuración, esta es de Carlos Altamirano ¿Es necesario hacer alguna configuración en los ruteadores de border para hacer? >> Esto es un atributo que vamos a tener desde BGP para que en nuestra tabla BGP vayamos a poder ver este estado de validez, de hecho esta configuración se hace muy, muy rápido en los routers, son como tres comandos que hay que darle para que podamos ver en la tabla BGP el estado de validez de la información de las rutas. >> Bien. Carlos dice "todos los routers son compatibles?" >> Bueno, sí, de hecho no tengo en este momento conocimiento de qué sistema operativo, pero yo he hecho pruebas con varios equipos de diferentes marcas. Algunos lo que sí tenemos que tener presente es un poco la versión d sistema operativo que se tiene, no recuerdo bien la última versos que tenía en las prácticas que hice, en cuanto a versiones de sistemas operativos de los routers para hacer la activación y en la mayoría de equipos a nivel de enrutamientos soporta la funcionalidad de RPKI. En alguna época con equipos Cisco tuvimos que hacer algunas actualizaciones de software, pero no recuerdo números de versiones de software. >> Bien. Bueno estoy un poco perdido con la cantidad de preguntas que hay. "si yo creo un ROAs con /16 cuál es el lineamiento, cómo funciona el parámetro Max?" >> En el caso de un /16 normalmente uno lo que debería publicar son los ROAs tales como los hace los anuncios de BGP en internet. Si tengo un /16 y hago un anuncio de /16 completo, agregado, podría ser el caso, tengo un ISP y a a cada uno le doy un pedacito, si lo público como un único /16 lo que te debía crear un ROAs /16. Si estoy publicando prefijos 22 estaría validando mis propias publicación, lo importante es que los ROAs correspondan con lo que ustedes publican en la tabla BGP. Hay algunas herramientas, incluso cuando ustedes crean los ROAs en LACNIC en MiLACNIC le sugiere cómo crear los ROAs de acuerdo a lo que ve en las tablas de BGP globales y hay algunas herramientas como las que mencionó Erika, que toman la información y este sugiere el ROA Wizard y sugiere los ROAs que deberían crear. Bueno, yo todavía tengo un poco más de presentación, vamos con mis slide. Así avanzamos. Gracias Erika. >> Dale. >> Bueno. Para terminar con lo que veniamos hablando recuerden que hicimos como referencia a MANRS para tomarlo como guía de buenas prácticas de Routing, MANRS lo que nos pide es la cuestión de los filtros y cuestión de validación global que habló Erika y faltaría IRR de LACNIC. Una de las cuestiones que se decidió en LACNIC como una decisión de diseño fue no hacer un IRR nuevo. Vale la pena mencionar que LACNIC no tenía un routing resistric, el año pasado se trabajó en eso, ahora está disponible y en parte una de las razones fue el desarrollo RPKI y el desarrollo RPKI en la región. La idea de diseño es no duplicar la información que no tengamos bases de datos separadas porque eso no sería bueno. Decir la información de RPKI por un lado y IRR por otro y sean inconsistentes y lo que se hace es que de las bases de datos como el Whois y RPKI se extrae información para crear los objetos de IRR de LACNIC y otra decisión es no hacer una implementación compleca de RSPI Porque la mayoría de operadores utilizan solo una parte limitada de facilidades, RPSL implementa objetos que muchas veces no se usan, empezamos con la parte que más nos pedían los operadores, por decirlo de alguna manera. Lo más requerido. Y bueno, tomando esta idea d generarlo a partir del información de RPKI un objeto q está faltando es el concepto de AS-SET Hay una propuesta que lleva algún tiempo y que todavía no pasa a ser AS-SET no ha avanzado lo suficiente y hay que crearlo a través de de MiLACNIC. Como ya dijimos la equivalencia entre ROAs y Route 6 son similares la diferencia es que los ROAs están firmados criptográficamente, pero los dos asocian prefijo a un ASN que permite hacer la validación de origen en BGP. ¿Cómo usarlo? El peering ya lo usaron, en el 65501 crear un filtro para los prefijos. Una forma rudimentaria es directamente usar la información de IRR usando una consulta al Whois, el IRR una de las interfases que tiene es basada en IRRD4 aquí victimios todos los prefijos 65502 y luego los IPv4 y bueno con estas dos podríamos construir la lista de acceso. Estamos tomando del 65502 los prefijos y podríamos construir las listas. Acá en esta URL Está la información para saber qué significa cada cosa. En el ejemplo de tránsito es un poco más complejo, tendría que tomar todo esto y como decía Mariela, si hiciera una lista de prefijos sería muy complicado acá, lo que podemos hacer es valernos de este objeto recuerdan que ella explicó comunidades y acá dejábamos pasar y es una cosa que puede ser parecida de alguna manera la idea de esto es nosotros definimos, digamos el ejemplo de Mariela se aplica al 65502 lo que hacemos es que ellos tengan información para que ellos puedan hacer sus filtros, con el el ejemplo de comunidades podría filtrar acá a la salida, pero 501 no tiene forma de saber lo que anuncia el 502 si no se ponen de acuerdo no tienen la manera de saber qué van a aprender. Puedo decir cuáles son los ASN que daré. El Nombre es arbitrario, en este caso es indicación que son ASN de tránsito y los miembros puse acá los tres. Entonces, cuando yo publico esto cualquier otro externo podrá ver el ASN 65502 dice que sus ASN son estos tres. Entonces, en el sistema ASN 65501 ven distinta la visión, no es acá, sino que es este a la entrada y va a poder generar las listas de acceso. ¿Cómo se hace? hay una nueva versión de la herramienta bgpq3/4 permite exclusivamente los que responden a este ASN y lo que hace esto es, acá les dicen ustedes un nombre de listo de acceso, con la que va a crear, ustedes le ponen el IRR que va a consultar, la lista de acceso que va a crear, que es la que ustedes van a aplicar, ustedes acá ponen el ASN, qué hará este comando, lo que hará es fijarse cuáles son los sistemas autónomos, por cada uno de ellos hará una nueva consulta y va a obtener todos los prefijos IPv4 correspondientes a eso. Y luego va a crear la lista de acceso con sintaxis. En el caso de IPv6 es lo mismo, acá hay dos prefijos, en el anterior había solo uno IPv4. Acá hay uno solo, el otro tiene dos IPv6. Esto lo copian y lo pegan en el router. Bueno, pueden tener un script que lo hace. Esto ya saca la lista de acceso directamente. Acá hay más información, lo que hacen con eso es directamente configurar los routers y generar las configuraciones automáticamente. Con esto quedan demostrados con dos formas distintas de implementarlo, filtros con ROAs y con IRR. Bueno, no sé si hay más preguntas hasta acá. Con esto estaríamos terminando. >> Muchas preguntas. >> Hay una sesión de referencias y luego pasamos a terminar con las preguntas. Como ya estamos con la hora cumplida, para quienes quieran irse, les quiero dejar las referencias, los cersos de campus, el curso de RPKI, entre otros. el de LACNIC 32 lo pueden ver, donde hablamos de estos temas. Empecé con las estadísticas de un webinar en marzo. Acá hay otra documentación del proyecto FORT. para los que preguntaban cómo se creaban los ROAs, acá está. >> Tenemos algunas preguntas del IRR, que fue el último tema que hablamos. >> Dale. >> Por ejemplo, Manul pregunta: ¿El IRR de LACNIC tiene interfaz web, cómo es el acceso? >> hay dos aspectos de eso, uno es cómo crear objetivos y otro es cómo consultarlos. Si hay una interfaz web, en el último link que dejé pueden ver cómo consultar. Y por otro lado, para crear objetivos, es una sección nueva, que se llama IRR, ahí tienen que dar un clic para generar los objetivos, con eso genera los objetivos a partir de RPKI. En este caso para crear, vale la pena mencionar, tienen que tener creados los ROAs. Si no tienen ROAs creados, no los generarán. Sí se generan los objetivos y además, pero bueno. es lo principal. Seguimos con otra. >> Muchas. >> Quería unas pendientes. Algunas las fuimos contestando por escrito y otras dejé, porque por ahí era bueno... Una me daba pie a un anuncio. "buenos días, ¿Habrá estadistica mundial de cuál es el uso del RPKI? Hay uso en función de la cantidad de ROAs y demás. Hay varias organizaciones que llevan eso, lo que quería comentar es que el proyecto FORT, que hablamos del validador nada más, tienen una parte del monitoreo FORT, bueno, estaba en mi presentación, monitorea la cantidad de prefijos que están cubiertos por ROAs a nivel de la región. Y de los prefijos que se anuncian, cuáles son válidos, cuáles inválidos. Bueno. Es una referencia que pueden usar para tener idea del uso de RPKI. >> Por ejemplo, Guillermo. Una pregunta simple, pero que quieren saber. ¿Cada cuánto se deben actualiizar los ROAs? >> Los ROAs se deben actualiizar cada vez que cambiamos la forma de anunciar los prefijos hacia fuera. Como dije antes, si yo sé que voy a anunciar el /16 completo, debería crear un ROAs con longitud máxima 16, porque de esta forma no doy posibilidad a que otros creen anuncios, a que hagan secuestros de ruta con cosas más específicas. Si llega algo más específico de 16, va a ser inválido desde el punto de vista RPKI. Si yo el 16 lo voy a publicar en /20 o /22, entonces ahí sí voy a tener, diferentes ROAs, uno por el 16 completo y luego ROAs para cada uno de los 22, o creo un ROAs que digo prefijo 16 longitud máxima 22, pero ahí doy posibilidad de crear cosas en el medio, prefijo 18, 20, 21, si tengo prefijos especificados no voy a tener problema, pero si no... La consulta de cuándo lo cambias, si voy a cambiar algo en los anuncios. Si dejo de anunciar algo, porque entonces ahí, quizá, no tiene sentido el ROAs. Sobre todo cuando hay algo nuevo, tengo que estar creando un ROAs que corresponda con el anuncio que hago. Si ahora empiezo a anunciar en /21, y anunciaba en /20 tengo que cambiar el ROAs. ¿Cuál es el impacto al consumo en el router? Una de las cosas que mencioba Erika, el tema de la validación se hace en un servidor externo, por ejemplo en el validador FORT, entonces esa es la parte que más carga y, por lo tanto, no estaría cargando al router. El router no recibe carga muy alta, es baja porque todas las operaciones pesadas se hacen afuera, por eso se puso afuera del router. >> Guillermo. Esta que dice: ¿Qué tiempo le toma refrescarse la información de RPKI del prefijo a partir de la creación del ROAs en LACNIC? >> Creo que está en cuatro horas. No sé si Carlos Martínez está en línea para que nos dé precisión. >> ¿Me escuchan? >> ¿Qué tiempo le toma refrescarse la información RPKI del prefijo a partir de la creación de ROAs en LACNIC? >> En el peor de los casos, lleva alrededor de un par de horas. En la práctica se regenera muy rápidamente. Hay dos caminos, uno en función de cambios y otro es regeneración completa. En el peor de los casos, toca la regeneración completa y es un par de horas que tarda. >> Quedó una que no sé mucho la respuesta. La leo. ¿Cuál es la mejor manera en su visión para validar los anuncios a través de de RPKI? He visto que hay discusión sobre eso, la verdad es que no he seguido tanto el tema, es algo que se está discutiendo tanto en los foros de operadores. Te aconsejo que los sigas, porque yo no tengo ese tema tan claro. El tema pasa porque, para aclararlo, porque cuando uno configura black y tiene que anunciar, cuando recibe un ataque de una IP, tiene que pasar una comunidad a su proveedor para que la bloquee. Generalmente es un /32 de IPv4. El CPE lo va a bloquear. Pero eso no estaría respetando RPKI. Que se te haga ese anuncio, la organización afectada y no el dueño. Hay algunas consideraciones particulares. Además, es un 32 y no normalmente uno tiene un ROAs creado con longitud 34. No sé si Carlos tiene un comentario. >> No, tampoco es un tema que haya seguido de cerca, pero me parece interesante y esperamos investigarlo. >> Bueno. Yo quiero comentarles que quedan ocho preguntas. Estamos hablando con el estaff de hacer el razón de responderlas. Bueno, vamos viendo, veo ocho. Dejo que las vayan leyendo. No nos vamos a pelear en público ahora. >> No, no me aparecen, me aparecen cinco. >> Bueno. Por ejemplo, ¿Cuál es la dependencia de tener un ROAs y luego tener que implementar la solución de RPKI? ¿Tengo que hacerlo inmediatamente o puedo posponerlo a mediano o largo plazo? >> Creo que tiene que ver con cuándo crear los ROAs. Los ROAs se pueden crear en cualquier momento en realidad, lo que conviene es que.. Si uno no adoptó RPKI todavía, puede hacerse en cualquier momento. Es importante para estar protegido porque muchas organizaciones empiezan a hacer esta validación. Luego, tiene que ver con lo que comentamos el tiempo de cuándo crear los ROAs, bueno, cuando se hacen cambios, tienen que corresponder con las comunicaciones BGP, si hay un cambio que sigue cubierto por el ROAs no hay que hacer nada, pero si tengo uno que tien longitud mynpa de 20 y está en 22 sí debo hacer el cambio. >> Bueno, "con la implementación del RPKI los caches podrían ser... ¿Qué medida hay para protegerlos? >> Es importante cómo proteger un servidor de DNS y de hecho el caché solo debería hablar con los routers, no debería tener acceso desde afuera desde ningún lado. >> "¿Cuál es el impacto de consumo de recursos en los router usando RPKI? Ya se respondió LACNIC cuenta con repositorio de RPKI para las organizaciones independientes? >> sí, es el modo de hosteado y LACNIC la publica en el repositorio. >> Queda respondida. cualquier cosa está en la mitad de la pregunta respondida y cualquier cosa nos pueden escribir. si tengo más de un peering de salida hay que hacer algo adiconal en nuestra ROAs? >> Acá es importante una cosa, también en la slide de Erika estaba, si es peering uno va a crear el ROAs. Yo tengo mi ASN y si tengo por ejemplo una organización que tiene sus IP, pero no las publica porque no tiene ASN la organización puede crear ROAs con sus ISP. Por ejemplo si tengo delegadas direcciones de LACNIC a mi organización, pero si publican los ISP que yo vengo, por ejemplo el 10 y el 20 yo tengo que crear mis ROAs uno con ASN 10 y 20. Eso sería todo. >> La que sigue es corta ¿Cada ASN es responsable de crear sus ROAs? >> Sí, en realidad sí. El responsable es el que tiene los prefijos, cada ASN define si lo publica con su propio ASN u otro. >> ¿Qué herramientas podemos usar para levantar un servidor para rutas? >> Erika. >> Bueno, una de las herramientas es el validador Fort y que dejé la documentación en uno de los slide, no sé si tenga tiempo para volverla a presentar y otro validador que se utiliza mucho es el que fue desarrollado por RIPE y en realidad la instalación de este validador no requiere muchos recursos, más de una memoria RAM de 4 Gygas >> Queda poco, las slides están disponibles en la web de LACNIC. ¿En el caso que tenga un prefijo anunciado en un routeador administrado por mí alguna recomendación para que este ISP habilite este RPKI? >> Puedo hablar desde la experiencia con los diferentes ISP para una implementación a nivel nacional y la mejor práctica son los contratos con los ISP se renuenvan anualmente y lo ideal es indicar antes que inicie el contrato que ustedes tienen todos sus ROAs creados y que quieren tener como este esquema de validación para no entrar como en esta discusión porque en realidad sí es un tema difícil con los ISP lograr esta activación de este protocolo. >> Bueno, última pregunta y comentario. Óscar Cardenas dice "me refería si tengo que tener mi host de caché o puedo implementar mi caché a mediano plazo? >> Es un tema interesante, los ROAs y la validación son cosas que se pueden hacer de manera independiente, lo más importante para la cantidad de asistentes que hay acá de distintas organización, deberían crear sus ROAs para sus prefijos para protegerse. ¿Quiénes tienen que hacer validación? No necesariamente todos, con que lo hagan las principales organizaciones, IXP es importante que lo hagan. Organizaciones quizás redes académicas o más grandes cualquiera puede instalar un validador y usarlo, es un paso más complejo, si ustedes no reciben, o si reciben solo un default con sus proveedores no necesitan un validador, entonces si ustedes no están recibiendo una tabla completa o no tienen peering o conexiones con un IXP las organizaciones que sí tienen que hacer validación son las organizaciones que tienen tablas completas como los IXP que es una de las cosas que deberían hacer. Una de las partes, de hecho, bueno hay algunas bases de datos que muestran qué IXP están haciendo validación RPKI y bueno pueden consultar esto para verlo, pero son cosas separadas, una cosa es la creación de ROAs y otra es la implementación de validación que como dije no todas las organización. >> Bueno, estamos para terminar sson dos comentarios: una espectador que dice tiene más que ver con BGP que con el tema que presentamos hoy. "cuando un cliente no tiene ASN y quiere anunciar prefijos que no tiene anunciados, no serírecomendable formar un peer creo que tiene que ver más con funcionamento de BGP que en el sistema de ruteo que hablamos hoy ¿Qué te parece Guillermo? >> Sí, pero responderle. bueno siempre es dentro del ASN sí tienen que ser ASN separados y no tendría que ver con su proveedor. >> Por último, Ricardo dice que una opción es crear dos ROAs. Y esa con el MANRS Prefix-List y bueno chicos tuvimos un récord de respuestas contestadas más allá de la que me retaste recién. >> Te digo que no solo el curso, en realidad él está. En realidad el concepto de BGP solo. >> Llevamos más de 40 preguntas respondidas, 45. Así que bueno, Macarena, todo tuyo, nosotros terminamos con nuestro tutorial y gracias. >> Gracias, muchas gracias Mariela, Erika y Guillermo por sus presentaciones, en las próximas horas quedarán publicadas tanto el video como el texto de la transcripción simultánea. Gracias a los más de 260 participantes. Los esperamos mañana a las 14 UTC para el tutorial de MiLACNIC gracias y nos vemos mañana.