Kurzstudie MPLS

Kurzstudie zu Gefhrdungen und Manahmen beim Einsatz von
MPLS
Version 1.5
Bundesamt fr Sicherheit in der Informationstechnik

Postfach 20 03 63
53133 Bonn
Tel.: +49 228 99 9582-5369
E-Mail: grundschutz@bsi.bund.de
Internet: https://www.bsi.bund.de
Bundesamt fr Sicherheit in der Informationstechnik 2009
Danksagung
Danksagung
Das BSI dankt der Firma T-Systems, besonders Herrn Lutz Emrich und Herrn Dr. Eric Hildebrandt,
fr die Mitwirkung bei der Erstellung dieser Kurzstudie.
Auf Seite des BSI haben Frau Mechthild Schtz, Herr Bernd Becker und Herr Dr. Harald
Niggemann das Projekt betreut.
Es sei allen gedankt, die dieses Werk ermglicht und begleitet haben.
Inhaltsverzeichnis
Inhaltsverzeichnis
1
Einleitung....................................................................................................................................7
Grundlagen der MPLS-Technik..................................................................................................8
2.1
2.2
2.3
2.4
3
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4
MPLS-Nomenklatur..........................................................................................................................8
MPLS-berblick.............................................................................................................................10
MPLS-Architektur...........................................................................................................................15
Sicherheitsbetrachtung MPLS.........................................................................................................17
Gefhrdungen bei der Nutzung von MPLS-Infrastrukturen.....................................................19

Austritt markierter MPLS-Pakete aus dem VPN.............................................................................20
Injizieren unberechtigter Pakete aus einem MPLS-VPN in ein anderes MPLS-VPN......................20
Injizieren unberechtigter Pakete vom Transportnetz des Netzdienstleisters in ein MPLS-VPN......21
Einbringen unberechtigter Pakete vom Transportnetz eines anderen Netzdienstleisters in ein
MPLS-VPN.....................................................................................................................................21
Anbinden eines unberechtigten CE-Routers durch Fehlkonfiguration.............................................22
Anbinden eines unberechtigten CE-Routers im Transportnetz eines anderen Netzdienstleisters.....22
Sichtbarkeit der logischen Struktur des Provider-Netzes.................................................................22
Vermischung des Datenverkehrs verschiedener Kundennetze.........................................................23
Denial-of-Service-Angriff auf PE-Router........................................................................................23
Denial-of-Service-Angriff aus dem Internet....................................................................................23
Denial-of-Service-Angriffe auf das Routing-Protokoll BGP im Core.............................................24
Denial-of-Service-Angriffe auf VPNs durch Routing-Updates.......................................................24
Denial-of-Service durch Ausfall des Transportnetzes......................................................................25
Sicherheitsmanahmen fr MPLS-Netze..................................................................................26
Programmierung sicherer Software / Firmware, Zertifizierungen...................................................28
Verhindern von MPLS-Label-Spoofing...........................................................................................28
Zuverlssigkeit des Dienstleisterpersonals......................................................................................28
Zuverlssigkeit verbundener MPLS-Carrier....................................................................................29
Einsatz von Netzberwachungssystemen........................................................................................29
Sichere Kopplung von Netzdienstleistern........................................................................................30
Deaktivierung von MPLS-Traceroute-Funktionen..........................................................................31
Separierung des Datenverkehrs verschiedener Kunden-VPNs........................................................31
Schutz des PE-Routers....................................................................................................................32
Verstecken der IP-Adresse des PE-Routers.....................................................................................33
Internet-bergang als eigenes MPLS-VPN.....................................................................................33
Sichere Konfiguration von BGP......................................................................................................33
Etablierung von Schwellwert-Alarmen............................................................................................34
Anwendung von "Best Practice"-Empfehlungen fr die Konfiguration der MPLS-Router.............34
Redundanz zum Schutz der Verfgbarkeit in MPLS-Netzen...........................................................35
Nutzung einer dedizierten MPLS-Infrastruktur...............................................................................36
Programmieren und Einspielen von Software-Patches....................................................................36
Nutzung von IPSec-Tunneln ber MPLS-Verbindungen.................................................................36
Inhaltsverzeichnis
4.19
4.20
4.21
4.22
4.23
4.24
MPLS-Core ohne Internet-Konnektivitt.........................................................................................37

Verbindungstest nach Anbinden eines VPN-Standorts....................................................................37
Erstellen eines Label-Konzepts.......................................................................................................38
Auswahl geeigneter Netzkomponenten...........................................................................................38
Konzeption des MPLS-Netzes.........................................................................................................38
Rollout-Konzept..............................................................................................................................39
Restrisiken.................................................................................................................................40
Ausblick und zuknftige Bedrohungen.....................................................................................41
6.1
6.2
7
7.1
7.2
7.3
Next Generation Networks (NGN)..................................................................................................41

Generalized Multi-Protocol Label Switching (GMPLS)..................................................................41
Anhang......................................................................................................................................42
Kreuzreferenz-Tabelle.....................................................................................................................42
Abkrzungsverzeichnis...................................................................................................................43
Referenzen.......................................................................................................................................45
Abbildungsverzeichnis
Abbildung 1: IP-Datagramme werden am Ingress-Router (links) mit einem MPLS-Label versehen,
das am Egress-Router (rechts) wieder entfernt wird..........................................................................10
Abbildung 2: Pakete werden von jedem LSR entsprechend seiner LSP-Tabelle neu "gelabeled"....11
Abbildung 3: Der LSP ergibt sich aus der CE-CE-Strecke ber die LSR..........................................11
Abbildung 4: Die PE-Systeme knnen mit CE verschiedener Kundennetze verbunden sein............12
Abbildung 5: Auf den PE werden die Routen innerhalb separater VRF-Instanzen (VPN Routing /
Forwarding) getrennt verwaltet..........................................................................................................13
Abbildung 6: ber unterschiedliche Sub-Interfaces werden die angebundenen CEs den VRFs
zugeordnet..........................................................................................................................................13
Abbildung 7: Schematische Darstellung eines MPLS-Netzes...........................................................15
Abbildung 8: Abgrenzung der Verantwortungsbereiche zwischen Kunde und Provider..................16
Tabellenverzeichnis
Tabelle 1: MPLS-Nomenklatur..........................................................................................................10
Tabelle 2: bersicht ber die spezifischen Gefhrdungen bei der Nutzung von MPLS-Netzen.......20
Tabelle 3: berblick ber die Sicherheitsmanahmen fr die Nutzung von MPLS..........................27
Tabelle 4: Kreuzreferenzen - Spezifische Sicherheitsmanahmen fr MPLS...................................42
Einleitung
Einleitung
Bei der Vernetzung von Standorten greifen Kunden, wie z. B. Behrden und Unternehmen, aus
Grnden der Wirtschaftlichkeit meist auf Angebote von Telekommunikationsdienstleistern
(Provider, Carrier, Netzdienstleister) zurck. Der Datentransport kann dabei unter Nutzung
verschiedener Weitverkehrstechniken, wie z. B. ATM, Frame Relay, "Leased Lines", realisiert
werden. Heute existierende, moderne Providernetze werden zum grten Teil auf Basis des MPLSbertragungsprotokolls (Multi-Protocol Label Switching) realisiert [4].
Gegenber den "traditionellen" Netztechniken bietet MPLS die folgenden Vorteile:
- Im Vergleich zu IP-Routing geschieht der Datentransport durch Providernetze
ressourcenschonender, weil im MPLS-Backbone auf Routing-Entscheidungen verzichtet werden

kann.
- Vereinfachte und damit schnellere Bereitstellungs- und Betriebsprozesse.
- Verbesserte QoS-Eigenschaften (Quality-of-Service).
- Weniger "Protokoll-Overhead" im Vergleich zu ATM.
Die Nutzung einer MPLS-Infrastruktur eines Netzdienstleisters ermglicht Kunden die Anbindung
seiner rumlich entfernt liegenden Standorte ber ein virtuelles privates Netz. ber das MPLS-Netz
wird der Datenverkehr mehrerer Kundennetze, innerhalb eigener virtueller privater Netze (VPN),
parallel bertragen. Das MPLS-Transportnetz stellt aus dieser Perspektive ein geteiltes
Transportmedium dar, im Unterschied zur exklusiven Nutzung so genannter "Leased Lines" [3].
Dadurch entstehen Bedrohungen, die sowohl fr Provider als auch fr Behrden und Unternehmen
relevant sind.
Das Bundesamt fr Sicherheit in der Informationstechnik (BSI) ist als IT-Sicherheitsbehrde des
Bundes unter anderem mit der Absicherung von behrdlichen Netzinfrastrukturen betraut. Innerhalb
solcher Netzstrukturen werden im groen Umfang die Techniken DWDM (Dense Wavelength
Division Multiplexing) und MPLS (Multi-Protocol Label Switching) zur Datenbertragung genutzt,
oder deren Nutzung ist fr die Zukunft vorgesehen. Die sichere Anwendung dieser bertragungstechniken ist eine notwendige Voraussetzung fr die Gesamtsicherheit der nationalen Netzinfrastrukturen und der daran angebundenen Systeme.
Die Sicherheitskonzeption der Netzarchitekturen kann grundstzlich anhand der existierenden BSIStandards zur Informationssicherheit [12] vorgenommen werden. Die IT-Grundschutz-Kataloge
[13] enthalten zurzeit aber keinen speziellen Baustein zu dem Themenbereich MPLS. Aus diesem
Grund wurde die Firma T-Systems durch das BSI beauftragt, im Rahmen dieser Kurzstudie eine
Sicherheitsanalyse fr die Technik MPLS zu erstellen. Diese Sicherheitsanalyse bercksichtigt die
verfgbaren Sicherheitsmechanismen und die relevanten Gefhrdungen beim Einsatz von MPLS.
Das vorliegende Dokument enthlt das Studienergebnis der Bedrohungen, die sich aus der Nutzung
des bertragungsprotokolls MPLS ergeben. Diese Studie beschreibt die damit verbundenen
Gefhrdungen und leitet, in Anlehnung an die IT-Grundschutz-Kataloge des Bundesamts fr
Sicherheit in der Informationstechnik (BSI), Manahmen daraus ab. Gefhrdungen und
Manahmen, die bereits heute in den IT-Grundschutz-Katalogen aufgefhrt sind, werden in der
vorliegenden Studie nicht betrachtet. Zum Thema DWDM wurde eine vergleichbare Studie erstellt.
Diese Studie kann von Netz-Dienstleistern und deren Auftraggebern fr technische Bewertungen
des Sicherheitsniveaus verwendet werden.
Grundlagen der MPLS-Technik
Multi-Protocol Label Switching kombiniert die positiven Eigenschaften von Switching mit Routing
auf einem Netzknoten. MPLS ist zwischen den Schichten 2 und 3 des OSI-Schichtenmodells
angesiedelt (Layer "2,5").
- OSI-Schicht 3:
IP
- OSI-Schicht 2-3: MPLS

- OSI-Schicht 2:
ATM, FR, Ethernet
Daten-Frames auf der Schicht 2 werden "geswitcht". Dabei wird der Frame anhand einer Tabelle
einer Ausgangsschnittstelle zugeordnet. Fr diesen Vorgang wird dem Prozessor des Netzknotens
keine Rechenzeit abverlangt. Datagramme auf Schicht 3 werden "geroutet". Fr die "RoutingEntscheidung" muss jeweils anhand einer "Forwarding-Tabelle" der "Next Hop" ermittelt werden.
Dieser Vorgang beansprucht Rechenleistung.
2.1
MPLS-Nomenklatur
Es existieren unterschiedliche Auffassungen darber, was ein VPN kennzeichnet. Demnach wird
ein VPN beispielsweise verstanden als:
- Privates Netz durch die logische Trennung der transportierten Kundendaten. Beispiele dafr sind
die auf Schicht 2 bzw. 2,5 des OSI-Schichtenmodells angesiedelten Transportprotokolle wie:
- ATM
- Frame Relay
- MPLS
-
Diese Techniken werden als Layer-2-VPN bezeichnet. Diese Transportnetze sind vollkommen
unabhngig vom ffentlich zugnglichen Internet. Layer-2-VPN weisen sich durch definierte
Qualittsparameter (Quality of Service, QoS) aus. Dies betrifft sowohl die zur Verfgung
stehende Bandbreite als auch die mit dem Service-Provider vereinbarten "Service Level
Agreements" (SLA).
- Privates Netz durch den Einsatz von Verschlsselung. Beispiele dafr sind die auf den Schichten
3-7 angesiedelten Protokolle:

