El Informe Técnico 069 ( TR-069 ) es un documento del Broadband Forum que especifica el Protocolo de Gestión de WAN de CPE ( CWMP ). CWMP es un protocolo de capa de aplicación para la gestión y el aprovisionamiento remotos de equipos en las instalaciones del cliente (CPE) conectados a una red de Protocolo de Internet (IP). Proporciona funciones de soporte para la configuración automática, la gestión de imágenes de software o firmware, la gestión de módulos de software, la gestión de estado y rendimiento y el diagnóstico.
CPWM es un protocolo bidireccional basado en SOAP y HTTP que proporciona la comunicación entre un CPE y servidores de configuración automática (ACS). El protocolo está dirigido a la creciente cantidad de dispositivos de acceso a Internet , como módems , enrutadores y puertas de enlace , así como dispositivos de usuario final que se conectan a Internet, como decodificadores y teléfonos VoIP .
El TR-069 se publicó por primera vez en mayo de 2004, con modificaciones en 2006, 2007, 2010, julio de 2011 (versión 1.3), [1] y noviembre de 2013 (versión 1.4 am5) [2].
Otras iniciativas técnicas, como la Home Gateway Initiative (HGI), la Digital Video Broadcasting (DVB) y el WiMAX Forum respaldaron a CWMP como protocolo para la gestión remota de dispositivos y terminales de redes residenciales.
CWMP es un protocolo basado en texto. Las órdenes enviadas entre el dispositivo (CPE) y el servidor de configuración automática (ACS) se transportan a través de HTTP (o más frecuentemente HTTPS). En este nivel (HTTP), el CPE actúa como cliente y el ACS como servidor HTTP. Esto significa básicamente que el control sobre el flujo de la sesión de aprovisionamiento es responsabilidad exclusiva del dispositivo.
Para que el dispositivo se conecte al servidor, primero debe tener configurados ciertos parámetros. Estos incluyen la URL del servidor al que el dispositivo desea conectarse y el intervalo en el que el dispositivo iniciará la sesión de aprovisionamiento ( PeriodicInformInterval ). Además, si se requiere autenticación por razones de seguridad, se deben proporcionar datos como el nombre de usuario y la contraseña. [3]
Todas las comunicaciones y operaciones se realizan en el ámbito de la sesión de aprovisionamiento. La sesión siempre la inicia el dispositivo (CPE) y comienza con la transmisión de un mensaje Inform . Su recepción y la preparación del servidor para la sesión se indican mediante un mensaje InformResponse . Con ello concluye la etapa de inicialización de la sesión. El orden de las dos etapas siguientes depende del valor del indicador HoldRequests . Si el valor es false , la etapa de inicialización es seguida por la transmisión de las solicitudes del dispositivo; de lo contrario, las órdenes ACS se transmiten primero. La siguiente descripción supone que el valor es false .
En la segunda etapa, las órdenes se transmiten desde el dispositivo al ACS. Aunque el protocolo define múltiples métodos que pueden ser invocados por el dispositivo en el ACS, solo se encuentra uno comúnmente - TransferComplete - que se utiliza para informar al ACS de la finalización de una transferencia de archivo iniciada por una solicitud de descarga o carga emitida previamente. Esta etapa finaliza con la transmisión de una solicitud HTTP vacía al ACS.
En la tercera etapa, los roles cambian en el nivel CWMP. La respuesta HTTP para la solicitud HTTP vacía del dispositivo contendrá una solicitud CWMP del ACS. A continuación, se enviará una solicitud HTTP que contendrá una respuesta CWMP para la solicitud CWMP anterior. Se pueden transmitir varios pedidos uno por uno. Esta etapa (y toda la sesión de aprovisionamiento) finaliza con una respuesta HTTP vacía del ACS que indica que no hay más pedidos pendientes.
Existen determinados eventos que activarán la sesión de aprovisionamiento, entre ellos:
Como los datos vitales (como los nombres de usuario y las contraseñas) pueden transmitirse al CPE a través de CWMP, es esencial proporcionar un canal de transporte seguro y siempre autenticar el CPE frente al ACS. El transporte seguro y la autenticación de la identidad del ACS se pueden proporcionar fácilmente mediante el uso de HTTPS y la verificación del certificado del ACS. La autenticación del CPE es más problemática. La identidad del dispositivo se verifica en función de un secreto compartido (contraseña) a nivel HTTP. Las contraseñas se pueden negociar entre las partes (CPE-ACS) en cada sesión de aprovisionamiento. Cuando el dispositivo se comunica con el ACS por primera vez (o después de un restablecimiento de fábrica), se utilizan contraseñas predeterminadas. En redes grandes, es responsabilidad de la adquisición garantizar que cada dispositivo utilice credenciales únicas, su lista se entrega con los propios dispositivos y se protege. [ cita requerida ] .
La inicialización y el control del flujo de la sesión de aprovisionamiento son responsabilidad exclusiva del dispositivo, pero es posible que el ACS solicite el inicio de una sesión desde el dispositivo. El mecanismo de solicitud de conexión también se basa en HTTP. En este caso, el dispositivo (CPE) se pone en el papel de servidor HTTP. El ACS solicita una conexión desde el dispositivo visitando una URL negociada y realizando la autenticación HTTP. También se negocia un secreto compartido con el dispositivo por adelantado (por ejemplo, sesión de aprovisionamiento anterior) para evitar el uso de los CPE para ataques DDoS en el servidor de aprovisionamiento (ACS). Después de que el dispositivo envíe la confirmación, la sesión de aprovisionamiento debe iniciarse lo antes posible y no más tarde de 30 segundos después de que se transmita la confirmación.
El protocolo CWMP también define un mecanismo para alcanzar los dispositivos que están conectados detrás de NAT (por ejemplo, teléfonos IP, decodificadores ). Este mecanismo, basado en STUN y UDP NAT traversal, se define en el documento TR-069 Anexo G (anteriormente en TR-111).
La Enmienda 5 del protocolo introduce un método alternativo para ejecutar la Solicitud de Conexión a través de NAT basado en XMPP (ver Anexo K de la Enmienda 5 del TR-069 para más detalles).
La mayor parte de la configuración y el diagnóstico se realizan mediante la configuración y la recuperación del valor de los parámetros del dispositivo. Estos están organizados en una estructura jerárquica bien definida que es más o menos común para todos los modelos y fabricantes de dispositivos. Broadband Forum publica sus estándares de modelos de datos en dos formatos: archivos XML que contienen una especificación detallada de cada modelo de datos posterior y todos los cambios entre sus versiones y archivos PDF que contienen detalles legibles para humanos. Los estándares y extensiones compatibles deben estar claramente marcados en el modelo de datos del dispositivo. Esto debe estar en el campo Device.DeviceSummary o InternetGatewayDevice.DeviceSummary que se requiere a partir de Device:1.0 e InternetGatewayDevice:1.1 respectivamente. Si no se encuentra el campo, se implica InternetGatewayDevice:1.0 . A partir de Device:1.4 e InternetGatewayDevice:1.6 se introdujo un nuevo campo ( '<RO>'.SupportedDatamodel ) para la especificación de estándares compatibles.
El modelo siempre tiene su raíz en una clave única denominada Device o InternetGatewayDevice , según la elección del fabricante. En cada nivel de la estructura se permiten objetos y parámetros (o instancias de matriz). Las claves se construyen concatenando los nombres de los objetos y parámetros utilizando '.'(punto) como separador, p. ej. InternetGatewayDevice.Time.NTPServer1 .
Cada uno de los parámetros puede marcarse como escribible o no escribible. El dispositivo informa de esto en el mensaje GetParameterNamesResponse . El dispositivo no debe permitir el cambio de ningún parámetro marcado como de solo lectura. Las especificaciones y extensiones del modelo de datos marcan claramente el estado requerido de la mayoría de los parámetros.
Los valores aplicables al parámetro, su tipo y significado también están definidos con precisión por la norma.
Algunas partes del modelo de datos requieren la existencia de múltiples copias del subárbol. Los mejores ejemplos son los que describen tablas, por ejemplo, la tabla de reenvío de puertos. Un objeto que representa una matriz solo tendrá números de instancia o nombres de alias como sus hijos.
Un objeto de varias instancias puede ser de solo lectura o de escritura, según lo que represente. Los objetos de escritura permiten la creación y eliminación dinámica de sus elementos secundarios. Por ejemplo, si un objeto representa cuatro puertos físicos en un conmutador Ethernet, no debería ser posible agregarlos ni eliminarlos del modelo de datos. Si se agrega una instancia a un objeto, se le asigna un identificador. Después de asignarlos, los identificadores no pueden cambiar durante el ciclo de vida del dispositivo, excepto mediante un restablecimiento de fábrica.
Aunque la lista de parámetros y sus atributos está bien definida, la mayoría de los dispositivos no siguen los estándares por completo. Los problemas más comunes incluyen parámetros faltantes, identificadores de instancia omitidos (para objetos de múltiples instancias donde solo hay una instancia presente), nivel de acceso de parámetro incorrecto y uso correcto solo de valores válidos definidos. Por ejemplo, para el campo que indica el estándar admitido de protocolos WLAN, el valor 'g' debería indicar compatibilidad con 802.11b y 802.11g, y 'g-only' compatibilidad solo con 802.11g. Aunque valores como 'bg' o 'b/g' no son legales según los estándares del Broadband Forum, se encuentran muy comúnmente en los modelos de datos de dispositivos.
Todo el aprovisionamiento se basa en un conjunto definido de operaciones simples. Cada pedido se considera atómico, aunque no se admiten transacciones. Si el dispositivo no puede completar el pedido, se debe devolver un error adecuado al ACS; el dispositivo nunca debe interrumpir la sesión de aprovisionamiento.
Para una lista más completa de operaciones y un análisis del protocolo, véase [4]
El compromiso de un ACS de un ISP o del enlace entre un ACS y un CPE por parte de entidades no autorizadas puede dar acceso a los dispositivos habilitados con TR-069 de toda la base de suscriptores de un proveedor de servicios . La información del cliente y el funcionamiento del dispositivo estarían disponibles para los atacantes potenciales, incluidas otras direcciones MAC en las redes del cliente. La redirección encubierta de consultas DNS a un servidor DNS no autorizado podría ser posible, e incluso actualizaciones de firmware subrepticias con funciones de puerta trasera. [5] Se ha descubierto que el software ACS TR-069 a menudo se implementa de forma insegura. [6] Se encontraron fallas en las implementaciones combinadas de TR-064 (configuración de CPE DSL del lado LAN) y TR-069 (CWMP), que reutilizaban el mismo punto final HTTP a través de Internet público para solicitudes de conexión sin las protecciones adecuadas, en dispositivos de varios proveedores y son explotadas por botnets basados en Mirai y otro malware. [7] [8]
{{cite book}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace )