Remote Access VPN und IPSec.

Transkript

1 Remote Access VPN und IPSec. IPSec gilt heute als absoluter Standard und das für jede Netzwerktopologie einsetzbare VPN-Protokoll. Der aktuelle Wissensstand hat jedoch einige seiner ursprünglichen Initiatoren gezwungen, proprietäre Derivate zu implementieren, um einige Schwächen von IPSec zu überwinden. Insbesondere die Abbildung von Direkteinwahl-Remote Access-Netzen auf ein IPSec-VPN hat sich als sehr schwer beziehungsweise umständlich erwiesen. Grundlagen Ein Virtual Private Network (VPN) ist die Realisierung eines privaten Netzes über ein öffentliches Netz wie das Internet. Im Internet wird grundsätzlich das IP- Netzwerkprotokoll (Internet Protocol) benutzt, um Daten von einem Rechner zu einem anderen zu leiten. Jedes Datenpaket wird mit einem IP-Header versehen, der die eigene Adresse und die Zieladresse beinhaltet(ip Adressen). Netzwerkprotokolle wie IP sind auf Ebene 3 (Layer 3) in dem OSI-Schichtenmodell definiert. Ein Layer-3-Protokoll wie IP benötigt jedoch einen Layer 2 (und Layer 1), um die Datenpakete bis zum nächsten Vermittlungsrechner (Router) zu übertragen. Layer 2 und Layer 1 können wie ein LAN verbindungslos sein - sie werden in diesem Fall durch eine LAN -Karte dargestellt - oder eben verbindungsorientiert. In diesem Fall erfolgt die Einwahl beispielsweise via ISDN über das DFÜ-Netz zum NAS (Network Access Server) eines Providers. Nach Aufbau der ISDN-Verbindung (B-Kanal) wird das Layer-2-Protokoll PPP (Point-to-Point-Protokoll) verhandelt, erst danach kann der Rechner IP-Pakete zum Provider übermitteln. Während einer PPP- Session werden bestimmte Attribute wie die öffentliche IP-Adresse, DNS-Server und WINS-Server zwischen NAS und dem entfernten Rechner ausgetauscht. Die IP- Adresse behält der Remote Client nur so lange wie die PPP-Verbindung steht. Eine Layer-2PPP-Verbindung ist multiprotokollfähig, d.h. es können neben IP auch andere Protokolle wie beispielsweise IPX und ATLK übermittelt werden. Des Weiteren beinhaltet eine PPP-Verhandlung sicherheitsspezifischen Abläufe wie Authentifizierung mit Benutzername/Password (PAP/CHAP) und einfache Verschlüsselung (Encryption Control Protocol ECP) sowie weitere Features wie Datenkompression (Compression Control Protocol CCP) und Rückruf (Link Control Protocol LCP). Ein weiteres Beispielscenario für den Einsatz von PPP ist die Anbindung einer Filiale (LAN) an das Internet und der Zugriff von beliebigen Arbeitsplatz-PCs auf das zentrale Datennetz. Hierfür baut der in der Filiale installierte IP- Router für den Versand seiner IP-Pakete eine ISDN-Verbindung zum nächsten NAS auf, über diese anschließend alle PPP-Verhandlungen erfolgen. Der Router erhält vom NAS eine öffentliche IP-Adresse (die einzige, die im Internet zu vermitteln ist). Der Knackpunkt ist nun der: die Rechner im LAN besitzen jeweils eine abweichende - private - IP-Adresse Bei jedem von einemlan-rechner erzeugten Datenpaket wird 1

