Um cliente pode descobrir um servidor CoAP utilizando uma URI que referencia a localização de
sua porta UDP, ou até mesmo, vários servidores através de um endereçamento multicast. Se essa
indicação não ocorre, assume-se que o servidor esteja na porta padrão.
Em um ambiente CoRE, onde não se pode realizar configurações manuais por alguém e as
interfaces são estáticas, cabe ao servidor detectar quais recursos serão utilizados, garantindo
que as operações sejam ininterruptas. Isso é extremamente útil em aplicações M2M.
Com o CoAP é possível utilizar o conceito de Multicast para enviar uma única mensagem a vários destinos, porém, existe possibilidade de haver perdas e o risco adicional de as sequências de mensagens chegarem corrompidas ao deixar a origem com um estado desconhecido ou indesejável.
O fato é que nesse ambiente, onde consideramos aplicações IoT, queremos garantir que toda uma sequência de comandos cheguem a um determinado dispositivo, porém às vezes, é melhor que eles não cheguem ao invés de serem recebidos sem termos conhecimentos de qual deles falhou.
Os tamanhos de quadros costumam ser relativamente grandes, mas é possível empacotá-los em diversas mensagens CoAP menores e mandá-las em grupo. Isso pode ser implementado facilmente através do Multicast CoAP, que é independente do dispositivo e não necessita de encriptação do canal, atendendo aos recursos restritos de um dispositivo receptor.
O CoAP utiliza uma camada de segurança chamada Datagram Transport Layer Security (DTLS) acima
da camada UDP. Existem quatro modos de segurança, NoSec, PreSharedKey, RawPublicKey, e
Certificate. O modo NoSec não possui DTLS ativo, enquanto os outros três modos utilizam o DTLS
de formas diferentes, com chaves compartilhadas que indicam quais nós podem ser utilizados, ou
com pares de chaves assimétricos com ou sem certificação.
O nó final de cliente do CoAP também deve ser um cliente DTLS. A sessão deve ser iniciada na
porta adequada e deve esperar o DTLS handshake terminar para que o primeiro pedido CoAP seja
feito. Todas as mensagens CoAP devem ser enviadas como DTLS application data.
Para que haja segurança entre as mensagens, vemos que entre mensagens de ACK ou RST para uma
mensagem de confirmação, ou uma mensagem de Reset para uma Non-confirmable, ou para que haja
segurança na camada de solicitação/resposta, a sessão DTLS e momento (época) deve ser a mesma.
O nó final deve suportar Server Name Indication (SNI). Isso é necessário para casos onde um
servidor atue como múltiplos servidores (de forma virtual), podendo então qual chave usar para
cada conexão DTLS.
O proxying para entre os protocolos é fácil de ser implementado, pois o CoAP suporta um grupo de funcionalidades do HTTP, e existem diferentes razões para isso que seja feito, como por exemplo, ao se projetar interfaces web que trabalhem em cima de outros protocolos.
Existem duas maneiras de um cliente CoAP acessar um recurso sobre o HTTP através de um intermediário: CoAP-HTTP Proxying (incluindo um Proxy-URI ou uma opção de Proxy-Scheme com uma URI “http” ou “https” numa solicitação CoAP) ou HTTP-CoAP (especificando uma URI “coap” ou “coaps” na Request-Line de uma solicitação HTTP).
De qualquer jeito, apenas o modelo de solicitação/resposta é mapeado para o HTTP. O modelo subjacente de mensagens CON e NON, entre outras, se mantém invisível e a operação não deve ter efeito sobre uma função proxy. Apenas os métodos a seguir podem ser implementados nos dois casos citados, fazendo requisições ao proxy:
>> CoAP-HTTP: GET (retorna a representação de um recurso HTTP identificado na solicitação URI, PUT (atualiza ou cria um recurso HTTP identificado pela solicitação URI com representação fechada), DELETE (deleta um recurso HTTP identificado pela solicitação URI a partir do servidor de origem) e POST (obtém uma representação fechada na solicitação a ser processada pelo servidor HTTP de origem, sendo este método determinado pelo servidor e dependente do recurso identificado pela solicitação URI).
>> HTTP-CoAP: GET (retorna a representação de um recurso CoAP identificado na solicitação URI), HEAD (é idêntico ao GET exceto que o servidor não precisa retornar uma mensagem no corpo da mensagem), PUT (atualiza ou cria um recurso CoAP identificado pela solicitação URI com representação fechada), DELETE (deleta um recurso CoAP identificado pela solicitação URI a partir do servidor de origem) e POST (obtém uma representação fechada na solicitação a ser processada pelo servidor CoAP de origem, sendo este método determinado pelo servidor e dependente do recurso identificado pela solicitação URI).
- Análise do protocolo e processamento de URI’s
- Proxying e Cache
- Ataques de falsificação de IP
- Ataques entre protocolos
- Considerações sobre nós restritos
- Risco de Amplificação: Servidores que utilizam CoAP geralmente possuem pacotes de resposta significativamente maiores que os pacotes
de requisição. Isso pode ser utilizado por invasores que usam nós de uma rede CoAP para aumentar seus pacotes
de ataque, algo muito utilizado em ataques do tipo DoS (denial-of-service) quando o invasor está com limitações
de tráfego. Devido a isso, grandes fatores de amplificação em pacotes de resposta não devem ser fornecidos sem
uma prévia autenticação da requisição feita. Um ponto que torna o CoAP menos atraente para esse tipo de ataque é sua restrição na quantidade de tráfego.