TR-069

Last updated

Technical Report 069 (TR-069) is a technical specification of the Broadband Forum that defines an application layer protocol for remote management and provisioning of customer-premises equipment (CPE) connected to an Internet Protocol (IP) network. TR-069 uses the CPE WAN Management Protocol (CWMP) which provides support functions for auto-configuration, software or firmware image management, software module management, status and performance managements, and diagnostics.

Contents

The CPE WAN Management Protocol is a bidirectional SOAP- and HTTP-based protocol, and provides the communication between a CPE and auto configuration servers (ACS). The protocol addresses the growing number of different Internet access devices such as modems, routers, gateways, as well as end-user devices which connect to the Internet, such as set-top boxes, and VoIP-phones.

TR-069 was first published in May 2004, with amendments in 2006, 2007, 2010, July 2011 (version 1.3), [1] and November 2013 (version 1.4 am5) [2]

Other technical initiatives, such as the Home Gateway Initiative (HGI), Digital Video Broadcasting (DVB) and WiMAX Forum endorsed CWMP as the protocol for remote management of residential networking devices and terminals.

Communication

Transport

CWMP is a text based protocol. Orders sent between the device (CPE) and auto configuration server (ACS) are transported over HTTP (or more frequently HTTPS). At this level (HTTP), the CPE acts as client and ACS as HTTP server. This essentially means that control over the flow of the provisioning session is the sole responsibility of the device.

Remote CPE Control via TR-069.svg

Configuration parameters

In order for the device to connect to the server, it needs to have certain parameters configured first. These include the URL of the server the device wants to connect to and the interval at which the device will initiate the provisioning session (PeriodicInformInterval). Additionally, if authentication is required for security reasons, data such as the username and the password needs to be provided. [3]

Provisioning session

All communications and operations are performed in the scope of the provisioning session. The session is always started by the device (CPE) and begins with the transmission of an Inform message. Its reception and readiness of the server for the session is indicated by an InformResponse message. That concludes the session initialization stage. The order of the next two stages depends on the value of the flag HoldRequests. If the value is false the initialization stage is followed by the transmission of device requests, otherwise ACS orders are transmitted first. The following description assumes the value is false.

In the second stage, orders are transmitted from the device to the ACS. Even though the protocol defines multiple methods that may be invoked by the device on the ACS, only one is commonly found - TransferComplete - which is used to inform the ACS of the completion of a file transfer initiated by a previously issued Download or Upload request. This stage is finalized by transmission of empty HTTP-request to the ACS.

In the third stage the roles change on the CWMP level. The HTTP-response for the empty HTTP-request by the device will contain a CWMP-request from the ACS. This will subsequently be followed by an HTTP-request containing a CWMP-response for the previous CWMP-request. Multiple orders may be transmitted one-by-one. This stage (and the whole provisioning session) is terminated by an empty HTTP-response from the ACS indicating that no more orders are pending.

Session triggers

There are certain events that will trigger the provisioning session. These include:

  • Bootstrap – when device contacts the server for the first time, the server URL changed, or the device settings were reset to default;
  • Periodic – the device is scheduled to perform a periodic session, as per the PeriodicInformInterval settings;
  • Connection request – the device responds to the server's request for a connection;
  • Value change – value for a parameter that is being monitored has changed;
  • Boot – after the device was reset or lost power and was reconnected;
  • Scheduled – when the device was previously instructed by the server to initialize an additional session with ScheduleInform command;
  • Transfer complete – after the device finished downloading or uploading files requested by the server;
  • Diagnostic complete – once the device finishes a diagnostic. [3]

Security and authentication

As vital data (like user names and passwords) may be transmitted to the CPE via CWMP, it is essential to provide a secure transport channel and always authenticate the CPE against the ACS. Secure transport and authentication of the ACS identity can easily be provided by usage of HTTPS and verification of the ACS certificate. Authentication of the CPE is more problematic. The identity of the device is verified based on a shared secret (password) at the HTTP level. Passwords may be negotiated between the parties (CPE-ACS) at every provisioning session. When the device contacts the ACS for the first time (or after a factory-reset) default passwords are used. In large networks it is the responsibility of the procurement to ensure each device is using unique credentials, their list is delivered with the devices themselves and secured.[ citation needed ].

