13. Security Considerations (Considerazioni sulla sicurezza)
13. Security Considerations (Considerazioni sulla sicurezza)
Poiché questo documento descrive un protocollo di sicurezza, molti aspetti di interesse per la sicurezza sono descritti nelle sezioni pertinenti. Questa sezione evidenzia problemi che potrebbero non essere ovvi in altre sezioni.
Cache Validation (Convalida della cache): Affinché una raccolta di cache come descritto nella sezione 11 garantisca una vista coerente, devono ricevere ancoraggi di fiducia coerenti da utilizzare nel loro processo di convalida interno. La distribuzione di un ancoraggio di fiducia coerente si presume avvenga fuori banda.
Cache Peer Identification (Identificazione dei peer della cache): Il router avvia una connessione di trasporto verso una cache, che identifica tramite indirizzo IP o nome di dominio completo. Si noti che un attacco di spoofing DNS o di indirizzo potrebbe rendere la cache corretta irraggiungibile. Non verrebbe stabilita alcuna sessione, poiché le chiavi di autorizzazione non corrisponderebbero.
Transport Security (Sicurezza del trasporto): La RPKI si basa sulla fiducia degli oggetti, non sulla fiducia del server o del trasporto. Cioè, l'ancoraggio di fiducia radice IANA viene distribuito a tutte le cache attraverso mezzi fuori banda e può quindi essere utilizzato da ciascuna cache per convalidare certificati e ROA fino in fondo all'albero. Le relazioni inter-cache si basano su questo modello di sicurezza degli oggetti; pertanto, il trasporto inter-cache può essere leggermente protetto.
Tuttavia, questo documento di protocollo presuppone che i router non possano eseguire la crittografia di convalida. Pertanto, l'ultimo collegamento, dalla cache al router, è protetto dall'autenticazione del server e dalla sicurezza a livello di trasporto. Questo è pericoloso, poiché l'autenticazione del server e il trasporto hanno modelli di minaccia molto diversi rispetto alla sicurezza degli oggetti.
Quindi la forza della relazione di fiducia e del trasporto tra il(i) router e la(e) cache è critica. State scommettendo il vostro routing su questo.
Sebbene non possiamo dire che la cache deve essere sulla stessa LAN, anche solo a causa del problema di un'azienda che desidera scaricare il compito della cache sul(i) suo(i) ISP upstream, località, fiducia e controllo sono questioni molto critiche qui. La(e) cache DOVREBBE(RO) davvero essere il più vicino possibile, nel senso di trasporto controllato e protetto (contro DDoS, MITM), al(ai) router. DOVREBBE anche essere topologicamente vicina in modo che sia necessario un minimo di dati di routing convalidati per avviare l'accesso di un router a una cache.
L'identità del server cache DOVREBBE essere verificata e autenticata dal client router, e viceversa, prima che vengano scambiati dati.
I trasporti che non possono fornire l'autenticazione e l'integrità necessarie (vedere sezione 9) devono fare affidamento sulla progettazione della rete e sui controlli operativi per fornire protezione contro attacchi di spoofing/corruzione. Come sottolineato nella sezione 9, TCP-AO è il piano a lungo termine. I protocolli che forniscono integrità e autenticità DOVREBBERO essere utilizzati, e se non possono esserlo, cioè se TCP viene utilizzato come trasporto, il router e la cache DEVONO trovarsi sulla stessa rete affidabile e controllata.