DSL fernkonfiguriert

Inhaltsverzeichnis

Das Geschäft mit breitbandigen Internet-Zugängen brummt. Gegenwärtig besitzen weltweit 200 Millionen Haushalte einen DSL-Breitband-Internet-Zugang, und es werden täglich mehr. Doch DSL-Kunden, die einen neuen Router ohne Weiteres konfigurieren können, sind dabei nur eine kleine Gruppe. Trotz laufend optimierter Benutzeroberflächen oder auch aufs Wesentliche zurückgestutzter Assistenten wirkt die Internet-Einrichtung auf viele Netzwerk-Novizen abschreckend. Und wer VoIP, IPTV oder Video on Demand nutzen und selbst einrichten möchte, muss noch mehr meist humorlose Text-Adventures bestehen.

Deshalb entwickelten Netzbetreiber, Provider und Endgerätehersteller unter dem Dach des DSL-Forums eine Spezifikation für die DSL-Fernkonfiguration (Autoprovisionierung). Sie ist bereits seit Mai 2004 unter dem Namen Technical Report 069 verabschiedet (TR-069 – PDF, 1,7 MByte) und soll den per DSL feilgebotenen Diensten die Mühsal der Einrichtung nehmen und Triple Play den Weg zum Massenmarkt ebnen.

TR-069 beschreibt, wie Konfigurationsdaten von einem Auto Configuration Server (ACS) über einen Breitband-Anschluss in ein Teilnehmergerät (CPE, Customer Premise Equipment) übertragen werden. Deshalb kennt man die Spezifikation auch unter dem Begriff CPE WAN Management Protocol (CWMP). Ein DSL-Provider kann so mit einem ACS herstellerübergreifend alle Breitband-Router von AVM bis Zyxel in seinem Netz mit denselben Verfahren und Methoden konfigurieren und überwachen; prinzipiell lassen sich nahezu alle Router-Funktionen aus der Ferne einstellen. Allerdings wird TR-069 nicht vorausgesetzt; herkömmliche Router lassen sich auf die gleiche Art wie bisher in den Netzen von Providern verwenden, die TR-069 nutzen.

Als Vorbilder sehen die TR-069-Väter analoge Geräte wie das Telefon oder den Fernseher, die der Kunde lediglich mit dem jeweiligen Anschluss verbinden muss. TR-069 verkürzt aber nicht nur die Inbetriebnahme auf wenige, einleuchtende Handgriffe, sondern ermöglicht es dem Provider auch, DSL-Endgeräte zentral zu verwalten und zu aktualisieren.

Doch TR-069 ist nicht unumstritten. Manche Datenschützer befürchten Übergriffe von Strafverfolgungsbehörden auf die Privatsphäre. Bei Einsicht in die Spezifikation erscheinen solche Befürchtungen freilich gegenstandslos, denn die rein über TR-069-Funktionen zugänglichen Benutzerdaten sind nicht brisant; überdies liegt ein Großteil der Verkehrsdaten auf Backbone-Routern der Provider ohnehin unverschlüsselt vor. Anlass zu Kritik gibt es freilich in einigen Bereichen, in denen die Spezifikation zu wenig auf Bedürfnisse der Anwender eingeht.

Startcode für DSL

Startcode für DSL

Seit der Verabschiedung der Spezifikation veranstaltet das DSL-Forum regelmäßig Plugfests – organisierte Treffen, bei denen ACS- und CPE-Hersteller ihre Produkte auf Interoperabilität prüfen. Inzwischen experimentieren etliche CPE-Hersteller, etwa Allied Telesyn, AVM, Conexant, Netgear, Siemens, SMC, Sphairon, Thomson oder auch Zyxel mit TR-069, und einige haben damit bereits Erfahrungen in öffentlichen Netzen gesammelt. Auch die Zahl der ACS-Hersteller wächst. Die bekanntesten sind Axiros, Motive, die von Motorola aufgekaufte Netopia und SupportSoft.

In Deutschland setzen DSL-Anbieter seit Mitte 2006 die vereinfachte Einrichtung für den Internet-Zugang und die IP-Telefonie auf Basis von TR-069 bereits ohne viel Aufhebens ein. Wie die Fernkonfiguration in Gang gesetzt wird, ist von Provider zu Provider unterschiedlich: Beispielsweise sind Router am Markt, bei denen der Kunde lediglich einen Startcode (PIN) über die Oberfläche des Geräts eingeben muss, um so die Fernkonfiguration in Gang zu setzen – ein Server des Providers erledigt dann den Rest und stellt im Teilnehmer-Router die Zugangs- und Anmeldedaten automatisch aus der Ferne ein. Bei manchen Providern wird per TR-069 lediglich die IP-Telefonie eingerichtet; dabei leiten Kunden die Konfiguration durch Eingabe einer PIN per Telefontastatur ein.

Damit die Kundendaten nicht Unbefugten in die Hände fallen, die damit zum Beispiel Telefonate zu Lasten des legitimen Nutzers führen könnten, setzen viele Provider auf separate Zusendung dieser Daten per Post.

Manche Betreiber gehen bei ihrem DSL-Angebot noch einen Schritt weiter: Die Inbetriebnahme von Internet und Telefonie ist mit dem Anschluss des Gerätes bereits abgeschlossen; ein Startcode ist nicht erforderlich und der PC kann ausgeschaltet bleiben. So bietet die Deutsche Telekom seit letztem Jahr einen Internet-Zugang mit automatischer Einrichtung an. VDSL-Teilnehmeranschlüsse funktionieren ohne manuelle Eingabe von Internet-Zugangsdaten direkt nach dem Verbinden mit dem DSL-Anschluss. Weitere Provider wollen bald schon nachziehen.

