Filtrate prima di preferire. Una policy BGP di edge che fallisce in sicurezza

Essere multi-homed non è la stessa cosa che essere resilienti. Due carrier di transito e una porta su un internet exchange vi danno opzioni; la policy di routing decide se quelle opzioni vi rendono più veloci e più sicuri, o se danno semplicemente a una route cattiva più strade per entrare. Ecco come ragioniamo su una policy di edge, nell'ordine in cui una route la incontra davvero.

Il problema che ogni rete multi-homed ha

Nel momento in cui prendete full table da più di un carrier, il vostro router sceglie tra percorsi tutto il giorno, ogni giorno, e sceglie secondo le regole che avete scritto. Se non ne avete scritte, ricade sui criteri di spareggio predefiniti di BGP: AS path più corto, poi una cascata di dettagli che non hanno nulla a che fare con latenza, costo o i vostri clienti.

La scorciatoia comune è imbullonare prima la preferenza sulle sessioni («preferisci il carrier A, costa meno») e aggiungere il filtraggio dopo, se mai. Quell'ordine è al contrario. La preferenza è una decisione sulle route buone. Se la spazzatura non è stata rimossa prima di prendere quella decisione, state classificando con cura della spazzatura.

Fase uno: igiene, prima di qualsiasi decisione

Ogni sessione in ingresso, transito o peer, passa attraverso la stessa policy di igiene prima che qualsiasi altra cosa tocchi la route. L'elenco è corto e noioso, ed è questo il punto:

• Bogons. Spazio privato, riservato, di documentazione e non allocato non ha nulla da fare arrivando da internet.
• I vostri prefissi. Una route verso il vostro spazio imparata dall'esterno è un loop o un hijack. Scartatela.
• La default route. A meno che non abbiate chiesto una default a un carrier, non volete che ne compaia una perché qualcuno a monte ha commesso un errore.
• Troppo specifico. Qualsiasi cosa più lunga di un /24 per IPv4 (e di un /48 per IPv6) non è globalmente instradabile per convenzione. Accettarla invita hijack più specifici.
• AS path assurdi. Path con ASN privati al loro interno, o path molto più lunghi di quanto qualsiasi route reale richieda.

In termini generici di route-policy Cisco IOS-XR, lo scheletro è questo:

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

Notate che la logica di preferenza viene applicata alla fine, come policy separata. L'igiene è identica su ogni sessione; la preferenza differisce per sessione. Tenerle separate significa che una modifica allo steering non può mai indebolire per sbaglio il filtraggio.

Fase due: preferenza a livelli

Quando restano solo route sane, decidete quale percorso vince. Usiamo livelli di local preference invece di un numero per carrier, perché i livelli descrivono un'intenzione:

• Il peering diretto vince. Una route imparata dalla rete stessa, a un exchange o su una sessione bilaterale, è il percorso più corto che potete ottenere.
• Poi vengono i clienti del carrier stesso. Se un carrier di transito marca con una community le route che impara dai propri clienti, quelle route restano sulla rete di quel carrier da un capo all'altro.
• Tutto il resto passa dal transito che misura meglio per il grosso del traffico.

Un secondo carrier viene tenuto caldo in standby: full table accettata, preferenza più bassa, pronto nel momento in cui il primo ritira.

Un'altra regola si guadagna il posto in silenzio: non usate mai un carrier di transito per raggiungere i clienti di un altro carrier quando il secondo carrier è collegato a voi direttamente. Fare match sull'AS del vicino nel path e abbassare la preferenza impedisce al traffico di fare una deviazione costosa attraverso una terza parte.

Fase tre: disciplina in uscita

Il lato in uscita è più semplice e più importante. Annunciate esattamente i prefissi che originate, e nient'altro:

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 allow list esplicita in uscita significa che un errore altrove nella vostra rete (una statica ridistribuita, una route di un cliente che doveva restare interna) non può trasformarvi in un percorso di transito per il traffico di qualcun altro. La modellazione del percorso di ritorno, come l'AS-path prepending verso un carrier che volete usare meno in ingresso, avviene dentro questa policy, mai al suo posto.

Fase quattro: non originate traffico spoofed

La policy di routing controlla ciò a cui credete; l'anti-spoofing controlla ciò che inviate. BCP38 dice che una rete non dovrebbe inoltrare pacchetti il cui indirizzo sorgente non potrebbe legittimamente provenire da dietro l'interfaccia su cui sono arrivati. Sulle interfacce verso internet e verso i clienti, questo significa unicast reverse path forwarding in modalità strict dove la topologia lo consente, o filtri espliciti sull'indirizzo sorgente dove non lo consente. È uno dei pochi controlli che protegge il resto di internet da voi, ed è la differenza tra un server compromesso nella vostra rete che è un vostro problema e uno che è un problema di tutti.

Controllare il vostro edge

Se gestite il vostro edge, o volete fare al vostro provider le domande giuste, ecco una breve checklist:

• L'igiene è applicata in modo identico su ogni sessione in ingresso, compresi i route server degli exchange e i peer «fidati»?
• Riuscite a dimostrare che un /25 o un vostro prefisso inviatovi da un vicino viene scartato? Provatelo in laboratorio, o leggete la policy riga per riga.
• La vostra policy in uscita è una allow list esplicita, o «tutto tranne»?
• Sapete da quale carrier esce il vostro traffico verso le dieci destinazioni principali, e perché? Un traceroute dall'edge più show bgp <prefix> risponde in pochi minuti.
• Il filtraggio BCP38 è legato a ogni interfaccia verso internet, e avete un test che lo dimostra?
• Misurate la vostra rete dall'esterno? Una piattaforma indipendente come RIPE Atlas mostra come internet vi raggiunge davvero, che spesso non è come il vostro router pensa.

Perché ci prendiamo il disturbo

Ognuno di questi passaggi è invisibile in un giorno buono. Il giorno in cui un carrier fa un leak di una tabella, mette giù un circuito per manutenzione, o un vicino annuncia qualcosa che non dovrebbe, decidono se il vostro traffico se ne accorge. Gestiamo i nostri sistemi autonomi con questa struttura su router Cisco ASR 9000 e Juniper MX, misurati di continuo dall'esterno, perché è l'unico modo che conosciamo per far comportare in modo prevedibile una rete multi-homed.

Se volete un secondo paio di occhi sulla vostra policy di edge, o una piattaforma che stia dietro una costruita così, parliamone volentieri.

Parla con un ingegnere

Related

Correlati: La nostra rete: due ASN, molti carrier, peering · Monitoraggio di rete ed evidenze · IPv6, nativo e dual-stack