2 vom Router die private Quell-IP-Adresse gegen die öffentliche IP-Adresse ausgetauscht. Das Ergebnis: Alle LAN-Rechner erscheinen im Internet ausschließlich mit der öffentlichen IP-Adresse. Dieser Vorgang wird IP-NAT (IP- Network-Address-Translation) oder auch Maskieren genannt. Das Verfahren bietet somit gleichzeitig Schutz gegen unerwünschte Verbindungen vom Internet in s LAN. Remote Access VPN Ein RemoteAccess-VPN ist die Abbildung eines traditionellen Direkteinwahl Remote-Access-Netzes über ein öffentliches IP-Netz. Unternehmen, die ein solches VPN planen, stellen an dieses 1:1 die gleichen Anforderungen wie beim direkten Zugriff auf die Unternehmenszentrale. Im wesentlichen geht es um diue Erfüllung folgender Punkte: starke und persönliche Authentisierung jedes einzelnen -Users, Unterstützung verschiedener Authentisierungsmethoden wie PKI, X.509.v3- Zertifikate, Zertifkate auf Smartcards, User-ID/Password (Radius),SecureID oder OTP (One Time Password), starke Verschlüsselung, sicherer Schlüsselaustausch, überschaubare Konfiguration und Administration der VPN-Clients und der dazu gehörenden Sicherheits-Policy, keine Topologie-Einschränkungen sowie Multiprotokollfähigkeit beim Einsatz unterschiedlicher Netzwerkprotokolle. Tunneling-Verfahren Grundlage von Layer-2- und Layer-3-VPNs ist das Tunneling. Dieses Verfahren ist notwendig für den Transport der Daten zwischen einem zentrale VPN-Gateway und Remote VPN-Client über ein öffentliches, unsicheres Netz. Etabliert wird ein Tunnel dadurch, dass jedem erzeugten Datenpaket ein extra IP-Header und ein oder mehrere - je nach eingesetztem Tunneling-Verfahren - spezifische Header vorangestellt werden. Der Tunnel beginnt da, wo der extra IP-Header hinzugefügt wird und endet wo der IP-Header wieder entfernt wird. Da Authentisierung und Verschlüsselung komplett innerhalb des Tunnels ablaufen, spielen die Tunnelendpunkte eine sehr wichtige Rolle. Abhängig vom Tunnelendpunkt spricht man von Site-to-Site-VPN, End-to-Site-VPN und End-to-End-VPN. Ein Beispiel für Site-to-Site-VPN ist ein Tunnel zwischen einem Filial-Router und einem VPN- Gateway in der Zentrale. Bei einem End-to-Site-VPN wird entweder ein Tunnel zwischen einem Einzelplatz-PC und einem VPN-Gateway oder einem Client in einem Filialnetz und dem zentralen VPN-Gateway aufgebaut. Dabei ist es nicht erforderlich, dass der Filial-Router VPN-fähig ist. Das End-to-End-VPN funktioniert im Grunde genauso wie ein End-to-Site-VPN, nur dass das VPN Gateway im Applilationsserver integriert ist. Dadurch ist die gesamte Stecke vom Client-PC bis zur zentralen Applikation gesichert. Unternehmen gehen zunehmend dazu über, die 2

3 Tunnel nicht im Filialrouter enden zu lassen, sondern in den einzelnen LAN- Workstations. Die Vorteileliegen auf der Hand: Eine persönliche Authentisierung der Teilnehmer und eine Verschlüsselung der Unternehmensdaten im Filialnetz, Am Remote Access-Markt zeichnet sich daher zunehmend eine Entwicklung weg von Site-to-Site- hin zu End-to-Site-VPNs ab. Layer 2 VPN Zu den bekanntesten Layer-2-Verfahren gehören L2F (Layer-2- Forwarding), L2TP (Layer-2-Tunneling-Protocol) und PPTP (Point-to-Point-Tunneling-Protocol). Ein Layer-2-Tunnel stellt ein virtuelles Kabel über jede IP-Plattform dar und lässt sich über jede IP-Struktur hinweg aufbauen. Dabei ist es unerheblich, ob die installierten Router zwischen Client und VPN-Gateway IP-NAT einsetzen,. Wie eingangs beschrieben ist ein Layer-2-Tunnel multiprotokollfähig. Folglich besteht bei einem Layer-2 VPN die Möglichkeit, über ein öffentliches Netz, das nur IP vermittelt, mit der Unternehmenszentrale über beliebige Netzwerkprotokolle zu kommunizieren. Der Tunnelaufbau bei einem Layer-2-VPN wird realisiert durch einen extra IP- Header, einen UDP- (User Datagramm Protocol) oder TCP-Header (Transport Control Protocol) und einen Tunnel-Verfahren-spezifischen Header. Der Overheader pro Paket ist dabei abhäng vom eingesetzten Verfahren und liegt bei ungefähr 40 Bytes. Wie hervorragend die Eigenschafften der Layer-2-Tunneling-Verfahren für Remote Access auch sind, ein Nachteil ist, dass sie nur zum Teil Datenintegrität und eine relativ schwache Authentisierung (CHAP/PAP-) gewährleisten.weiter fehlen wesentliche Sicherheitsfunktionen, wie: Verschlüsselung, Unterstützung von digitalen Zertifikaten und ein leistungsfähiges Schlüsselmanagement.. Eine Möglichkeit, Security-Mechanismen und Layer-2-VPN-Tunneling zu vereinen, bietet sich mit der Erweiterung des Point-to-Point-Protokolls. Man unterscheidet hier zwei Ansätze: 1. Erweiterung der PPP-Authentication-Phase (PAP/CHAP). 2. Erweiterung des PPP Encryption-Control-Protocols (ECP). In beiden Fällen wird für die Erweiterung das SSL (Secure-Socket-Layer) v3.0 Handshake-Protokoll eingesetzt. Dieses Verfahren ist in dem von Microsoft eingereichten Experimental RFC 2716 (PPP EAP TLS Authentication Protocol) beschrieben. Es unterstützt die Anwendung von Zertifikaten, d.h. starke Authentisierung und sicherer Schlüsselaustausch sind möglich - das VPN ist somit PKI enabled (Public Key Infrastructure). Nach Ablauf der SSL-Verhandlung wird alles verschlüsselt was über die PPP-Verbindung läuft: die Netzwerkprotokolle IP/IPX und auch der letzte Teil der PPP-Verhandlung, wo die Zuweisung der privaten IP-Adresse, DNS- und/oder WINS-Server an den Client erfolgt. 3

