lunedì 17 febbraio 2020

Per un'Internet più sicura: l'architettura BGP RPKI - parte III (pratica)

PREMESSA: questo è l'ultimo di tre post scritti congiuntamente dal sottoscritto e da Flavio LucianiChief Innovation Officer di NaMeX, che ringrazio per la sua disponibilità a collaborare a questo blog. Prima di leggere questo post è consigliabile leggere i due precedenti, il primo lo trovate qui, mentre il secondo qui.

Dopo aver visto i principali elementi dell'architettura RPKI e il suo funzionamento di base, è ora di mettere in pratica quanto detto. Illustreremo in questo post l'implementazione RPKI sia in ambiente Cisco (IOS XE) che Juniper (JUNOS).

NOTA: nello scenario seguente i numeri di AS utilizzati sono stati presi a caso (non ce ne vogliano i legittimi proprietari). I prefissi annunciati da ciascun AS sono stati presi dal RPKI repository di RIPE NCC, in modo da poterne verificare l'effettiva validità o non validità o l'impossibilità di verificarne lo stato.

La figura riporta lo scenario di un Case Study che utilizzeremo per implementare l’architettura RPKI e verificarne il funzionamento.

Lo scenario è quello di un IXP (AS 1234) che tramite i suoi Route Server (RS-1 e RS-2) fornisce ai propri consorziati (in questo Case Study esemplificati dagli AS 101, 1299, 2914 e 6762) il servizio di validazione degli annunci scambiati.
Per questo i due Route Server utilizzano il RPKI Validator fornito dal RIR Europeo RIPE NCC, installato su un server COTS, che ha indirizzo IP 192.168.150.84. La porta TCP utilizzata dal RPKI Validator di RIPE NCC è la 8282. Il RPKI Validator è a sua volta collegato via Internet al RPKI repository di RIPE NCC.
I due Route Server sono realizzati attraverso due routeruno Cisco che utilizza l’IOS XE, e l'altro Juniper che utilizza il JUNOS.  Ciascun AS annuncia i prefissi riportati nella figura. Per rendere il Case Study più interessante, abbiamo fatto annunciare agli AS 101 e 1299 due prefissi appartenenti ad altri due AS (vedi figura) e quindi non validi. Nella figura sono riportati gli stati di validazione che dovremmo aspettarci a valle del processo di validazione (V = Valid; N = NotFound; I = Invalid).

NOTA: in una infrastruttura IXP la validazione dei prefissi sui Route Server è consigliata dalle norme MANRS (Mutually Agreed Norms for Routing Security), che nella pagina dedicata agli IXP, alla sezione "Action 1. Prevent propagation of incorrect routing information. (Mandatory)", così recita: "IXPs using a Route Server to facilitate multilateral peerings should use it to validate received route announcements from a peer and subsequently filter them to other peers.".

CONFIGURAZIONI IN AMBIENTE CISCO
Le configurazioni da eseguire su un router Cisco, per interconnettersi a un RPKI Validator sono molto semplici, è sufficiente specificare tre parametri:
  • L’indirizzo IP del RPKI Validator
  • La porta TCP da utilizzare. Di solito la porta utilizzata dal RPKI Validator è la 323, ma può anche essere diversa. Ad esempio, come nel nostro Case Study, se si utilizzasse il RPKI Validator fornito dal RIR Europeo RIPE NCC, la porta da utilizzare è la 8282.
  • Il periodo delle query verso il RPKI Validator (refresh time) per il download dei ROA. Un valore tipico utilizzato nelle applicazioni pratiche è 600 sec. 
Le configurazioni da eseguire sono le seguenti:
router(config)# router bgp numero-AS
router(config-router)# bgp rpki server tcp IP-RPKI-Validator port porta-RPKI-Validator refresh secondi
Qualora per affidabilità si avessero due o più RPKI validator, è sufficiente ripetere il comando "bgp rpki ..." due volte, variando l'indirizzo IP del server dove risiede il RPKI validator.
La configurazione appena vista è applicabile a router Cisco con IOS classico o IOS XE. Per completezza riportiamo le configurazioni nei router che adottano l'IOS XR.

