Filtre antes de preferir: cómo escribir una política BGP de borde que falle de forma segura

Estar multihomed no es lo mismo que ser resiliente. Dos carriers de tránsito y un puerto en un punto de intercambio le dan opciones; la política de enrutamiento decide si esas opciones le hacen más rápido y más seguro, o simplemente le dan a una ruta mala más maneras de entrar. Así pensamos nosotros una política de borde, en el orden en que una ruta la encuentra realmente.

El problema que tiene toda red multihomed

En cuanto recibe tablas completas de más de un carrier, su router está eligiendo entre caminos todo el día, todos los días, y elige según las reglas que usted escribió. Si no escribió ninguna, recurre a los criterios de desempate por defecto de BGP: el AS path más corto, y después una cascada de detalles que no tienen nada que ver con la latencia, el coste ni sus clientes.

El atajo habitual es atornillar primero la preferencia a las sesiones («prefiere el carrier A, que es más barato») y añadir el filtrado después, si acaso. Ese orden está al revés. La preferencia es una decisión sobre rutas buenas. Si no se ha retirado la basura antes de tomar esa decisión, lo que está haciendo es ordenar basura con esmero.

Primera etapa: higiene, antes de cualquier decisión

Cada sesión de entrada, de tránsito o de peering, pasa por la misma política de higiene antes de que nada más toque la ruta. La lista es corta y aburrida, que es justo la idea:

• Bogons. El espacio privado, reservado, de documentación y no asignado no tiene nada que hacer llegando desde internet.
• Sus propios prefijos. Una ruta hacia su propio espacio aprendida desde fuera es un bucle o un secuestro. Descártela.
• La ruta por defecto. Salvo que haya pedido una ruta por defecto a un carrier, no quiere que aparezca una porque alguien aguas arriba cometió un error.
• Demasiado específico. Cualquier cosa más larga que un /24 en IPv4 (y un /48 en IPv6) no es enrutable globalmente por convención. Aceptarlo invita a secuestros con prefijos más específicos.
• AS paths absurdos. Caminos con ASN privados, o caminos mucho más largos de lo que necesita cualquier ruta real.

En términos genéricos de route-policy de Cisco IOS-XR, el esqueleto es este:

route-policy TRANSIT-IN
  if destination in BOGONS-V4 or destination in OUR-PREFIXES then
    drop
  endif
  if destination in (0.0.0.0/0) then
    drop
  endif
  if destination in (0.0.0.0/0 ge 25) then
    drop
  endif
  if as-path in PRIVATE-ASNS then
    drop
  endif
  apply SET-PREFERENCE
end-policy

Fíjese en que la lógica de preferencia se aplica al final del todo, como una política separada. La higiene es idéntica en todas las sesiones; la preferencia difiere por sesión. Mantenerlas separadas significa que un cambio en el direccionamiento del tráfico nunca puede debilitar el filtrado por accidente.

Segunda etapa: preferencia por niveles

Una vez que solo quedan rutas sanas, decida qué camino gana. Nosotros usamos niveles de local preference en lugar de un número por carrier, porque los niveles describen la intención:

• El peering directo gana. Una ruta aprendida de la propia red, en un punto de intercambio o por una sesión bilateral, es el camino más corto que puede conseguir.
• Los clientes propios de un carrier van después. Si un carrier de tránsito etiqueta con una comunidad las rutas que aprende de sus propios clientes, esas rutas se quedan en la red de ese carrier de extremo a extremo.
• Todo lo demás va por el tránsito que mide mejor para el grueso del tráfico.

Un segundo carrier se mantiene caliente como reserva: tabla completa aceptada, preferencia más baja, listo en cuanto el primero retire sus rutas.

Una regla más se gana el sueldo en silencio: nunca use un carrier de tránsito para llegar a los clientes de otro carrier cuando el segundo está conectado a usted directamente. Casar el AS vecino en el camino y bajar la preferencia evita que el tráfico dé un rodeo caro por un tercero.

Tercera etapa: disciplina de salida

El lado de salida es más simple y más importante. Anuncie exactamente los prefijos que origina, y nada más:

prefix-set OUR-PREFIXES-V4
  192.0.2.0/24,
  198.51.100.0/24
end-set

route-policy TRANSIT-OUT
  if destination in OUR-PREFIXES-V4 then
    pass
  else
    drop
  endif
end-policy

Una lista explícita de permitidos en salida significa que un error en otra parte de su red (una estática redistribuida, una ruta de cliente que debió quedarse interna) no puede convertirle en camino de tránsito para el tráfico de otro. El modelado del camino de retorno, como el prepending de AS path hacia un carrier que quiere usar menos en entrada, ocurre dentro de esta política, nunca en lugar de ella.

Cuarta etapa: no origine tráfico falsificado

La política de enrutamiento controla lo que usted cree; el antispoofing controla lo que envía. BCP38 dice que una red no debería reenviar paquetes cuya dirección de origen no pueda provenir legítimamente de detrás de la interfaz por la que llegaron. En las interfaces hacia internet y hacia clientes, eso significa unicast reverse path forwarding en modo estricto donde la topología lo permita, o filtros explícitos de dirección de origen donde no. Es uno de los pocos controles que protege al resto de internet de usted, y es la diferencia entre que un servidor comprometido en su red sea su problema y que sea el de todos.

Compruebe su propio borde

Si opera su propio borde, o quiere hacerle a su proveedor las preguntas correctas, aquí tiene una lista breve:

• ¿Se aplica la higiene de forma idéntica en todas las sesiones de entrada, incluidos los route servers de los puntos de intercambio y los peers «de confianza»?
• ¿Puede demostrar que un /25 o su propio prefijo enviado por un vecino se descarta? Pruébelo en un laboratorio, o lea la política línea a línea.
• ¿Es su política de salida una lista explícita de permitidos, o un «todo excepto»?
• ¿Sabe por qué carrier sale su tráfico hacia los diez destinos principales, y por qué? Un traceroute desde el borde más show bgp <prefix> lo responde en minutos.
• ¿Está el filtrado BCP38 ligado a cada interfaz hacia internet, y tiene una prueba que lo demuestre?
• ¿Mide su red desde fuera? Una plataforma independiente como RIPE Atlas muestra cómo llega realmente internet hasta usted, que a menudo no es como cree su router.

Por qué nos molestamos

Cada uno de estos pasos es invisible en un día bueno. El día en que un carrier filtra una tabla, tira un circuito por mantenimiento, o un vecino anuncia algo que no debería, deciden si su tráfico lo nota. Operamos nuestros propios sistemas autónomos con esta estructura en routers Cisco ASR 9000 y Juniper MX, medidos continuamente desde fuera, porque es la única forma que conocemos de que una red multihomed se comporte de manera predecible.

Si quiere un segundo par de ojos sobre su propia política de borde, o una plataforma que se apoye en una construida así, estaremos encantados de hablar.

Hable con un ingeniero

Related

Relacionado: Nuestra propia red: dos ASN, muchos carriers, peering · Monitorización de red y evidencias · IPv6, nativo y dual-stack