Zum Hauptinhalt springen

15. Security Considerations (Sicherheitsüberlegungen)

15. Security Considerations (Sicherheitsüberlegungen)

Header-Komprimierung selbst führt keine neuen Sicherheitsprobleme ein. Es sind jedoch folgende Punkte zu beachten:

Denial of service (Denial-of-Service)

Ein Angreifer könnte versuchen, den Kontextspeicher des Kompressors oder Dekompressors zu erschöpfen, indem er viele verschiedene Paketströme sendet. Dies kann durch Begrenzung der Anzahl der gleichzeitig komprimierbaren Paketströme abgemildert werden.

Ein Angreifer könnte auch versuchen, den Kontextspeicher zu erschöpfen, indem er Pakete mit vielen Erweiterungs-Headern sendet. Dies kann durch Begrenzung der maximalen Länge des im Kontext gespeicherten Headers abgemildert werden (siehe Parameter MAX_HEADER).

Context hijacking (Kontext-Hijacking)

Ein Angreifer könnte versuchen, einen vorhandenen Kontext zu übernehmen, indem er Pakete mit derselben CID sendet. Dies kann nur geschehen, wenn der Angreifer Zugang zur Verbindung hat. In diesem Fall kann der Angreifer bereits den gesamten Datenverkehr lesen oder ändern, sodass Header-Komprimierung die Situation nicht verschlimmert.

IPsec considerations (IPsec-Überlegungen)

Bei der Verwendung von Header-Komprimierung zusammen mit IPsec ist besondere Vorsicht geboten. Der IPsec Authentication Header (AH) schützt das gesamte IP-Paket, einschließlich des IP-Headers. Wenn der IP-Header komprimiert wird, kann AH das Paket nicht authentifizieren.

Eine Lösung besteht darin, Header-Komprimierung an den Endpunkten des IPsec-Tunnels anzuwenden, d. h. nach oder vor der IPsec-Verarbeitung. Eine andere Lösung ist die Verwendung von IPsec Encapsulating Security Payload (ESP) anstelle von AH, da ESP den äußeren IP-Header nicht schützt.