3.1) Descoberta



3.1.1) Descoberta de Serviços

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.


3.1.2) Descoberta de Recursos

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.


3.3) Segurança

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.


3.4) IoT

O CoAP se mostra muito adequado para aplicações relacionadas a IoT e pode ser considerado um substituto do HTTP para dispositivos inteligentes com recursos restritos.


3.5) Limitações

- Análise do protocolo e processamento de URI’s
- Proxying e Cache
- Risco de Amplificação
- Ataques de falsificação de IP
- Ataques entre protocolos
- Considerações sobre nós restritos


Escola Politécnica
UFRJ

Acesso ao site da Escola Politécnica da Universidade Federal do Rio de Janeiro.

Ir ao site

Grupo de Teleinformática e Automação

Site do Grupo de Teleinformática e Automação da Universidade Federal do Rio de Janeiro.

Ir ao site

Redes de Computadores I
2018.1

Primeira versão dos trabalhos feitos pela turma de Redes de Computadores I do período de 2018.1

Ir para o site

Contato

Fernanda Cassinelli: nandacassinelli@poli.ufrj.br
Lucas Miranda:
lucasgm@poli.ufrj.br
Lucas do Vale:
lukas22@poli.ufrj.br