11. Considerazioni sulla sicurezza
Esistono rischi significativi nel consentire a client arbitrari di stabilire un tunnel che consenta l'invio a host arbitrari, indipendentemente dal fatto che i tunnel siano limitati a host specifici o meno. I cattivi attori potrebbero abusare di questa capacità per inviare traffico e farlo attribuire al proxy IP. I server HTTP che supportano il proxying IP DOVREBBERO limitarne l'uso agli utenti autenticati. A seconda della distribuzione, i possibili meccanismi di autenticazione includono TLS reciproco tra endpoint di proxying IP, autenticazione basata su HTTP tramite l'intestazione HTTP Authorization [HTTP] o persino token bearer. I proxy possono applicare policy per gli utenti autenticati per limitare ulteriormente il comportamento del client o gestire possibili abusi. Ad esempio, i proxy possono limitare la velocità dei singoli client che inviano una quantità eccessivamente grande di traffico attraverso il proxy. Come altro esempio, i proxy possono limitare l'assegnazione dell'indirizzo (prefisso) ai client in base a determinati attributi del client, come la posizione geografica.
L'assegnazione degli indirizzi può avere implicazioni sulla privacy per gli endpoint. Ad esempio, se un proxy partiziona il proprio spazio degli indirizzi in base al numero di client autenticati e quindi assegna intervalli di indirizzi distinti a ciascun client, gli host di destinazione potrebbero utilizzare queste informazioni per determinare quando i pacchetti IP corrispondono allo stesso client. Evitare tali vettori di tracciamento può essere importante per determinate distribuzioni proxy. I proxy DOVREBBERO evitare l'assegnazione persistente di indirizzi (prefissi) per client quando possibile.
La falsificazione degli indirizzi IP di origine nel traffico inviato è stata comune per gli attacchi denial-of-service. Le implementazioni di questo meccanismo devono garantire di non facilitare tali attacchi. In particolare, ci sono scenari in cui un endpoint sa che il suo peer è autorizzato a inviare pacchetti IP solo da un determinato prefisso. Ad esempio, ciò può accadere tramite informazioni di configurazione fuori banda o quando i prefissi consentiti sono condivisi tramite capsule ADDRESS_ASSIGN. In tali scenari, gli endpoint DEVONO seguire le raccomandazioni di [BCP38] per impedire lo spoofing dell'indirizzo di origine.
Limitare l'ambito della richiesta (vedere la Sezione 4.6) consente a due client di condividere uno degli indirizzi IP esterni del proxy se le loro richieste sono limitate a diversi numeri di protocollo Internet. Se il proxy riceve un pacchetto ICMP destinato a quell'indirizzo IP esterno, ha la possibilità di inoltrarlo ai client. Tuttavia, alcuni di questi pacchetti ICMP trasportano parte del pacchetto IP originale che ha attivato la risposta ICMP. L'inoltro di tali pacchetti può divulgare accidentalmente informazioni sul traffico di un client a un altro client. Per evitare ciò, i proxy che inoltrano ICMP su indirizzi IP esterni condivisi DEVONO ispezionare il pacchetto invocante incluso nel pacchetto ICMP e inoltrare il pacchetto ICMP solo al client il cui ambito corrisponde al pacchetto invocante.
Gli implementatori trarranno vantaggio dalla lettura della guida in [TUNNEL-SECURITY]. Poiché esistono rischi noti con alcune intestazioni di estensione IPv6 (ad esempio, [ROUTING-HDR]), gli implementatori devono seguire le ultime linee guida relative alla gestione delle intestazioni di estensione IPv6.
Il trasferimento dei contrassegni DSCP dai pacchetti interni a quelli esterni (vedere la Sezione 10.3) espone le informazioni a livello di flusso end-to-end a un osservatore sul percorso tra gli endpoint di proxying IP. Ciò può potenzialmente esporre un singolo flusso end-to-end. Per questo motivo, tale uso di DSCP in contesti sensibili alla privacy NON È RACCOMANDATO.
L'invio opportunistico di pacchetti IP (vedere la Sezione 7.1) non è consentito in HTTP/1.x perché un server potrebbe rifiutare l'aggiornamento HTTP e tentare di analizzare i pacchetti IP come una successiva richiesta HTTP, consentendo attacchi di request smuggling; vedere [OPTIMISTIC]. In particolare, un intermediario che ricodifica una richiesta da HTTP/2 o 3 a HTTP/1.1 NON DEVE inoltrare alcuna capsula ricevuta finché non ha analizzato una risposta di proxying IP riuscita.