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.

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. ¿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. ¿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.  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. ¿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. 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.  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. 2007: no hay suficientes AS, los RIR empiezan a asignar AS de 32 bits (RFC 4893)

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. 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. 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. ¿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. 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. 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. 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. Topología interna del Route-Server

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. 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. 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. 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. 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.  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. 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. 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. CATNIX y MANRS
Mutually Agreed Norms for Routing Security

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. ¿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. 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