RP/0/RP0/CPU0:router(config)# router bgp numero-AS
RP/0/RP0/CPU0:router(config-bgp)# rpki server IP-RPKI-Validator
RP/0/RP0/CPU0:router(config-bgp-rpki-server)# transport tcp port porta-RPKI-Validator
RP/0/RP0/CPU0:router(config-bgp-rpki-server)# refresh-time secondi

L’utilizzo della validazione degli annunci BGP tramite RPKI, modifica il processo di selezione BGP, che non considera più tutti gli annunci (di uno stesso prefisso) per determinare il best-path. Infatti, di default gli annunci il cui stato di validazione è Invalid non vengono utilizzati (o almeno, non dovrebbero essere utilizzati) nel processo di selezione BGP. Un annuncio dichiarato Invalid non potrà mai quindi entrare in Tabella di Routing, che è poi, in ultima analisi, lo scopo principale dell’architettura RPKI.
È comunque possibile far partecipare al processo di selezione BGP anche gli annunci dichiarati Invalid, utilizzando i comandi seguenti:

IOS/IOS XE
router(config)# router bgp numero-AS
router(config-router)# address-family ipv4 unicast
router(config-router-af)# bgp bestpath prefix-validate allow-invalid


IOS XR
RP/0/RP0/CPU0:router(config)# router bgp numero-AS
RP/0/RP0/CPU0:router(config-bgp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-af)# bgp bestpath origin-as allow invalid

Si noti comunque, che in presenza di uno o più annunci di una stesso prefisso IP, di cui almeno uno dichiarato Valid, l’annuncio dichiarato Valid ha comunque la precedenza e viene eletto best-path indipendentemente dalle metriche BGP.
Ad esempio, supponiamo di avere due annunci eBGP del prefisso 79.140.80.0/20, di cui il primo dichiarato Valid e il secondo dichiarato Invalid, e supponiamo inoltre che il primo abbia il valore di Local Preference = 100 e il secondo il valore di Local Preference = 200. Non considerando gli stati validazione RPKI diverrebbe best-path il secondo annuncio, ma con RPKI abilitato, diviene best-path il primo annuncio poiché dichiarato Valid.

A volte, per motivi di testing, può essere utile disabilitare in toto l’utilizzo dell’informazione sugli stati di validazione nel processo di selezione. Ciò può essere fatto con i comandi seguenti:

IOS/IOS XE
router(config)# router bgp numero-AS
router(config-router)# address-family ipv4 unicast
router(config-router-af)# bgp bestpath prefix-validate disable

IOS XR
RP/0/RP0/CPU0:router(config)# router bgp numero-AS
RP/0/RP0/CPU0:router(config-bgp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-af)# bgp origin-as validation disable

Questi comandi, il cui utilizzo dovrebbe essere temporaneo e per situazioni specifiche, disabilitano l’utilizzo dell’informazione sugli stati di validazione nel processo di selezione ma non disconnettono il router dal RPKI Validator.
NOTA: è bene comunque essere consapevoli che l’utilizzo dei comandi sia della disabilitazione dell’utilizzo dell’informazione sugli stati di validazione nel processo di selezione, che sull’utilizzo nel processo di selezione degli annunci dichiarati Invalid, non è una buona pratica, poiché inficia le basi stesse dell’utilizzo dell’architettura RPKI.  
Infine, è possibile sfruttare i risultati del processo di validazione per applicare delle policy attraverso delle quali eseguire delle azioni sugli annunci, in funzione dello stato di validazione. Queste policy possono essere configurate attraverso i classici strumenti delle route-map (IOS e IOS XE) e route-policy (IOS XR). Per queste sono state definite delle nuove condizioni "match" che fanno riferimento agli stati di validazione.
Di seguito un esempio in ambiente IOS/IOS XE in cui agli annunci Valid viene assegnato un valore di Local Preference = 200, agli annunci NotFound viene assegnato un valore di Local Preference = 100, e infine agli annunci Invalid viene assegnato un valore di Local Preference = 50. Si noti che qualora si volessero eseguire azioni sugli annunci Invalid, è necessario eseguire il comando visto sopra che consente a questi annunci di partecipare al processo di selezione BGP. 