- IPSec
- Transport Layer Security / Secure Sockets Layer (TLS/SSL)
- Secure Shell (SSH)
-
Diese Techniken werden als Layer-3-VPN oder hher bezeichnet. Verschlsselte Layer-3-VPN
gewhrleisten den Schutz der Vertraulichkeit und werden daher oftmals fr Verbindungen ber
8
das Internet verwendet. Internet-VPN gelten als gnstig und flexibel, mit Schwchen im Bereich
der Verfgbarkeit.
Weitere Unterscheidungsmerkmale in Bezug auf VPN sind:
- Verbindungsorientierte Techniken wie
- ATM
- Frame Relay
- L2TP
- GRE und
- Verbindungslose Techniken wie
- MPLS
In verbindungsorientierten Netzen sind die beteiligten Netzkomponenten ber so genannte Punktzu-Punkt- oder Punkt-zu-Mehrpunkt-Architekturen verbunden. Die Kommunikationsteilnehmer
erreichen sich dadurch ber zentrale Netzknoten. In verbindungslosen Netzen ist dagegen von
"Any-to-Any"-Kommunikation die Rede. Alle Kommunikationsteilnehmer knnen dabei auf der
logischen (IP-)Ebene direkt miteinander kommunizieren.
Trotzdem kann der verbindungslose Charakter "gerouteter" IP-Netze beibehalten werden, indem
sich alle IP-Segmente eines VPN direkt erreichen knnen.
Das RFC 4364 [2] "BGP/MPLS IP Virtual Private Networks (VPNs)" definiert die Nomenklatur
und die Begriffe im Bereich der MPLS-basierten VPNs.
Darin ist beschrieben, auf welche Art und Weise VPN-Provider-Dienste eingehende IPDatagramme aus den Netzsegmenten der Kunden entgegennehmen, um die Daten zu anderen
Netzsegmenten des Kunden zu transportieren. Tabelle 1 gibt einige wichtige Begriffe der
Nomenklatur fr MPLS wieder.
Begriff im RFC 4364
Beschreibung
service provider
Provider oder Netz-Dienstleister, der Kunden

Transportleistungen ber sein MPLS-Netz zur Verfgung
stellt.
customer
Kunde, der Transportleistungen ber das MPLS-Netz des

Providers nutzt.
core network
Transportnetz, Core oder Backbone, ber das die Kunden ihre

Standorte verbinden.
Abkr
zung
SP
Begriff im RFC 4364
Beschreibung
Abkr
zung
customer edge router
Der CE bietet die Anschluss-Schnittstelle fr die Kunden und

wird blicherweise in Rumlichkeiten des Kunden betrieben.
Der CE wird mit dem PE des Providers verbunden.
CE
provider edge router
Der PE bindet die CE an den MPLS-Core an. An einem PE

werden meist mehrere CE unterschiedlicher Kunden-VPN
angebunden.
PE
provider router
Netzknoten innerhalb des MPLS-Core. Das sind alle

Netzknoten innerhalb des MPLS-Netzes, die nicht direkt mit
CE-Routern verbunden sind.
Tabelle 1: MPLS-Nomenklatur
Die verwendeten Abkrzungen werden im Anhang 7.2 aufgelistet oder im Text erlutert.
2.2
MPLS-berblick
MPLS nutzt das so genannte "Label Switching"-Verfahren, um Daten durch das Netz zu
transportieren. Router innerhalb des MPLS-Netzes verarbeiten die Label und werden als Label
Switch Router (LSR) bezeichnet. Die IP-Datagramme werden am "Ingress-Router"
(Eingangsrouter) erstmalig mit einem MPLS-Label (Header) versehen, das am Ausgangsrouter
(Egress-Router) wieder entfernt wird (siehe Abbildung 1). Somit kann ab dort wieder IP geroutet
werden. Der Provider kann dadurch beliebige IP-Segmente des Kunden transportieren. IP-Segmente
mehrerer Kundennetze drfen sich dabei berlappen. Im Regelfall geschieht der Transport fr den
Kunden vollkommen transparent. Lediglich die IP-Adresse der kundenseitigen PE-Schnittstelle ist
fr Kunden sichtbar.
Abbildung 1: IP-Datagramme werden am Ingress-Router (links) mit einem MPLS-Label versehen, das am EgressRouter (rechts) wieder entfernt wird.
10
Alle LSR im MPLS-Netz kommunizieren ber das Label Distribution Protocol (LDP) miteinander.
ber LDP werden die im Netz konfigurierten, fr jedes Kunden-VPN einmal existierenden MPLSLabel zu allen Routern propagiert. Die MPLS-Router speichern diese Informationen in ihrer LSPTabelle. Beim Eintritt eines Datagramms in einen MPLS-Knoten wird das ursprngliche Label
entfernt und ein neues Label, entsprechend der LSP-Tabelle des Routers, vor das IP-Datagramm
gesetzt (siehe Abbildung 2).
Abbildung 2: Pakete werden von jedem LSR entsprechend seiner LSP-Tabelle neu "gelabeled".
Der resultierende Weg, den Datenpakete zwischen zwei Standorten durch das MPLS-Netz
zurcklegen, wird als Label Switched Path (LSP) bezeichnet (siehe Abbildung 3).
Abbildung 3: Der LSP ergibt sich aus der CE-CE-Strecke ber die LSR.
11
Ein Kunden-VPN besteht aus einer Anzahl von Standorten (Sites), die ber das MPLS-Netz
miteinander verbunden sind. Ein CE-Router einer Site ist immer Bestandteil genau eines KundenVPN. Der CE-Router ist mit dem PE-Router verbunden. Ein PE-Router einer Site ist blicherweise
mit mehreren CE-Routern unterschiedlicher Kunden-VPN verbunden (siehe Abbildung 4).
Jede Site eines Kunden-VPN wird aus Sicht des Kunden durch einen CE-Router definiert. Aus
Sicht des Service-Providers wird jede Site eines Kunden-VPN durch die Schnittstelle des PERouters definiert, die mit dem entsprechenden CE-Router verbunden ist.
Abbildung 4: Die PE-Systeme knnen mit CE verschiedener Kundennetze verbunden sein.
Auf dem PE wird jedes Kunden-VPN eines Standorts durch einen einmalig vorhandenen
Bezeichner oder "Route Distinguisher" (RD) gekennzeichnet. Der "Route Distinguisher" wird einer
dedizierten VRF-Instanz (VPN Routing / Forwarding) fr dieses Kunden-VPN zugeordnet.
Dadurch werden die Routen der unterschiedlichen Kunden-VPN getrennt voneinander in vllig
verschiedenen virtuellen Router-Instanzen verwaltet (siehe Abbildung 5).
12
Abbildung 5: Auf den PE werden die Routen innerhalb separater VRF-Instanzen (VPN Routing / Forwarding) getrennt
verwaltet.
Die unterschiedlichen VRF-Instanzen werden nun bestimmten Sub-Interfaces auf den Routern
zugeordnet. ber diese Sub-Interfaces wird die Verbindung zu den jeweiligen CE-Systemen des
Kunden-VPN realisiert (siehe Abbildung 6).
Abbildung 6: ber unterschiedliche Sub-Interfaces werden die angebundenen CEs den VRFs zugeordnet.
Jeder virtuelle Router ist gekennzeichnet durch:

- Eine virtuelle IP-Routing-Tabelle,
13
- Eine aus der Routing-Tabelle abgeleitete Forwarding-Tabelle,

- Eine Anzahl zugeordneter (Sub-)Interfaces, die diese Forwarding-Tabelle nutzen,
- Regeln, die den Im- und Export von Routen in und aus der VPN-Routing-Tabelle kontrollieren,
und
- Eventuell zugeordnete Routing-Protokolle (EIGRP, OSPF).
Anhand Abbildung 6 wird hier ein VRF-Konfigurationsbeispiel (Ausschnitt) fr Cisco IOS auf dem
PE-Router an Standort 1 gegeben:
! Kunde Rot
ip vrf Kunde_Rot
Rd 123:1
! Kunde Blau
ip vrf Kunde_Blau
Rd 117:1
! Link zu CE Kunde rot Site 1
Interface FastEthernet 1/1/0.18
ip vrf forwarding Kunde_Rot
! Link zu CE Kunde blau Site 1
Interface FastEthernet 1/1/0.17
ip vrf forwarding Kunde_Blau
Der Route Distinguisher (RD) ist das Unterscheidungsmerkmal zwischen den VPN-VRFs. Der RD
ist in den MPLS-Headern der MPLS-Pakete wiederzufinden. Im MPLS-Core wird durch die
Nutzung von einmalig vorhandenen Route Distinguishern (RD) die Adressraumseparierung
zwischen den VPN erreicht.
bergnge zwischen verschiedenen MPLS-VPNs sind in dieser Konfiguration nicht vorhanden. Es
ist jedoch mglich, bergnge zwischen unterschiedlichen VPNs zu schaffen, wenn dies so gewollt
ist. Ein denkbares Szenario ist hierbei der Einsatz eines dedizierten und zentralen Internet-VPN fr
den Internetzugang der Kunden. In Cisco IOS werden die Routen dazu innerhalb der VRFKonfiguration explizit importiert oder exportiert.
! Kunde Rot
ip vrf Kunde_Rot
Rd 123:1
route-target import 222:1
! Internet
ip vrf Internet_VPN
Rd 222:1
route-target export 123:1
14
2.3
MPLS-Architektur
Die Architektur von MPLS-Netzen ist hierarchisch angelegt und enthlt die 3 Ebenen
- Access (Netzzugang),
- Distribution (Verteilung) und
- Core (Kerntransportnetz).
In Abbildung 7 ist die MPLS-Architektur schematisch dargestellt.
Abbildung 7: Schematische Darstellung eines MPLS-Netzes
blicherweise werden alle in Abbildung 7 dargestellten Netzkomponenten vom Provider betrieben.

Dabei stellt die kundenseitige Ethernet-Schnittstelle des Customer Edge Routers den Netzabschluss
aus Sicht des Providers dar. Der CE wird als Customer Premises Equipment (CPE) in den Rumen
des Kunden aufgestellt und mit dessen LAN-Infrastruktur (Ethernet-Switch) verbunden (siehe
Abbildung 8).
15
Abbildung 8: Abgrenzung der Verantwortungsbereiche zwischen Kunde und Provider
Am so genannten Service Access Point verlassen Datenpakete den Verantwortungsbereich des

Kunden und erreichen den Verantwortungsbereich des Providers. Dieser bergabepunkt ist meist
die Eingangsschnittstelle der CPE (also der Ethernet-Port des vom Provider verwalteten CE). In
anderen Szenarien wird der CE vom Kunden selbst betrieben. In diesem Fall ist der PE das erste
Gert in der Verantwortung des Providers.
Die Datenpakete der unterschiedlichen Kundenanwendungen (E-Mail, Internet, Sprache, Video,
Terminalanwendungen, Datenbanken) werden auf dem CE anhand spezifischer Eigenschaften
(Protokoll) klassifiziert. Die Klassifizierung wird im IP-Header angezeigt (DiffServ mittels IP
DSCP Bits). Anhand der so gekennzeichneten Pakete kann schon der CE-Router eine
Transportpriorisierung vornehmen. Eine solche Unterscheidung ist notwendig, weil ber das
Datennetz in der Regel mehrere Dienste mit unterschiedlichen Ansprchen an die
bertragungsqualitt gesendet werden. VoIP-Anwendungen z. B. sind sehr empfindlich in Hinblick
auf Laufzeiten (Delay), die Verzgerungen beim Telefonieren verursachen, und in Hinblick auf
Schwankungen (Jitter). Um einer wichtigen Unternehmensanwendung wie Telefonie ber
Datennetze gerecht zu werden, wird diesen Paketen eine Art Vorfahrt in den Warteschlangen der
Router-Schnittstellen eingerumt. Diese sorgt zum einen dafr, dass
- stndig eine garantierte Bandbreite fr die Anwendung bereitgehalten wird (vergleichbar mit der
Committed Information Rate (CIR) bei FR) und

