Protocolo de aplicativo restrito - Constrained Application Protocol

O Constrained Application Protocol ( CoAP ) é um protocolo de aplicativo da Internet especializado para dispositivos restritos, conforme definido no RFC 7252 . Ele permite que os dispositivos restritos chamados "nós" se comuniquem com a Internet mais ampla usando protocolos semelhantes. O CoAP é projetado para uso entre dispositivos na mesma rede restrita (por exemplo, redes com baixa potência e perdas), entre dispositivos e nós gerais na Internet e entre dispositivos em diferentes redes restritas, ambos conectados por uma Internet. O CoAP também está sendo usado por meio de outros mecanismos, como SMS em redes de comunicação móvel.

CoAP é um protocolo de camada de serviço destinado ao uso em dispositivos de Internet com recursos limitados, como nós de rede de sensores sem fio . O CoAP foi projetado para ser facilmente traduzido para HTTP para integração simplificada com a web, ao mesmo tempo que atende a requisitos especializados, como suporte multicast , sobrecarga muito baixa e simplicidade. Multicast, baixo overhead e simplicidade são importantes para a comunicação Internet das coisas (IoT) e máquina-a-máquina (M2M), que tendem a ser profundamente incorporadas e têm muito menos memória e fonte de alimentação do que os dispositivos tradicionais de Internet. Portanto, a eficiência é muito importante. O CoAP pode ser executado na maioria dos dispositivos que suportam UDP ou UDP analógico.

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

Especificação

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

  • RFC  7641 (2015) Observando recursos no protocolo de aplicativo restrito
  • RFC  7959 (2016) Transferências Block-Wise no Constrained Application Protocol (CoAP)
  • RFC  8323 (2018) CoAP (Constrained Application Protocol) sobre TCP, TLS e WebSockets
  • RFC  8974 (2021) Tokens estendidos e clientes sem estado no protocolo de aplicativo restrito (CoAP)

Formatos de mensagem

A menor mensagem CoAP tem 4 bytes de comprimento, se omitindo Token, Opções e Carga útil. O CoAP usa dois tipos de mensagem, solicitações e respostas, usando um formato de cabeçalho básico simples e binário. O cabeçalho básico pode ser seguido por opções em um formato otimizado de tipo-comprimento-valor. O CoAP é, por padrão, vinculado ao UDP e, opcionalmente, ao DTLS , fornecendo um alto nível de segurança de comunicação.

Quaisquer bytes após os cabeçalhos do pacote são considerados o corpo da mensagem. O comprimento do corpo da mensagem está implícito no comprimento do datagrama. Quando vinculado ao UDP, a mensagem inteira DEVE caber em um único datagrama. Quando usado com 6LoWPAN conforme definido no RFC 4944, as mensagens DEVEM caber em um único quadro IEEE 802.15.4 para minimizar a fragmentação.

Cabeçalho CoAP
Offsets Octeto 0 1 2 3
Octeto Pedaço 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
4 32 VER Modelo Comprimento do token Código de Solicitação / Resposta ID da mensagem
8 64 Token (0 - 8 bytes)
12 96
16 128 Opções (se disponível)
20 160 1 1 1 1 1 1 1 1 Carga útil (se disponível)

Cabeçalho fixo do CoAP: versão, tipo, comprimento do token, código de solicitação / resposta e ID da mensagem.

Os primeiros 4 bytes são obrigatórios em todos os datagramas CoAP.

Esses campos podem ser facilmente extraídos desses 4 bytes em C por meio destas 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]) )

Versão (VER) (2 bits)

Indica o número da versão do CoAP.

Tipo (2 bits)

Isso descreve o tipo de mensagem do datagrama para os dois contextos de tipo de mensagem de Solicitação e Resposta.
  • Solicitar
    • 0: Confirável: Esta mensagem espera uma mensagem de Confirmação correspondente.
    • 1: Não confirmável: Esta mensagem não espera uma mensagem de confirmação.
  • Resposta
    • 2: Confirmação: esta mensagem é uma resposta que confirma uma mensagem que pode ser confirmada
    • 3: Reiniciar: Esta mensagem indica que recebeu uma mensagem, mas não conseguiu processá-la.

