11. Security Considerations (Sicherheitsüberlegungen)
11. Security Considerations (Sicherheitsüberlegungen)
Sicherheitsaspekte in Verbindung mit NAT sind lange dokumentiert. Siehe [RFC2663] und [RFC2993].
Die Verlagerung der NAT-Funktionalität vom CPE in den Kern des Netzes des Dienstanbieters und die gemeinsame Nutzung von IPv4-Adressen unter Kunden erzeugen jedoch zusätzliche Anforderungen bei der Protokollierung von Daten zum Missbrauch. In jeder Architektur, in der eine IPv4-Adresse keinen End-Host eindeutig repräsentiert, reichen IPv4-Adressen und Zeitstempel nicht mehr aus, um einen bestimmten Breitbandkunden zu identifizieren. Das AFTR sollte in der Lage sein, die Tunnel-ID, das Protokoll, Ports/IP-Adressen und den Erstellungszeitpunkt der NAT-Bindung zu protokollieren, um Nutzersitzungen eindeutig zu identifizieren. Exakte Details der Protokollierung sind implementierungsspezifisch und liegen außerhalb des Geltungsbereichs dieses Dokuments.
Das AFTR führt Übersetzungsfunktionen für interne IPv4-Hosts aus, die RFC-1918-Adressen oder den von der IANA reservierten Adressbereich (192.0.0.0/29) nutzen. In einigen Fällen kann ein ISP Richtlinien im AFTR bereitstellen und das AFTR anweisen, Übersetzungsfunktionen basierend auf dem Tupel aus IPv4-Adresse, Portnummer und Protokoll zu umgehen. Wenn das AFTR ein Paket mit passenden Richtlinieninformationen vom internen Host empfängt, kann es das Paket schlicht ohne Übersetzung weiterleiten. Adressen, Ports und Protokollinformationen MÜSSEN am AFTR bereitgestellt werden, bevor das Paket empfangen wird. Der Bereitstellungsmechanismus liegt außerhalb des Geltungsbereichs dieser Spezifikation.
Beim Entkapseln von Paketen DARF das AFTR nur Pakete weiterleiten, die von RFC-1918-Adressen, einem von der IANA reservierten Adressbereich oder anderen außerbandmäßig vorab autorisierten Adressen stammen. Das AFTR MUSS alle anderen Pakete verwerfen. Dies verhindert, dass bösartige Geräte Denial-of-Service-Angriffe starten, indem sie nicht autorisierte öffentliche IPv4-Adressen im IPv4-Quellkopffeld oder einen nicht autorisierten Transport-Portbereich im IPv4-Transportkopffeld verwenden. Beispielsweise könnten bösartige Geräte einen öffentlichen Webserver mit einem TCP-SYN-ACK-Angriff überfluten [RFC4987]. Das Opfer würde TCP-SYNs mit zufälligen IPv4-Quelladressen in hoher Rate empfangen und TCP-Dienste für legitime Nutzer verweigern.
Bei von mehreren Nutzern geteilten IPv4-Adressen werden Ports zu einer kritischen Ressource. Daher MÜSSEN Mechanismen am AFTR vorgesehen werden, um die Portnutzung zu begrenzen, entweder durch Ratenbegrenzung neuer Verbindungen oder durch eine harte Obergrenze für die maximale Anzahl nutzbarer Ports pro einzelnem Nutzer. Wenn diese Zahl hoch genug ist, sollte sie den normalen Gebrauch nicht beeinträchtigen und dennoch angemessenen Schutz des gemeinsamen Pools bieten. Weitere Überlegungen zur gemeinsamen Nutzung von IPv4-Adressen finden sich in [RFC6269]. Weitere Überlegungen und Empfehlungen zur Protokollierung finden sich in [RFC6302].
AFTRs sollten Möglichkeiten unterstützen, den Dienst nur registrierten Kunden zu gewähren. Eine einfache Option ist die Implementierung eines IPv6-Ingress-Filters auf der Tunnel-Schnittstelle des AFTR, der nur den in dem Filter definierten IPv6-Adressbereich akzeptiert.