- eine priorisierte Signalisierung auf die bertragungsleitung, vor den Datenpaketen anderer
Anwendungen, stattfindet.
In Cisco IOS gibt es fr die Realisierung von QoS z. B. die Verfahren "Class-Based Weighted Fair
Queuing" (CBWFQ) und "Low-Latency Queuing" (LLQ). Datenpakete von Anwendungen
16
niedriger Prioritt (Internet, E-Mail) werden im Vergleich zu VoIP oder Video-Anwendungen

verzgert bertragen und im Falle erschpfter bertragungskapazitten bevorzugt verworfen.
Die Umsetzung der Klassifizierung innerhalb der IP-Datagramme in die MPLS-Header wird vom
Ingress-LSR (PE) bernommen. Der LSR bertrgt die Informationen aus dem DSCP-Feld des IPHeaders in das EXP-Feld ("Experimental") des MPLS-Headers. Gem IETF-Empfehlung ist der
MPLS-Shim-Header 32 Bit lang. Fr das MPLS-Label stehen 20 Bit zur Verfgung. Das EXP-Feld
umfasst 3 Bit. Der Rest des Headers wird von Stack (1 Bit) und TTL (8 Bit) eingenommen [11].
2.4
Sicherheitsbetrachtung MPLS
Klassische Layer-2-VPN bieten per Definition keine integrierte Verschlsselung (siehe Kapitel 2.1).
Gleichwohl bringen diese Techniken ein gewisses Ma an Sicherheit mit sich, weil die Daten
verschiedener Kundennetze innerhalb separierter Transportkanle bertragen werden (ATM VPI /
VCI; Frame Relay DLCI). Layer-3-IP-Datagramme werden fr den Transport ber die Providerplattform in ATM-Zellen oder in FR-Rahmen gekapselt und im Zielsegment wieder ausgepackt.
Innerhalb der Netzplattform existiert also keine IP-Konnektivitt. Dadurch entfallen die meisten der
heute bekannten Angriffsszenarien auf IP-Ebene. Weiterhin verwenden Layer-2-Netze hufig
private Netzinfrastrukturen. ffentliche Netze wie das Internet werden in der Regel fr den Datentransport nicht genutzt. Gleichwohl kann das Netz einer Behrde oder eines Unternehmens aus
einer Kombination von privaten Layer-2-Verbindungen und Internet-VPNs (TLS/SSL/IPSec/SSH)
realisiert werden.
MPLS ist zwischen den Netzschichten 2 und 3 angesiedelt. Es bringt durch die Verwendung der
Label-Technik ein mit anderen Layer-2-VPN vergleichbares Ma an Sicherheit mit sich [5]. Dabei
werden die IP-Datagramme mit einem vorgeschalteten MPLS-Label-Stack versehen. Dadurch sind
die IP-Daten der unterschiedlichen Kundennetze voneinander getrennt. Somit ist ein MPLS-Netz
sicherheitstechnisch durchaus mit ATM/FR-Netzen vergleichbar. Trotzdem bleibt der MPLSBackbone mit seinen Netzknoten ein zwischen mehreren Kunden geteiltes Medium. Es gibt
theoretische und praktische Angriffsszenarien auf die Schutzziele Vertraulichkeit, Integritt und
Verfgbarkeit. Tter knnen dabei aus anderen Kunden-VPN, aus dem Internet oder direkt aus dem
Providernetz heraus angreifen.
Um ein hheres Ma an Sicherheit zu erzielen, besteht fr Kunden von Layer-2- und MPLS-Netzen
die Mglichkeit, verschlsselte Verbindungen einzusetzen. Als gngiges Verfahren sei an dieser
Stelle das "IPSec Site-to-Site Tunneling" genannt, mit dem auch gegenber dem Providerpersonal
die Schutzziele Vertraulichkeit und Integritt in hohem Mae gewhrleistet werden knnen.
Als grundstzlich vorhandenes Risiko geteilter MPLS-Infrastrukturen existiert auch bei Einsatz von
Tunneltechniken die Gefahr eines Denial-of-Service (DoS). Dies ist vor allem bei den PE-Routern
relevant, die Verbindungen zu den CE-Systemen mehrerer Kunden-VPN haben. Ein DoS-Angriff
aus einem Kunden-VPN, der zu einem Ausfall des PE-Systems fhrt, wrde auch die anderen
VPNs, die den selben PE nutzen, negativ beeinflussen.
MPLS-Netze knnen auch dediziert fr nur einen Kunden (Behrde oder Unternehmen) existieren.
MPLS-Netze werden an Hand der folgenden 3 Merkmale charakterisiert. Diese Unterscheidung ist
wichtig fr die Einschtzung der Bedrohungen:
1. Control Plane (Steuerungsebene)
- Die Control Plane wird durch Routing-Instanzen definiert. Der CE-Router propagiert dabei
die IP-Routen seines Standorts zum angeschlossenen PE-Router. Dieser wiederum versorgt
17
den CE-Router mit seinen Routing-Informationen. Dies kann ber Routing-Protokolle (wie
OSPF, BGP) oder ber statisches Routing geschehen.
- Ein PE ist mit den CE mehrerer Kundennetze verbunden. Die Routing-Informationen der
einzelnen Kundennetze werden in separierten VRF-Instanzen ("VPN Routing / Forwarding")

vorgehalten. Die VRF werden anhand von "Route Distinguishern (RD)" unterschieden.
2. Data Plane (Ebene des Kundendatenverkehrs)
- Im Bereich der Data Plane transportiert das CE-System den IP-Verkehr des Kunden zu den
VRF der PE.

- Am PE-System werden die Pakete mit dem PE-Label des Egress-Routers (Ziel-PE) und dem
kundenspezifischen VPN-Label versehen.

3. Management Plane (Verwaltungsebene)
- Die Management Plane definiert den Netzmanagementverkehr (in-band oder out-of-band),
ber den die Netzoperatoren ihre Netze verwalten.

Unterschiedliche Angriffe zielen auf die unterschiedlichen Ebenen dieser Netzklassifikation ab.
18
Gefhrdungen bei der Nutzung von MPLS-Infrastrukturen
Gefhrdungen bei der Nutzung von MPLSInfrastrukturen
Die allgemeinen Gefhrdungen fr die sichere Datenbertragung in MPLS-Netzen entsprechen den

relevanten Gefhrdungen in den IT-Grundschutz-Katalogen G1 bis G5. Diese allgemeinen Gefhrdungen werden in dieser Kurzstudie bercksichtigt, jedoch nicht mit aufgefhrt.
In diesem Kapitel werden die spezifischen, durch Nutzung der MPLS-Technik entstehenden
Gefhrdungen beschrieben. Tabelle 2 listet die MPLS-spezifischen Gefhrdungen in einem
berblick auf. Im Anschluss daran werden die einzelnen Gefhrdungen erlutert.
Bezeichner
Beschreibung der Gefhrdung
Manahmen
G.PakAus
Austritt markierter MPLS-Pakete aus dem VPN
M01, M16, M17, M22
G.PakInjVPN
Injizieren unberechtigter Pakete aus einem MPLSVPN in ein anderes MPLS-VPN
M01, M02, M16, M17,

M18, M22
G.PakInjCore
Injizieren unberechtigter Pakete vom Transportnetz

des Netzdienstleisters in ein MPLS-VPN
M01, M02, M03, M17,

M18, M20, M22
G.PakInjIntAS
Einbringen unberechtigter Pakete vom Transportnetz

eines anderen Netzdienstleisters in ein MPLS-VPN
M01, M02, M03, M04,

M16, M18, M20, M22
G.FehlCE
Anbinden eines unberechtigten CE-Routers durch

Fehlkonfiguration
M03, M05, M16, M18,

M20, M21, M24
G.FehlCE-IAS
Anbinden eines unberechtigten CE-Routers im

Transportnetz eines anderen Netzdienstleisters
M05, M06, M16, M18,

M21, M24
G.Sichtbar
Sichtbarkeit der logischen Struktur des ProviderNetzes
M07, M10
G.DatenMix
Vermischung des Datenverkehrs verschiedener

Kundennetze
M08, M16, M18, M21
G.PE-DoS
Denial-of-Service-Angriff auf PE-Router
M09, M16
G.WWW-DoS
Denial-of-Service-Angriff aus dem Internet
M07, M10, M11, M19
G.BGP-DoS
Denial-of-Service-Angriffe auf das RoutingProtokoll BGP im Core
M07, M12, M16
19
Bezeichner
Beschreibung der Gefhrdung
Manahmen
G.Route-DoS
Denial-of-Service-Angriffe auf VPNs durch RoutingUpdates
M09, M13, M14, M15,

M16
G.Ausfall
Denial-of-Service durch Ausfall des Transportnetzes
M15, M23
Tabelle 2: bersicht ber die spezifischen Gefhrdungen bei der Nutzung von MPLS-Netzen
Im Folgenden werden die fr MPLS relevanten Gefhrdungen, die in Tabelle 2 aufgefhrt sind,
erlutert.
3.1
Austritt markierter MPLS-Pakete aus dem VPN
Bezeichner: G.PakAus
Erluterung:
Mit MPLS-Header versehene ("gelabelte") Pakete knnen unter Umstnden unbeabsichtigt das
vorgesehene MPLS-VPN verlassen und in anderen VPNs oder IP-Netzen sichtbar werden. Diese
Gefhrdung ist in RFC 4364 [2] "Data Plane Security" beschrieben. Demnach kann diese
Gefhrdung auftreten, wenn ein Backbone-Router "gelabelte" Pakete an nicht-vertrauenswrdige
Systeme weiterleitet, zu denen eine IPv4-Route existiert. Dieses Verhalten ist gem RFC nicht
zugelassen. Als mgliche Ursachen kommen demnach Softwarefehler und Fehlkonfigurationen in
Frage.
Anmerkungen:
Diese Gefhrdung entsteht auf der Ebene der "Data Plane".
Betroffene Schutzziele: Vertraulichkeit
3.2
Injizieren unberechtigter Pakete aus einem MPLS-VPN in ein

anderes MPLS-VPN
Bezeichner: G.PakInjVPN
Erluterung:
Teilnetze unterschiedlicher MPLS-VPN am gleichen Standort (Site) sind ber einen gemeinsamen
PE-Router mit dem MPLS-Backbone und mit den anderen Standorten des zugehrigen MPLS-VPN
verbunden. Datenpakete mit vernderten MPLS-Labeln ("MPLS-Label-Spoofing") knnten unberechtigt in ein MPLS-VPN gelangen, wenn der PE-Router entsprechende Pakete mit geflschtem
Label vom CE-Router eines Kunden-VPN akzeptiert und in ein anderes Kunden-VPN transportiert.
Bidirektionale Kommunikation ist in diesem Szenario nicht mglich. Gem RFC darf ein PERouter keine Pakete mit MPLS-Label von einem CE-System annehmen. Bei RFC-konformer
Konfiguration und Implementierung ist demnach ein MPLS-Label-Spoofing von einem VPN in ein
anderes nicht mglich. Als mgliche Ursachen kommen demnach Softwarefehler, Fehlkonfiguration und gezielte Angriffe in Frage.
20
Anmerkungen:
Betroffene Schutzziele: Vertraulichkeit, Integritt
3.3
Injizieren unberechtigter Pakete vom Transportnetz des

