5. Sicherheitsbetrachtungen

Dieser Abschnitt identifiziert Bedrohungen, gegenüber denen LDP anfällig sein kann, und erörtert Mittel, mit denen diese Bedrohungen abgeschwächt werden könnten.

5.1. Spoofing

Es gibt zwei Arten der LDP-Kommunikation, die Ziel eines Spoofing-Angriffs sein könnten.

1. Von UDP transportierter Discovery-Austausch

   LSRs zeigen ihre Bereitschaft an, LDP-Sitzungen aufzubauen und aufrechtzuerhalten, indem sie periodisch Hello-Nachrichten senden. Der Empfang eines Hello dient dazu, eine neue "Hello-Adjazenz" zu erzeugen, falls noch keine existiert, oder eine bestehende aufzufrischen. Das Spoofing eines Hello-Pakets für eine bestehende Adjazenz kann dazu führen, dass die Adjazenz zeitlich abläuft, was zur Beendigung der zugehörigen Sitzung führen kann. Dies kann auftreten, wenn das gefälschte Hello eine kleine Hold Time angibt, wodurch der Empfänger Hellos innerhalb dieses Intervalls erwartet, während der echte Nachbar weiterhin Hellos mit der niedrigeren, zuvor vereinbarten Frequenz sendet.

   LSRs, die auf Verbindungsebene direkt verbunden sind, tauschen Basic Hello-Nachrichten über die Verbindung aus. Die Bedrohung durch gefälschte Basic Hellos kann verringert werden durch:

   o die Annahme von Basic Hellos nur auf Schnittstellen, an die LSRs, denen vertraut werden kann, direkt angeschlossen sind.

   o das Ignorieren von Basic Hellos, die nicht an die Multicast-Gruppe All Routers on this Subnet adressiert sind.

   LSRs, die auf Verbindungsebene nicht direkt verbunden sind, können Extended Hello-Nachrichten verwenden, um ihre Bereitschaft anzuzeigen, eine LDP-Sitzung aufzubauen. Ein LSR kann die Bedrohung durch gefälschte Extended Hellos verringern, indem er sie filtert und nur solche akzeptiert, die von durch eine Zugriffsliste erlaubten Quellen stammen.

2. Von TCP transportierte Sitzungskommunikation

   LDP legt die Verwendung der TCP MD5 Signature Option fest, um die Authentizität und Integrität von Sitzungsnachrichten zu gewährleisten.

   [RFC2385] behauptet, dass die MD5-Authentifizierung inzwischen von einigen für diese Anwendung als zu schwach angesehen wird. Es weist außerdem darauf hin, dass eine ähnliche TCP-Option mit einem stärkeren Hash-Algorithmus (es nennt SHA-1 als Beispiel) eingeführt werden könnte. Nach unserem Kenntnisstand wurde keine solche TCP-Option definiert und eingeführt. Wir stellen jedoch fest, dass LDP jede verfügbare TCP-Nachrichtendigest-Technik verwenden kann, und wenn eine stärkere als MD5 spezifiziert und implementiert wird, wäre die Aufrüstung von LDP zu deren Verwendung relativ unkompliziert.

5.2. Privatsphäre

LDP bietet keinen Mechanismus zum Schutz der Privatsphäre der Labelverteilung.

Die Sicherheitsanforderungen von Labelverteilungsprotokollen sind im Wesentlichen identisch mit denen der Protokolle, die Routing-Informationen verteilen. Indem LDP einen Mechanismus zur Gewährleistung der Authentizität und Integrität seiner Nachrichten bereitstellt, bietet es ein Sicherheitsniveau, das mindestens so gut ist wie das, das die Routing-Protokolle selbst bieten können, aber nicht besser. Die allgemeinere Frage, ob Privatsphäre für Routing-Protokolle gefordert werden sollte, liegt außerhalb des Geltungsbereichs dieses Dokuments.

