7. Security Considerations (Sicherheitsüberlegungen)
Dieser Abschnitt untersucht Sicherheitsprobleme, die durch die Einführung differenzierter Dienste aufgeworfen werden, hauptsächlich die Möglichkeit von Denial-of-Service-Angriffen und die damit verbundene Möglichkeit des Dienstdiebstahls durch nicht autorisierten Verkehr (Abschnitt 7.1). Abschnitt 7.2 behandelt den Betrieb differenzierter Dienste in Gegenwart von IPsec, einschließlich der Interaktionen mit IPsec-Tunnelmodus und anderen Tunneling-Protokollen. Eine umfassendere Behandlung der Sicherheitsbedenken, die durch die gesamte Architektur differenzierter Dienste aufgeworfen werden, findet sich in [ARCH].
7.1 Theft and Denial of Service (Diebstahl und Denial of Service)
Das Hauptziel differenzierter Dienste ist es, die Bereitstellung unterschiedlicher Servicelevel für Verkehrsströme über eine gemeinsame Netzwerkinfrastruktur zu ermöglichen. Verschiedene Techniken können verwendet werden, um dies zu erreichen, aber das Endergebnis ist, dass einige Pakete einen anderen (z.B. besseren) Service als andere erhalten. Da die Zuordnung von Netzwerkverkehr zu spezifischen Verhalten, die zu unterschiedlichem (z.B. besserem oder schlechterem) Service führen, hauptsächlich durch den DS-Codepunkt angezeigt wird, könnte ein Angreifer möglicherweise einen besseren Service erhalten, indem er Codepunkte modifiziert, um ein Verhalten anzuzeigen, das für erweiterten Service verwendet wird, oder indem er Pakete mit solchen Codepunkt-Werten injiziert. Bis zum Extrem getrieben, wird ein solcher Dienstdiebstahl (theft-of-service) zu einem Denial-of-Service-Angriff (denial-of-service attack), wenn der modifizierte oder injizierte Verkehr die verfügbaren Ressourcen zur Weiterleitung dieses Verkehrs und anderer Verkehrsströme erschöpft.
Die Verteidigung gegen diese Klasse von Diebstahls- und Denial-of-Service-Angriffen besteht aus einer Kombination von Verkehrskonditionierung an DS-Domänengrenzen und der Sicherheit und Integrität der Netzwerkinfrastruktur innerhalb der DS-Domäne. DS-Domänengrenzknoten müssen (MUST) sicherstellen, dass der gesamte in die Domäne eintretende Verkehr mit Codepunkt-Werten markiert ist, die für den Verkehr und die Domäne geeignet sind, und Verkehr bei Bedarf mit neuen Codepunkt-Werten neu markieren. Diese DS-Grenzknoten sind die primäre Verteidigungslinie (primary line of defense) gegen Diebstahls- und Denial-of-Service-Angriffe, die auf modifizierten Codepunkten basieren. Der Erfolg eines solchen Angriffs zeigt an, dass die vom angreifenden Verkehr verwendeten Codepunkte unangemessen waren. Eine wichtige Instanz von Grenzknoten ist, dass Verkehrsursprungsknoten in einer DS-Domäne die anfänglichen Grenzknoten für diesen Verkehr sind. Interne Knoten in einer DS-Domäne verlassen sich auf DS-Codepunkte, um Verkehr mit Weiterleitungs-PHBs zu verknüpfen, und sind nicht verpflichtet (are NOT REQUIRED), Codepunkt-Werte zu überprüfen, bevor sie sie verwenden. Infolgedessen verlassen sich interne Knoten auf den korrekten Betrieb der DS-Domänengrenzknoten, um zu verhindern, dass Verkehr mit unangemessenen Codepunkten oder Verkehr, der provisionierte Levels (provisioned levels) überschreitet, ankommt und den Betrieb der Domäne stört.
7.2 IPsec and Tunneling Interactions (IPsec- und Tunneling-Interaktionen)
Die in [ESP, AH] definierten IPsec-Protokolle schließen das DS-Feld des IP-Headers nicht in ihre kryptografischen Berechnungen ein (im Fall des Tunnelmodus ist es das DS-Feld des externen IP-Headers, das nicht eingeschlossen ist). Daher kann die Änderung des DS-Feldes durch Netzwerkknoten nicht dazu führen, dass IPsec-Integritätsprüfungen fehlschlagen, und beeinträchtigt daher nicht die End-to-End-Sicherheit von IPsec. Infolgedessen bietet IPsec keine Verteidigung gegen die Änderung des DS-Feldes durch einen Angreifer (d.h. einen Man-in-the-Middle-Angriff, man-in-the-middle attack), gerade weil die Änderung durch den Angreifer auch nicht die End-to-End-Sicherheit von IPsec beeinträchtigt.
Der IPsec-Tunnelmodus bietet Sicherheit für das DS-Feld des gekapselten IP-Headers. Ein IPsec-Tunnelmodus-Paket enthält zwei IP-Header: einen externen Header, der vom Tunnel-Ingress-Knoten (tunnel ingress node) bereitgestellt wird, und einen gekapselten internen Header, der von der ursprünglichen Quelle des Pakets bereitgestellt wird. Wenn ein IPsec-Tunnel (ganz oder teilweise) über ein Differentiated Services-Netzwerk gehostet wird, manipulieren zwischengeschaltete Netzwerkknoten das DS-Feld des externen Headers. Am Tunnel-Egress-Knoten (tunnel egress node) umfasst die IPsec-Verarbeitung das Entfernen des externen Headers und (falls erforderlich) die Weiterleitung des Pakets unter Verwendung des internen Headers. Die IPsec-Protokolle erfordern (REQUIRES), dass diese Dekapselierungsverarbeitung (decapsulation processing) das DS-Feld des internen Headers nicht ändert, um sicherzustellen, dass Änderungen des DS-Feldes nicht verwendet werden können, um Diebstahls- oder Denial-of-Service-Angriffe über IPsec-Tunnelendpunkte hinaus zu starten. Dieses Dokument ändert diese Anforderung nicht. Wenn der interne IP-Header nicht von einem DS-Grenzknoten der DS-Domäne des Tunnel-Egress-Knotens verarbeitet wurde, dann ist der Tunnel-Egress-Knoten der Grenzknoten für den Verkehr, der den Tunnel verlässt, und muss (MUST) daher sicherstellen, dass der resultierende Verkehr geeignete DS-Codepunkte hat.
Wenn die IPsec-Tunnel-Egress-Dekapselierungsverarbeitung eine ausreichend starke kryptografische Integritätsprüfung (cryptographic integrity check) des gekapselten Pakets umfasst (die Angemessenheit wird durch lokale Sicherheitsrichtlinien bestimmt), dann kann der Tunnel-Egress-Knoten sicher annehmen, dass das DS-Feld des internen Headers denselben Wert hat wie am Tunnel-Ingress-Knoten. Ein wichtiges Ergebnis ist, dass andere unsichere Links in einer DS-Domäne durch einen ausreichend starken IPsec-Tunnel geschützt werden können. Diese Analyse und ihre Implikationen gelten für jedes Tunneling-Protokoll, das Integritätsprüfungen durchführt, obwohl die Sicherheitsstufe (level of assurance) des DS-Feldes des internen Headers von der Stärke der vom Tunneling-Protokoll durchgeführten Integritätsprüfung abhängt. In Abwesenheit ausreichender Sicherheit für einen Tunnel, der möglicherweise Knoten außerhalb der aktuellen DS-Domäne durchquert (oder anderweitig anfällig ist, otherwise vulnerable), müssen (MUST) gekapselte Pakete behandelt werden, als ob sie an einer Grenze von außerhalb der DS-Domäne ankommen.