Netzdienstleisters in ein MPLS-VPN
Bezeichner: G.PakInjCore
Erluterung:
In ein MPLS-VPN knnten manipulierte Datenpakete aus dem Transportnetz des Netzdienstleisters
(Core) eindringen. Dies setzt voraus, dass Manipulationen (MPLS-Label-Spoofing) innerhalb des
Cores nicht von den PE-Routern verworfen werden, sondern in ein MPLS-VPN eindringen knnen.
RFC 4364 enthlt Vorgaben, die die Eintrittswahrscheinlichkeit dieser Gefhrdung senken.
Bidirektionale Kommunikation ist in diesem Szenario nicht mglich.
Als mgliche Ursachen kommen Softwarefehler, Fehlkonfiguration oder gezielte Angriffe aus dem
Transportnetz des Dienstleisters in Frage (MPLS-Label-Spoofing durch Man-in-the-MiddleAngriff, z. B. des Providerpersonals).
Anmerkungen:
3.4
Einbringen unberechtigter Pakete vom Transportnetz eines

anderen Netzdienstleisters in ein MPLS-VPN
Bezeichner: G.PakInjIntAS
Erluterung:
Zur Kopplung verschiedener Kundenstandorte eines MPLS-VPNs ber die Netzgrenzen des Transportdienstleisters hinaus (z. B. in das Ausland) etablieren MPLS-Provider sogenannte "Inter-AS"Verbindungen (AS: Autonomous System) oder "Carriers Carrier"-Verbindungen untereinander.
Dadurch entsteht aus diesen Netzen heraus prinzipiell ein analoges Gefhrdungsszenario, wie in
G.PakInjCore beschrieben. Das heit, es knnten unberechtigte Pakete vom Transportnetz eines
anderen Netzdienstleisters in ein MPLS-VPN gelangen.
Als mgliche Ursachen kommen Softwarefehler, Fehlkonfiguration oder gezielte Angriffe aus dem
Transportnetz des externen MPLS-Dienstleisters in Frage (MPLS-Label-Spoofing durch Man-inthe-Middle-Angriff, z. B. des Providerpersonals).
Anmerkungen:
21
3.5
Anbinden eines unberechtigten CE-Routers durch

Fehlkonfiguration
Bezeichner: G.FehlCE
Erluterung:
Eine Fehlkonfiguration oder ein gezielter Angriff des Betreiberpersonals kann dazu fhren, dass ein
CE-Router eines Kunden (A) unautorisiert in das MPLS-VPN eines anderen Kunden (B) integriert
wird, wenn (A) und (B) ber einen gemeinsamen PE-Router an das MPLS-Netz angeschlossen sind.
Der MPLS-Standort (A) wre folglich Mitglied des anderen Kunden-MPLS-VPN (B). Diese
Gefhrdung kann durch eine ungewollte oder eine gezielte Fehlkonfiguration verursacht werden.
Einem erfolgreichen Angreifer sind in der Folge alle netzbasierten Angriffe, die auch ein Innentter
durchfhren knnte, auf Systeme im VPN mglich.
Es ist auch ein Szenario denkbar, in dem ein Innentter als "Man-in-the-Middle" einen zustzlichen
CE an einen PE einer beliebigen Site anschliet und diesen CE in das VPN eines Kundennetzes
integriert.
Anmerkungen:
Diese Gefhrdung betrifft alle Ebenen: "Data", "Control" und "Management".
Betroffene Schutzziele: Vertraulichkeit, Integritt, Verfgbarkeit
3.6
Anbinden eines unberechtigten CE-Routers im Transportnetz

eines anderen Netzdienstleisters
Bezeichner: G.FehlCE-IAS
Erluterung:
Zur Kopplung verschiedener Kundenstandorte eines MPLS-VPNs ber die Netzgrenzen des
Transportdienstleisters hinaus (z. B. in das Ausland) etablieren MPLS-Provider sogenannte "InterAS"-Verbindungen oder "Carriers Carrier"-Verbindungen untereinander. Dadurch entsteht aus
diesen Netzen heraus prinzipiell ein analoges Gefhrdungsszenario, wie in G.FehlCE beschrieben.
Ein mglicher Angriff wrde dann aus dem Netzbereich des externen Dienstleisters erfolgen.
Anmerkungen:
Betroffene Schutzziele: Vertraulichkeit, Integritt, Verfgbarkeit
3.7
Sichtbarkeit der logischen Struktur des Provider-Netzes
Bezeichner: G.Sichtbar
Erluterung:
Kenntnisse ber die logische Struktur des Providernetzes, insbesondere die Adressen der P- und PERouter, ermglichen unter Umstnden weitere gezielte Angriffe auf die Infrastruktur des MPLSBackbones.
22
Anmerkungen:
Betroffene Schutzziele: Vertraulichkeit
3.8
Vermischung des Datenverkehrs verschiedener Kundennetze
Bezeichner: G.DatenMix
Erluterung:
Durch Softwarefehler oder Fehlkonfiguration kann es passieren, dass Datenverkehr von einem
Kunden-VPN (A) in ein anderes Kunden-VPN (B) gelangt und umgekehrt. Durch eine solche
Datenvermischung wird die Vertraulichkeit und/oder Integritt der Netzkommunikation verletzt.
Anmerkungen:
3.9
Denial-of-Service-Angriff auf PE-Router
Bezeichner: G.PE-DoS
Erluterung:
ber PE-Router werden die CE-Router mehrerer Kunden-VPN einer gemeinsamen Site mit dem
MPLS-Transportnetz verbunden. Ein Denial-of-Service-Angriff aus einem Kunden-VPN ber eine
PE-CE-Verbindung auf einen PE-Router beeintrchtigt unter Umstnden alle anderen CE-PEVerbindungen ber diesen PE-Router ebenfalls. Angriffe knnen z. B. ber andauernde RoutingUpdates mittels EIGRP (Enhanced Interior Gateway Routing Protocol) oder OSPF (Open Shortest
Path First) geschehen. Denkbar ist auch die Erzeugung hoher Last durch das gezielte Senden vieler
kleiner Pakete.
Anmerkungen:
Diese Gefhrdung entsteht auf der Ebene der "Data Plane" und der "Control Plane".
Betroffene Schutzziele: Verfgbarkeit
3.10 Denial-of-Service-Angriff aus dem Internet

Bezeichner: G.WWW-DoS
Erluterung:
Hufig stellt der MPLS-Provider einen oder mehrere zentrale Ausstiege in das Internet fr seine
Kunden-VPNs zur Verfgung. Dadurch besteht die potentielle Gefhrdung durch Angriffe aus dem
Internet auf das MPLS-Core-Netz.
Anmerkungen:
23
Abhngig von der Realisierung der Internet-Anbindung kann diese Gefhrdung alle Ebenen
betreffen: "Data", "Control" und "Management".
3.11 Denial-of-Service-Angriffe auf das Routing-Protokoll BGP im

Core
Bezeichner: G.BGP-DoS
Erluterung:
BGP ist das dynamische Routing-Protokoll, ber das die Routing-Informationen zwischen den
MPLS-Routern ausgetauscht werden.
Gelingt es einem Angreifer, das zentrale Routing-Protokoll zu beeintrchtigen, kann es zu
Instabilitten im gesamten Netz kommen. Die Verfgbarkeit kann nachhaltig beeintrchtigt werden.
Angriffe knnen aus den MPLS-VPN, aus dem Internet und im Backbone selbst durchgefhrt
werden. Mgliche Angriffsszenarien sind:
- TCP-Reset-Angriff auf die BGP-Session
- Last-Erzeugung auf dem Route-Prozessor durch das Senden von BGP-Paketen zu einem BGP-
Router
- ICMP-Angriff auf einen BGP-Partner mit dem Ziel, die BGP-Sitzung zu terminieren
Anmerkungen:
- Diese Gefhrdung entsteht auf der Ebene der "Control Plane" und gefhrdet auch die "Data
Plane" und die "Management Plane".

- Vergleiche Meldung 2004-218 des Sicherheitsdienstleisters dCERT vom 2005-05-03: "TCP
Stack Implementierungen ermglichen Denial-of-Service Angriffe".

3.12 Denial-of-Service-Angriffe auf VPNs durch Routing-Updates

Bezeichner: G.Route-DoS
Erluterung:
Der Netzverkehr der unterschiedlichen MPLS-VPN ber das Core-Netz ist voneinander separiert.
Jedoch knnen Denial-of-Service-Angriffe auf das VPN eines Kunden negative Auswirkungen fr
andere Kunden nach sich ziehen, wie z. B. Leistungseinbuen des Transportnetzes. Eine mgliche
Ursache hierfr ist, dass in den VRF-Instanzen (VPN Routing / Forwarding) der Kunden auf den
PE-Routern stndig Routing-Updates fr neu hinzukommende Routen durchgefhrt werden
mssen. Das kann zu bermigem Ressourcenverbrauch auf den Core-Routern fhren und damit
auch Beeintrchtigungen der Transportkapazitten fr andere VPN nach sich ziehen.
Anmerkungen:
Diese Gefhrdung entsteht auf der Ebene der "Control Plane".
24
3.13 Denial-of-Service durch Ausfall des Transportnetzes

Bezeichner: G.Ausfall
Erluterung:
Ein Ausfall oder Teilausfall des MPLS-Netzes kann unter anderem durch Versagen wichtiger
Netzkomponenten (Stromausfall, technisches Versagen) oder durch Beeintrchtigung der
Leitungswege (z. B. durch Tiefbaumanahmen) hervorgerufen werden.
Anmerkungen:
Vergleiche die IT-Grundschutz-Gefhrdung G 4.1 "Ausfall der Stromversorgung". Dieses Szenario
ist eigentlich nicht MPLS-spezifisch und wird hier nur aufgefhrt, weil Stromausflle auch heute
oftmals Ursache fr einen Ausfall sind.
25
Sicherheitsmanahmen fr MPLS-Netze
In diesem Kapitel sind die spezifischen Manahmen fr die sichere Nutzung von MPLS-Netzen
aufgefhrt.
Die allgemein zu ergreifenden Sicherheitsmanahmen fr die Datenbertragung in MPLS-Netzen
entsprechen zum Teil bereits einzelnen Manahmen, die in den IT-Grundschutz-Katalogen M1 bis
M6 enthalten sind. Die dort aufgefhrten Manahmen sind hier nicht beschrieben. An bestimmten
Stellen findet sich jedoch ein Verweis auf die relevanten Passagen der IT-Grundschutz-Kataloge.
Tabelle 3 zeigt einen berblick ber die spezifischen Sicherheitsmanahmen fr MPLS. Bei den
Manahmen, die in der Tabelle mit einem Stern (*) gekennzeichnet sind, handelt es sich um
zustzliche Manahmen fr besonders sicherheitskritische MPLS-Netze. Die brigen Manahmen
sind Basismanahmen. Im Anschluss an die Tabelle werden die einzelnen Manahmen erlutert.
Die Entscheidung, welche Sicherheitsmanahmen fr den jeweiligen Einsatzzweck erforderlich und
geeignet sind, sollte im Rahmen eines systematischen Sicherheitsprozesses getroffen werden.
Weitere Hinweise hierzu finden sich in den BSI-Standards zur Informationssicherheit [12].
Nr.
Beschreibung der Manahme
Gefhrdungen
M01
Programmierung sicherer Software / Firmware,

Zertifizierungen
G.PakAus, G.PakInjVPN,
G.PakInjCore, G.PakInjIntAS
M02
Verhindern von MPLS-Label-Spoofing
G.PakInjVPN, G.PakInjCore,
G.PakInjIntAS
M03
Zuverlssigkeit des Dienstleisterpersonals
G.PakInjCore, G.PakInjIntAS,
G.FehlCE
M04
Zuverlssigkeit verbundener MPLS-Carrier
G.PakInjIntAS
M05
Einsatz von Netzberwachungssystemen
G.FehlCE, G.FehlCE-IAS
M06
Sichere Kopplung von Netzdienstleistern
G.FehlCE-IAS
M07
Deaktivierung von MPLS-Traceroute-Funktionen
G.Sichtbar, G.WWW-DoS, G.BGPDoS
M08
Separierung des Datenverkehrs verschiedener

