Hispanopedia Wiki
Articulo de referencia

Protocolo de aplicación restringido

El Protocolo de Aplicación Restringida ( CoAP ) es un protocolo de aplicación de Internet especializado , basado en UDP , para dispositivos con recursos limitados, tal como se d...

Hispanopedia WikiContenido en espanolLectura gratuita

El Protocolo de Aplicación Restringida ( CoAP ) es un protocolo de aplicación de Internet especializado , basado en UDP , para dispositivos con recursos limitados, tal como se define en el RFC 7252 (publicado en 2014). Permite que estos dispositivos, denominados "nodos", se comuniquen con Internet mediante protocolos similares. CoAP está diseñado para su uso entre dispositivos en la misma red con recursos limitados (por ejemplo, redes de baja potencia y con pérdidas), entre dispositivos y nodos generales de Internet, y entre dispositivos en diferentes redes con recursos limitados conectadas a Internet. CoAP también se utiliza mediante otros mecanismos, como los SMS en redes de comunicación móvil.

CoAP es un protocolo de capa de aplicación diseñado para su uso en dispositivos de Internet con recursos limitados, como nodos de redes de sensores inalámbricos . CoAP está diseñado para traducirse fácilmente a HTTP para una integración simplificada con la web, al tiempo que cumple con requisitos especializados como soporte para multidifusión , sobrecarga muy baja y simplicidad. [ 1 ] [ 2 ] La multidifusión, la sobrecarga baja y la simplicidad son importantes para el Internet de las cosas (IoT) y la comunicación máquina a máquina (M2M), que tienden a estar integrados y tienen mucha menos memoria y fuente de alimentación que los dispositivos de Internet tradicionales. Por lo tanto, la eficiencia es muy importante. CoAP puede ejecutarse en la mayoría de los dispositivos que admiten UDP o un análogo de UDP.

El Grupo de Trabajo sobre Entornos RESTful Restringidos ( CoRE ) del Grupo de Trabajo de Ingeniería de Internet ( IETF ) ha llevado a cabo la mayor parte del trabajo de estandarización de este protocolo. Para adaptarlo a las aplicaciones de IoT y M2M, se han añadido diversas funciones nuevas.

Especificación

El núcleo del protocolo se especifica en el RFC 7252. Se han propuesto varias extensiones, en particular: 

  • RFC 7641 (2015) Observación de recursos en el protocolo de aplicación restringido 
  • RFC 7959 (2016) Transferencias por bloques en el protocolo de aplicación restringida (CoAP) 
  • RFC 8323 (2018) CoAP (Protocolo de Aplicación Restringida) sobre TCP, TLS y WebSockets 
  • RFC 8974 (2021) Tokens extendidos y clientes sin estado en el protocolo de aplicación restringida (CoAP) 

Formatos de mensajes

CoAP utiliza dos tipos de mensajes, solicitudes y respuestas, con un formato de encabezado binario simple. Por defecto, CoAP se enlaza con UDP y, opcionalmente, con DTLS , lo que proporciona un alto nivel de seguridad en las comunicaciones. Cuando se enlaza con UDP, el mensaje completo debe caber en un único datagrama. Al utilizarse con 6LoWPAN , tal como se define en la RFC 4944, los mensajes deben caber en una única trama IEEE 802.15.4 para minimizar la fragmentación.

El mensaje CoAP más pequeño tiene una longitud de 4 bytes si se omiten los campos de token, opciones y carga útil, es decir, si solo consta del encabezado CoAP. El encabezado va seguido del valor del token (de 0 a 8 bytes), que puede ir seguido de una lista de opciones en un formato optimizado de tipo-longitud-valor. Los bytes posteriores al encabezado, el token y las opciones (si las hay) se consideran la carga útil del mensaje, que se prefija con el marcador de carga útil de un byte (0xFF). La longitud de la carga útil viene determinada por la longitud del datagrama.

Encabezado CoAP de tamaño fijo

Los primeros 4 bytes son obligatorios en todos los datagramas CoAP; constituyen la cabecera de tamaño fijo.

Estos campos se pueden extraer de estos 4 bytes en C mediante estas macros:

#define COAP_HEADER_VERSION(data) ( (0xC0 & (data)[0]) >> 6 ) #define COAP_HEADER_TYPE(data) ( (0x30 & (data)[0]) >> 4 ) #define COAP_HEADER_TKL(data) ( (0x0F & (data)[0]) >> 0 ) #define COAP_HEADER_CLASS(data) ( ((data)[1] >> 5) & 0x07 ) #define COAP_HEADER_CODE(data) ( ((data)[1] >> 0) & 0x1F ) #define COAP_HEADER_MID(data) ( ((data)[2] << 8) | (data)[3] )

Versión (ver) (2 bits)

Indica el número de versión de CoAP.

Tipo (2 bits)

Esto describe el tipo de mensaje del datagrama para los dos contextos de tipo de mensaje de Solicitud y Respuesta.
  • Pedido
    • 0  : Confirmable  : Este mensaje espera un mensaje de confirmación correspondiente.
    • 1  : No confirmable  : Este mensaje no espera un mensaje de confirmación.
  • Respuesta
    • 2  : Acuse de recibo  : Este mensaje es una respuesta que acusa recibo de un mensaje confirmable.
    • 3  : Reinicio  : Este mensaje indica que se recibió un mensaje pero no se pudo procesar.

