13. Security Considerations (Sicherheitsüberlegungen)
13. Security Considerations (Sicherheitsüberlegungen)
Da dieses Dokument ein Sicherheitsprotokoll beschreibt, werden viele sicherheitsrelevante Aspekte in den entsprechenden Abschnitten beschrieben. Dieser Abschnitt weist auf Probleme hin, die in anderen Abschnitten möglicherweise nicht offensichtlich sind.
Cache Validation (Cache-Validierung): Damit eine Sammlung von Caches wie in Abschnitt 11 beschrieben eine konsistente Ansicht garantieren kann, müssen ihnen konsistente Vertrauensanker gegeben werden, die sie in ihrem internen Validierungsprozess verwenden. Die Verteilung eines konsistenten Vertrauensankers wird als außerhalb des Bandes angenommen.
Cache Peer Identification (Cache-Peer-Identifizierung): Der Router initiiert eine Transportverbindung zu einem Cache, den er entweder über die IP-Adresse oder den vollständig qualifizierten Domainnamen identifiziert. Beachten Sie, dass ein DNS- oder Adress-Spoofing-Angriff den korrekten Cache unerreichbar machen könnte. Es würde keine Sitzung aufgebaut, da die Autorisierungsschlüssel nicht übereinstimmen würden.
Transport Security (Transportsicherheit): Die RPKI basiert auf Objekt-, nicht auf Server- oder Transportvertrauen. Das heißt, der IANA-Root-Vertrauensanker wird über irgendwelche außerbandigen Mittel an alle Caches verteilt und kann dann von jedem Cache verwendet werden, um Zertifikate und ROAs bis ganz nach unten im Baum zu validieren. Die Inter-Cache-Beziehungen basieren auf diesem Objektsicherheitsmodell; daher kann der Inter-Cache-Transport leicht geschützt werden.
Dieses Protokolldokument geht jedoch davon aus, dass Router die Validierungskryptographie nicht durchführen können. Daher wird die letzte Verbindung vom Cache zum Router durch Serverauthentifizierung und Transportsicherheit gesichert. Dies ist gefährlich, da Serverauthentifizierung und Transport sehr unterschiedliche Bedrohungsmodelle haben als Objektsicherheit.
Daher sind die Stärke der Vertrauensbeziehung und des Transports zwischen dem (den) Router(n) und dem (den) Cache(s) kritisch. Sie setzen Ihr Routing darauf.
Obwohl wir nicht sagen können, dass der Cache im selben LAN sein muss, sei es auch nur aufgrund des Problems, dass ein Unternehmen die Cache-Aufgabe an seinen (seine) vorgelagerten ISP(s) auslagern möchte, sind Standort, Vertrauen und Kontrolle hier sehr kritische Probleme. Der (Die) Cache(s) SOLLTE(N) wirklich so nah wie möglich am (an den) Router(n) sein, im Sinne von kontrolliertem und geschütztem (gegen DDoS, MITM) Transport. Er SOLLTE auch topologisch nah sein, damit ein Minimum an validierten Routing-Daten benötigt wird, um den Zugriff eines Routers auf einen Cache zu initialisieren.
Die Identität des Cache-Servers SOLLTE vom Router-Client verifiziert und authentifiziert werden, und umgekehrt, bevor Daten ausgetauscht werden.
Transporte, die die notwendige Authentifizierung und Integrität nicht bereitstellen können (siehe Abschnitt 9), müssen sich auf Netzwerkdesign und betriebliche Kontrollen verlassen, um Schutz vor Spoofing-/Korruptionsangriffen zu bieten. Wie in Abschnitt 9 dargelegt, ist TCP-AO der langfristige Plan. Protokolle, die Integrität und Authentizität bieten, SOLLTEN verwendet werden, und wenn sie es nicht können, d.h. wenn TCP als Transport verwendet wird, MÜSSEN Router und Cache im selben vertrauenswürdigen, kontrollierten Netzwerk sein.