Kunden-VPNs
G.DatenMix
M09
Schutz des PE-Routers
G.PE-DoS, G.Route-DoS
M10
Verstecken der IP-Adresse des PE-Routers
G.Sichtbar, G.WWW-DoS
26
Nr.
Beschreibung der Manahme
Gefhrdungen
M11 * Internet-bergang als eigenes MPLS-VPN
G.WWW-DoS
M12
Sichere Konfiguration von BGP
G.BGP-DoS
M13
Etablierung von Schwellwert-Alarmen
G.Route-DoS
M14 * Anwendung von "Best Practice"-Empfehlungen

fr die Konfiguration der MPLS-Router
G.Route-DoS
M15 * Redundanz zum Schutz der Verfgbarkeit in

MPLS-Netzen
G.Route-DoS, G.Ausfall
M16 * Nutzung einer dedizierten MPLS-Infrastruktur
G.PakInjIntAS, G.FehlCE,
G.FehlCE-IAS, G.DatenMix, G.PEDoS, G.BGP-DoS, G.Route-DoS
M17
Programmieren und Einspielen von SoftwarePatches
G.PakInjCore
M18
Nutzung von IPSec-Tunneln ber MPLSVerbindungen
G.PakInjVPN, G.PakInjCore,
G.PakInjIntAS, G.FehlCE,
G.FehlCE-IAS, G.DatenMix
M19 * MPLS-Core ohne Internet-Konnektivitt
G.WWW-DoS
M20
Verbindungstest nach Anbinden eines VPNStandorts
G.PakInjCore, G.PakInjIntAS,
G.FehlCE
M21
Erstellen eines Label-Konzepts
G.FehlCE, G.FehlCE-IAS,
G.DatenMix
M22
Auswahl geeigneter Netzkomponenten
G.PakInjCore, G.PakInjIntAS
M23
Konzeption des MPLS-Netzes
G.Ausfall
M24
Rollout-Konzept
G.FehlCE, G.FehlCE-IAS
Tabelle 3: berblick ber die Sicherheitsmanahmen fr die Nutzung von MPLS
In den folgenden Kapiteln werden die Manahmen im Einzelnen beschrieben.

27
4.1
Programmierung sicherer Software / Firmware,

Zertifizierungen
Bezeichner:
M01
Lebenszyklus:
Beschaffung
Verantwortlich:
Hersteller (Programmierung), Provider (Einsatz)
Erluterung:
Schwachstellen werden hufig durch nachlssig programmierte Software verursacht. Durch die
Anwendung von Modellen wie z. B. CMMI (Capability Maturity Model Integration) knnen bei der
Entwicklung von Software qualittssichernde Prozessschritte integriert werden, um so die Gte und
Reife der Software zu verbessern und damit die Anzahl der potentiellen Schwachstellen zu
verringern.
Bei der Planung von MPLS-Netzen kann der Provider den Einsatz entsprechend qualittsgeprfter
Software bercksichtigen.
Anmerkungen:
Diese Manahme ist grundstzlich bei allen Software-Projekten sinnvoll, gerade wenn es um den
Einsatz innerhalb sicherheitskritischer Netze geht.
4.2
Verhindern von MPLS-Label-Spoofing
Bezeichner:
M02
Lebenszyklus:
Umsetzung
Verantwortlich:
Erluterung:
Die Eingangs-Netzknoten des MPLS-Cores (PE-Router oder Ingress-LSR) mssen markierte
("labeled") MPLS-Pakete blockieren, wenn sie ber eine CE-PE-Verbindung in das Netz eintreten
("Data Plane Security") oder von einem nicht vertrauenswrdigen Router stammen, der nicht
Mitglied des VPNs ist. Diese Manahme wird auf Seiten der Hersteller durch sichere
Programmierung (siehe M01) erreicht. Auf Seiten der Netz-Dienstleister kann dieses Verhalten, das
in RFC 4364 definiert ist, nach Software-Aktualisierungen durch Tests in Referenzanlagen
verifiziert werden.
Anmerkungen:
Der Nachweis der Umsetzung erfolgt in Abnahmetests.
4.3
Zuverlssigkeit des Dienstleisterpersonals
Bezeichner:
M03
Lebenszyklus:
Beschaffung
Verantwortlich:
Provider (Verpflichtung und Nachweis), Leiter IT
28
Erluterung:
Das Dienstleisterpersonal ist auf die Einhaltung der einschlgigen Gesetze, Vorschriften und
Regelungen zu verpflichten (siehe auch IT-Grundschutz-Manahme M 3.2).
Bei sicherheitskritischen Netzen ist auerdem die IT-Grundschutz-Manahme M 3.33
"Sicherheitsberprfung von Mitarbeitern" zu beachten. In bestimmten Fllen, z. B. wenn Personen
auf VS-VERTRAULICH oder hher eingestufte staatliche Verschlusssachen zugreifen knnen, ist
eine berprfung gem Sicherheitsberprfungsgesetz (SG) zulssig und erforderlich.
Seine Sorgfalt bei der Auswahl von Mitarbeitern soll der Provider dem Kunden in geeigneter Form
nachweisen knnen, etwa durch Prozessbeschreibungen zu den Verpflichtungen.
Anmerkungen:
Diese Manahme ist nicht MPLS-spezifisch. Sie wird hier aufgefhrt, weil dieser Aspekt im
Zusammenhang mit dem Betrieb sicherheitskritischer Netze eine besondere Bedeutung hat. Fr den
Dienstleister gilt die Pflicht, in jedem Fall alle datenschutzrechtlichen Bestimmungen einzuhalten.
4.4
Zuverlssigkeit verbundener MPLS-Carrier
Bezeichner:
M04
Lebenszyklus:
Beschaffung
Verantwortlich:
Provider (Verpflichtung und Nachweis), Leiter IT
Erluterung:
Kunden, die ihre Auslandsstandorte ber MPLS-VPN anbinden, mssen sich nicht nur auf den
nationalen MPLS-Provider, sondern auch auf die beteiligten internationalen MPLS-Provider
verlassen knnen. Vertragsbeziehungen geht der Kunde jedoch blicherweise nur mit dem
nationalen MPLS-Provider ein. Daher mssen MPLS-Carrier, die ber "Inter-AS"- oder "Carriers
Carrier"-Schnittstellen miteinander verbunden sind, entsprechende Service-Vereinbarungen
untereinander treffen. Dem IT-Grundschutz-Baustein B 1.11 folgend, kann der MPLS-Dienstleister,
mit dem die Verbindung eingegangen wird, als Outsourcing-Dienstleister angesehen werden. Der
Outsourcing-Dienstleister soll ber ein IT-Sicherheitskonzept, Notfallvorsorgeplne und genaue
Prozessbeschreibungen verfgen. Weiterhin mssen zwischen allen Parteien die juristischen
Rahmenbedingungen geregelt sein. Dies gilt insbesondere bei Fragen bezglich der Haftung im
Schadensfall. Der Partner-Provider muss zudem nachweisen knnen, dass er bei der Auswahl seines
Personals mit der notwendigen Sorgfalt vorgeht.
Anmerkungen:
Diese Manahme hat im Zusammenhang mit dem Betrieb sicherheitskritischer Netze eine
besondere Bedeutung.
4.5
Einsatz von Netzberwachungssystemen
Bezeichner:
M05
Lebenszyklus:
Betrieb
Verantwortlich:
Provider, Leiter IT, IT-Sicherheitsbeauftragter, Router-Administrator
29
Erluterung:
Es mssen Netzberwachungssysteme, meist als Bestandteil eines Netzmanagementsystems
(NMS), eingesetzt werden. Diese sollen auf Kundenseite und auf Dienstleisterseite die Integritt des
MPLS-VPN berwachen. In diesem Zusammenhang sind auch die IT-Grundschutz-Bausteine
B 3.302 "Router und Switches" und B 4.2 "Netz- und Systemmanagement" zu bercksichtigen. Bei
der Einrichtung des Netzmanagements fr MPLS-Komponenten sind auerdem wichtige MPLSEigenschaften zu beachten, wie z. B. die Abbildung der VRF und der einzelnen VPN. Diese
Eigenschaften sind in den SNMP-MIBs der Hersteller enthalten [8], [11].
Netzberwachungssysteme auf Providerseite sollen redundant existieren, um bei Ausfall einer
NMS-Verbindung nicht die Sicht auf das gesamte Netz zu verlieren.
Die Anbindung des Netzmanagements muss ausreichend dimensioniert sein. Die Auslastung der
Netzmanagementverbindung selbst muss berwacht werden.
Netzmanagementpakete mssen ber QoS-Parameter derart priorisiert werden, dass sie auch im Fall
eines DoS-Angriffs vorrangig gegenber anderen Transportklassen behandelt werden.
Der Provider darf dem Kunden dabei nur eine Sicht auf seine CE-PE-Verbindungen geben. Diese
Sicht soll dem Kunden die notwendigen Informationen ber Verfgbarkeit und Performance seines
VPN bereitstellen, nicht jedoch ber die Struktur des MPLS-Netzes selbst, mit seinen weiteren
Kunden-VPN. Die Kundeninformationen sollten dabei nicht direkt vom CE zum Kunden gelangen
(z. B. ber SNMP oder NetFlow), sondern ber ein Kundenportal bereitgestellt werden. Bei der
Bereitstellung solcher Dienste ist zu beachten, dass die Performance der Netzknoten beeintrchtigt
werden kann, wenn SNMP-Traps an viele NMS gesendet werden und wenn mehrere Stationen
SNMP-Get-Requests starten. Die fr das MPLS-Netz einzurichtenden Stationen mssen deshalb auf
ein Mindestma beschrnkt werden. Dies gilt ebenso fr den Umfang der abzufragenden SNMPInformationen.
Beim Netzmanagement sind sichere Protokolle zu nutzen. Insbesondere auf den Einsatz von Telnet
sollte in diesem Umfeld zugunsten verschlsselter Alternativen (SSH) verzichtet werden. SNMPv3
sollte in abgesicherter Form zum Einsatz kommen. Wenn nur SNMPv2 mglich ist, muss auf
SNMP-Read/Write-Communities verzichtet werden.
Anmerkungen:
Die Prozessbeschreibung fr die Bereitstellung von Kunden-VPNs sollte einen Test der
Funktionstchtigkeit und des Funktionsumfangs des MPLS-NMS umfassen.
4.6
Sichere Kopplung von Netzdienstleistern
Bezeichner:
M06
Lebenszyklus:
Planung
Verantwortlich:
Provider
Erluterung:
Im Falle internationaler Verbindungen ist es notwendig, dass nationale MPLS-Provider
Verbindungen mit internationalen Providern eingehen, um die Auslandsstandorte ihrer Kunden zu
bedienen. Diese Verbindungen sollten in Form von dedizierten VRF-zu-VRF-Kopplungen ber
ASBR (Autonomous System Border Router) erfolgen. Die ASBR beider Provider halten fr jedes
Kunden-VPN, das ber die Netzgrenzen transportiert werden soll, ein separates VRF bereit. Auf
30
den ASBR werden die VRF dann bestimmten Sub-Interfaces zugeordnet. Die ASBR verhalten sich
dabei wie PE-Router. Die VRF des gegenberliegenden ASBR werden wie CE-Router angebunden.
Label-Spoofing wird unterbunden, weil zwischen den ASBR nur "ungelabelte" Pakete ausgetauscht
werden (wie bei einer PE-CE-Verbindung). Jeder der MPLS-Provider kann also sein eigenes
MPLS-Label fr das Kunden-VPN vorsehen.
Eine weitere Eigenschaft des VRF-VRF-AS-Modells ist, dass ein AS die Struktur des anderen AS
nicht erkennen kann, weil sich die ASBR-bergnge wie CE-Verbindungen verhalten. Nur der
nchste Hop zur IP-Adresse des gegenberliegenden ASBR ist erreichbar.
Zur Herstellung einer VPN-Verbindung zwischen den Providern ist eine genaue Koordination
notwendig, da die Konfiguration aufeinander abgestimmt sein muss. Fehlkonfigurationen knnen
vorkommen und dafr sorgen, dass Standorte zweier verschiedener Kunden-VPN unerlaubt
miteinander verbunden werden. Dieses Risiko ist durch Tests in der Bereitstellungsphase zu
reduzieren.
Anmerkungen:
Als Alternative zum VRF-VRF-AS-Modell kann auch die "Carriers Carrier"-Schnittstelle gewhlt
werden. Hier wird der gesamte Verkehr aus dem Netz des angeschlossenen Providers innerhalb
eines VPN transportiert. Angriffe aus dem angeschlossenen Providernetz in andere VPN sind in
dieser Konstellation also auch nicht ohne Weiteres mglich.
Neben den beiden genannten Modellen gibt es weitere Mglichkeiten, MPLS-Providernetze zu
koppeln. Diese bieten zum Teil eine wesentlich grere Flexibilitt in Hinblick auf die Einrichtung
neuer VPN-Verbindungen fr Kunden. Aufgrund der Gefhrdungslage sollten die Kopplungen
jedoch ausschlielich ber das VRF-VRF-AS-Modell oder ber die "Carriers Carrier"-Schnittstelle
erfolgen.
4.7
Deaktivierung von MPLS-Traceroute-Funktionen
Bezeichner:
M07
Lebenszyklus:
Betrieb
Verantwortlich:
Provider
Erluterung:
Es ist von Providerseite dafr Sorge zu tragen, dass ausschlielich die logischen Adressen der
kundenseitigen Schnittstellen der PE-Router fr Kunden sichtbar sind. Funktionen, welche die
logische Struktur des Providernetzes nach auen bekannt machen, sind abzustellen. Bei Cisco-IOS
kann dies z. B. ber die Funktion "no mpls ip propagate-ttl forwarded" erfolgen.
4.8
Separierung des Datenverkehrs verschiedener Kunden-VPNs
Bezeichner:
M08
Lebenszyklus:
Planung
Verantwortlich:
Provider
Erluterung:
31
Um sicherzustellen, dass keine Mischung der Datenverkehrsstrme unterschiedlicher Kundennetze