Gelehrige Router

Gelehrige Router

Die Autoprovisionierung beginnt bei jedem TR-069-fähigen Teilnehmergerät gleich: Schaltet man es ein, verbindet es sich mit dem ACS und der provisioniert das Teilnehmergerät, wenn es noch nicht konfiguriert ist. Diese erste Verbindung wird auch als First Connect bezeichnet. Der Verbindungsaufbau läuft grundsätzlich nur vom Teilnehmergerät zu einem spezifischen ACS ab. Die normalerweise für den Internet-Verkehr erforderliche Benutzerkennung (etwa für den T-Online-Zugang) wird dafür nicht verwendet. Vielmehr bringt das CPE für den First Connect bereits Parameter mit, die ihm die Kontaktaufnahme mit dem ACS ermöglichen (z. B. die grundlegende Konfiguration für PPPoE-Verbindungen über das Trägermedium ATM).

Je nach Anforderungen des Providers – der Position ihres eigenen ACS im Netz –, legen die Hersteller ihre CPEs entweder für die Verbindungsaufnahme übers öffentliche Internet oder für den Zugang zu einem separaten IP-Netz aus (Walled Garden). Die IP-Adresse oder URL seines ACS muss dem CPE bekannt sein (zum Beispiel https://mein-provider.de für einen ACS im öffentlichen Internet). Abhängig von der Netzinfrastruktur des Providers ist die Konfiguration für den Zugriff auf den ACS entweder in der Werkseinstellung enthalten oder sie wird mit der automatischen IP-Adressvergabe vom DHCP-Server zum Teilnehmer-Router übermittelt.

Steht die Internet-Verbindung, baut das CPE eine [# 437 HTTP]- oder [# 1271 HTTPS]-Verbindung zum ACS auf. An dieser Stelle verlangt der ACS in der Regel eine Anmeldung mit der TR-069-Kennung des Kunden (User-Credentials für die Provisionierung); eine Authentifizierung des ACS gegenüber dem CPE ist laut Spezifikation nicht erforderlich, kann aber bei HTTPS-Verbindungen anhand üblicher SSL-Mechanismen ablaufen. Nach der CPE-Authentifizierung, die per Basic- oder Digest-Verfahren abläuft, ordnet der ACS ein Gerät einem bestimmten Kunden zu und fragt die Eigenschaften und Fähigkeiten des CPE ab. So erfährt er die Gerätebezeichnung sowie dessen Einstellmöglichkeiten. Danach beginnt er mit der Konfiguration, für die er nur wenige Sekunden braucht – der Router ist dann für die vorgesehenen Dienste eingerichtet und betriebsbereit.

Bei den meisten aktuellen Geräten können die Nutzer diese Einstellungen nicht nur einsehen, sondern auch ändern und ergänzen. Letzteres ist sinnvoll, wenn man zum Beispiel zusätzliche VoIP-Provider definieren will, die der DSL-Anbieter selbst nicht vorgesehen hat.

Zero-Touch-Parametrierung

Die Beschränkung auf die PIN-Eingabe ist zwar schon eine erhebliche Vereinfachung, aber die DSL-Provider streben eine Autoprovisionierung an, bei der die Einrichtung schon mit dem Anschluss der Zugangshardware abgeschlossen ist, in Provider-Kreisen auch "Zero Touch" genannt.

Provider, die ein eigenes Zugangsnetz betreiben, darunter die Deutsche Telekom, QSC, Arcor oder auch Stadtnetzbetreiber wie Netcologne, haben für Zero Touch bessere Voraussetzungen, denn sie können an der Gegenstelle des DSL-Routers, dem DSLAM, anhand der Port-ID leicht ablesen, welchem Kunden ein Anschluss zugeordnet ist. Sie können daher die Port-ID an Stelle der User-Credentials für die Authentifizierung am ACS verwenden und mit einem kundenspezifischen CPE-Konfigurationsdatensatz verknüpfen.

DSL-Reseller erhalten die Port-ID aber üblicherweise nicht, müssen also für Zero Touch andere individuelle Merkmale der DSL-Elemente für die Zuordnung verwenden. Gewöhnlich benutzen sie dafür die Seriennummer des CPE. Diese muss daher vor dem Versand des CPE an den Teilnehmer einem kundenspezifischen Konfigurationsdatensatz zugeordnet werden. Sobald sich das CPE am ACS authentifiziert, impft der ACS das CPE mit diesem Datensatz. Weil sie für TR-069-fähige Geräte höhere Sicherheit anstreben als für herkömmliche, lassen Provider per Post versandte TR-069-Router nur gegen Vorlage des Personalausweises aushändigen. So soll verhindert werden, dass präparierte Geräte Unbefugten in die Hände fallen, die damit etwa auf fremde Kosten telefonieren und surfen.

TR-069 im laufenden Betrieb

TR-069 im laufenden Betrieb

Neben der vereinfachten Geräteeinrichtung bietet TR-069 auch Vorteile während des laufenden Betriebs. Ein Beispiel ist das zentral gesteuerte Aktualisieren der Firmware. Auch lassen sich so neue Dienste bequem freischalten. Technikern bleiben die Wege zu den Kunden erspart.

Sofern diese Updates ohne Komplikationen verlaufen, werden die meisten Nutzer die automatische Aktualisierung nicht bemerken, zumal die Spezifikation eine Protokollierung oder Hinweise an den Nutzer nicht vorsieht. Ob die Update-Automatik abschaltbar ist, entscheidet der CPE Hersteller nach eigenem Gusto. Für den Fall, dass Updates während des Schreibens scheitern, zum Beispiel wegen Stromausfall, müssen CPE-Hersteller selbst sicherstellen, dass das nicht zum Totalausfall ihrer CPEs führt; die TR-069-Spezifikation behandelt das Thema nicht.

Für Anwender, die die Wahl der Firmware-Version selbst treffen wollen, dürfte das ein gewichtiges Auswahlkriterium sein. Nur bei abschaltbarem Auto-Update können sie zum Beispiel wenig erprobte Versionen mit spannenden, aber noch nicht freigegebenen Funktionen nutzen oder eben eine besonders stabile Version bewahren. Beispielsweise kann man bei einer Fritz!Box 7170 die Update-Automatik im Menü Netzwerk unterbinden (die Option "automatische Updates zulassen" abschalten). Zuvor muss man gegebenenfalls im Menü "System, Ansicht" die "erweiterte Ansicht" einschalten. Ähnliche Optionen finden sich auch in jüngeren Speedport-Routern und Modellen anderer Hersteller.

Darüber hinaus bietet TR-069 eine Plattform für Anwendungen, die die Spezifikation nicht explizit nennt. Dazu gehört die Übertragung von Statistiken über Leitungsqualität, Bitfehlerraten, Checksummenfehler oder auch Verluste des Synchronisationssignals. Der Provider kann diese Daten weiterverarbeiten, um Störungen und Supportfällen präventiv zu begegnen.

Tritt dann trotz aller Umsicht doch ein Störungsfall ein, profitieren Kunden von TR-069 durch verkürzte Reaktionszeiten. Wenn der Router Kontakt zum ACS hat, erspart das Verfahren die zeit- und nervenraubenden Beschreibungen von Fehlern und Router-Konfigurationen; die Bearbeiter im Service-Center können über den Zugriff auf den ACS Einstellungen der Endgeräte abfragen, analysieren und gegebenenfalls Korrekturen vornehmen – wenn die Fehlerursache im DSL-Router liegt.

Von inkonsistenten oder falschen Konfigurationen kann der ACS auf zwei Arten erfahren: Indem er die Einstellungen aktiv abfragt oder indem er sich Änderungen der Einstellungen übermitteln lässt. Dafür registriert sich der ACS beim CPE für bestimmte Parameter und fortan wird er vom CPE benachrichtigt, sobald sich einer dieser Parameter ändert (Active Notification).

Damit kann der ACS beispielsweise im Fehlerfall Maßnahmen zur Beseitigung ergreifen, etwa wenn ein unerfahrener Nutzer die VoIP-Konfiguration verstellt. Es liegt jedoch im Ermessen des Providers, ob er die Fehleinstellung automatisch vom ACS korrigieren lässt oder erst dann eingreift, wenn sich der Nutzer beklagt. Prinzipiell kann der Provider einen fehlkonfigurierten Anschluss jedenfalls innerhalb von Sekunden flottmachen.

Weil es TR-069 erlaubt, nahezu alle wichtigen Einstellungen des DSL-Endgeräts zu beeinflussen, erwägen einige DSL-Anbieter ihr CPE bereits ohne die übliche Benutzeroberfläche auszuliefern – die Nutzer hätten bei diesen Geräten keine Eingriffsmöglichkeiten mehr. Wer sich um Router-Einstellungen nicht kümmern will und die Verantwortung für eine funktionierende Konfiguration komplett beim Serviceanbieter sieht, wird das als Vorteil werten. Allerdings sind Geräte ohne User-Interface zwingend auf TR-069 angewiesen. Sie können bei Konfigurationsfehlern nur noch per TR-069 wieder aufs richtige Gleis gesetzt werden – sofern sie noch Kontakt zum ACS aufnehmen können.

Technisch versierte oder auch anspruchsvolle Anwender werden solche Geräte natürlich meiden, wenn sie – durchaus gängige – Router-Funktionen nutzen wollen, die der Provider nicht per TR-069 für sie verwalten kann. Beispielsweise bieten handelsübliche Router Benutzerprofile etwa für die Kindersicherung, die Nachtschaltung für WLAN und Telefon oder auch das Port-Forwarding. Die TR-069-Spezifikation sieht für viele derartige Funktionen keine Handhabe vor, sodass sie bei Geräten ohne Benutzerschnittstelle schon deshalb nicht implementiert sind. Auch gilt zu bedenken, dass Geräte ohne User-Interface, aber mit fester ATM- oder Netzwerk-Konfiguration nicht an beliebigen DSL-Anschlüssen laufen – etwa weil sie nur für PPPoE-Authentifizierung ausgelegt sind, der neue Provider aber zum Beispiel DHCP oder anderes erwartet.

Datenmodell und Protokoll

Datenmodell und Protokoll

Die herstellerübergreifende Funktionalität gewährleistet TR-069 mit einem einheitlichen Datenmodell. Es besteht aus Name-Wert-Paaren, die als Parameter einem Objekt zugeordnet sind – beispielsweise sind Username und Password für die Internet-Einwahl dem Objekt WANPPPConnection. zugeordnet. Username und Passwort werden in allen TR-069-fähigen Breitband-Routern so adressiert:

InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.

Objekte sind in einer hierarchischen Struktur angeordnet, in der Objektebenen durch Punkte getrennt sind; das Modell ist dem von SNMP vergleichbar. Insgesamt sind über 480 Parameter definiert. Objekte sind fett und Parameter eingerückt dargestellt:

<b>InternetGatewayDevice.</b>
   DeviceSummary 
<b>InternetGatewayDevice.DeviceInfo.</b>
   Manufacturer 
   SerialNumber 
<b>InternetGatewayDevice.LANDevice.1.LANHostConfigManagement.</b>
   DHCPServerEnable 
   DNSServers 
<b>InternetGatewayDevice.LANDevice.1.LANHostConfigManagement.IPInterface.</b>
   IPAddress 
   SubnetMask 
<b>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.</b>
   Username 
   Password

Sollten einem Router-Hersteller die definierten Parameter nicht genügen, kann er die Liste für sein CPE in Abstimmung mit dem ACS-Hersteller und dem Provider erweitern. So könnte man im ACS und CPE etwa Funktionen für Einstellung und Wartung von Jugendschutzfiltern für die Verwaltung per TR-069 nachrüsten.

Die Übertragung von Konfigurations- und Statusdaten vom CPE zum ACS läuft über das CPE-WAN-Management-Protokoll ab. Manche ACS-Hersteller können dafür auch proprietäre Protokolle einsetzen, für die die CPEs entsprechend adaptiert sein müssen. Die CWMP-Kommunikation basiert auf dem Simple Object Access Protocol (SOAP), das den Austausch von XML-basierten Objekten ermöglicht.

Über SOAP tauschen CPE und ACS Remote Procedure Calls untereinander aus (RPC). Die RPCs sind in Methoden untergliedert. Damit der ACS die Methoden nutzen kann, muss sich das CPE mittels InformRequest zunächst beim ACS anmelden. Jede TR-069-Session beginnt mit dem InformRequest. Mittels der Methode GetParameterNames liest der ACS die Parameterhierarchie ein, GetParameterValues dient zum Lesen der Parameterwerte, SetParameterValues zum Schreiben. Per AddObjekt kann er Objekte hinzufügen, beispielsweise um einen neuen VoIP-Account einzurichten. Per DeleteObjekt entfernt er ein Objekt. Über Download fordert er das CPE auf, ein Firmware-Update zu laden.

Abonnements verwalten

Neben den Standard-Methoden gibt es optionale, speziell für die Verwaltung und Konfiguration kostenpflichtiger Dienste entwickelte. Die zugehörigen Einstellungen werden über Vouchers übertragen; diese müssen gemäß dem XML Signature Format signiert sein; es ist also ein zusätzlicher Verschlüsselungs-Layer implementiert, der sich etwa für die Verwaltung von Abonnements eignet. Ein Voucher ist spezifisch für ein bestimmtes CPE und kann nicht von irgendeinem anderen CPE verwendet werden.

SetVouchers erlaubt es, eine Liste von Vouchers zum CPE zu senden; jeder Voucher kann im Voucher selbst genannte Optionen ein- oder ausschalten. Die Optionen können zeitlich befristet sein; nach Ablauf der Frist muss das CPE die Optionen selbst abschalten. Deshalb muss ein CPE, das die Voucher-Option implementiert, auch ein Protokoll zur Zeitsynchronisation beherrschen (NTP oder SNTP). Man unterscheidet übertragbare und nicht übertragbare Optionen – nur übertragbare bleiben beim Wechsel des Providers eingeschaltet, alle übrigen tilgt das CPE nach einem Wechsel. Mittels GetOptions kann der Server den Status solcher Optionen auslesen.

Bestellter Rückruf

Bestellter Rückruf

Näher betrachtet läuft die Autoprovisionierung nach einem simplen Muster wie im vereinfachten Diagramm ab. Ein ausführliches Beispiel in Form eines TCP-Mitschnitts haben wir an Ende dieses Artikels gestellt.

TR-069 spezifiziert nur eine Richtung für den Verbindungsaufbau, nämlich vom CPE zu einem bestimmten ACS. Diese Aktion kann eines von fünf Ereignissen auslösen: Ein Neustart, das Laden der Werkseinstellungen, ein vom ACS gesetztes Intervall für regelmäßige Rückmeldungen (PeriodicInformInterval), eine Verbindungsaufforderung des ACS (Connection Request) sowie Änderungen von Parametern, auf die das CPE laut Maßgabe des ACS achten soll (Active Notification). Zu den Notification-Parametern gehört in der Grundeinstellung die Internet IP-Adresse. In der Praxis folgt daraus für die meisten TR069-Router, dass sie sich nach jeder Internet-Einwahl beim ACS melden – denn die weitaus meisten Geräte haben keine statische öffentliche IP-Adresse, sondern eine dynamische, die sich eben bei jeder Einwahl ändert.

Die Verbindungsaufforderung, Connection Request, ist keine vollständige TR-069-Verbindung, sondern soll lediglich das CPE veranlassen, eine solche aufzubauen. Der Connection Request setzt voraus, dass das CPE den ACS mindestens einmal kontaktiert und dabei die für den Request erforderlichen Daten übertragen hat. Das sind die aktuelle IP-Adresse, der für diesen Zweck vom CPE-Hersteller ausgewählte Port (zusammen bilden sie den Connection Request URL), ein gerätespezifischer Pfadname sowie die ACS-Credentials.

Beim Connection Request dürfen keine Daten zum CPE übertragen werden; das CPE muss etwaige so empfangene Daten verwerfen. Der ACS muss sich beim Connection Request per Digest-Authentifizierung mittels seiner Credentials beim CPE anmelden. Die Credentials liegen als modifizierbare Parameter auf dem CPE vor und sind nur dem ACS und dem CPE bekannt. Weil die URL und der Schlüssel normalerweise nicht öffentlich bekannt sind, gehen die Autoren der Spezifikation davon aus, dass das Verfahren ausreichend sicher ist.

Für den Connection Request sind unverschlüsselte HTTP-Verbindungen vorgeschrieben und HTTPS-verschlüsselte ausdrücklich verboten, weil die Autoren davon ausgehen, dass die einzig interessanten Daten, die bei dieser Kurzverbindung übermittelt werden – die Credentials des ACS – ohnehin durch die Digest-Authentifizierung ausreichend verschlüsselt und somit geschützt sind (sobald das CPE den Befehl HTTP-GET auf die ConnectionRequestURL erhält, antwortet es mit "Authentication required"). Hat sich der ACS authentifiziert, wird die Verbindung getrennt und das CPE ruft zurück; seinen HTTP-Server nimmt das CPE beim Connection Request nicht in Betrieb. Zur Vermeidung von DoS-Attacken darf das CPE nur eine begrenzte Anzahl von Verbindungen pro Minute annehmen; Details nennt die Spezifikation nicht, aber Fachleute halten Werte von unter 10 pro Minute für sinnvoll.

Nach dem TCP-Verbindungsaufbau zum ACS sendet das CPE einen InformRequest. Dabei übermittelt es allgemeine Geräteinformationen wie Herstellername, Seriennummer, Software- und Hardwareversion, die Daten für den Connection Request und, sofern bereits vom ACS gesetzt, auch den Provisioning-Code.

Konfiguration aus der Konserve

Der ACS quittiert den InformRequest mit InformResponse. Hat das CPE keine weiteren Requests in der Warteschlange, signalisiert es das mit einem leeren HTTP Post. Nun prüft der ACS, ob das CPE den Provisioning-Code mitgeschickt hat. Wenn ja, ist das CPE konfiguriert. Wenn nein, wird der zugehörige, vom Service Configuration Manager bereitgehaltene Konfigurationsdatensatz in SetParameterValues Request gekapselt und mit dem Provisioning-Code an das CPE übertragen. Das CPE teilt per SetParameterValueResponse mit, ob der Provisionierungsprozess erfolgreich war. Wenn beide Seiten ihre Requests abgearbeitet haben, wird die Verbindung nicht mehr benötigt und das CPE baut die TCP-Verbindung zum ACS ab.

TR-069-fähige Geräte sind mit ihrem für den Connection Request geöffneten Port im Internet exponiert; vorstellbar sind daher Angriffe, die das Ziel haben, den Router unter Kontrolle zu bringen, um etwa Online-Banking-Zugriffe auf präparierte Server umzuleiten. Deshalb müssen die Sicherheitsmaßnahmen bei TR-069 deutlich schärfer sein als bei herkömmlichen Konfigurationsverfahren, die auf LAN-Verbindungen gründen. Eine erste Schranke gegen unbefugte Zugriffe ist der Verbindungsaufbau – eingehende TR-069-Verbindungen darf ein CPE nicht annehmen, sondern kann sie immer nur selbst zu seinem, in der Firmware gespeicherten ACS-URL hin initiieren.

Sicherheitsaspekte

Sicherheitsaspekte

Netzbetreiber können die TR-069-Kommunikation zusätzlich schützen, indem sie den ACS in einem logisch vom Internet separierten Netz betreiben; Provider, die beispielsweise ein ATM-Netz unterhalten, können den ACS vom Internet abschirmen, indem sie ihn in ein privates Netz stecken.

Dem TR-069-Traffic zwischen DSL-Modem und ATM-Netz des Providers wird dafür ein eigener ATM-Kanal zugewiesen. Angriffe auf den ACS könnten dann nur aus dem privaten Netz des Providers kommen, nicht aber aus dem großen, bösen Internet.

Ferner müssen sich ACS und CPE auf die erhaltenen Daten verlassen können – es muss also sichergestellt sein, dass sie wirklich vom angegebenen Absender stammen, vollständig und unverändert sind. Die SSL/TLS-verschlüsselte Kommunikation (HTTPS) kann das gewährleisten. Dazu müssten sich aber Client und Server gegenseitig authentifizieren. Im Zusammenspiel mit den per OpenSSL vergebenen Zertifikaten und geheimen Schlüsseln lassen sich damit Teilnehmer-Router zweifelsfrei identifizieren und auch die Integrität der übertragenen Daten gewährleisten.

Doch die Spezifikation schreibt HTTPS nicht vor, sondern empfiehlt die Technik lediglich und erlaubt stattdessen auch unverschlüsselte HTTP-Verbindungen. Nur bei HTTPS ist aber gewährleistet, dass sich bei einer TR-069-Verbindung auch der ACS gegenüber dem CPE mittels Zertifikaten authentifiziert, sodass das CPE einen vorgetäuschten ACS erkennen kann (Spoofing vermeiden). Immerhin setzen alle DSL-Anbieter, die bereits TR-069 anwenden, HTTPS ein.

Die öffentlichen SSL-Zertifikate sind bereits ab Werk in der Firmware des CPE enthalten. Wie sich ein CPE bei abgelaufenen Zertifikaten verhalten soll, beschreibt die Spezifikation nicht. Ein abgelaufenes Zertifikat, CPE- oder ACS-seitig, verhindert natürlich die Kontaktaufnahme. Nutzer müssen also darauf bauen, dass die Zertifikate durch Firmware-Updates aktuell gehalten werden.

Wie man Zertifikate und geheime Schlüssel sicher aufbewahrt, diskutiert die Spezifikation nicht. Auch lässt sie offen, wie man verhindert, dass ein Router manipulierte Firmware akzeptiert, die unbedarften Nutzern untergeschoben werden könnte. Deshalb konzipieren manche Hersteller ihre TR-069-fähigen Geräte so, dass sie nur digital signierte Firmware annehmen. Dabei ist unerheblich, ob die Firmware aus dem Internet oder aus dem LAN auf dem Router eingeht.

Auch beim automatischen Firmware-Update per TR-069 sollte das CPE nur vom CPE-Hersteller signierte Daten akzeptieren. Dafür definiert die Spezifikation das Signed Package Format, mit dem sich ein bis mehrere Dateien in einem signierten Paket übertragen lassen (Package). Auf diese Weise lassen sich Malware-Installationen vermeiden. Vorgeschrieben ist diese Art Eingangsprüfung jedoch nicht, sondern freigestellt.

Außerdem stellt die Spezifikation sicher, dass ein ACS private Daten wie Passwörter des CPE allenfalls schreiben, nicht aber lesen kann – dafür räumt ihm das CPE keine Rechte ein. Deshalb kann ein DSL-Anbieter über ACS beispielsweise eigene VoIP-Konten für den sofortigen Gebrauch anlegen, nicht aber manuell angelegte Parameter fremder VoIP-Anbieter auslesen. Das heißt auch, dass WLAN-Keys zur Verschlüsselung des Funknetzwerks ebenso geheim bleiben wie Passwörter von VoIP-Konten, die der Nutzer manuell hinzugefügt hat.

Dass es Unbefugten gelingen könnte, die Router-Firmware zu manipulieren, um an solche Daten zu gelangen, erscheint kaum wahrscheinlich. Hersteller geben ihre Firmware-Sourcen normalerweise nicht weiter und die meisten Hersteller schützen ihre Geräte vor solcher Malware dadurch, dass sie nur signierte Firmware akzeptieren.

Es ist zwar richtig, dass TR-069 dem Internet-Dienstanbieter die Möglichkeit gibt, unbemerkt vom Nutzer Einstellungen des DSL-Routers auszulesen und zu verändern. Ein heimliches Firmware-Update mit einem "TR-069-Trojaner" würde aber noch lange keine Online-Durchsuchung von PCs ermöglichen, dafür ist TR-069 nicht ausgelegt, und automatische Updates sind ja auch ohne TR-069 möglich.

Mit viel Phantasie und zusätzlichen, TR-069-fremden Funktionen wäre allenfalls das Mitschneiden des Datenflusses im Heimnetzwerk möglich. TR-069 könnte die TCP-Mitschnitte sogar effektiv transportieren, denn mit einem Befehl kann ein CPE bis zu 32 KByte auf einen Schlag senden. Allerdings dürfte das Interesse an solchen Daten gering sein, denn einen Großteil dieses Verkehrs sehen die DSL-Anbieter schon heute und Strafverfolgungsbehörden bekommen diese Daten auf richterliche Genehmigung hin. Was sie nicht sehen, ist der verschlüsselte Verkehr des PC und dafür brauchen sie ein Werkzeug, das direkt auf dem PC mitlauscht.

Wer seine Privatsphäre dennoch durch TR-069 gefährdet sieht, hat nur eine Wahl, um seine Zweifel zu beruhigen: einen Router nutzen, bei dem TR-069 abschaltbar ist. Wenn der Anbieter einen bestimmten Router voraussetzt und diesen für die Dauer der Vertragslaufzeit zur Verfügung stellt, ist dies aber oft nicht möglich. Bessere Akzeptanz hätte aber auch schon eine TR-069-Auslegung, bei der der User selbst bestimmen darf, welche der im Router implementierten Funktionen per TR-069 genutzt werden.

Triple-Play-Spezifikationen

Triple-Play-Spezifikationen

Viele aktuelle DSL-Router bringen eine TK-Anlage für VoIP-Telefonate mit. Deren detaillierte Konfiguration sieht TR-069 aber nicht vor; vielmehr hat das DSL-Forum dafür die SpezifikationTR-104 (PDF, 822 kByte) konzipiert. Damit können Provider VoIP-Konten, Rufnummern für ein- und ausgehende Gespräche oder auch Leistungsmerkmale von Telefonanlagen einrichten oder auch Statistiken abfragen und diverse andere Parameter setzen.

TR-104 kommt im Hinblick auf die Entbündelung von DSL- und Festnetzanschlüssen eine besondere Bedeutung zu. Damit im Rücken, wäre der IP-Telefonanschluss mit einem Handgriff einzurichten und könnte so herkömmliche Festnetzanschlüsse leichter ablösen. Mit TR-069 als zusätzlichen stillen Helfer wird man nach dem Anschluss des Telefons sofort telefonieren können. Ähnlich verhält es sich mit Fernsehbildern, die künftig über IP ins Wohnzimmer gelangen sollen; die eigentlichen Empfänger sind Settop-Boxen und auch für deren Autoprovisionierung hat das DSL-Forum eine Spezifikation in Arbeit. Zurzeit wird sie unter der Bezeichnung Working Text 135 (WT-135) diskutiert.

Im Heimnetzwerk integrierte Geräte (Home Networking Devices) nutzen den DSL-Router als Internetgateway. Üblicherweise sind Settop-Boxen, VoIP-Endgeräte oder Spielkonsolen über das LAN oder WLAN an den DSL-Router angebunden, bekommen private IP-Adressen und gelangen so nur mittelbar – über die Network Address Translation des Routers – ins Internet (NAT). Der Technical Report 111, "Applying TR-069 to Remote Management of Home Networking Devices" beschreibt, wie der ACS eine Verbindung zu einem Gerät hinter einem NAT-Gateway herstellt (Connection Request).

Daneben hat das DSL-Forum weitere Spezifikationen verabschiedet, die ergänzend zu TR-069 verbindliche Testprozeduren für ACS- und CPE-Hersteller definieren (PD-128) und die Datenmodelle für TR-069-fähige Endgeräte allgemein strukturieren (TR-098 und TR-106) – siehe die Approved Technical Reports des DSL-Forums.

Mit solchen Spezifikationen sind die Eckpfeiler für das Remoteprovisioning im Triple-Play-Szenario gesetzt. Alle haben TR-069 als Grundlage. Es ist zu erwarten, dass in naher Zukunft mit der Verbreitung neuer Dienste im Internet nicht nur der DSL-Router, sondern auch die Geräte im LAN fernprovisioniert werden. Dann gilt: Plug and Play auch für das gesamte Heimnetz, wenn am Eingang dazu ein TR-069-fähiger Router steht.

Mitschnitt

Mitschnitt

TCP-Mitschnitt einer Autoprovisionierung mittels TR-069: Eine AVM Fritz!Box Fon WLAN 7170 wird mit Internetzugangsdaten und VoIP-Anmeldedaten gefüttert. Der Übersichtlichkeit halber haben wir die obligatorische HTTP-Authentifzierung mit den User-Credentials am ACS weggelassen. Die Benutzerdaten für den Internetzugang und die VoIP-Rufnummer sind lediglich Testdaten.

POST /testacs/services/Cpemanagemnt HTTP/1.1
HOST: 87.234.237.172:8432
CONTENT-LENGTH: 2180
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: "cwmp:Inform"

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/"
               soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               xmlns:cwmp="urn:dslforum-org:cwmp-1-0"
               xmlns:xsi="http://www.w3.org/ 1999/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/1999/XMLSchema"> 
   <soap:Header> 
      <cwmp:ID soap:mustUnderstand="1">100</cwmp:ID>
      </soap:Header> 
   <soap:Body> 
      <cwmp:Inform> 
         <DeviceId> 
            <Manufacturer>AVM</Manufacturer> 
            <OUI>00040E</OUI> 
            <ProductClass>FRITZ!Box</ProductClass> 
            <SerialNumber>00150C492F89</SerialNumber>
            </DeviceId> 
         <MaxEnvelopes>1</MaxEnvelopes> 
         <CurrentTime>2007-01-26T10:33:12</CurrentTime> 
         <RetryCount>0</RetryCount> 
         <Event soap-enc:arrayType="cwmp:EventStruct[1]"> 
            <EventStruct> 
               <EventCode>0 BOOTSTRAP</EventCode> 
               <CommandKey></CommandKey>
            </EventStruct>
         </Event> 
         <ParameterList soap-enc:arrayType="cwmp:ParameterValueStruct[7]"> 
            <ParameterValueStruct> 
               <Name>InternetGatewayDevice.DeviceInfo.HardwareVersion</Name> 
               <Value xsi:type="xsd:string">AVM FRITZ!Box Fon WLAN 7170 ( )
                  29.05.01</Value></ParameterValueStruct> 
            <ParameterValueStruct> 
               <Name>InternetGatewayDevice.DeviceInfo.SoftwareVersion</Name> 
               <Value xsi:type="xsd:string">29.05.01-release-build_1818-2904</ Value="Value">
            </ParameterValueStruct>

            <ParameterValueStruct> 
               <Name>InternetGatewayDevice.DeviceInfo.SpecVersion</Name> 
               <Value xsi:type="xsd:string">1.0</Value>
            </ParameterValueStruct>

            <ParameterValueStruct> 
               <Name>InternetGatewayDevice.DeviceInfo.ProvisioningCode</Name>

               <Value xsi:type="xsd:string">000.000.000.000</Value>
            </ ParameterValueStruct="ParameterValueStruct">

            <ParameterValueStruct> 
               <Name>InternetGatewayDevice.ManagementServer.ParameterKey</Name>

               <Value xsi:type="xsd:string"></Value>
            </ParameterValueStruct> 

            <ParameterValueStruct> 
               <Name>InternetGatewayDevice.ManagementServer.ConnectionRequestURL</Name>

               <Value xsi:type="xsd:string">http://194.175.125.104:8089/4b123c06</ Value="Value">
            </ParameterValueStruct>

            <ParameterValueStruct> 
               <Name>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.
                  1.WANPPPConnection.1.ExternalIPAddress</Name> 
               <Value xsi:type="xsd:string">194.175.125.104</Value>
            </ ParameterValueStruct="ParameterValueStruct">
         </ParameterList>
      </cwmp:Inform>
   </soap:Body>
</ soap:Envelope="soap:Envelope">

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build:  
CVSTag=JBoss_4_0_3_SP1 date=200510231054)/Tomcat-5.5
Set-Cookie: JSESSIONID=F886A504A8289C03C91009D9DEF4682B; Path=/
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Thu, 26 Jan 2007 10:33:13 GMT

<?xml version="1.0" encoding="UTF-8" ?> 
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/ envelope/"
                  xmlns:xsd="http://www.w3.org/1999/XMLSchema"
                  xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"> 
   <soapenv:Header> 
      <ns1:ID soapenv:mustUnderstand="1"
              xmlns:ns1="urn:dslforum- org:cwmp-1-0">100</ns1:ID> 
   </soapenv:Header> 
   <soapenv:Body> 
      <ns2:InformResponse soapenv:encodingStyle="http:// schemas.xmlsoap.org/soap/encoding/"
                          xmlns:ns2="urn:dslforum- org:cwmp-1-0"> 
         <MaxEnvelopes xsi:type="ns3:unsignedInt"
                       xmlns:ns3="http:// www.w3.org/2001/XMLSchema">1</MaxEnvelopes>

      </ns2:InformResponse> 
   </soapenv:Body> 
</soapenv:Envelope>

POST /testacs/services/Cpemanagemnt HTTP/1.1
HOST: 87.234.237.172:8432
Cookie: JSESSIONID=F886A504A8289C03C91009D9DEF4682B
CONTENT-LENGTH: 0
CONTENT-TYPE: text/xml; charset="utf-8"

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build:  
CVSTag=JBoss_4_0_3_SP1 date=200510231054)/Tomcat-5.5
Transfer-Encoding: chunked
Date: Thu, 26 Jan 2007 10:33:13 GMT