route-map RPKI permit 10
  match rpki invalid
  set local-preference 50
!
route-map RPKI permit 20
  match rpki not-found
  set local-preference 100
!
route-map RPKI permit 30
  match rpki valid
  set local-preference 200
!
router bgp
numero-AS
  bgp bestpath prefix-validate allow-invalid
  neighbor 10.1.1.1 route-map RPKI in


Riportiamo di seguito un secondo esempio, ma per l’IOS XR. L’unica differenza rispetto a quello appena mostrato è che in questo caso gli annunci Invalid vengono scartati.

route-policy RPKI
 if validation-state is valid then
   set local-preference 200
 elseif validation-state is not-found then
   set local-preference 100
 else
   drop
!
router bgp
numero-AS
  neighbor 10.1.1.1
    address-family ipv4 unicast
      route-policy RPKI in


Con RPKI abilitato, il comportamento di default di un router Cisco è di non propagare sulle sessioni iBGP, lo stato di validazione RPKI degli annunci eBGP ricevuti. Per consentirne la propagazione si utilizzano i comandi seguenti:


IOS/IOS XE
router(config)# router bgp numero-AS
router(config-router)# address-family ipv4 unicast
router(config-router-af)# neighbor IP-iBGP-peer announce rpki state
router(config-router-af)# neighbor IP-iBGP-peer send-community extended 

IOS XR
RP/0/RP0/CPU0:router(config)# router bgp numero-AS
RP/0/RP0/CPU0:router(config-bgp)# address-family ipv4 unicast
RP/0/RP0/CPU0:router(config-bgp-af)# bgp origin as validation signal ibgp

Si noti che l’informazione sullo stato di validazione viene propagata utilizzando una opportuna BGP Extended Community. Il formato della Extended Community è il seguente:
  • 1° byte = 0x43 - indica Extended Community del tipo Non-Transitive Opaque (vedi RFC 7153, sez. 5.2.9).
  • 2° byte = 0x0 – indica BGP Origin Validation State (vedi RFC 7153, sez. 5.2.9).
  • 3-8° byte = 0x0/0x1/0x2 rispettivamente per gli stati Valid/NotFound/Invalid (vedi RFC 8097, sez. 2).
Alla ricezione dell’annuncio iBGP contenente la BGP Extended Community, l’iBGP peer è in grado di ricavare lo stato di validazione dell’annuncio, senza necessità di un collegamento verso il RPKI Validator.

CONFIGURAZIONI IN AMBIENTE JUNIPER
Le configurazioni da eseguire su un router Juniper che adotta il JUNOS sono un po' più complesse (almeno quelle base) e molto più manuali rispetto a quelle Cisco. Per contro danno ampia libertà sulla gestione degli annunci Valid/Invalid/NotFound. Questa maggiore libertà deriva dal fatto che l'implementazione JUNOS dell'architettura RPKI richiede necessariamente l'implementazione di una routing policy, attraverso la quale è possibile decidere se accettare o meno una tipologia di annunci, associare agli stati di validazione delle Community, dei particolari valori di Local preference, ecc.

La configurazione è divisa in due parti. Nella prima parte si stabilisce il collegamento con il server dove risiede il RPKI validator. I comandi da eseguire sono i seguenti:

[edit routing-options]
validation {
    group NOME {
        session IP-RPKI-validator {
            refresh-time secondi;
            hold-time secondi;
            port porta-RPKI-Validator;
            local-address IP-locale;
        }
    }
}