Connection request

Initialization and control of the provisioning session flow is the sole responsibility of the device, but it is possible for the ACS to request a session start from the device. The connection request mechanism is also based on HTTP. In this case the device (CPE) is put in the role of HTTP-server. The ACS requests a connection from the device by visiting a negotiated URL and performing HTTP Authentication. A shared secret is also negotiated with the device in advance (e.g. previous provisioning session) to prevent the usage of CPEs for DDoS attacks on the provisioning server (ACS). After confirmation is sent by the device the provisioning session should be started as soon as possible and not later than 30 seconds after confirmation is transmitted.

Connection request over NAT

The CWMP protocol also defines a mechanism for reaching the devices that are connected behind NAT (e.g. IP-Phones, Set-top boxes). This mechanism, based on STUN and UDP NAT traversal, is defined in document TR-069 Annex G (formerly in TR-111).

Amendment 5 of the protocol introduces alternative method of executing Connection Request via NAT based on XMPP (see Annex K of TR-069 Amendment 5 for details).

Data model

Most of the configuration and diagnostics is performed through setting and retrieving the value of the device parameters. These are organized in a well defined hierarchical structure that is more or less common to all device models and manufacturers. Broadband Forum publishes its data model standards in two formats - XML files containing a detailed specification of each subsequent data model and all of the changes between their versions and PDF files containing human-readable details. Supported standards and extensions should be clearly marked in the device data model. This should be in the field Device.DeviceSummary or InternetGatewayDevice.DeviceSummary which is required starting from Device:1.0 and InternetGatewayDevice:1.1 respectively. If the field is not found InternetGatewayDevice:1.0 is implied. As of Device:1.4 and InternetGatewayDevice:1.6 new field ( '<RO>'.SupportedDatamodel) for supported standard specification was introduced.

The model is always rooted in the single key named Device or InternetGatewayDevice depending on the manufacturer's choice. At each level of the structure objects and parameters (or array-instances) are allowed. Keys are constructed by concatenating the names of objects and parameter using '.'(dot) as a separator, e.g. InternetGatewayDevice.Time.NTPServer1 .

Each of the parameters may be marked as writable or non-writable. This is reported by the device in GetParameterNamesResponse message. The device should not permit the change of any parameter marked as read-only. Data model specifications and extensions clearly mark required status of most of the parameters.

Values applicable for the parameter, their type and meaning are also precisely defined by the standard.

Multi-instance objects

Some parts of the data model require the existence of multiple copies of the subtree. The best examples are those describing tables, e.g. Port Forwarding Table. An object representing an array will only have instance numbers or alias names as its children.

A multi-instance object may be writable or read-only, depending on what it represents. Writable objects allow dynamic creation and removal of their children. For example, if an object represents four physical ports on an Ethernet switch, then it should not be possible to add or remove them from the data model. If an instance is added to an object, an identifier is assigned. After being assigned, identifiers cannot change during the life-cycle of the device, except by factory reset.

Common problems

Even though the list of the parameters and their attributes is well-defined, most of the devices do not follow standards completely. Most common problems include missing parameters, omitted instance identifiers (for multi-instance objects where only one instance is present), wrong parameter access level and correctly using only defined valid values. For example, for the field that indicates supported standard of WLAN protocols, the value 'g' should indicate support of 802.11b and 802.11g, and 'g-only' support only of 802.11g. Even though values such as 'bg' or 'b/g' are not legal according to the Broadband Forum standards, they are very commonly found in device data models.

Common operations

The whole provisioning is built on top of a defined set of simple operations. Each order is considered atomic, though there is no support of transactions. If the device cannot fulfill the order a proper error must be returned to the ACS – the device should never break the provisioning session.