<?xml version="1.0" encoding="UTF-8" ?> 
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/ envelope/"
                  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
   <soapenv:Header> 
      <ns1:ID soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next"
              soapenv:mustUnderstand="1" xsi:type="xsd:string"
              xmlns:ns1="urn:dslforum-org:cwmp-1-0">ACS_SetParameterValues_1</ns1:ID>

   </soapenv:Header> 
   <soapenv:Body> 
      <ns2:SetParameterValues soapenv:encodingStyle="http:// schemas.xmlsoap.org/soap/encoding/"
                              xmlns:ns2="urn:dslforum- org:cwmp-1-0"> 
         <ParameterList soapenc:arrayType="ns2:ParameterValueStruct[8]"
                        xsi:type="soapenc:Array"
                        xmlns:soapenc="http://schemas.xmlsoap.org/ soap/encoding/">

            <ParameterValueStruct xsi:type="ns2:ParameterValueStruct"> 
               <Name xsi:type="xsd:string">InternetGatewayDevice.WANDevice.
                  1.WANConnectionDevice.1.WANPPPConnection.1.Username</Name> 
               <Value xsi:type="xsd:string">10021Avf121212R0001@my-net1.de</ Value="Value">

            </ParameterValueStruct> 
            <ParameterValueStruct xsi:type="ns2:ParameterValueStruct"> 
               <Name xsi:type="xsd:string">InternetGatewayDevice.WANDevice.
                  1.WANConnectionDevice.1.WANPPPConnection.1.Password</Name> 
               <Value xsi:type="xsd:string"></Value> 
            </ParameterValueStruct> 
            <ParameterValueStruct xsi:type="ns2:ParameterValueStruct"> 
               <Name xsi:type="xsd:string">InternetGatewayDevice.Services.VoiceService.
                  1.VoiceProfile.1.SIP.RegistrarServer</Name> 
               <Value xsi:type="xsd:string">sip.my-net1.de</Value> 
            </ParameterValueStruct> 
            <ParameterValueStruct xsi:type="ns2:ParameterValueStruct"> 
               <Name xsi:type="xsd:string">InternetGatewayDevice.Services.VoiceService.
                  1.VoiceProfile.1.Line.1.SIP.URI</Name> 
               <Value xsi:type="xsd:string">sip:0121123456789@tel.my-net1.de</ Value="Value">

            </ParameterValueStruct> 
            <ParameterValueStruct xsi:type="ns2:ParameterValueStruct"> 
               <Name xsi:type="xsd:string">InternetGatewayDevice.Services.VoiceService.
                  1.VoiceProfile.1.STUNServer</Name> 
               <Value xsi:type="xsd:string">stun.my-net1.de</Value> 
            </ParameterValueStruct> 
            <ParameterValueStruct xsi:type="ns2:ParameterValueStruct"> 
               <Name xsi:type="xsd:string">InternetGatewayDevice.Services.VoiceService.
                  1.VoiceProfile.1.Line.1.SIP.AuthUserName</Name> 
               <Value xsi:type="xsd:string">anonymous</Value> 
            </ParameterValueStruct> 
            <ParameterValueStruct xsi:type="ns2:ParameterValueStruct"> 
               <Name xsi:type="xsd:string">InternetGatewayDevice.Services.VoiceService.
                  1.VoiceProfile.1.Line.1.SIP.AuthPassword</Name> 
               <Value xsi:type="xsd:string"></Value> 
            </ParameterValueStruct> 
            <ParameterValueStruct xsi:type="ns2:ParameterValueStruct"> 
               <Name xsi:type="xsd:string">InternetGatewayDevice.DeviceInfo.ProvisioningCode</Name>

               <Value xsi:type="xsd:string">001.000.000.000</Value> 
            </ParameterValueStruct> 
         </ParameterList> 
         <ParameterKey xsi:type="xsd:string">acs</ParameterKey> 
      </ns2:SetParameterValues> 
   </soapenv:Body> 
</soapenv:Envelope>

POST /testacs/services/cpemanagemnt HTTP/1.1
HOST: 87.234.237.172:8432
Cookie: JSESSIONID=F886A504A8289C03C91009D9DEF4682B
CONTENT-LENGTH: 554
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/"
               soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               xmlns:cwmp="urn:dslforum-org:cwmp-1-0"
               xmlns:xsi="http://www.w3.org/ 1999/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/1999/XMLSchema"> 
   <soap:Header> 
      <cwmp:ID soap:mustUnderstand="1">ACS_SetParameterValues_1</cwmp:ID>
   </ soap:Header="soap:Header">

   <soap:Body> 
      <cwmp:SetParameterValuesResponse> 
         <Status>0</Status>
      </cwmp:SetParameterValuesResponse>
   </soap:Body>
</ soap:Envelope="soap:Envelope">

HTTP/1.1 204 No Content
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build:  
CVSTag=JBoss_4_0_3_SP1 date=200510231054)/Tomcat-5.5
Date: Thu, 26 Jan 2007 10:33:16 GMT


(ssu)