All'interno di ciascun gruppo possono essere definiti al più due sessioni verso due diversi RPKI validator. Rispetto alla configurazione Cisco, compare un timer in più, l'Hold Time, che è il tempo trascorso il quale senza nessuna attività con il server, la sessione TCP viene abbattuta. Questo timer deve essere ovviamente maggiore del valore di refresh-time

NOTA: in alcune versioni del JUNOS più vecchie, la specifica del valore di Hold Time non era obbligatoria. Nella versione utilizzata nel nostra Case Study (17.2R1.13) era invece obbligatoria.

La seconda parte della configurazione riguarda la verifica della validazione e le policy da applicare agli annunci in funzione del loro stato di validità, policy sulle quali vi è ampia libertà. Inoltre, all'interno della stessa policy è possibile assegnare i valori di Extended Community citati sopra, che possono essere utilizzati sulle sessioni iBGP per propagare lo stato di validazione degli annunci. 

La generica configurazione della policy è la seguente:

[edit policy-options]
policy-statement Nome-Policy-RPKI {
    term VALID {
        from {
            protocol bgp;
            validation-database valid;
        }
        then {
            validation-state valid;
            community add COMM-V;
            accept;
        }
    }
    term INVALID {
        from {
            protocol bgp;
            validation-database invalid;
        }
        then {
            validation-state invalid;
            community add COMM-I;
            accept/reject;
        }
    }
    term NOTFOUND {
        from {
            protocol bgp;
            validation-database unknown;
        }
        then {
            validation-state unknown;
            community add COMM-U;
            accept/reject;
        }
    }
}
community COMM-I members 0x4300:2;
community COMM-U members 0x4300:1;
community COMM-V members 0x4300:0;

NOTA: in teoria è possibile utilizzare la clausola "reject" anche per annunci Valid, ma non l'abbiamo mostrata poiché non ha alcun senso da un punto di vista pratico.

Questa routing-policy va quindi applicata al processo BGP nella direzione "import", su tutte le sessioni eBGP per le quali si vogliono validare i prefissi ricevuti:

[edit protocols bgp]
group eBGP {
    import Nome-Policy-RPKI;
. . .    
}

A questo punto non ci resta che applicare tutte le configurazioni sin qui viste al nostro Case Study e vedere i principali comandi di visualizzazione che consentono di verificare il funzionamento dell'architettura RPKI.

CASE STUDY
Il nostro Case Study è basato sullo scenario riportato all'inizio del post. Le configurazioni riguardanti l'architettura RPKI eseguite sui due Route Server sono le seguenti:

RS-1 (Cisco IOS XE)

router bgp 1234
  bgp rpki server tcp 192.168.150.84 port 8282 refresh 600

RS-2 (Juniper JUNOS)

[edit routing-options]
validation {
    group RPKI-VAL {
        session 192.168.150.84 {
            refresh-time 600;
            hold-time 1500;
            port 8282;
            local-address 192.168.150.2;
        }
    }

}

[edit policy-options]
policy-statement VALIDATION {
    term VALID {
        from {
            protocol bgp;
            validation-database valid;
        }
        then {
            validation-state valid;
            community add COMM-V;
            accept;
        }
    }
    term INVALID {
        from {
            protocol bgp;
            validation-database invalid;
        }
        then {
            validation-state invalid;
            community add COMM-I;
            reject;
        }
    }
    term NOTFOUND {
        from {
            protocol bgp;
            validation-database unknown;
        }
        then {
            validation-state unknown;
            community add COMM-U;
            accept;
        }
    }
}
community COMM-I members 0x4300:2;
community COMM-U members 0x4300:1;

community COMM-V members 0x4300:0;

[edit protocols bgp]
group eBGP {
    import VALIDATION;
. . .    
}