Comprimento do token (4 bits)

Indica o comprimento do campo Token de comprimento variável, que pode ter 0-8 bytes de comprimento.

Código de solicitação / resposta (8 bits)

0 1 2 3 4 5 6 7
Classe Código

Os três bits mais significativos formam um número conhecido como "classe", que é análogo à classe dos códigos de status HTTP . Os cinco bits menos significativos formam um código que comunica mais detalhes sobre a solicitação ou resposta. Todo o código é normalmente comunicado no formulário class.code.

Você pode encontrar os códigos de solicitação / resposta CoAP mais recentes em [1] , embora a lista abaixo forneça alguns exemplos:

  • Método: 0.XX
    1. VAZIO
    2. PEGUE
    3. PUBLICAR
    4. POR
    5. EXCLUIR
    6. BUSCAR
    7. CORREÇÃO
    8. iPATCH
  • Sucesso: 2.XX
    1. Criada
    2. Excluído
    3. Válido
    4. Mudado
    5. Contente
    6. Prosseguir
  • Erro do cliente: 4.XX
    1. Pedido ruim
    2. Não autorizado
    3. Opção Ruim
    4. Proibido
    5. Não encontrado
    6. Método não permitido
    7. Não aceitável
    8. Solicitar Entidade Incompleta
    9. Conflito
    10. A pré-condição falhou
    11. Solicitar Entidade Muito Grande
    12. Formato de conteúdo não suportado
  • Erro do servidor: 5.XX
    1. Erro do Servidor Interno
    2. Não implementado
    3. Gateway ruim
    4. Serviço indisponível
    5. Tempo Limite do Gateway
    6. Proxying Não Suportado
  • Códigos de Sinalização: 7.XX
    1. Não atribuído
    2. CSM
    3. Ping
    4. Pong
    5. Liberar
    6. Abortar

ID da mensagem (16 bits)

Usado para detectar a duplicação de mensagens e para fazer a correspondência entre mensagens do tipo Confirmação / Redefinir com mensagens do tipo Confirmavel / Não confirmavel.: As mensagens de resposta terão o mesmo ID de Mensagem da solicitação.

Símbolo

Campo opcional cujo tamanho é indicado pelo campo Token Length, cujos valores são gerados pelo cliente. O servidor deve ecoar cada valor de token sem nenhuma modificação de volta para o cliente. Destina-se a ser usado como um identificador local do cliente para fornecer contexto extra para certas transações simultâneas.

Opção

Formato de Opção
Posições de bits
0 1 2 3 4 5 6 7
Opção Delta Comprimento da Opção
Opção Delta Extendida (Nenhum, 8 bits, 16 bits)
Comprimento da opção estendido (nenhum, 8 bits, 16 bits)
Valor da Opção

Opção Delta:

  • 0 a 12: Para delta entre 0 a 12: Representa o valor delta exato entre a última ID de opção e a ID de opção desejada, sem nenhum valor de Opção Delta Estendido
  • 13: Para delta de 13 a 268: Option Delta Extended é um valor de 8 bits que representa o valor Option Delta menos 13
  • 14: Para delta de 269 a 65.804: Option Delta Extended é um valor de 16 bits que representa o valor Option Delta menos 269
  • 15: Reservado para o marcador de carga útil, onde o Delta da opção e o comprimento da opção são definidos juntos como 0xFF.

Comprimento da opção:

  • 0 a 12: para o comprimento da opção entre 0 a 12: representa o valor exato do comprimento, sem valor estendido do comprimento da opção
  • 13: Para o comprimento da opção de 13 a 268: o comprimento da opção estendido é um valor de 8 bits que representa o valor do comprimento da opção menos 13
  • 14: Para o comprimento da opção de 269 a 65.804: o comprimento da opção estendido é um valor de 16 bits que representa o valor do comprimento da opção menos 269
  • 15: Reservado para uso futuro. É um erro se o campo Comprimento da opção estiver definido como 0xFF.