Man könnte argumentieren, dass die Labelverteilung Privatsphäre erfordert, um der Bedrohung durch Label-Spoofing zu begegnen. Diese Privatsphäre würde jedoch nicht vor Label-Spoofing-Angriffen schützen, da Datenpakete Labels im Klartext transportieren. Darüber hinaus können Label-Spoofing-Angriffe ohne Kenntnis der an ein Label gebundenen FEC durchgeführt werden.

Um Label-Spoofing-Angriffe zu vermeiden, ist es notwendig sicherzustellen, dass gelabelte Datenpakete von vertrauenswürdigen LSRs gelabelt werden und dass die auf die Pakete gesetzten Labels von den labelnden LSRs ordnungsgemäß erlernt wurden.

5.3. Dienstverweigerung (Denial of Service)

LDP bietet zwei potenzielle Ziele für Denial-of-Service-(DoS-)Angriffe:

1. Bekannter UDP-Port für LDP Discovery

   Ein LSR-Administrator kann der Bedrohung durch DoS-Angriffe über Basic Hellos begegnen, indem er sicherstellt, dass der LSR nur direkt mit Peers verbunden ist, denen vertraut werden kann, dass sie einen solchen Angriff nicht initiieren. Schnittstellen zu Peers im Inneren der Domäne des Administrators sollten keine Bedrohung darstellen, da innere Peers unter der Kontrolle des Administrators stehen. Schnittstellen zu Peers außerhalb der Domäne stellen eine potenzielle Bedrohung dar, da äußere Peers dies nicht sind. Ein Administrator kann diese Bedrohung verringern, indem er den LSR nur mit äußeren Peers verbindet, denen vertraut werden kann, dass sie keinen Basic Hello-Angriff initiieren.

   DoS-Angriffe über Extended Hellos sind potenziell eine ernstere Bedrohung. Dieser Bedrohung kann begegnet werden, indem Extended Hellos mit Zugriffslisten gefiltert werden, die die Adressen definieren, mit denen Extended Discovery zulässig ist. Die Durchführung der Filterung erfordert jedoch LSR-Ressourcen.

   In einer Umgebung, in der eine vertrauenswürdige MPLS-Cloud identifiziert werden kann, können LSRs am Rand der Cloud verwendet werden, um innere LSRs gegen DoS-Angriffe über Extended Hellos zu schützen, indem Extended Hellos, die von außerhalb der vertrauenswürdigen MPLS-Cloud stammen, herausgefiltert und nur solche akzeptiert werden, die von durch Zugriffslisten erlaubten Adressen stammen. Diese Filterung schützt LSRs im Inneren der Cloud, verbraucht aber Ressourcen an den Rändern.

2. Bekannter TCP-Port für den LDP-Sitzungsaufbau

   Wie andere Steuerungsebenen-Protokolle (control plane protocols), die TCP verwenden, kann LDP das Ziel von DoS-Angriffen wie SYN-Angriffen sein. LDP ist gegenüber solchen Angriffen nicht mehr oder weniger anfällig als andere Steuerungsebenen-Protokolle, die TCP verwenden.

   Die Bedrohung durch solche Angriffe kann durch Folgendes einigermaßen abgeschwächt werden:

   o Ein LSR SOLLTE promiskuitive TCP-Listen für den LDP-Sitzungsaufbau vermeiden. Er SOLLTE nur Listen verwenden, die für entdeckte Peers spezifisch sind. Dies ermöglicht es ihm, Angriffspakete früh in ihrer Verarbeitung zu verwerfen, da sie mit bestehenden oder in Bearbeitung befindlichen Verbindungen weniger wahrscheinlich übereinstimmen.

   o Die Verwendung der MD5-Option hilft einigermaßen, da sie verhindert, dass ein SYN akzeptiert wird, es sei denn, die MD5-Segmentprüfsumme ist gültig. Der Empfänger muss die Prüfsumme jedoch berechnen, bevor er entscheiden kann, ein ansonsten akzeptables SYN-Segment zu verwerfen.

   o Die Verwendung von Zugriffslistenmechanismen, die an der Grenze der MPLS-Cloud in einer Weise angewendet werden, die der oben für Extended Hellos vorgeschlagenen ähnelt, kann das Innere gegen Angriffe schützen, die von außerhalb der Cloud stammen.