Longitud del token (4 bits)

Indica la longitud del campo Token de longitud variable, que puede ser de 0 a 8 bytes.

Código de solicitud/respuesta (8 bits)

Los tres bits más significativos forman un número conocido como la "clase", que es análoga a la clase de códigos de estado HTTP . Los cinco bits menos significativos forman un código que comunica más detalles sobre la solicitud o respuesta. El código completo se comunica normalmente en el formato class.code.

Puedes encontrar los últimos códigos de solicitud/respuesta de CoAP en, aunque la siguiente lista ofrece algunos ejemplos:

  • Método: 0.XX
    1. VACÍO
    2. CONSEGUIR
    3. CORREO
    4. PONER
    5. BORRAR
    6. BUSCAR
    7. PARCHE
    8. iPATCH
  • Éxito: 2.XX
    1. Creado
    2. Eliminado
    3. Válido
    4. Cambió
    5. Contenido
    6. Continuar
  • Error del cliente: 4.XX
    1. Solicitud incorrecta
    2. No autorizado
    3. Mala opción
    4. Prohibido
    5. Extraviado
    6. Método no permitido
    7. No es aceptable
    8. Solicitud de entidad incompleta
    9. Conflicto
    10. Fallo en la condición previa
    11. La entidad de solicitud es demasiado grande.
    12. Formato de contenido no compatible
  • Error del servidor: 5.XX
    1. Error Interno del Servidor
    2. No implementado
    3. Puerta de enlace defectuosa
    4. Servicio No Disponible
    5. Tiempo de espera de la puerta de enlace
    6. No se admite el uso de proxy.
  • Códigos de señalización: 7.XX
    1. Sin asignar
    2. CSM
    3. Silbido
    4. Apestar
    5. Liberar
    6. Abortar

Identificador del mensaje (16 bits)

Se utiliza para detectar la duplicación de mensajes y para hacer coincidir los mensajes de tipo acuse de recibo/restablecimiento con los mensajes de tipo confirmable/no confirmable.

Simbólico

Cada solicitud incluye un token (que puede ser de longitud cero) cuyo valor fue generado por el cliente. El servidor debe devolver al cliente, en la respuesta correspondiente, el valor de cada token sin ninguna modificación. Su función es servir como identificador local del cliente para relacionar solicitudes y respuestas, especialmente en el caso de solicitudes concurrentes.

La correspondencia entre solicitudes y respuestas no se realiza mediante el ID del mensaje, ya que la respuesta puede enviarse en un mensaje diferente al de la confirmación (que utiliza el ID del mensaje para la correspondencia). Por ejemplo, esto podría hacerse para evitar retransmisiones si la obtención del resultado requiere tiempo. Esta respuesta independiente se denomina «respuesta separada». En cambio, transmitir la respuesta directamente en la confirmación se denomina «respuesta integrada», lo cual se considera preferible por razones de eficiencia.

Opción

delta de opción:

  • De 0 a 12: Para delta entre 0 y 12: Representa el valor delta exacto entre el último ID de opción y el ID de opción deseado, sin valor delta extendido de opción.
  • 13: Para delta de 13 a 268: El delta extendido de la opción es un valor de 8 bits que representa el valor delta de la opción menos 13.
  • 14: Para delta de 269 a 65.804: El delta de opción extendido es un valor de 16 bits que representa el valor delta de la opción menos 269.
  • 15: Reservado para el marcador de carga útil, donde el delta de la opción y la longitud de la opción se establecen juntos como 0xFF.

Longitud de la opción:

  • De 0 a 12: Para longitudes de opción entre 0 y 12: Representa el valor de longitud exacto, sin valor de longitud de opción extendida.
  • 13: Para longitudes de opción de 13 a 268: La longitud de opción extendida es un valor de 8 bits que representa el valor de la longitud de opción menos 13.
  • 14: Para longitudes de opción de 269 a 65.804: La longitud de opción extendida es un valor de 16 bits que representa el valor de la longitud de opción menos 269.
  • 15: Reservado para uso futuro. Es un error que el campo de longitud de opción esté configurado en 0xFF.

Valor de la opción:

  • El tamaño del campo de valor de la opción se define mediante el valor de longitud de la opción en bytes.
  • La semántica y el formato de este campo dependen de la opción correspondiente.

Implementaciones de protocolos activos

Implementaciones de proxy

Existen implementaciones de proxy que proporcionan funcionalidad de proxy directo o inverso para el protocolo CoAP, así como implementaciones que traducen entre protocolos como HTTP y CoAP.

Los siguientes proyectos proporcionan funcionalidad de proxy:

  • Squid 3.1.9 con módulo de mapeo HTTP-CoAP transparente
  • Proxy de jcoap
  • Californium cf-proxy2
  • CoAPthon
  • FreeCoAP
  • libcoap

Proyectos que utilizan CoAP