Facciamo notare che nella configurazione di RS-2, la routing policy VALIDATION scarta gli annunci Invalid. Quello che accade in realtà, come vedremo a breve, che il JUNOS li mette in una parte "nascosta" (hidden) della Tabella di Routing, 

Vediamo ora come verificare se le configurazioni "fanno il loro dovere". La prima cosa da fare è verificare se la connessione TCP verso il RPKI Validator è attiva. Vediamolo dapprima per RS-1: 

RS-1# show bgp ipv4 unicast rpki servers
BGP SOVC neighbor is 192.168.150.84/8282 connected to port 8282
Flags 64, Refresh time is 600, Serial number is 133, Session ID is 4568
InQ has 0 messages, OutQ has 0 messages, formatted msg 462
Session IO flags 3, Session flags 4008
 Neighbor Statistics:
  Prefixes 86361
  Connection attempts: 12
  Connection failures: 1
  Errors sent: 0
  Errors received: 0

Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
Local host: 192.168.150.1, Local port: 13642
Foreign host: 192.168.150.84, Foreign port: 8282
Connection tableid (VRF): 0
Maximum output segment queue size: 50

. . . < resto dell’output omesso > . . .

Il risultato della visualizzazione mostra che la connessione TCP è stata stabilita correttamente (Connection state is ESTAB) e le 4 componenti che identificano la connessione TCP (Indirizzi IP e porte sorgente/destinazione):
  • Local host: 192.168.150.1, Local port: 13462
  • Foreign host: 192.168.150.84, Foreign port: 8282
Inoltre vengono visualizzate anche altre informazioni di minore importanza. Tra queste è possibile anche vedere il numero di ROA scaricati (Prefixes 86361). Si noti che la visualizzazione è stata troncata per brevità.

La stessa verifica per RS-2 si ottiene con il comando seguente:

tt@RS-2> show validation session detail
Session 192.168.150.84, State: up, Session index: 2
  Group: RPKI-VAL, Preference: 100
  Local IPv4 address: 192.168.150.2, Port: 8282
  Refresh time: 600s
  Hold time: 1500s
  Record Life time: 3600s
  Serial (Full Update): 133
  Serial (Incremental Update): 133
    Session flaps: 0
    Session uptime: 23:44:23
    Last PDU received: 00:00:13
    IPv4 prefix count: 75112
    IPv6 prefix count: 11249

I comandi seguenti consentono di visualizzare le RPKI Table IPv4/IPv6 ossia l’elenco dei ROA che il router scarica dal RPKI Validator e immette nella memoria locale. Poiché l'elenco dei ROA è molto lungo, diciamo dell'ordine delle decine di migliaia e in futuro (si spera) dell'ordine delle centinaia di migliaia, è opportuno eventualmente visualizzare la sola parte di interesse. Ad esempio, supponiamo di voler visualizzare sul database locale di RS-1 tutti i ROA IPv4/IPv6 dell'AS 6762; il comando da eseguire è il seguente:

RS-1#show bgp ipv4 unicast rpki table | i 6762
5.178.40.0/21        21      6762       0       192.168.150.84/8282
45.189.119.0/24      24      6762       0       192.168.150.84/8282
79.140.80.0/20       20      6762       0       192.168.150.84/8282
89.221.32.0/20       20      6762       0       192.168.150.84/8282
93.186.128.0/21      21      6762       0       192.168.150.84/8282
93.186.136.0/22      22      6762       0       192.168.150.84/8282
149.3.176.0/21       21      6762       0       192.168.150.84/8282
176.115.184.0/22     22      6762       0       192.168.150.84/8282
185.70.200.0/22      22      6762       0       192.168.150.84/8282
185.100.112.0/22     22      6762       0       192.168.150.84/8282
195.22.192.0/19      19      6762       0       192.168.150.84/8282
213.144.160.0/19     19      6762       0       192.168.150.84/8282

RS-1#show bgp ipv6 unicast rpki table | i 6762
2001:41A8::/32       32      6762       0       192.168.150.84/8282