vorkommt, sind fr jedes Kundennetz dedizierte VRF-Instanzen (VPN Routing / Forwarding) zu
konfigurieren (siehe Kapitel 2.2). Die wirksame Trennung der VPN ist durch entsprechende Tests
whrend des Bereitstellungsprozesses zu berprfen. bergnge in andere VPN drfen nicht
existieren, es sei denn, der Kunde hlt mehrere unterschiedliche VRF bereit oder bentigt einen
bergang in ein Internet-VRF.
Anmerkungen:
Wenn Netzbergnge zwischen VPNs existieren, sind diese in der Dokumentation entsprechend
kenntlich zu machen und hervorzuheben.
4.9
Schutz des PE-Routers
Bezeichner:
M09
Lebenszyklus:
Umsetzung
Verantwortlich:
Provider
Erluterung:
Der PE-Router als Ingress- und Egress-LSR stellt den einzigen Netzknoten des MPLS-Netzes dar,
der aus Kunden-VPNs sichtbar sein darf und dessen kundenseitige IP-Adresse erreichbar sein darf.
Der PE-Router ist dadurch das Gert, das beim Schutz des MPLS-Netzes vor ueren Angriffen im
Mittelpunkt steht. Beeintrchtigungen und Strungen eines PE-Routers knnen sich auf alle VPNs
auswirken, die ber diesen PE an das MPLS-Netz angebunden sind.
Es sind deshalb geeignete Schutzmanahmen fr den PE-Router zu ergreifen. Diese Manahmen
mssen insbesondere verhindern, dass durch einen Angriff ber eine CE-PE-Verbindung die
Ressourcen des Systems so beansprucht werden, dass dies zum teilweisen oder vollstndigen
Denial-of-Service (DoS) fhren kann. Die Schutzmanahmen betreffen vor allem dynamische
Routing-Protokolle, die im Kunden-VPN genutzt werden, aber auch Management-Protokolle, wie
z. B. SNMP.
- Beschrnkung der mglichen BGP-Prefixe: Anderenfalls besteht die Gefahr, dass der
Systemspeicher des PE-Routers durch sehr viele zu verwaltende Routen bermig belegt wird.
- Begrenzung der Anzahl von Routing-Updates: PE-Router sollen Routing-Updates durch die CE-
Router (aus den Kunden-VPNs) nur in einem sinnvollen Intervall zulassen. Dies betrifft
beispielsweise die dynamischen Routing-Protokolle EIGRP (Enhanced Interior Gateway Routing
Protocol) oder OSPF (Open Shortest Path First).
- Einsatz von Zugriffskontrolllisten (Access Control Lists, ACLs), die einen unerlaubten Zugriff
auf den PE-Router ber CE-PE-Verbindungen unterbinden (z. B. Telnet oder SSH): Nur die
Ports fr die erlaubten Protokolle drfen von den CE-Systemen aus erreichbar sein.
- Die PE-Schnittstelle, die Bestandteil des Kunden-VPN ist, sollte mittels ACLs vor direkten
Zugriffen aus dem Kundennetz geschtzt werden. Die einzige bentigte IP-Verbindung zu dieser
Schnittstelle ist die zwischen PE und CE.
32
4.10 Verstecken der IP-Adresse des PE-Routers

Bezeichner:
M10
Lebenszyklus:
Umsetzung
Verantwortlich:
Provider, Kunde
Erluterung:
Das "Anpingen" der kundenseitigen IP-Adresse des PE-Routers ist konfigurationstechnisch zu
unterbinden (siehe M09). Die CE-Adresse sollte fr den Kunden dagegen erreichbar sein, damit er
seine Gateway-Verbindungen berprfen kann.
Bei erhhten Sicherheitsanforderungen besteht die Mglichkeit, durch Verwendung einer
unadressierten IP-Verbindung zwischen PE und CE (unnumbered IP) und durch Beschrnkung auf
statisches Routing auch die Kundenschnittstelle des PE-Routers zu verbergen. Dies trgt dazu bei,
dass mglichst wenige Informationen ber die logische Struktur des MPLS-Transportnetzes
innerhalb von Kunden-VPNs bekannt werden.
4.11 Internet-bergang als eigenes MPLS-VPN

Bezeichner:
M11
Lebenszyklus:
Planung
Verantwortlich:
Provider
Erluterung:
Im MPLS-Core kann fr Kunden ein bergang in das Internet bereitgestellt werden. Der bergang
kann in unterschiedlicher Art und Weise konfiguriert werden, insbesondere hinsichtlich des
Routings.
Die Routen des Internets sollten jedoch nicht in der globalen Routing-Tabelle innerhalb des MPLSCores vorgehalten werden. Dies wrde zu unntig groen, Ressourcen-aufbrauchenden RoutingTabellen des MPLS-Netzes fhren. berdies htten Angreifer aus dem Internet dadurch
vermeidbare Angriffsmglichkeiten (Routing-Updates, Route-Flooding).
Internet-Routen sollten daher innerhalb eines eigenen MPLS-VPN ber dedizierte VRF-Instanzen
auf den PE-Routern fr die Internet-Kunden vorgehalten werden. Diese PE-Router sollen
ausschlielich mit Internet-CEs verbunden sein. Andere Kunden-VPN-CEs sollen nicht direkt mit
dem Internet-PE verbunden werden.
Anmerkungen:
Die Realisierung des Internet-bergangs in einem eigenen VRF ist als "Best Practice"-Empfehlung
anzusehen.
4.12 Sichere Konfiguration von BGP

Bezeichner:
M12
Lebenszyklus:
Umsetzung
33
Verantwortlich:
Provider
Erluterung:
Das im Backbone verwendete BGP-Protokoll muss explizit geschtzt werden. Hierzu sind folgende
Hinweise zu beachten:
- Authentifizierung der BGP-Partner (Peer Authentication) mit Hilfe von kryptographischen
Methoden. Dadurch wird die Authentizitt und Integritt der Routing-Information geschtzt
(RFC 2385).
- "Route Flap Dampening": Routing-Updates werden durch diese Funktion fr eine bestimmte
Zeit von der Routing-Instanz ignoriert, um ein stndiges Neuberechnen und "Klappern" der
Routing-Tabellen zu vermeiden. Der Einsatz dieser Funktion ist jedoch genau abzuwgen. Nach
neuesten Studien bezglich des Einsatzes dieser Funktion sind die negativen Auswirkungen
grer als der Nutzen. Daher lautet die aktuelle Empfehlung des RIPE, das "Route Flap
Dampening" nicht einzusetzen.
- BGP-Peer-Pakete mit TTL-Werten ungleich 254/255 drfen nicht akzeptiert werden. Durch
diese Funktion knnen bestimmte entfernte Angriffsmuster (Injection, DoS, Reset) blockiert
werden. BGP-Peers mssen sich in diesem Punkt abstimmen und identische Konfigurationen
verwenden.
- Beschrnkung der BGP-Prefixe, um einen bermigen Verbrauch an Speicher durch BGP-
Updates zu vermeiden.
4.13 Etablierung von Schwellwert-Alarmen

Bezeichner:
M13
Lebenszyklus:
Umsetzung
Verantwortlich:
Provider
Erluterung:
Um bestimmte Angriffe oder Fehlkonfigurationen auf Routing-Ebene erkennen zu knnen, sollte
der Provider einen Schwellwert-Alarm fr die Anzahl der Routen innerhalb eines Kunden-VPNs
etablieren.
Anmerkungen:
Ein Router liefert die Anzahl der Routen auf Anfrage an die Management-Station, etwa via SNMP.
Die Schwellwerte werden auf den NMS definiert.
4.14 Anwendung von "Best Practice"-Empfehlungen fr die

Konfiguration der MPLS-Router
Bezeichner:
M14
Lebenszyklus:
Umsetzung
Verantwortlich:
Provider
Erluterung:
34
So genannte "Best Practice"-Empfehlungen fr IT-Systeme enthalten die zu einer Zeit sinnvollsten

Vorgehensweisen fr die Konfiguration oder den Einsatz dieser Produkte. Sie stammen von
Herstellern, Organisationen oder Beratungsfirmen. "Best Practice" ist kein Standard und stellt
lediglich eine unverbindliche Empfehlung dar, die jeweils kritisch zu hinterfragen und zu prfen ist.
Als Beispiel fr eine Best-Practice-Empfehlung sei hier die Verwendung von Zugriffskontrolllisten
(Access Control Lists, ACL) fr die Limitierung des Zugriffs auf Management-IP-Adressen der
Backbone-Router genannt. Als "Best-Practice" gilt auerdem die gegenseitige Authentifizierung der
BGP-Partner (Peer Authentication) mit Hilfe von kryptographischen Methoden. Dies ist in RFC
2385 auch definiert.
4.15 Redundanz zum Schutz der Verfgbarkeit in MPLS-Netzen

Bezeichner:
M15
Lebenszyklus:
Notfallvorsorge
Verantwortlich:
Provider
Erluterung:
Der Ausfall oder der Teilausfall des MPLS-Provider-Netzes kann fr Kunden-VPN erhebliche
Auswirkungen haben. Mittels redundanter Netzarchitekturen soll je nach Verfgbarkeitsbedarf eine
Ausfallsicherung erreicht werden.
- CE-Router: An wichtigen Standorten sollten zwei CE-Router verwendet werden, die z. B. in
unterschiedlichen Brandabschnitten betrieben werden (Hardware-Redundanz).

- Gedoppelte PE-Router am Point-of-Presence (PoP): An wichtigen PoPs sollten Provider ber
gedoppelte PE-Router verfgen. Diese sollen in verschiedenen Brandabschnitten stehen. Ein