MessageDescription
GetParameterNamesRetrieve list of supported parameters from the device.
GetParameterValuesRetrieve current value of the parameter(s) identified by keys. A variation of this call takes an object as its key. It retrieves all of the object's parameters
SetParameterValuesSet the value of one or more parameters
GetParameterAttributesRetrieve attributes of one or more parameters
SetParameterAttributesSet attributes of one or more parameters
DownloadOrder CPE to download and use a file, specified by URL. File types include Firmware Image, Configuration File, Ringer file, etc.
UploadOrder CPE to upload a file to a specified destination. File types include the current configuration file, log files, etc.
AddObjectAdd new instance to an object
DeleteObjectRemove instance from an object

For a more complete list of operations and an analysis of the protocol, see [4]

High-level operations possible through TR-069

Security

The compromise of an ISP ACS or the link between an ACS and CPE by unauthorized entities can yield access to the TR-069-enabled devices of a service provider's entire subscriber base. Customer information and device operation would be available to the potential attackers, including other MAC addresses on client's networks. Covert redirection of DNS queries to a rogue DNS server might be possible, and even surreptitious firmware updates with backdoor features. [5] TR-069 ACS software has been found to be often implemented insecurely. [6] Flaws in combined implementations of TR-064 (LAN side DSL CPE configuration) and TR-069 (CWMP), that reused the same HTTP endpoint over public internet for Connection Requests without proper protections, were found in devices by various vendors and are exploited by Mirai-based botnet and other malware. [7] [8]

See also

Related Research Articles

The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.

The Lightweight Directory Access Protocol is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.

In telecommunication, provisioning involves the process of preparing and equipping a network to allow it to provide new services to its users. In National Security/Emergency Preparedness telecommunications services, "provisioning" equates to "initiation" and includes altering the state of an existing priority service or capability.

Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behaviour. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more.

<span class="mw-page-title-main">Email client</span> Computer program used to access and manage a users email

An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises in 1991 as an access server authentication and accounting protocol. It was later brought into IEEE 802 and IETF standards.

In computing, Internet Key Exchange is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP. IKE uses X.509 certificates for authentication ‒ either pre-shared or distributed using DNS ‒ and a Diffie–Hellman key exchange to set up a shared session secret from which cryptographic keys are derived. In addition, a security policy for every peer which will connect must be manually maintained.

SOCKS is an Internet protocol that exchanges network packets between a client and server through a proxy server. SOCKS5 optionally provides authentication so only authorized users may access a server. Practically, a SOCKS server proxies TCP connections to an arbitrary IP address, and provides a means for UDP packets to be forwarded.

In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent to provide a user name and password when making a request. In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>, where credentials is the Base64 encoding of ID and password joined by a single colon :.

Extensible Authentication Protocol (EAP) is an authentication framework frequently used in network and internet connections. It is defined in RFC 3748, which made RFC 2284 obsolete, and is updated by RFC 5247. EAP is an authentication framework for providing the transport and usage of material and parameters generated by EAP methods. There are many methods defined by RFCs, and a number of vendor-specific methods and new proposals exist. EAP is not a wire protocol; instead it only defines the information from the interface and the formats. Each protocol that uses EAP defines a way to encapsulate by the user EAP messages within that protocol's messages.

<span class="mw-page-title-main">Broadband remote access server</span>

A broadband remote access server routes traffic to and from broadband remote access devices such as digital subscriber line access multiplexers (DSLAM) on an Internet service provider's (ISP) network. BRAS can also be referred to as a broadband network gateway or border network gateway (BNG).

OMA Device Management is a device management protocol specified by the Open Mobile Alliance (OMA) Device Management (DM) Working Group and the Data Synchronization (DS) Working Group. The current approved specification of OMA DM is version 1.2.1, the latest modifications to this version released in June 2008. The candidate release 2.0 was scheduled to be finalized in September 2013.

IEC 60870 part 6 in electrical engineering and power system automation, is one of the IEC 60870 set of standards which define systems used for telecontrol in electrical engineering and power system automation applications. The IEC Technical Committee 57 have developed part 6 to provide a communication profile for sending basic telecontrol messages between two systems which is compatible with ISO standards and ITU-T recommendations.

