12. Security Considerations (Sicherheitsüberlegungen)
12. Security Considerations (Sicherheitsüberlegungen)
Es wird angenommen, dass bei Verwendung von Kontrollebenen-Prozessen zum Erhalt von EID-to-RLOC-Mappings die meisten Sicherheitsmechanismen Teil des Mapping-Datenbankdienstes sein werden. Für das in dieser Spezifikation beschriebene datenebenenausgelöste Mapping wird Schutz vor ETR-Spoofing durch Verwendung des Routen-Rückführbarkeitsmechanismus (siehe Abschnitt 3) bereitgestellt, wie durch die Verwendung des 24-Bit-'Nonce'-Feldes im LISP-Kapselungs-Header und des 64-Bit-'Nonce'-Feldes in LISP-Kontrollnachrichten nachgewiesen.
Die Nonce, kombiniert damit, dass der ITR nur angeforderte Map-Replies akzeptiert, bietet ein grundlegendes Sicherheitsniveau, das in vielerlei Hinsicht der im aktuellen Internet-Routing-System erfahrenen Sicherheit ähnelt. Es ist schwierig für Off-Path-Angreifer, Angriffe gegen diese LISP-Mechanismen zu starten, da sie den Nonce-Wert nicht haben. Es ist möglich, eine große Anzahl von Paketen zu senden, um zufällig den richtigen Nonce-Wert zu finden, aber dies stellt selbst einen Denial-of-Service (DoS)-Angriff dar. On-Path-Angreifer können schwerwiegendere Angriffe durchführen, aber On-Path-Angreifer können auch im aktuellen Internet schwere Angriffe starten, einschließlich Abhören, Blockieren oder Umleiten von Verkehr. Für eine ausführlichere Diskussion zu diesem Thema siehe Abschnitt 6.1.5.1.
LISP ist nicht auf PKI oder schwergewichtigere Authentifizierungssysteme angewiesen. Diese Systeme stellen eines der Hauptentwurfsziele von LISP in Frage - Skalierbarkeit.
Die DoS-Angriffsprävention hängt davon ab, dass die Implementierung die Anzahl der Map-Requests und Map-Replies zur Kontrollebene sowie die Anzahl der datenausgelösten Map-Replies ratenbegrenzt.
Ein nicht ordnungsgemäß implementierter oder böswilliger ITR kann wählen, die Priority und Weight zu ignorieren, die der ETR in seinem Map-Reply bereitstellt. Diese Verkehrslenkung wird auf Verkehr beschränkt sein, der von diesem ITR-Standort gesendet wird, und ist nicht schwerwiegender als wenn der Standort einen Bandbreiten-DoS-Angriff auf einen der Eingabelinks des ETR startet. Der Standort des ITR erhält normalerweise keinen Vorteil davon, die Weights nicht zu respektieren, und kann durch deren Einhaltung einen besseren Service erhalten.
Um Versuche zur Map-Cache-Erschöpfung im ITR/PITR zu behandeln, sollten Implementierungen in Betracht ziehen, eine maximale Obergrenze für die Anzahl der gespeicherten Einträge festzulegen und eine Reserveliste für spezielle oder häufig aufgerufene Standorte zu pflegen. Dies sollte durch eine Konfigurationsrichtlinie gesteuert werden, die vom Netzwerkadministrator festgelegt wird, der die ITRs und PITRs verwaltet. Wenn sich EID-Prefixes über mehrere Map-Cache-Einträge hinweg überschneiden, muss die Integrität der Menge vollständig aufrechterhalten werden. Wenn daher aufgrund des Erreichens der maximalen Obergrenze kein spezifischerer Eintrag hinzugefügt werden kann, sollten keine weniger spezifischen Einträge im Map-Cache gespeichert werden.
Da der ITR/PITR einen Cache von EID-to-RLOC-Mappings pflegt, sind Cache-Größe und -Wartung Probleme, die während der Implementierung zu beachten sind. Es ist eine gute Idee, Instrumente zu installieren, um Cache-Thrashing zu erkennen. Implementierungsexperimente werden verwendet, um zu bestimmen, welche Cache-Management-Strategien am besten funktionieren. Im Allgemeinen ist es schwierig, sich gegen Cache-Thrashing-Angriffe zu verteidigen. Es sollte beachtet werden, dass ein zu kleiner Cache im ITR/PITR nicht nur negative Auswirkungen auf den von ihm unterstützten Standort oder Bereich hat, sondern auch zu einer erhöhten Map-Request-Last auf dem Mapping-System führen kann.
Die in Abschnitt 6.1.3 diskutierten "Piggybacked (huckepack)" Mapping-Daten spezifizieren, wie solche Mappings zu behandeln sind, und schließen die Möglichkeit ein, dass der ETR solche Mappings vor der Überprüfung vorübergehend akzeptiert, wenn der ETR in einer "vertrauenswürdigen" Umgebung läuft. In diesem Fall besteht eine potenzielle Bedrohung, dass ein falsches Mapping (wenn auch nur für kurze Zeit) in den Map-Cache eingefügt werden könnte. Wie in Abschnitt 6.1.3 angegeben, muss der ETR speziell konfiguriert werden, um in einem solchen Modus zu arbeiten, und kann nur bestimmte ITRs als auch in derselben vertrauenswürdigen Umgebung laufend betrachten.
Es besteht ein Sicherheitsrisiko in der Tatsache, dass ETRs die EID-Prefixes generieren, auf die sie antworten. ETRs können kürzere Präfixe beanspruchen, als sie tatsächlich verantworten. Verschiedene Mechanismen zur Verbesserung oder Lösung dieses Problems werden in Zukunft untersucht [LISP-SEC].
Das Spoofing der inneren Header-Adresse von LISP-gekapselten Datenpaketen ist wie bei jedem Tunneling-Mechanismus möglich. Der ITR muss vor der Kapselung überprüfen, ob die Quelladresse des Datenpakets eine EID ist, die zum Standort-EID-Prefix-Bereich gehört. Der ETR muss nur Datagramme entkapseln und weiterleiten, deren innerer Header-Ziel mit einem seiner EID-Prefix-Bereiche übereinstimmt. Wenn beim Empfang und bei der Entkapselung die Ziel-EID des Datagramms nicht mit einem der für den ETR konfigurierten EID-Prefixes übereinstimmt, muss der ETR dieses Datagramm verwerfen. Wenn ein LISP-gekapseltes Datenpaket beim ETR ankommt, sollte er die innere Header-Quell-EID-Adresse und die äußere Header-Quell-RLOC-Adresse mit den in der Mapping-Datenbank vorhandenen Mappings vergleichen. Wenn dann ein Spoofing-Angriff auftritt, kann die äußere Header-Quell-RLOC-Adresse verwendet werden, um den Angriff mit vorhandenen Betriebswerkzeugen zum Quellstandort zurückzuverfolgen.
Diese experimentelle Spezifikation befasst sich nicht mit automatischem Schlüsselmanagement (AKM). BCP 107 [RFC4107] bietet Orientierungshilfe in diesem Bereich. Darüber hinaus werden zum Zeitpunkt der Abfassung dieses Dokuments zahlreiche Arbeiten durchgeführt, um die Sicherheit des Routing-Systems zu verbessern [RFC6518] [RFC6480] [BGP-SEC] [LISP-SEC]. Zukünftige Arbeiten zu LISP sollten die in BCP 107 diskutierten Probleme sowie andere offene Sicherheitsüberlegungen ansprechen, was möglicherweise Änderungen an dieser Spezifikation erfordert.