4 Layer-2-Tunneling mit den oben beschriebenen Sicherheitsmechanismen ermöglicht den Aufbau eines Remote Access VPN, das jede Infrastruktur unterstüzt. Bereits vorhandene Netzwerkkomponenten können problemlos genutzt werden. Es ist unerheblich, ob ein Client den Tunnel über einen Provider, einen Branch Office- Router (der sich zum Provider einwählt), einen NAS in der Zentrale oder direkt zum VPN-Gateway in der Firmenzentrale aufbaut. Der Remote-User erhält für die PPP- Session immer dieselben Attribute: IP-Adresse, Datenkompression, DNS-Adresse usw.. Layer 3 VPN- IPSec Ein Layer-3-VPN ist nicht multiprotokollfähig, sondern bezieht sich immer auf ein bestimmtes Netzwerkprotokoll im Falle von IPSec ist das Netzwerkprotokoll IP. Mit den IPSec RFCs ( ) lässt sich ein VPN mit vorgegebener Security für das IP-Protokoll realisieren. Es steht ein komplettes Rahmenwerk zur Verfügung, das sowohl (Layer 3-) Tunneling als auch alle notwendigen Sicherheitsmechanismen wie starke Authentisierung, Schlüsselaustausch und Verschlüsselung umfasst. Das Ziel dieses VPN-Standards ist dessen Herstellerunabhängigkeit. Funktionsbeschreibung: Jede Kommunikationskomponente, die IPSec unterstüzt, verfügt über ein IPSec- Modul. Mit Hilfe dieses Modul wird jedes Datenpaket gegenüber einer Security- Policy-Database (SPD) entsprechend überprüft. Die SPD besteht aus Einträgen (SPD-Entries), in denen u.a. die Securitymerkmale beschrieben sind. Die SPD- Entries beinhalten einen zusätzlichen Filterteil (Selector). Der Selector setzt sich aus IP-Adressen, UDP- und TCP-Ports sowie IP-Header-spezifischen Einträgen zusammen. Stimmt nun ein Datenpaket mit dem Selector eines SPD-Eintrags überein, wird die weitere Vorgehensweise überprüft. Je nach Ergebnis wird das Paket entweder durchgelassen (permit), weggeworfen (deny) oder es werden bestimmte Securitymerkmale appliziert (IPSec-Processing). Nach Übereinstimmung eines Datenpaketes mit einem SPD-Eintrag wird überprüft, ob bereits eine Security Association (SA) für diesen SPD-Eintrag existiert. Die SA bestimmt, ob das Security-Protokoll ESP (Encapsulating Security Payload) oder AH (Authentication Header) verwendet werden soll. ESP unterstützt die Verschlüsselung und Authentisierung des IP-Paketes, AH ermöglicht nur die Authentisierung. Eine weitere Aufgabe der SA ist, den Modus des Security-Protokolls festzulegen. IPSec unterscheidet hierfür zwei Betriebsmodi: Tunnel-Mode und Transport-Mode. Im Tunnel-Mode wird der gesamte Rahmen verschlüsselt. Das Datenpaket bekommt einen neuen Header. Quelle und Ziel sind so versteckt und nur die Tunnelendpunkte sind erkennbar. Im Transport-Mode wird der Rahmeninhalt verschlüsselt, der ursprüngliche IP-Header wird beibehalten. Quell- und Zieladresse bleiben ungeschützt. 4

