11. Security Considerations (Considerazioni di sicurezza)
11. Security Considerations (Considerazioni di sicurezza)
Le problematiche di sicurezza associate al NAT sono documentate da tempo. Vedere [RFC2663] e [RFC2993].
Tuttavia, spostare la funzionalità NAT dal CPE al core della rete del service provider e condividere indirizzi IPv4 tra i clienti crea requisiti aggiuntivi quando si registrano dati per uso in caso di abuso. In qualsiasi architettura in cui un indirizzo IPv4 non rappresenta in modo univoco un host finale, indirizzi IPv4 e timestamp non sono più sufficienti per identificare un particolare cliente broadband. L'AFTR dovrebbe avere la capacità di registrare il tunnel-id, il protocollo, le porte/gli indirizzi IP e l'istante di creazione del binding NAT per identificare univocamente le sessioni utente. I dettagli esatti di ciò che viene registrato sono specifici dell'implementazione e fuori dall'ambito del presente documento.
L'AFTR esegue funzioni di traduzione per host IPv4 interni che usano indirizzi RFC 1918 o l'intervallo di indirizzi riservato IANA (192.0.0.0/29). In alcune circostanze, un ISP può fornire politiche nell'AFTR e istruire l'AFTR a bypassare le funzioni di traduzione in base a `<IPv4 Address, port number, protocol>`. Quando l'AFTR riceve un pacchetto con informazioni corrispondenti alla politica dall'host interno, l'AFTR può semplicemente inoltrare il pacchetto senza traduzione. Gli indirizzi, le porte e le informazioni sul protocollo devono essere forniti sull'AFTR prima di ricevere il pacchetto. Il meccanismo di provisioning è fuori dall'ambito della presente specifica.
Quando decapsula i pacchetti, l'AFTR DEVE inoltrare solo pacchetti originati da indirizzi RFC 1918, un intervallo di indirizzi riservato IANA o qualsiasi altro indirizzo pre-autorizzato out-of-band. L'AFTR DEVE scartare tutti gli altri pacchetti. Ciò impedisce a dispositivi rogue di lanciare attacchi denial-of-service usando indirizzi IPv4 pubblici non autorizzati nel campo sorgente IPv4 dell'intestazione IPv4 o un intervallo di porta di trasporto non autorizzato nel campo di intestazione di trasporto IPv4. Ad esempio, dispositivi rogue potrebbero bombardare un server web pubblico lanciando un attacco TCP SYN ACK [RFC4987]. La vittima riceverà TCP SYN da indirizzi IPv4 sorgente casuali a velocità elevata e negherà servizi TCP agli utenti legittimi.
Con indirizzi IPv4 condivisi tra più utenti, le porte diventano una risorsa critica. Pertanto, alcuni meccanismi devono essere messi in atto da un AFTR per limitare l'uso delle porte, sia limitando la velocità delle nuove connessioni sia imponendo un limite rigido al numero massimo di porte utilizzabili da un singolo utente. Se questo numero è sufficientemente alto, non dovrebbe interferire con l'uso normale e fornirebbe comunque una protezione ragionevole del pool condiviso. Ulteriori considerazioni sulla condivisione degli indirizzi IPv4 si trovano in [RFC6269]. Altre considerazioni e raccomandazioni sul logging si trovano in [RFC6302].
Gli AFTR dovrebbero supportare modi per limitare il servizio solo ai clienti registrati. Una opzione semplice è implementare un filtro di ingresso IPv6 sull'interfaccia tunnel dell'AFTR per accettare solo l'intervallo di indirizzi IPv6 definito nel filtro.