12. Security Considerations (Considerazioni di sicurezza)
12. Security Considerations (Considerazioni di sicurezza)
Finché le Flow Specifications sono limitate a corrispondere ai percorsi di routing unicast appropriati per i prefissi interessati (Sezione 6), le proprietà di sicurezza di questa proposta equivalgono alle proprietà di sicurezza esistenti del routing unicast BGP. Qualsiasi allentamento del processo di validazione descritto nella Sezione 6 può consentire la propagazione di Flow Specifications indesiderate e potenzialmente l'applicazione di Traffic Filtering Actions indesiderate sui flussi di traffico.
Se i meccanismi sopra non sono in atto, ciò può aprire la strada ad ulteriori attacchi di denial of service, come filtraggio del traffico indesiderato, nuovo marcamento o reindirizzamento.
Il dispiegamento, all'interno dei confini amministrativi di una rete, di allentamenti specifici della validazione può essere utile per alcune reti per distribuire rapidamente filtri per contrastare attacchi di denial of service. Affinché una rete sfrutti tale allentamento, la policy BGP DEVE supportare filtraggio aggiuntivo, poiché il campo source AS è vuoto. Le specifiche che allentano i vincoli di validazione DEVONO includere considerazioni di sicurezza che forniscono i dettagli del filtraggio aggiuntivo richiesto. Ad esempio, la validazione dell'origine può fornire filtraggio rafforzato all'interno di una confederazione di AS.
Il routing inter-dominio si basa su una rete di fiducia. I sistemi autonomi adiacenti sono fidati di annunciare informazioni di raggiungibilità valide. Se questo modello di fiducia è violato, un sistema autonomo adiacente può causare un attacco di denial of service annunciando informazioni di raggiungibilità per un dato prefisso per il quale non fornisce servizio (dirottamento dello spazio di indirizzi non filtrato). Poiché la validazione delle Flow Specifications è legata all'annuncio del miglior routing unicast, un fallimento nella validazione del miglior percorso può impedire al router locale di usare la Flow Specification. Possibili mitigazioni sono [RFC6811] e [RFC8205].
Agli Internet Exchange Point (IXP), il routing è spesso scambiato tramite route server che non estendono AS_PATH. In questo caso, non è possibile imporre che l'AS più a sinistra in AS_PATH sia l'AS vicino (l'AS del route server). Poiché la validazione delle Flow Specifications (Sezione 6) si basa su ciò, è necessaria estrema cautela. Si raccomanda di usare una policy di routing in ingresso rigida in tali scenari.
Abilitare funzionalità simili a firewall nei router senza amministrazione centralizzata può rendere alcuni guasti più difficili da diagnosticare. Ad esempio, i pacchetti TCP possono essere consentiti tra una coppia di indirizzi, ma non i pacchetti ICMP. I pacchetti più piccoli di 900 o più grandi di 1000 ottetti possono essere consentiti tra una coppia di indirizzi, ma non quelli con lunghezza tra 900 e 1000. Un tale comportamento può essere fonte di confusione; sia che sia configurato manualmente o coordinato tramite le estensioni di protocollo descritte in questo documento, queste funzionalità DOVREBBERO essere usate con cautela.
Un parlante BGP Flow Specification (ad esempio, un controller DDoS automatizzato), se mal programmato, se l'algoritmo non si comporta come previsto o se è semplicemente un sistema malevolo, può annunciare Flow Specifications inattese, inviare aggiornamenti ad alta frequenza o generare un gran numero di Flow Specifications. Ciò può sottoporre a stress i sistemi riceventi oltre la loro capacità o causare l'applicazione di Traffic Filtering Actions indesiderate sui flussi.
Un sistema potrebbe non essere in grado di individuare tutti i valori di intestazione necessari per identificare un pacchetto. Ciò è particolarmente problematico per i pacchetti frammentati che non sono il primo frammento, quindi privi di intestazione del protocollo di livello superiore o crittografia ESP (Encapsulating Security Payload) NULL [RFC4303].
Sebbene la validazione generale del NLRI Flow Specification sia specificata in questo documento (Sezione 6), la ricezione di Traffic Filtering Actions da terze parti può richiedere validazione o filtraggio personalizzati. In particolare, tutte le azioni diverse dal rate del traffico possono consentire a terze parti di modificare gli attributi di inoltro dei pacchetti e potenzialmente ottenere accesso ad altre tabelle di routing/VPN o code indesiderate. Ciò può essere evitato filtrando correttamente le community Traffic Filtering Action ai confini della rete ed esponendo a terze parti solo un sottoinsieme predefinito di Traffic Filtering Actions (vedere Sezione 7). Un modo per farlo è mappare community definite dall'utente che possono essere impostate da terze parti su Traffic Filtering Actions e non accettare Extended Community Traffic Filtering Action provenienti da terze parti.
Questa estensione aggiunge informazioni supplementari ai router Internet. Questi sono limitati per quanto riguarda il numero massimo di elementi dati che possono ospitare e il numero di eventi che possono elaborare per unità di tempo. I fornitori di servizi DEVONO considerare la capacità massima delle proprie apparecchiature e potrebbero dover limitare il numero di Flow Specifications accettate ed elaborate.