Valor da opção:

  • O tamanho do campo Valor da opção é definido pelo valor do Comprimento da opção em bytes.
  • A semântica e o formato deste campo dependem da respectiva opção.

Implementações

Nome Linguagem de programação Versão CoAP implementada Servidor cliente Recursos do CoAP implementados Licença Ligação
aiocoap Python 3 RFC 7252 Cliente + Servidor Transferências em bloco, observe (parcial) MIT https://pypi.python.org/pypi/aiocoap
Californium Java RFC 7252, RFC 7641, RFC 7959 Cliente + Servidor Observe, Transferências Blockwise, Multicast (desde 2.x), DTLS (ID de conexão + DTLS 1.2) EPL + EDL https://www.eclipse.org/californium https://github.com/eclipse/californium
cantcoap C ++ / C RFC 7252 Cliente + Servidor BSD https://github.com/staropram/cantcoap
Canopus Ir RFC 7252 Cliente + Servidor Essencial Licença Apache 2.0 https://github.com/zubairhamed/canopus
Go-CoAP Ir RFC 7252, RFC 8232, RFC 7641, RFC 7959 Cliente + Servidor Core, Observe, Blockwise, Multicast, TCP / TLS Licença Apache 2.0 https://github.com/go-ocf/go-coap
Implementação CoAP para Go Ir RFC 7252 Cliente + Servidor Core + Draft Assine MIT https://github.com/dustin/go-coap
CoAP.NET C # RFC 7252, coap-13, coap-08, coap-03 Cliente + Servidor Transferências centrais, observadas e em bloco BSD de 3 cláusulas https://github.com/smeshlink/CoAP.NET
CoAPSharp C #, .NET RFC 7252 Cliente + Servidor Core, Observe, Block, RD LGPL http://www.coapsharp.com
CoAPthon Pitão RFC 7252 Cliente + servidor + proxy de encaminhamento + proxy reverso Observe, descoberta de servidor multicast, análise de formato de link CoRE, bloco a nível MIT https://github.com/Tanganelli/CoAPthon
CoAP Shell Java RFC 7252 Cliente Observe, Transferências Blockwise, DTLS Licença Apache 2.0 https://github.com/tzolov/coap-shell
Cobre JavaScript (plugin do navegador) RFC 7252 Cliente Observe, transferências em bloco BSD de 3 cláusulas https://github.com/mkovatsc/Copper https://addons.mozilla.org/firefox/addon/copper-270430/
eCoAP C RFC 7252 Cliente + Servidor Essencial MIT https://gitlab.com/jobol/ecoap
Erbium para Contiki C RFC 7252 Cliente + Servidor Observe, transferências em bloco BSD de 3 cláusulas http://www.contiki-os.org/ (er-rest-example)
FreeCoAP C RFC 7252 Cliente + Servidor + HTTP / Proxy CoAP Transferências Core, DTLS, Blockwise BSD https://github.com/keith-cullen/FreeCoAP
iCoAP Objective-C RFC 7252 Cliente Transferências centrais, observadas e em bloco MIT https://github.com/stuffrabbit/iCoAP
java-coap Java RFC 7252, RFC 7641, RFC 7959, RFC 8323 Cliente + Servidor Licença Apache 2.0 https://github.com/PelionIoT/java-coap
jCoAP Java RFC 7252 Cliente + Servidor Observe, transferências em bloco Licença Apache 2.0 https://code.google.com/p/jcoap/
libcoap C RFC 7252 Cliente + Servidor Observe, Transferências Blockwise, DTLS BSD / GPL https://github.com/obgm/libcoap
LibNyoci C RFC 7252 Cliente + Servidor Núcleo, Observar, Bloco, DTLS MIT https://github.com/darconeous/libnyoci
lobaro-coap C RFC 7252 Cliente + Servidor Observe, transferências em bloco MIT http://www.lobaro.com/lobaro-coap
microcoap C RFC 7252 Cliente + Servidor MIT https://github.com/1248/microcoap
microCoAPy MicroPython RFC 7252 Cliente + Servidor Essencial Licença Apache 2.0 https://github.com/insighio/microCoAPy
nanocoap C RFC 7252 Cliente + Servidor Transferências centrais, em bloco LGPL https://api.riot-os.org/group__net__nanocoap.html
nCoap Java RFC 7252 Cliente + Servidor Observe, Transferências em Bloco, Formato de Link CoRE, Endpoint-ID-Draft BSD https://github.com/okleine/nCoAP
node-coap Javascript RFC 7252,