OpenWebNet is a communications protocol developed by Bticino since 2000.

TR-196 is a Broadband Forum technical specification. Its official title is "Femto Access Point Service Data Model." The purpose of this Technical Report is to specify the Data Model for the Femto Access Point (FAP) for remote management purposes using the TR-069 CWMP.

IEEE 1905.1 is an IEEE standard which defines a network enabler for home networking supporting both wireless and wireline technologies: IEEE 802.11, IEEE 1901 power-line networking, IEEE 802.3 Ethernet and Multimedia over Coax (MoCA).

IMS is a set of specifications to offer multimedia services through IP protocol. This makes it possible to incorporate all kinds of services, such as voice, multimedia and data, on an accessible platform through any Internet connection.

A software-defined perimeter (SDP), also called a "black cloud", is an approach to computer security which evolved from the work done at the Defense Information Systems Agency (DISA) under the Global Information Grid (GIG) Black Core Network initiative around 2007. Software-defined perimeter (SDP) framework was developed by the Cloud Security Alliance (CSA) to control access to resources based on identity. Connectivity in a Software Defined Perimeter is based on a need-to-know model, in which device posture and identity are verified before access to application infrastructure is granted. Application infrastructure is effectively “black”, without visible DNS information or IP addresses. The inventors of these systems claim that a Software Defined Perimeter mitigates the most common network-based attacks, including: server scanning, denial of service, SQL injection, operating system and application vulnerability exploits, man-in-the-middle, pass-the-hash, pass-the-ticket, and other attacks by unauthorized users.

Port Control Protocol (PCP) is a computer networking protocol that allows hosts on IPv4 or IPv6 networks to control how the incoming IPv4 or IPv6 packets are translated and forwarded by an upstream router that performs network address translation (NAT) or packet filtering. By allowing hosts to create explicit port forwarding rules, handling of the network traffic can be easily configured to make hosts placed behind NATs or firewalls reachable from the rest of the Internet, which is a requirement for many applications.

OMA Lightweight M2M (LwM2M) is a protocol from the Open Mobile Alliance for machine to machine (M2M) or Internet of things (IoT) device management and service enablement. The LwM2M standard defines the application layer communication protocol between an LwM2M Server and an LwM2M Client which is located in an IoT device. It offers an approach for managing IoT devices and allows devices and systems from different vendors to co-exist in an IoT- ecosystem. LwM2M was originally built on Constrained Application Protocol (CoAP) but later LwM2M versions also support additional transfer protocols.

References

  1. ↑ "CPE WAN Management Protocol" (PDF). TR-069 Amendment 4. Broadband Forum. July 2011. Retrieved February 16, 2012.
  2. ↑ "CPE WAN Management Protocol" (PDF). TR-069 Amendment 5. Broadband Forum. November 2013. Retrieved March 3, 2014.
  3. 1 2 "Crash course in TR-069 (CWMP)". AVSystem. Retrieved November 16, 2020.
  4. ↑ Basicevic, Ilija (2023). "An analysis of the TR069 (CWMP) protocol". 2023 46th MIPRO ICT and Electronics Convention (MIPRO). Opatija, Croatia. pp. 460–465. doi:10.23919/MIPRO57284.2023.10159841. ISBN   978-953-233-104-2. S2CID   259299865.{{cite book}}: CS1 maint: location missing publisher (link)
  5. ↑ Many home routers supplied by ISPs can be compromised en masse, researchers say
  6. ↑ Check Point's Malware and Vulnerability Research Group uncovered several flaws in solutions from ACS vendors
  7. ↑ "Mirai attack on home routers and alleged TR-069 vulnerability". www.qacafe.com. Retrieved April 25, 2020.
  8. ↑ "Practical ways to misuse a router". blog.ptsecurity.com. Archived from the original on June 22, 2017. Retrieved June 16, 2017.

Configuration Server

Open source implementations

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.