Protocolo de Aplicação Restrita

O Protocolo de Aplicação Restrita (mais conhecido pela sigla CoAP, Constrained Application Protocol em inglês) é um protocolo de aplicação de internet especializado baseado em UDP para dispositivos restritos, conforme definido na RFC 7252 (publicada em 2014). Ele permite que esses dispositivos restritos, chamados de "nós", comuniquem-se com a internet em geral usando protocolos semelhantes. O CoAP foi projetado para uso entre dispositivos na mesma rede restrita (por exemplo, redes de baixa potência e com perdas), entre dispositivos e nós gerais na internet e entre dispositivos em diferentes redes restritas, ambas unidas por uma internet. O CoAP também vem sendo utilizado por meio de outros mecanismos, como SMS em redes de comunicação móvel.

O CoAP é um protocolo de camada de aplicação destinado ao uso em dispositivos de internet com recursos restritos, como nós de rede de sensores sem fio. O CoAP foi projetado para traduzir-se facilmente para HTTP para integração simplificada com a web, ao mesmo tempo em que atende a requisitos especializados, como suporte a multicast, overhead (sobrecarga) muito baixo e simplicidade. Multicast, baixo overhead e simplicidade são importantes para a Internet das Coisas (IoT) e para a comunicação máquina a máquina (M2M), que tendem a ser de sistemas embarcados e possuem muito menos memória e capacidade de alimentação do que os dispositivos tradicionais de internet. Portanto, a eficiência é de suma importância. O CoAP pode rodar na maioria dos dispositivos que suportam UDP ou um análogo ao UDP. Ele serve como base para outros serviços de internet, como o DNS sobre CoAP.

O Grupo de Trabalho de Ambientes RESTful Restritos da Internet Engineering Task Force (IETF) (CoRE) realizou o principal trabalho de padronização para este protocolo. Para tornar o protocolo adequado para aplicações de IoT e M2M, várias novas funções foram adicionadas.

Especificação

O núcleo do protocolo está especificado na RFC 7252. Várias extensões foram propostas, particularmente:

• RFC 7641 (2015) Observing Resources in the Constrained Application Protocol
• RFC 7959 (2016) Block-Wise Transfers in the Constrained Application Protocol (CoAP)
• RFC 8323 (2018) CoAP (Constrained Application Protocol) over TCP, TLS e WebSockets
• RFC 8974 (2021) Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)

Formatos de mensagem

O CoAP utiliza dois tipos de mensagem, requisições e respostas, empregando um formato de cabeçalho binário simples. O CoAP é vinculado por padrão ao UDP e opcionalmente ao DTLS, fornecendo um alto nível de segurança de comunicação. Quando vinculado ao UDP, a mensagem inteira deve caber em um único datagrama. Quando usado com o 6LoWPAN conforme definido na RFC 4944, as mensagens devem caber em um único quadro IEEE 802.15.4 para minimizar a fragmentação.

A menor mensagem CoAP tem 4 bytes de comprimento, se os campos de token, opções e carga útil (payload) forem omitidos, ou seja, se consistir apenas no cabeçalho CoAP. O cabeçalho é seguido pelo valor do token (0 a 8 bytes), que pode ser seguido por uma lista de opções em um formato otimizado de tipo–comprimento–valor (TLV). Quaisquer bytes após o cabeçalho, token e opções (se houver) são considerados a carga útil da mensagem, que é prefixada pelo "marcador de carga útil" de um byte (0xFF). O comprimento da carga útil é implícito pelo comprimento do datagrama.

#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] )

Implementações ativas do protocolo

Implementações de proxy

Existem implementações de proxy que fornecem funcionalidade de proxy direto (forward proxy) ou reverso (reverse proxy) para o protocolo CoAP, bem como implementações que fazem a tradução entre protocolos como HTTP e CoAP.

Os seguintes projetos fornecem funcionalidade de proxy:

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

Projetos que usam CoAP

Implementações inativas do protocolo

Comunicação em grupo no CoAP

Em muitos domínios de aplicação do CoAP, é essencial ter a capacidade de endereçar vários recursos CoAP como um grupo, em vez de endereçar cada recurso individualmente (por exemplo, para acender todas as luzes habilitadas para CoAP em uma sala com uma única requisição CoAP disparada ao acionar o interruptor de luz). Para atender a essa necessidade, o IETF desenvolveu uma extensão opcional para o CoAP na forma de um RFC experimental: Group Communication for CoAP - RFC 7390 Esta extensão depende de IP multicast para entregar a requisição CoAP a todos os membros do grupo. O uso de multicast tem certos benefícios, como a redução do número de pacotes necessários para entregar a requisição aos membros. No entanto, o multicast também tem suas limitações, como baixa confiabilidade e incompatibilidade com cache (cache-unfriendly). Um método alternativo para a comunicação em grupo no CoAP que usa unicasts em vez de multicasts depende de ter um intermediário onde os grupos são criados. Os clientes enviam suas requisições de grupo para o intermediário, que por sua vez envia requisições unicast individuais para os membros do grupo, coleta as respostas deles e envia de volta uma resposta agregada ao cliente.

Segurança

O CoAP define quatro modos de segurança:

• NoSec (sem segurança), onde o DTLS está desativado.
• PreSharedKey (chave pré-compartilhada), onde o DTLS está ativado, há uma lista de chaves pré-compartilhadas e cada chave inclui uma lista de quais nós ela pode ser usada para se comunicar. Os dispositivos devem suportar o conjunto de cifras AES (AES cipher suite).
• RawPublicKey (CHAVE PÚBLICA BRUTA), onde o DTLS está ativado e o dispositivo usa um par de chaves assimétricas sem certificado, que é validado fora de banda. Os dispositivos devem suportar o conjunto de cifras AES e algoritmos de curva elíptica (Elliptic Curve) para troca de chaves.
• Certificate (certificado), onde o DTLS está ativado e o dispositivo usa certificados X.509 para validação.

Pesquisas foram conduzidas sobre a otimização do DTLS implementando associações de segurança como recursos CoAP, em vez de usar o DTLS como um invólucro de segurança para o tráfego CoAP. Essa pesquisa indicou melhorias de até 6,5 vezes em relação a implementações não otimizadas.

Além do DTLS, a RFC 8613 define o protocolo Object Security for Constrained RESTful Environments (OSCORE), que fornece segurança para o CoAP na camada de aplicação.

Problemas de segurança

Embora o padrão do protocolo inclua provisões para mitigar a ameaça de ataques de ampliação DDoS, essas provisões não são implementadas na prática, resultando na presença de mais de 580.000 alvos localizados principalmente na China e ataques de até 320 Gbit/s.

Ver também

• Internet das Coisas
• OMA Lightweight M2M
• Compressão Estática de Cabeçalho de Contexto (SCHC)
• Web das Coisas

Referências

Ligações externas

O Commons possui uma categoria com imagens e outros ficheiros sobre Protocolo de Aplicação Restrita

• RFC 7252 "The Constrained Application Protocol (CoAP)"
• coap.me – Servidor de teste CoAP mantido pela Universidade de Bremen