5 Darüberhinaus legt die SA den Algorithmus für die Authentisierung, die Verschlüsselungsmethode (nur bei ESP) und den verwendeten Schlüssel fest. Funktions-Voraussetzung den des oben beschriebenenablaufes ist, dass die Gegenstelle über dieselbe SA verfügt. IP Abbreviations ESP : Encapsulating Security Payload AH : Authentication Header PL : Pay-Load PL * = Encrypted data. Transport Mode IPSec Tunnel Mode PL PL* PL PL PL* AH ESP * AH ESP IP2 IP2 Abb. 1: IPSec Processing Der obere Teil des Bildes zeigt das Versenden eines IP-Datenpaket vom IP-Stack zum IPSec-Modul. Dort findet das IPSec-Processing des orginal IP-Headers () mit seinem Payload (PL Nutzdaten) statt. Der untere Teil des Bildes stellt das Ergebnis des Prozesses dar: Der Transport-Mode ist für Rechner-zu-Rechner- Kommunikation, der Tunnel-Mode für den Betrieb über ein VPN-Gateway. Der IP2- Header ermöglicht den Datentransport vom Client via Internet zu einem Gateway. Das VPN-Gateway entfernt den IP2-Header, entschlüsselt und sendet das Paket weiter zum Unternehmensnetz. Für Remote Access und End-to-Site-VPNs kommt nur der ESP-Tunnel-Mode in Frage. Wenn eine IPSec-SA für einen bestimmten SPD-Eintrag nicht vorliegt, muss sie mit der Gegenstelle ausgehandelt werden. In so einem Fall kommt die zweite große Komponente einer IPSec-Implementation zum Einsatz: das IKE- (Internet- KeyExchange ) Protokoll. Wie wichtig IKE in diesem Zusammenhang ist, verdeutlicht das Beispiel einer Internetverbindung zwischen Remote Client und dem VPN-Gateway in der Firmenzentrale. Der Client hat einen SPD-Eintrag mit einem 5

6 Selector, der ESP im Tunnel-Mode für IP-Pakete an die Firmenzentrale vorgibt. Vom Client wird zunächst eine Layer-2-(PPP) Verbindung zum Provider hergestellt. Anschließend erhält das IPSec-Modul im Client ein IP-Paket mit der Zieladresse Firmenzentrale. Es existiert zwar ein SPD-Eintrag für dieses IP-Paket, jedoch keine SA. Nun stellt das IPSec-Modul an das IKE-Modul die Anforderung, eine IPSec-SA mit der Gegenstelle - dem VPN-Gateway,- auszuhandeln (dieser Vorgang wird als Phase-2-Verhandlung bezeichnet). Dabei bekommt das IKE-Modul auch die im SPD-Eintrag vorhandenen Security-Merkmale. Voraussetzung für den Ablauf dieses Prozesses ist eine Art Kontrollverbindung zwischen Client und VPN- Gateway.. Diese Kontrollverbindung ist die sogenannte Phase-1-Verhandlung unddas Resultat die IKE-SA. Die Phase1-Verhandlung übernimmt den gesamten Authentisierungsvorgang vom Client zum VPN-Gateway und erzeugt gleichzeitig eine verschlüsselte Kontrollverbindung, über die anschließend die Phase-2- Verhandlung (IPSec-SA) abläuft. Die IKE Phase-1-Verhandlung ist ein Handshake, das den Austausch von digitalen Zertifikaten erlaubt und einen Schlüsselaustausch für die Kontrollverbindung beinhaltet. Dieses Verfahren kann in zwei verschiedenen Hauptmodi erfolgen: dem Main Mode und dem Aggressive Mode. Im Main-Mode (oder Identity-Protection- Mode) erfolgt ein Austausch von insgesamt sechs Nachrichten, wobei übertragene IDs oder Zertifikate verschlüsselt werden. Im Aggressive-Mode hingegen werden nur drei Nachrichten ausgetauscht und es wird keine Verschlüsselung eventuell übertragener IDs und Zertifikaten vorgenommen. Unabhängig vom Verhandlungsmode gibt es verschiedene bidirectionale Authentisierungsmethoden. Nachfolgend werden die zwei am häufigsten implementierten Methoden dargestellt. 1. Preshared Key: Client und VPN-Gateway besitzen jeweils diesselben, vorkonfigurierten Schlüssel. 2. RSA Signatures: Diese Methode unterstützt die Anwendung von digitalen Zertifikaten. Während einer IKE-Verhandlung mit Preshared Key und Main Mode, muss der Client vom VPN-Gateway anhand seiner IP-Adresse eindeutig identifizierbar sein. Denn der Preshared Key wird in die symmetrische Schlüsselberechnung mit einbezogen, d.h. die Verschlüsselung beginnt bereits vor der Übertragung von Merkmale, die den Client identifizieren. Erfolgt nun die Einwahl eines Clients über einen Provider, bleibt seine IP-Adresse aufgrund der dynamischen Adresszuweisung unerkannt. Eine Möglichkeit, dieses Problem zu umgehen, ist der sogenannte Aggressive Mode. Der Nachteil bei dieser Methode: Die Übertragung der IDs und/oder digitalen Zertifikate erfolgt im Klartext. Eine andere Methode ist, dass alle Clients denselben Preshared Key erhalten. Diese Vorgehensweise ist allerdings mit einer Schwächung der Authentisierung verbunden. 6