RFC 7641, RFC 7959

Cliente + Servidor Core, Observe, Block MIT https://github.com/mcollina/node-coap
Ruby Coap Rubi RFC 7252 Cliente + Servidor (david) Core, Observe, Block, RD MIT, GPL https://github.com/nning/coap
https://github.com/nning/david
Biblioteca de dispositivos Sensinode C C RFC 7252 Cliente + Servidor Core, Observe, Block, RD Comercial https://silver.arm.com/browse/SEN00
Biblioteca de dispositivos Sensinode Java Java SE RFC 7252 Cliente + Servidor Core, Observe, Block, RD Comercial https://silver.arm.com/browse/SEN00
Plataforma Sensinode NanoService Java SE RFC 7252 Servidor Nuvem Core, Observe, Block, RD Comercial https://silver.arm.com/browse/SEN00
SwiftCoAP Rápido RFC 7252 Cliente + Servidor Transferências centrais, observadas e em bloco MIT https://github.com/stuffrabbit/SwiftCoAP
TinyOS CoapBlip nesC / C coap-13 Cliente + Servidor Observe, transferências em bloco BSD https://web.archive.org/web/20130312140509/http://docs.tinyos.net/tinywiki/index.php/CoAP
coisas Python (torcido) RFC 7252 Cliente + Servidor Transferências em bloco, observe (parcial) MIT https://github.com/mwasilak/txThings/
coap-rs Ferrugem RFC 7252 Cliente + Servidor Opção de núcleo, multicast, observar, código de resposta de muitas solicitações MIT https://github.com/Covertness/coap-rs

https://docs.rs/coap/

YaCoAP C MIT https://github.com/RIOT-Makers/YaCoAP

Implementações de proxy

Comunicação do grupo CoAP

Em muitos domínios de aplicação 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 ligar todas as luzes habilitadas para CoAP em uma sala com uma única solicitação CoAP acionada alternando o interruptor). Para atender a essa necessidade, o IETF desenvolveu uma extensão opcional para CoAP na forma de um RFC experimental: Group Communication for CoAP - RFC 7390 Esta extensão depende de multicast IP para entregar a solicitaçã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 solicitação aos membros. No entanto, o multicast também tem suas limitações, como baixa confiabilidade e hostilidade em cache. Um método alternativo para comunicação de grupo CoAP que usa unicasts em vez de multicasts depende de ter um intermediário onde os grupos são criados. Os clientes enviam suas solicitações de grupo para o intermediário, que por sua vez envia solicitações individuais de unicast aos membros do grupo, coleta as respostas deles e envia de volta uma resposta agregada ao cliente.

Segurança

CoAP define quatro modos de segurança

  • NoSec, onde DTLS está desabilitado
  • PreSharedKey, onde DTLS está habilitado, 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 oferecer suporte ao pacote de criptografia AES.
  • RawPublicKey, onde DTLS está habilitado e o aparelho usa um par de chaves assimétricas sem um certificado, que é validado fora da banda. Os dispositivos devem oferecer suporte ao pacote de criptografia AES e aos algoritmos da curva elíptica para a troca de chaves.
  • Certificado, onde DTLS está habilitado e o aparelho usa certificados X.509 para validação.

A pesquisa foi conduzida para otimizar o DTLS através da implementação de associados de segurança como recursos CoAP em vez de usar o DTLS como um invólucro de segurança para o tráfego CoAP. Esta pesquisa indicou que melhorias de até 6,5 vezes nenhuma implementação otimizada.

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

Problemas de segurança

Embora o padrão de protocolo inclua disposições para mitigar a ameaça de ataques de amplificação DDoS , essas disposiçõ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 Gbps.

Veja também

Referências

links externos