Protocole d'application contraint - Constrained Application Protocol

Le protocole d'application contraint ( CoAP ) est un protocole d'application Internet spécialisé pour les périphériques contraints, tel que défini dans la RFC 7252 . Il permet à ces appareils contraints appelés « nœuds » de communiquer avec l'Internet au sens large en utilisant des protocoles similaires. CoAP est conçu pour être utilisé entre des appareils sur le même réseau contraint (par exemple, des réseaux à faible puissance et avec perte), entre des appareils et des nœuds généraux sur Internet, et entre des appareils sur différents réseaux contraints, tous deux reliés par un Internet. CoAP est également utilisé via d'autres mécanismes, tels que les SMS sur les réseaux de communication mobile.

CoAP est un protocole de couche de service destiné à être utilisé dans les appareils Internet à ressources limitées, tels que les nœuds de réseau de capteurs sans fil . CoAP est conçu pour se traduire facilement en HTTP pour une intégration simplifiée avec le Web, tout en répondant à des exigences spécialisées telles que la prise en charge de la multidiffusion , une très faible surcharge et la simplicité. La multidiffusion, la faible surcharge et la simplicité sont importantes pour l' Internet des objets (IoT) et la communication de machine à machine (M2M), qui ont tendance à être profondément intégrées et ont beaucoup moins de mémoire et d'alimentation que les appareils Internet traditionnels. Par conséquent, l'efficacité est très importante. CoAP peut fonctionner sur la plupart des appareils prenant en charge UDP ou un analogue UDP.

Le groupe de travail sur les environnements RESTful contraints ( CoRE ) de l' Internet Engineering Task Force ( IETF ) a effectué les principaux travaux de normalisation pour ce protocole. Afin de rendre le protocole adapté aux applications IoT et M2M, diverses nouvelles fonctions ont été ajoutées.

spécification

Le cœur du protocole est spécifié dans la RFC 7252. Différentes extensions ont été proposées, notamment :

• RFC  7641 (2015) Observation des ressources dans le protocole d'application contraint
• RFC  7959 (2016) Transferts par blocs dans le protocole d'application contraint (CoAP)
• RFC  8323 (2018) CoAP (Constrained Application Protocol) sur TCP, TLS et WebSockets
• RFC  8974 (2021) Jetons étendus et clients sans état dans le protocole d'application contraint (CoAP)

Formats des messages

Le plus petit message CoAP a une longueur de 4 octets, en omettant le jeton, les options et la charge utile. CoAP utilise deux types de messages, demandes et réponses, en utilisant un format d'en-tête de base simple et binaire. L'en-tête de base peut être suivi d'options dans un format Type-Longueur-Valeur optimisé. CoAP est par défaut lié à UDP et éventuellement à DTLS , offrant un niveau élevé de sécurité des communications.

Tous les octets après les en-têtes du paquet sont considérés comme le corps du message. La longueur du corps du message est impliquée par la longueur du datagramme. Lorsqu'il est lié à UDP, le message entier DOIT tenir dans un seul datagramme. Lorsqu'ils sont utilisés avec 6LoWPAN comme défini dans la RFC 4944, les messages DEVRAIENT tenir dans une seule trame IEEE 802.15.4 pour minimiser la fragmentation.

En-tête fixe CoAP : version, type, longueur du jeton, code de demande/réponse et ID de message.

Les 4 premiers octets sont obligatoires dans tous les datagrammes CoAP.

Ces champs peuvent être facilement extraits de ces 4 octets en C via ces 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]) )

Version (VER) (2 bits)

Indique le numéro de version de CoAP.

Type (2 bits)

Ceci décrit le type de message du datagramme pour les deux contextes de type de message Demande et Réponse.

• Demander
  • 0 : Confirmable : Ce message attend un message d'accusé de réception correspondant.
  • 1 : Non confirmable : Ce message n'attend pas de message de confirmation.
• Réponse
  • 2 : Accusé de réception : Ce message est une réponse qui accuse réception d'un message confirmable
  • 3 : Reset : Ce message indique qu'il a reçu un message mais n'a pas pu le traiter.

Longueur du jeton (4 bits)

Indique la longueur du champ Token de longueur variable, qui peut avoir une longueur de 0 à 8 octets.

Code de requête/réponse (8 bits)

Les trois bits les plus significatifs forment un nombre appelé "classe", qui est analogue à la classe des codes d'état HTTP . Les cinq bits les moins significatifs forment un code qui communique des détails supplémentaires sur la demande ou la réponse. L'intégralité du code est généralement communiquée sous la forme class.code.

Vous pouvez trouver les derniers codes de demande/réponse CoAP sur [1] , bien que la liste ci-dessous donne quelques exemples :

Identifiant du message (16 bits)

Utilisé pour détecter la duplication des messages et pour faire correspondre les messages de type Accusé de réception/Réinitialisation aux messages de type Confirmable/Non-confirmable. : Les messages de réponse auront le même ID de message que la demande.

Jeton