7 IPSec und Remote Access Der folgende Abschnitt beschreibt die Probleme von IPSec im Bereich Remote Access und zeigt entsprechende Lösungsansätze auf: 1. Wenn Preshared Key, Main Mode und dynamische IP-Adressen benutzt werden, muss der Preshared Key für alle IPSec-Clients gleich sein. 2. IPSec unterstützt nicht die traditionell im Remote Access eingesetzten unidirektionalen Authentisierungsmethoden Radius (PAP/CHAP), SecureID oder OTP. 3. Die IP-,DNS- und WINS-Adresszuweisung vom VPN-Gateway zum Client ist innerhalb des IKE-Protokolls nicht spezifiziert. Die privaten IP-, DNS- und WINS- Adressen müssten danach in jedem IPSec-Client fest konfiguriert werden. 4. Bei größeren Remote-Access-Netzen (> 300 Teilnehmern) können Resource- Probleme im VPN-Gateway auftreten. Die IPSec-Clients unterbrechen ihre Layer-2- (PPP-) Verbindung zum Provider immer wieder und löschen (vielleicht) ihre eigenen SAs, die nach wie vor im VPN-Gateway exisitieren. 5. Zwischen IPSec-Client und VPN-Gateway darf kein IP-NAT-Verfahren eingesetzt werden, da der IPSec ESP-Header nicht über genügend Informationen verfügt. Setzt beispielsweise ein Filial-Router IP-NAT bei der Einwahl zum Provider ein, muss sich der Tunnelendpunkt im Router befinden. D.h. es findet nur eine Authentisierung des LANs statt, jedoch keine persönliche Authentisierung der Teilnehmer. Insbesondere beim Einsatz von digitalen Zertifikaten (PKI) muß der Tunnelendpunkt im Filial-PC liegen. 6. Bei großen Remote-Access Installationen ist die Konfiguration und Administration der SPD-Einträge sowohl auf Clientseite als auch im Zentralsystem sehr aufwendig. Zwischenzeitlich gibt es verschiedene Ansätze, um diese Mankos zu beseitigen und IPSec für Remote Access zu optimieren. Als Lösung für Punkt 1 und 2 existiert der von CISCO eingereichte Draft XAUTH (Extended Authentication). Er setzt jedoch eine Veränderung und Erweiterung des IKE-Protokolls voraus. Für Punkt 3 sind dem Autor derzeit keine Drafts bekannt. Um das in Punkt 4 dargestellte Problem zu lösen, gibt es einen Vorschlag (keinen Draft), der eine Art Polling beschreibt. Mit Hilfe dieses Verfahrens soll signalisiert werden, wenn eine SA nicht mehr aktiv ist. Polling wird allerdings zu einem Problem, wenn der Client im Shorthold-Mode arbeitet, da die Layer-2- (PPP-) Verbindung zum Provider immer bestehen bleibt. Für Punkt 5 gibt es einen neu eingereichten Draft (NAT Traversal 28/2-2001) der Firma SSH. Im Prinzip geht es darum, dass jedes erzeugte IPSec-Paket zusätzlich in einen IP und UDP- Header verpackt wird, um so eine Kommunikation über Geräte, die IP-NAT-einsetzen, zu ermöglichen. Punkt 6 ist davon abhängig, wie ein Hersteller die Verwaltung der SPDs implementiert. 7