Kundenstandort kann Redundanz durch die parallele Anbindung an beide PEs erzielen. Dieses
Szenario lsst wahlweise ein Cold- oder Hot-Standby zu.
- Redundante Architekturen sollten vom Kunden je nach Verfgbarkeitsanforderungen eingeplant
werden.
- Getrennte Leitungsfhrung: Die Leitungsstrecken zwischen CE(s) und PE(s) sollten mehrfach
existieren. Der Ausgang der Leitungen aus dem Kundenstandort erfolgt ber unabhngige
Hausanschlsse. Die Leitungen vom Kundenstandort zur Vermittlungsstelle werden ber
getrennte Wege realisiert. So lsst sich das Risiko eines Ausfalls durch Leitungsversagen (gezielt
oder unbeabsichtigt) begrenzen.
- Anbindung an zwei MPLS-Provider: Durch die Anbindung an zwei voneinander unabhngige
Autonome Systeme (AS) kann der Kunde erhhte Ausfallsicherheit erzielen. Dieses Szenario ist
jedoch als teuer und hinsichtlich des Routings als schwierig anzusehen.
- Backup: Durch Nutzung einer zustzlichen Backup-Lsung kann das Ausfallrisiko minimiert
werden. Denkbar ist das Backup ber andere Transportplattformen wie DSL, ISDN, GPRS,
UMTS oder EDGE.
- Redundante P-Router: Die Core-Router im Carrier-Netz mssen redundant ausgelegt sein, damit
der Ausfall eines P-Routers kompensiert werden kann. Auerdem mssen die Router im MPLSCore ber unabhngige Leitungen redundant miteinander verbunden sein.
- Das unter dem MPLS-Netz liegende SONET/SDH-Netz soll ber zwei voneinander unabhngige
Ringe verfgen. Das ist der Regelfall.

35
- Der Provider sollte ber mindestens zwei voneinander unabhngige bergnge zum Internet
verfgen, falls Internet-Zugang zum geforderten Leistungsumfang gehrt.

- Anbindung des Provider-Netzes an mehrere Autonome Systeme (AS) anderer MPLS-Carrier:
Durch diese Manahme soll das Ausfallrisiko eines "Carriers Carrier"-bergangs oder "InterAS"-Gateways minimiert werden.
Anmerkungen:
Redundanz wird zudem in hohem Mae innerhalb der Netzinfrastruktur der Provider gewhrleistet.
4.16 Nutzung einer dedizierten MPLS-Infrastruktur

Bezeichner:
M16
Lebenszyklus:
Planung
Verantwortlich:
Provider, Kunde
Erluterung:
Bei der Nutzung einer dedizierten MPLS-Infrastruktur durch nur einen Kunden werden
ausschlielich dessen Pakete ber das MPLS-Netz transportiert. Ein dediziertes Kunden-MPLSNetz wrde parallel zum existierenden Providernetz errichtet werden mssen. Es mssten demnach
die notwendigen PE-, CE- und P-Router installiert und ber Leitungen vermascht werden.
Anmerkungen:
Diese Manahme ist mit hohen Kosten verbunden.
4.17 Programmieren und Einspielen von Software-Patches

Bezeichner:
M17
Lebenszyklus:
Betrieb
Verantwortlich:
Erluterung:
Im Laufe des Lebenszyklus einer Firmware-Version fr Netzkomponenten werden hufig
Sicherheitslcken bekannt. Diese Schwachstellen werden vom Hersteller selbst, von den ServiceProvidern whrend des Betriebs der Komponenten oder von Dritten erkannt. Wird eine in der
Firmware vorhandene Schwachstelle entdeckt, muss der Hersteller einen Software-Patch
programmieren, der das Problem behebt. Dieser Prozess muss beim Hersteller nachweisbar
existieren.
Service-Provider mssen sicherheitsrelevante Software-Patches zeitnah einspielen. Dabei ist die ITGrundschutz-Manahme M 4.65 "Test neuer Hard- und Software" zu bercksichtigen.
4.18 Nutzung von IPSec-Tunneln ber MPLS-Verbindungen

Bezeichner:
M18
Lebenszyklus:
Planung
36
Verantwortlich:
Provider, Leiter IT, IT-Sicherheitsbeauftragter, Router-Administrator
Erluterung:
Durch den Einsatz von verschlsselten Tunneltechnologien, wie IPSec, TLS/SSL oder SSH, kann
ein Kunde die Integritt und Vertraulichkeit seines VPNs absichern.
Die Nutzung von Site-to-Site-Verschlsselung, beispielsweise mit Hilfe von IPSec, ermglicht es
dem Kunden, die Vertraulichkeit der ber das MPLS-Netz bertragenen Daten gegenber
potentiellen Angreifern in der Man-in-the-Middle-Position zu schtzen. Die IPSec-Tunnel werden
blicherweise zwischen CE und CE zweier Kundenstandorte aufgebaut. Alternativ knnen zu
diesem Zweck auch nachgelagerte Sicherheitsgateways oder VPN-Konzentratoren genutzt werden,
die unter der alleinigen Kontrolle des Kunden liegen. Auf diese Weise kann ein erhhter Schutz vor
mglichen Angriffen des Providerpersonals erreicht werden.
Beispielsweise mittels Access Control Lists (ACL) oder Firewall-Regeln kann auerdem dafr
gesorgt werden, dass ausschlielich IPSec-Datenpakete vom IPSec-Endpunkt (CE, VPNKonzentrator oder Sicherheitsgateway) akzeptiert werden.
Der IT-Grundschutz-Baustein B 4.4 "VPN" ist zu beachten.
Anmerkungen:
Der Einsatz von verschlsselten Tunneltechnologien, wie z. B. IPSec oder auch TLS/SSL, stellt die
wirksamste Manahme zur Gewhrleistung von Integritt und Vertraulichkeit in Kunden-VPNs
gegenber Providern dar. Der Einsatz solcher Verfahren ist in jedem Fall anzuraten.
4.19 MPLS-Core ohne Internet-Konnektivitt

Bezeichner:
M19
Lebenszyklus:
Planung
Verantwortlich:
Provider, Kunde
Erluterung:
In diesem Szenario existiert kein bergang aus dem MPLS-Core-Netz in das Internet. InternetVerbindungen werden, falls bentigt, ber alternative ISPs aus den Kundennetzen heraus realisiert.
4.20 Verbindungstest nach Anbinden eines VPN-Standorts

Bezeichner:
M20
Lebenszyklus:
Betrieb
Verantwortlich:
Provider, Kunde
Erluterung:
Beim Anbinden eines neuen VPN-Standorts kann es passieren, dass dieser durch einen
Konfigurationsfehler einem falschen Kunden-VPN zugeordnet wird. In der Folge htte dieser
Standort unautorisiert ber seinen CE die volle Konnektivitt in ein fremdes VPN. Aus diesem
Grund ist nach der Anbindung neuer Standorte ein Verbindungstest im Zusammenspiel zwischen
den Kunden und dem Provider durchzufhren, um zu verifizieren, dass der Standort dem richtigen
VPN zugeordnet worden ist.
37
4.21 Erstellen eines Label-Konzepts

Bezeichner:
M21
Lebenszyklus:
Planung
Verantwortlich:
Provider
Erluterung:
Der Provider muss die Vergabe der MPLS-Label an Kunden planen und dokumentieren. In der
Netzdokumentation muss das Label-Konzept inklusive Service-Zuordnung (z. B. VoIP, Daten)
wiedergegeben werden. Wichtige Parameter, wie VRF-Bezeichnung und Route Distinguisher (RD),
mssen ebenfalls in die Dokumentation aufgenommen werden.
4.22 Auswahl geeigneter Netzkomponenten

Bezeichner:
M22
Lebenszyklus:
Planung
Verantwortlich:
Provider
Erluterung:
Der Provider hat durch seine Produkt- und Herstellerauswahl sicherzustellen, dass ausschlielich
geeignete Netzkomponeten zum Einsatz kommen. Der Provider muss Support-Vertrge mit den
betreffenden Herstellern abschlieen oder abgeschlossen haben. Dabei sind auch die Hinweise im
IT-Grundschutz-Baustein B 3.302 "Router und Switches" zu beachten.
4.23 Konzeption des MPLS-Netzes