2801:15:7000::/48    48      6762       0       192.168.150.84/8282

Nella visualizzazione superiore è riportata la RPKI Table per IPv4 e in quella inferiore la RPKI Table per IPv6. La prima colonna contiene il prefisso del ROA, la seconda colonna la lunghezza massima della maschera, e la terza colonna l’AS di origine del prefisso. Infine, la penultima colonna è sempre nulla e l'ultima contiene l’indirizzo IP del RPKI Validator (= 192.168.150.84) e la porta TCP (= 8282).

La visualizzazione delle RPKI Table su RS-2, sempre relativamente all'AS origine 6762, si ottiene con il comando seguente:


tt@RS-2> show validation database | match 6762
5.178.40.0/21-21        6762 192.168.150.84             valid
45.189.119.0/24-24      6762 192.168.150.84             valid   
79.140.80.0/20-20       6762 192.168.150.84             valid
89.221.32.0/20-20       6762 192.168.150.84             valid
93.186.128.0/21-21      6762 192.168.150.84             valid
93.186.136.0/22-22      6762 192.168.150.84             valid
149.3.176.0/21-21       6762 192.168.150.84             valid
176.115.184.0/22-22     6762 192.168.150.84             valid
185.70.200.0/22-22      6762 192.168.150.84             valid
185.100.112.0/22-22     6762 192.168.150.84             valid
195.22.192.0/19-19      6762 192.168.150.84             valid
213.144.160.0/19-19     6762 192.168.150.84             valid
2001:41a8::/32-32       6762 192.168.150.84             valid
2801:15:7000::/48-48    6762 192.168.150.84             valid   

A questo punto non ci resta che verificare lo stato di validazione degli annunci eBGP. Su RS-1 si ottiene:

RS-1#show ip bgp
. . .
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop          Metric LocPrf Weight Path
V*>  2.255.248.0/21   10.0.0.2                             0 1299 i
V*>  5.63.24.0/21     10.0.0.2                             0 1299 i
V*>  5.158.208.0/21   10.0.0.3                             0 2914 i
V*>  5.178.40.0/21    10.0.0.4                             0 6762 i
V*>  62.73.160.0/24   10.0.0.3                             0 2914 i
V*>  79.140.80.0/20   10.0.0.4                             0 6762 i
I*                    10.0.0.2                    200      0 1299 i
N*>  101.1.0.0/16     10.0.0.1                             0 101 i
N*>  103.13.80.0/23   10.0.0.2                             0 1299 i
I*   105.233.0.0/17   10.0.0.1                    200      0 101 i

Lasciamo al lettore provare, confrontando questi annunci con lo scenario descritto nella figura iniziale, che gli stati di validazione sono corretti. Un aspetto interessante da notare riguarda gli annunci del prefisso 79.140.80.0/20, originato (legalmente) dall'AS 6762 e (illegalmente) dall'AS 1299. Di questi due annunci, uno ha lo stato Valid l'altro Invalid. Nonostante quest'ultimo abbia un valore di Local Preference superiore (= 200), il processo di selezione BGP sceglie come best-path l'annuncio nello stato Valid. Questo non sarebbe cambiato neanche se avessimo permesso gli annunci Invalid nel processo di selezione con il comando:

router bgp 1234
 address-family ipv4
  bgp bestpath prefix-validate allow-invalid

Vediamo, per concludere, la Tabella degli annunci BGP su RS-2 (Nota: in questo caso abbiamo lasciato tutti i valori di Local Preference al loro valore di default).

tt@RS-2> show route table inet.0 protocol bgp