8 Bei den oben genannten Lösungsansätzen handelt es um Drafts und Vorschläge, wobei nicht alle von der IPSRA und IPSec Working Group akzeptiert sind. Dies belegt auch folgender Auszug aus dem vom CISCO eingereichten XAUTH Draft: The document has been published as informational as the IPSRA working group will not accept any protocol which extends ISAKMP or IKE. Furthermore, the IPSec working group refuses to accept any protocols that deal with remote access. Der nach Meinung des Autors interessanteste Ansatz, um die in den Punkten 1 bis 5 aufgezeigten Probleme zu lösen, ist im Informational RFC 2888 IPSec over L2TP (Secure Remote Access with L2TP) beschrieben. Mit IPSec over L2TP werden keinerlei Veränderungen oder Erweiterungen am RFC vorgenommen, womit der Akzeptanz seitens der IPSec und IPSRA working groups nichts im Wege stehen dürfte. In der Praxis schaut das so aus, dass zunächst ein Layer-2-Tunnel zwischen Remote Client und VPN Gateway aufgebaut wird. Anschließend läuft eine Standard PPP-Verbindung (ohne zusätzliche Sicherheit wie PPP-EAP-TLS) über die die IKE-Verhandlung und die IPSec-Datenpakete übertragen werden (Punkt 1-3). Trennt der Client seine Layer-2-Verbindung zum Provider, erfolgt automatisch der Tunnelabbau und die IPSec-SAs können gelöscht werden (Punkt 4). Mit Punkt 5 (IP-NAT) gibt es wie eingangs beschrieben bei einem L2TP-Tunnel keine Probleme. Die im RFC 2888 beschriebenen Nachteile sind der Overhead (L2TP- und IPSec- Header), die Komplexität der Implementierung (Layer-2-Tunneling und IPSec) sowie das unverschlüsselte Versenden der privaten IP-Adressen (IPSec wird erst nach dem Tunnelaufbau und anschließender PPP-Verhandlung aktiv). Die praktische Erfahrung mit IPSec over L2TP zeigt jedoch, dass sich der Overhead entweder durch PPP-Kompression oder IP-Kompression (IPCOMP) auf IPSec-Ebene begrenzen lässt. Die Komplexität der Implementierung eines Herstellers hängt von dessen Kenntnissen hinsichtlich Layer-2-Technologie ab. Last but not least, das Problem bezüglich dem unverschlüsseltenversenden der privaten IP-Adressen ist letztlich abhängig vom Grad des Sicherheitsbedürfnisses des VPN-Betreibers. Fazit IPSec ist ein Standard mit ausgezeichneten Sicherheitsmechanismen, der in bestimmten VPN-Szenarien funktioniert, in denen mit festen IP-Adressen gearbeitet wird (z.b.b2b, Extranet). In diesen Fällen lassen sich durchaus auch VPN Gateways verschiedener Hersteller einsetzen. Allerdings können Probleme beim Einsatz von digitalen Zertifikaten auftreten. Im Bereich Remote Access weist IPSec erhebliche Mängel auf, die leider von Anbietern und Consultans sehr selten angesprochen werden, aber deren Kenntnis wichtig für Unternehmen sind, die in ein Remote-Access-VPN investieren wollen. 8

9 Ohne Zweifel hat IPSec für Remote Access seine Berechtigung, wenn es allen Herstellern gelänge, sich auf ein einheitliches Verfahren zu einigen (z.b. IPSec over L2TP ).Doch so lange immer wieder neue Drafts eingereicht werden oder sogar mehrere Drafts existieren, die das gleiche Problem zu lösen versuchen, ist es sehr schwer, von einem Standard zu spechen. 9