Bezeichner:
M23
Lebenszyklus:
Planung
Verantwortlich:
Provider, Kunde
Erluterung:
Die Konzeption eines MPLS-Netzes erfordert eine genaue Planung durch den Kunden. Der Ausfall
oder Teilausfall eines Netzes oder bestimmter Dienste soll durch ein gut durchdachtes Netzdesign
mglichst unwahrscheinlich gemacht werden.
Zur Planung gehrt eine genaue Analyse der Anwendungen (VoIP, E-Mail, Video, Web) und der
bentigten Service-Klassen (QoS) fr Dienste und Standorte (Netzschicht 4-7).
Davon abgeleitet muss das MPLS-Netzdesign gewhlt werden, z. B. Hub-and-Spoke (Sternnetz)
oder Any-to-Any (Vollvermaschung). Weiterhin muss der Verlauf der LSPs festgelegt werden
(Netzschicht 2-3).
Anhand von Verfgbarkeitsanforderungen fr einzelne Standorte und Dienste lassen sich die
notwendigen Redundanzen festlegen, z. B. Einfachanbindung, Doppelanbindung ber zwei CERouter, Anbindung an zwei verschiedene PoPs (Netzschicht 1-3).
38
4.24 Rollout-Konzept
Bezeichner:
M24
Lebenszyklus:
Planung
Verantwortlich:
Provider
Erluterung:
Der Provider muss ber einen definierten Prozess fr ein Kundennetz-Rollout und fr die
Anbindung neuer Kundenstandorte verfgen. Dazu gehrt die Vorbereitung der Konfiguration, die
Installation der bentigten Software-Releases und das Einspielen der Konfiguration,
mglicherweise in Abstimmung mit dem Kunden und internationalen MPLS-Providern.
39
Restrisiken
Restrisiken
Grundstzlich bringen MPLS-VPNs eine Reihe von Sicherheitsmechanismen mit, durch die sich
bereits eine gute Basis-Sicherheit erreichen lsst. Als Hauptbedrohungen sind anzusehen:
- Angriffe gegen die Verfgbarkeit aus VPNs, aus dem Internet und aus dem Core
- Angriffe gegen die Vertraulichkeit und Integritt aus dem Core
Durch Anwendung der empfohlenen Schutzmanahmen lassen sich die Risiken noch einmal
deutlich reduzieren. Insbesondere der Einsatz verschlsselter Tunneltechnologien, wie IPSec, TLS/
SSL oder SSH, sei hier noch einmal hervorgehoben, weil diese einen hohen Schutz gegen Man-inthe-Middle-Angriffe bieten und unter alleiniger Kontrolle des Kunden stehen knnen.
Nach Anwendung aller Schutzmanahmen verbleiben vor allem die folgenden Risiken:
- Netzausflle durch Sabotage (Angriffe auf die Netzinfrastruktur durch Innen- oder Auentter)
- Ausflle durch Fehlkonfigurationen oder Software-Fehler
- DoS-Angriffe durch Providerpersonal auf einzelne VPN oder auf das gesamte MPLS-Netz
Auch fr die Technologie MPLS gilt, dass sich keine 100%ige Sicherheit erreichen lsst.
40
Ausblick und zuknftige Bedrohungen
Ausblick und zuknftige Bedrohungen
6.1
Next Generation Networks (NGN)
Der parallele Betrieb mehrerer Netzplattformen ist fr die Netzanbieter teuer und aufwndig. Im
Zuge der Modernisierung ihrer Infrastruktur favorisieren die meisten Provider die ausschlieliche
Nutzung nur noch einer IP-Plattform fr alle Anwendungen. Die Planungen und die Umsetzung
dieser so genannten "Next-Generation-Networks" (NGN) sehen den Transport aller Dienste, wie
z. B. Telefonie und Datenanwendungen, ber ein MPLS-Netz vor. Daraus resultieren erhhte
Ansprche an die Qualitt und Verfgbarkeit der Providernetze, insbesondere fr VoiceAnwendungen, bei gleichzeitig immer weiter steigenden Kapazittsanforderungen an die
Transportnetze. Auerdem werden alle Kunden bei einem Ausfall eines Providernetzes in viel
strkerem Mae betroffen sein, als das heute der Fall ist. Damit steigt auch die Attraktivitt eines
NGN als Angriffsziel, insbesondere hinsichtlich DoS-Angriffen.
Herausforderung fr die Service-Provider in der Zukunft wird sein, die NGNs leistungsfhig,
qualitativ hochwertig und mit hinreichenden Redundanzen ausgestattet auszubauen. Bei dem
anzunehmenden gleichbleibenden Kostendruck durch die Konkurrenz der Mitbewerber stellt das fr
die Provider eine anspruchsvolle Aufgabe dar. Dabei drfen Sicherheitsaspekte nicht auer acht
gelassen werden, sondern es mssen angemessene und ausreichende Manahmen ergriffen werden,
um der gestiegenen Bedeutung der NGNs in dieser Hinsicht gerecht zu werden.
6.2
Generalized Multi-Protocol Label Switching (GMPLS)
Die derzeitige Planung und Umsetzung der "Next Generation Networks" oder "Triple Play
Networks" sieht hochverfgbare und flexibel nutzbare Bandbreite vor. Generalized Multi-Protocol
Label Switching (GMPLS) untersttzt eine automatische Signalisierung optischer Pfade bei der
Einrichtung von MPLS-LSPs. GMPLS schafft damit eine Schnittstelle zwischen MPLS und der
optischen bertragungs-Infrastruktur, wie z. B. DWDM.
Der Einsatz von GMPLS verspricht also eine groe Flexibilisierung bei der Einrichtung neuer
Verbindungen. Fr MPLS-Provider ist GMPLS sehr interessant, weil der betriebliche Aufwand und
damit die Einrichtungs- und Wartungskosten fr ein Kundennetz nachhaltig gesenkt werden
knnen. Die GMPLS-Architektur ist in RFC 3945 beschrieben.
Die Einfhrung und Nutzung von GMPLS bringt fr die Provider erhhte Anforderungen an die
Netzkonzeption und Planung mit sich. Gleichzeitig steigt die Gefahr von Schwankungen und
Inkonsistenzen im Netz durch permanente Neukonfigurationen der LSPs und der darunter
angesiedelten Kanle der WDM-Technik. Welche neuen Angriffsszenarien diese Entwicklung mit
sich bringt, kann heute noch nicht abschlieend beurteilt werden.
41
M03
M04
M05
M06
X
X
M07
M08
X
X
M09
M10
X
X
M11
M12
M13
M14
M15
M16
M17
M18
M20
M21
X
X
M23
M24
M19
M22
G.Ausfall
G.RouteDoS
M02
G.BGPDoS
G.PEDoS
G.DatenMix
G.FehlCEIAS
G.WWWDoS
M01
G.FehlCE
Gefhrdungen
/
Manahmen
G.PakInjIntAS
Kreuzreferenz-Tabelle
G.PakInjCore
7.1
G.PakInjVPN
Anhang
G.PakAus
G.Sichtbar
Anhang
X
X
Tabelle 4: Kreuzreferenzen - Spezifische Sicherheitsmanahmen fr MPLS
42
Anhang
7.2
Abkrzungsverzeichnis
ACL:
Access Control List
AS:
Autonomous System
ASBR:
Autonomous System Border Router
ATM:
Asynchronous Transfer Mode
BGP:
Border Gateway Protocol
BSI:
CBWFQ:
Class-Based Weighted Fair Queuing
CE:
Customer Edge router
CERT:
Computer Emergency Response Team
CIR:
Committed Information Rate
CMMI:
Capability Maturity Model Integration
CoS:
Class of Service
CPE:
Customer Premises Equipment
DDV:
Datendirektverbindung
DLCI:
Data Link Connection Identifier (Frame Relay)
DoS:
Denial of Service
DSCP:
Differentiated Services Code Point (DiffServ)
DSL:
Digital Subscriber Line
DWDM:
Dense Wavelength Division Multiplexing
EDGE:
Enhanced Data rates for GSM Evolution
EIGRP:
Enhanced Interior Gateway Routing Protocol
EXP:
Experimental
FR:
Frame Relay
GMPLS:
Generalized Multi-Protocol Label Switching
GPRS:
General Packet Radio Service
GRE:
Generic Routing Encapsulation
ICMP:
Internet Control Message Protocol
IETF:
Internet Engineering Task Force
IGP:
Interior Gateway Protocol
IOS:
Internetwork Operating System (Cisco)
IP:
Internet Protocol
IPSec:
Internet Protocol Security
43
Anhang
IPv4:
Internet Protocol version 4
IPv6:
Internet Protocol version 6
ISDN:
Integrated Services Digital Network
ISP:
Internet Service Provider
IT:
Informationstechnik
IVBB:
Informationsverbund Berlin-Bonn
L2TP:
Layer 2 Tunneling Protocol
LAN:
Local Area Network
LDP:
Label Distribution Protocol
LLQ:
Low-Latency Queuing
LSP:
Label Switched Path
LSR:
Label Switch Router
MIB:
Management Information Base
MPLS:
Multi-Protocol Label Switching
NGN:
Next Generation Network
NMS:
Netzmanagementsystem
OSI:
Open Systems Interconnection
OSPF:
Open Shortest Path First (Routing-Protokoll)
P:
Provider router
PE:
Provider Edge router
PoP:
Point of Presence
QoS:
Quality of Service
RD:
Route Distinguisher
RFC:
Request For Comments
RIPE:
Rseaux IP Europens
SFV:
Standardfestverbindung
SLA:
Service Level Agreement
SNMP:
Simple Network Management Protocol
SONET / SDH: Synchronous Optical Network / Synchrone Digitale Hierarchie

SP:
Service Provider
SSH:
Secure Shell
SSL:
Secure Sockets Layer
SG:
Sicherheitsberprfungsgesetz
TCP:
Transmission Control Protocol
44
Anhang
TLS:
Transport Layer Security
TTL:
Time to Live
UMTS:
Universal Mobile Telecommunications System
VoIP:
Voice over IP
VPI / VCI:
Virtual Path Identifier / Virtual Channel Identifier (ATM)
VPN:
Virtual Private Network
VRF:
VPN Routing / Forwarding
VS:
Verschlusssache
WDM:
Wavelength Division Multiplexing
7.3
Referenzen
[1]
RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option,
Internet Engineering Task Force (IETF, www.ietf.org), August 1998,
http://www.rfc-editor.org/rfc/rfc2385.txt
[2]
RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs), Internet

Engineering Task Force (IETF, www.ietf.org), February 2006,
http://www.rfc-editor.org/rfc/rfc4364.txt
[3]
Sicherheitseigenschaften von Standleitungstechnologien, BSI, 2007,

https://www.bsi.bund.de
[4]
Deutsche Telekom's Global MPLS-VPNs Deployment and QoS enabled Networks

Design and Implementation, Deutsche Telekom AG, 2001
[5]
Analysis of MPLS-Based IP VPN Security: Comparison to Traditional L2VPNs

Such as ATM and Frame Relay, and Deployment Guidelines, Cisco Systems,
2001, http://www.cisco.com/warp/public/cc/so/neso/vpn/prodlit/mpvpn_wp.pdf
[6]
Security of the MPLS Architecture, Cisco Systems, 2001,

http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/mxinf_ds.pdf
[7]
Sicherheitsrichtlinien fr den Betrieb von Cisco-Routern bei T-Systems, 2004
[8]
BGP and MPLS Configuration Guide, Juniper Networks, 2008,

http://www.juniper.net/techpubs/software/erx/junose90/bookpdfs/swconfig-bgpmpls.pdf
[9]
MPLS Security, Prsentation von Cisco Systems, 2004
[10]
MPLS VPN Security, M. Behringer and M. Morrow, Cisco Press, 2005,

ISBN 1-58705-183-4
[11]
Advanced Topics in MPLS-TE Deployment, Cisco Systems, 2002,

http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/mwglp_wp.pdf
[12]
BSI-Standards zur Informationssicherheit, BSI, 2008, http://www.bsi.bund.de
[13]
IT-Grundschutz-Kataloge Standard-Sicherheitsmanahmen, BSI, jhrlich neu,

https://www.bsi.bund.de
45

Kurzstudie MPLS

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Kurzstudie MPLS

Diunggah oleh

Hak Cipta:

Format Tersedia

Kurzstudie zu Gefhrdungen und Manahmen beim Einsatz von

Bundesamt fr Sicherheit in der Informationstechnik

Bundesamt fr Sicherheit in der Informationstechnik

Grundlagen der MPLS-Technik..................................................................................................8

Gefhrdungen bei der Nutzung von MPLS-Infrastrukturen.....................................................19

MPLS-Core ohne Internet-Konnektivitt.........................................................................................37

Ausblick und zuknftige Bedrohungen.....................................................................................41

Next Generation Networks (NGN)..................................................................................................41

Bundesamt fr Sicherheit in der Informationstechnik

ressourcenschonender, weil im MPLS-Backbone auf Routing-Entscheidungen verzichtet werden

Bundesamt fr Sicherheit in der Informationstechnik

Grundlagen der MPLS-Technik

Grundlagen der MPLS-Technik

- OSI-Schicht 2-3: MPLS

ATM, FR, Ethernet

3-7 angesiedelten Protokolle:

Bundesamt fr Sicherheit in der Informationstechnik

Grundlagen der MPLS-Technik

Begriff im RFC 4364

Provider oder Netz-Dienstleister, der Kunden

Kunde, der Transportleistungen ber das MPLS-Netz des

Transportnetz, Core oder Backbone, ber das die Kunden ihre

Bundesamt fr Sicherheit in der Informationstechnik

Grundlagen der MPLS-Technik

Begriff im RFC 4364

customer edge router

Der CE bietet die Anschluss-Schnittstelle fr die Kunden und

provider edge router

Der PE bindet die CE an den MPLS-Core an. An einem PE

Netzknoten innerhalb des MPLS-Core. Das sind alle

Bundesamt fr Sicherheit in der Informationstechnik

Grundlagen der MPLS-Technik

Bundesamt fr Sicherheit in der Informationstechnik

Grundlagen der MPLS-Technik

Abbildung 4: Die PE-Systeme knnen mit CE verschiedener Kundennetze verbunden sein.

Bundesamt fr Sicherheit in der Informationstechnik

Grundlagen der MPLS-Technik

Jeder virtuelle Router ist gekennzeichnet durch:

Grundlagen der MPLS-Technik

- Eine aus der Routing-Tabelle abgeleitete Forwarding-Tabelle,

Bundesamt fr Sicherheit in der Informationstechnik

Grundlagen der MPLS-Technik

In Abbildung 7 ist die MPLS-Architektur schematisch dargestellt.

Abbildung 7: Schematische Darstellung eines MPLS-Netzes

blicherweise werden alle in Abbildung 7 dargestellten Netzkomponenten vom Provider betrieben.

Bundesamt fr Sicherheit in der Informationstechnik

Grundlagen der MPLS-Technik

Abbildung 8: Abgrenzung der Verantwortungsbereiche zwischen Kunde und Provider

Am so genannten Service Access Point verlassen Datenpakete den Verantwortungsbereich des

Committed Information Rate (CIR) bei FR) und

Bundesamt fr Sicherheit in der Informationstechnik

Grundlagen der MPLS-Technik

niedriger Prioritt (Internet, E-Mail) werden im Vergleich zu VoIP oder Video-Anwendungen

Grundlagen der MPLS-Technik

einzelnen Kundennetze werden in separierten VRF-Instanzen ("VPN Routing / Forwarding")

VRF der PE.

kundenspezifischen VPN-Label versehen.

ber den die Netzoperatoren ihre Netze verwalten.

Bundesamt fr Sicherheit in der Informationstechnik

Gefhrdungen bei der Nutzung von MPLS-Infrastrukturen

Gefhrdungen bei der Nutzung von MPLSInfrastrukturen

Die allgemeinen Gefhrdungen fr die sichere Datenbertragung in MPLS-Netzen entsprechen den

Beschreibung der Gefhrdung