11. Sicherheitsüberlegungen
Es bestehen erhebliche Risiken, wenn beliebigen Clients erlaubt wird, einen Tunnel aufzubauen, der das Senden an beliebige Hosts erlaubt, unabhängig davon, ob Tunnel auf bestimmte Hosts beschränkt sind oder nicht. Böswillige Akteure könnten diese Fähigkeit missbrauchen, um Verkehr zu senden und diesen dem IP-Proxy zuschreiben zu lassen. HTTP-Server, die IP-Proxying unterstützen, SOLLTEN dessen Nutzung auf authentifizierte Benutzer beschränken. Abhängig von der Bereitstellung umfassen mögliche Authentifizierungsmechanismen gegenseitiges TLS zwischen IP-Proxying-Endpunkten, HTTP-basierte Authentifizierung über den HTTP-Authorization-Header [HTTP] oder sogar Bearer-Token. Proxys können Richtlinien für authentifizierte Benutzer durchsetzen, um das Client-Verhalten weiter einzuschränken oder möglichen Missbrauch zu behandeln. Zum Beispiel können Proxys einzelne Clients, die eine übermäßig große Menge an Verkehr durch den Proxy senden, in der Rate begrenzen. Als weiteres Beispiel können Proxys die Adress-(Präfix-)Zuweisung an Clients basierend auf bestimmten Client-Attributen, wie z. B. dem geografischen Standort, einschränken.
Die Adresszuweisung kann Auswirkungen auf die Privatsphäre von Endpunkten haben. Wenn ein Proxy beispielsweise seinen Adressraum nach der Anzahl der authentifizierten Clients partitioniert und dann jedem Client unterschiedliche Adressbereiche zuweist, könnten Zielhosts diese Informationen verwenden, um festzustellen, wann IP-Pakete demselben Client entsprechen. Die Vermeidung solcher Tracking-Vektoren kann für bestimmte Proxy-Bereitstellungen wichtig sein. Proxys SOLLTEN eine dauerhafte Adress-(Präfix-)Zuweisung pro Client vermeiden, wenn dies möglich ist.
Das Fälschen von IP-Quelladressen im gesendeten Verkehr ist bei Denial-of-Service-Angriffen üblich. Implementierungen dieses Mechanismus müssen sicherstellen, dass sie solche Angriffe nicht erleichtern. Insbesondere gibt es Szenarien, in denen ein Endpunkt weiß, dass sein Peer nur IP-Pakete von einem bestimmten Präfix senden darf. Dies kann beispielsweise durch Out-of-Band-Konfigurationsinformationen geschehen oder wenn zulässige Präfixe über ADDRESS_ASSIGN-Kapseln geteilt werden. In solchen Szenarien MÜSSEN Endpunkte den Empfehlungen aus [BCP38] folgen, um Quelladressen-Spoofing zu verhindern.
Die Einschränkung des Anforderungsbereichs (siehe Abschnitt 4.6) ermöglicht es zwei Clients, eine der externen IP-Adressen des Proxys zu teilen, wenn ihre Anforderungen auf unterschiedliche Internetprotokollnummern beschränkt sind. Wenn der Proxy ein ICMP-Paket empfängt, das für diese externe IP-Adresse bestimmt ist, hat er die Möglichkeit, es an die Clients zurückzuleiten. Einige dieser ICMP-Pakete enthalten jedoch einen Teil des ursprünglichen IP-Pakets, das die ICMP-Antwort ausgelöst hat. Das Weiterleiten solcher Pakete kann versehentlich Informationen über den Verkehr eines Clients an einen anderen Client preisgeben. Um dies zu vermeiden, MÜSSEN Proxys, die ICMP auf geteilten externen IP-Adressen weiterleiten, das im ICMP-Paket enthaltene aufrufende Paket inspizieren und das ICMP-Paket nur an den Client weiterleiten, dessen Bereich mit dem aufrufenden Paket übereinstimmt.
Implementierer werden von der Lektüre der Anleitung in [TUNNEL-SECURITY] profitieren. Da bei einigen IPv6-Erweiterungsheadern bekannte Risiken bestehen (z. B. [ROUTING-HDR]), müssen Implementierer die neuesten Anleitungen zur Handhabung von IPv6-Erweiterungsheadern befolgen.
Das Übertragen von DSCP-Markierungen von inneren auf äußere Pakete (siehe Abschnitt 10.3) legt End-to-End-Fluss-Level-Informationen für einen Beobachter auf dem Pfad zwischen den IP-Proxying-Endpunkten offen. Dies kann möglicherweise einen einzelnen End-to-End-Fluss offenlegen. Aus diesem Grund wird eine solche Verwendung von DSCPs in datenschutzsensiblen Kontexten NICHT EMPFOHLEN.
Das opportunistische Senden von IP-Paketen (siehe Abschnitt 7.1) ist in HTTP/1.x nicht zulässig, da ein Server das HTTP-Upgrade ablehnen und versuchen könnte, die IP-Pakete als nachfolgende HTTP-Anforderung zu parsen, was Request-Smuggling-Angriffe ermöglicht; siehe [OPTIMISTIC]. Insbesondere DARF ein Vermittler, der eine Anforderung von HTTP/2 oder 3 in HTTP/1.1 neu codiert, keine empfangenen Kapseln weiterleiten, bis er eine erfolgreiche IP-Proxying-Antwort geparst hat.