inet.0: 16 destinations, 17 routes (15 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

2.255.248.0/21     *[BGP/170] 15:22:08, localpref 100
                     AS path: 1299 I, validation-state: valid
                    > to 10.0.0.2 via ge-0/0/1.0
5.63.24.0/21       *[BGP/170] 15:22:08, localpref 100
                     AS path: 1299 I, validation-state: valid
                    > to 10.0.0.2 via ge-0/0/1.0
5.158.208.0/21     *[BGP/170] 15:22:08, localpref 100
                     AS path: 2914 I, validation-state: valid
                    > to 10.0.0.3 via ge-0/0/1.0
5.178.40.0/21      *[BGP/170] 15:22:08, localpref 100
                     AS path: 6762 I, validation-state: valid
                    > to 10.0.0.4 via ge-0/0/1.0
62.73.160.0/24     *[BGP/170] 15:22:08, localpref 100
                     AS path: 2914 I, validation-state: valid
                    > to 10.0.0.3 via ge-0/0/1.0
79.140.80.0/20     *[BGP/170] 00:01:19, localpref 100
                     AS path:  6762 I, validation-state: valid
                    > to 10.0.0.4 via ge-0/0/1.0
101.1.0.0/16       *[BGP/170] 15:22:08, localpref 100
                     AS path: 101 I, validation-state: unknown
                    > to 10.0.0.1 via ge-0/0/1.0
103.13.80.0/23     *[BGP/170] 15:22:08, localpref 100
                     AS path: 1299 I, validation-state: unknown
                    > to 10.0.0.1 via ge-0/0/1.0

Come si può notare la tabella mostra i soli annunci Valid e NotFound (che il JUNOS chiama Unknown). E gli annunci Invalid? Sono nella parte "nascosta" della tabella (2 hidden). Per visualizzarli si può utilizzare il comando seguente:

tt@RS-2> show route table inet.0 hidden

inet.0: 16 destinations, 17 routes (15 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

79.140.80.0/20      [BGP ] 11:18:49, localpref 100
                     AS path: 1299 I, validation-state: invalid
                    > to 10.0.0.2 via ge-0/0/1.0
105.233.0.0/17      [BGP ] 11:18:49, localpref 100
                     AS path: 101 I, validation-state: invalid
                    > to 10.0.0.1 via ge-0/0/1.0

Per chi non fosse familiare con il JUNOS, ricordiamo che gli annunci "hidden" non partecipano al processo di selezione BGP e quindi non possono diventare best-path.

NOTA: il comportamento del JUNOS nel processo di selezione BGP differisce da quello Cisco in quanto non tiene conto dello stato di validazione dei prefissi. Ad esempio,  accettando nella policy i prefissi Invalid e definendo i Local Preference per il prefisso 79.140.80.0/20 come per RS-1, il processo di selezione sceglie come best-path l'annuncio Invalid, come si evince dalla visualizzazione seguente:

tt@RS-2> show route 79.140.80.0/20

inet.0: 16 destinations, 17 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

79.140.80.0/20     *[BGP/170] 00:05:38, localpref 200
                      AS path: 1299 I, validation-state: invalid
                    > to 10.0.0.2 via ge-0/0/1.0
                    [BGP/170] 09:43:30, localpref 100
                      AS path: 6762 I, validation-state: valid
                    > to 10.0.0.4 via ge-0/0/1.0

E quindi, per evitare situazioni contrarie allo spirito dell'architettura RPKI, consigliamo come best practice di rigettare gli annunci Invalid.

FINE DELLA STORIA!!! 
Con questo post abbiamo concluso la trilogia sull'architettura RPKI. Ci auguriamo di avervi fatto capire l'importanza di applicarla alle reti reali. E speriamo che le prove pratiche illustrate in questo post vi siano utili. Ci preme farvi notare che non tutte le implementazioni sono uguali, per cui prima di mettere in campo il tutto accertatevi del funzionamento. La teoria comunque è uguale per tutti!!!

Io (Ammiraglio Tofonoto) e l'amico Flavio Luciani vi ringraziamo per averci seguito sin qui.

English versions coming up next ... stay tuned!!!

Nessun commento:

Posta un commento