Implementaciones de protocolo inactivas

Comunicación del grupo CoAP

En muchos dominios de aplicación de CoAP es esencial tener la capacidad de acceder a varios recursos CoAP como un grupo, en lugar de acceder a cada recurso individualmente (por ejemplo, encender todas las luces habilitadas para CoAP en una habitación con una sola solicitud CoAP activada al accionar el interruptor de luz). Para abordar esta necesidad, el IETF ha desarrollado una extensión opcional para CoAP en forma de un RFC experimental: Comunicación de grupo para CoAP - RFC 7390 [ 3 ]. Esta extensión se basa en la multidifusión IP para entregar la solicitud CoAP a todos los miembros del grupo. El uso de la multidifusión tiene ciertas ventajas, como la reducción del número de paquetes necesarios para entregar la solicitud a los miembros. Sin embargo, la multidifusión también tiene sus limitaciones, como la baja fiabilidad y la dificultad para almacenar en caché. Un método alternativo para la comunicación de grupo CoAP que utiliza unidifusión en lugar de multidifusión se basa en tener un intermediario donde se crean los grupos. Los clientes envían sus solicitudes grupales al intermediario, que a su vez envía solicitudes unicast individuales a los miembros del grupo, recopila las respuestas de ellos y envía una respuesta agregada al cliente. [ 4 ]

Seguridad

CoAP define cuatro modos de seguridad: [ 5 ]

  • NoSec, donde DTLS está deshabilitado
  • En PreSharedKey, donde DTLS está habilitado, existe una lista de claves precompartidas, y cada clave incluye una lista de los nodos con los que se puede comunicar. Los dispositivos deben ser compatibles con el conjunto de cifrado AES.
  • RawPublicKey, donde DTLS está habilitado y el dispositivo utiliza un par de claves asimétricas sin certificado, que se valida fuera de banda. Los dispositivos deben ser compatibles con el conjunto de cifrado AES y los algoritmos de curva elíptica para el intercambio de claves.
  • Certificado, donde DTLS está habilitado y el dispositivo utiliza certificados X.509 para la validación.

Se han realizado investigaciones para optimizar DTLS mediante la implementación de asociados de seguridad como recursos CoAP en lugar de utilizar DTLS como un envoltorio de seguridad para el tráfico CoAP. Estas investigaciones han indicado mejoras de hasta 6,5 ​​veces en comparación con las implementaciones no optimizadas. [ 6 ]

Además de DTLS, RFC8613 [ 7 ] define el protocolo Object Security for Constrained RESTful Environments ( OSCORE ) que proporciona seguridad para CoAP en la capa de aplicación.

Problemas de seguridad

Aunque el protocolo estándar incluye disposiciones para mitigar la amenaza de ataques de amplificación DDoS , [ 8 ] estas disposiciones no se implementan en la práctica, [ 9 ] lo que resulta en la presencia de más de 580 000 objetivos ubicados principalmente en China y ataques de hasta 320  Gbit/s. [ 10 ]

Véase también

Referencias

  1. ↑ RFC 7252, Protocolo de aplicación restringida (CoAP)
  2. ↑ " Integración de redes de sensores inalámbricos con la web. Archivado el 30/08/2017 en Wayback Machine ", Walter, Colitti 2011
  3. ↑ RFC 7390, Comunicación de grupo para CoAP
  4. ^ " Comunicación grupal flexible basada en unidifusión para dispositivos habilitados para CoAP ", Ishaq, I.; Hoebeke, J.; Van den Abeele, F.; Rossey, J.; Moerman, I .; Demeester, P. Sensores 2014
  5. ↑ RFC 7252, Protocolo de aplicación restringida (CoAP)
  6. ↑ Capossele, Angelo; Cervo, Valerio; De Cicco, Gianluca; Petrioli, Chiara (junio de 2015). «Seguridad como recurso CoAP: una implementación DTLS optimizada para el IoT». 2015 IEEE International Conference on Communications (ICC) . IEEE. págs. 529–554 . doi : 10.1109/ICC.2015.7248379 . ISBN  978-1-4673-6432-4. S2CID 12568959 . 
  7. ↑ Palombini, Francesca; Seitz, Ludwig; Selander, Goeran; Mattsson, John (2019). "Object Security for Constrained RESTful Environments (OSCORE)" . tools.ietf.org . doi : 10.17487/RFC8613 . S2CID 58380874. Consultado el 7 de mayo de 2021 . 
  8. ↑ "TLS 1.3 nos salvará a todos, y otras razones por las que el IoT sigue siendo inseguro", Dani Grant, 24/12/2017
  9. ↑ "Cuando las máquinas no pueden hablar: Problemas de seguridad y privacidad de los protocolos de datos de máquina a máquina", Federico Maggi y Rainer Vosseler, 6 de diciembre de 2018
  10. ↑ "El protocolo CoAP es la próxima gran novedad para los ataques DDoS", Catalin Cimpanu, 5 de diciembre de 2018
  • RFC 7252 "El protocolo de aplicación restringida (CoAP)"
  • coap.me – Servidor de pruebas CoAP gestionado por la Universidad de Bremen