Champ optionnel dont la taille est indiquée par le champ Token Length, dont les valeurs sont générées par le client. Le serveur doit renvoyer chaque valeur de jeton sans aucune modification au client. Il est destiné à être utilisé comme identifiant client local pour fournir un contexte supplémentaire pour certaines transactions simultanées.

Option

Delta d'options :

• 0 à 12 : Pour un delta entre 0 et 12 : Représente la valeur delta exacte entre le dernier ID d'option et l'ID d'option souhaité, sans valeur Option Delta Extended
• 13 : Pour delta de 13 à 268 : Option Delta Extended est une valeur de 8 bits qui représente la valeur Option Delta moins 13
• 14 : Pour le delta de 269 à 65 804 : Option Delta Extended est une valeur de 16 bits qui représente la valeur Option Delta moins 269
• 15 : réservé au marqueur de charge utile, où le delta d'option et la longueur d'option sont définis ensemble sur 0xFF.

Longueur des options :

• 0 à 12 : Pour une longueur d'option comprise entre 0 et 12 : Représente la valeur de longueur exacte, sans valeur d'extension de longueur d'option
• 13 : pour la longueur d'option de 13 à 268 : la longueur d'option étendue est une valeur de 8 bits qui représente la valeur de longueur d'option moins 13
• 14 : pour la longueur d'option de 269 à 65 804 : la longueur d'option étendue est une valeur de 16 bits qui représente la valeur de longueur d'option moins 269
• 15 : Réservé pour une utilisation future. Il s'agit d'une erreur si le champ Longueur d'option est défini sur 0xFF.

Valeur d'option:

• La taille du champ de valeur d'option est définie par la valeur de longueur d'option en octets.
• La sémantique et le format de ce champ dépendent de l'option respective.

Implémentations

Implémentations de proxy

• Squid 3.1.9 avec module de mappage HTTP-CoAP transparent
• Proxy jcoap
• Californium cf-proxy2
• CoAPthon
• FreeCoAP

Communication du groupe CoAP

Dans de nombreux domaines d'application CoAP, il est essentiel de pouvoir adresser plusieurs ressources CoAP en tant que groupe, au lieu d'adresser chaque ressource individuellement (par exemple, pour allumer toutes les lumières compatibles CoAP dans une pièce avec une seule demande CoAP déclenchée en basculant le interrupteur). Pour répondre à ce besoin, l'IETF a développé une extension facultative pour CoAP sous la forme d'une RFC expérimentale : Group Communication for CoAP - RFC 7390 Cette extension s'appuie sur la multidiffusion IP pour transmettre la demande CoAP à tous les membres du groupe. L'utilisation de la multidiffusion présente certains avantages tels que la réduction du nombre de paquets nécessaires pour transmettre la demande aux membres. Cependant, la multidiffusion a également ses limites, telles qu'une faible fiabilité et une mauvaise gestion du cache. Une méthode alternative pour la communication de groupe CoAP qui utilise des monodiffusions au lieu de multidiffusions repose sur un intermédiaire où les groupes sont créés. Les clients envoient leurs demandes de groupe à l'intermédiaire, qui à son tour envoie des demandes de monodiffusion individuelles aux membres du groupe, recueille les réponses de leur part et renvoie une réponse agrégée au client.

Sécurité

CoAP définit quatre modes de sécurité

• NoSec, où DTLS est désactivé
• PreSharedKey, où DTLS est activé, il existe une liste de clés pré-partagées, et chaque clé comprend une liste des nœuds avec lesquels elle peut être utilisée pour communiquer. Les appareils doivent prendre en charge la suite de chiffrement AES.
• RawPublicKey, où DTLS est activé et où l'appareil utilise une paire de clés asymétrique sans certificat, qui est validée hors bande. Les appareils doivent prendre en charge la suite de chiffrement AES et les algorithmes de courbe elliptique pour l'échange de clés.
• Certificat, où DTLS est activé et l'appareil utilise des certificats X.509 pour la validation.

Des recherches ont été menées sur l'optimisation de DTLS en implémentant des associés de sécurité en tant que ressources CoAP plutôt que d'utiliser DTLS en tant qu'enveloppe de sécurité pour le trafic CoAP. Cette recherche a indiqué que des améliorations allant jusqu'à 6,5 fois aucune implémentation optimisée.

En plus de DTLS, la RFC8613 définit le protocole OSCORE (Object Security for Constrained RESTful Environments ) qui assure la sécurité de CoAP au niveau de la couche application.

Les problèmes de sécurité

Bien que la norme du protocole comprenne des dispositions pour atténuer la menace d' attaques par amplification DDoS , ces dispositions ne sont pas mises en œuvre dans la pratique, ce qui entraîne la présence de plus de 580 000 cibles principalement situées en Chine et des attaques jusqu'à 320 Gbit/s.

Voir également

• Internet des objets
• OMA léger M2M
• Web des objets
• Compression d'en-tête de contexte statique (SCHC)

Les références

Liens externes

• RFC 7252 "Le protocole d'application contraint (CoAP)"
• coap.me – Serveur de test CoAP géré par l' Université de Brême