Dans cette première section, nous comparons les architectures A-DTLS, A-DTLS avec un cache de données, CASAN et CASAN-S. Le contexte et les critères de cette comparaison sont ceux du chapitre 5 (page41).
Le tableau 9.1 montre les différences entre les architectures A-DTLS (avec et sans cache de don- nées), CASAN, et CASAN-S. Ce tableau reprend les critères de comparaison du chapitre 5, tout en ajoutant d’autres critères plus spécifiques :
1. cryptographie asymétrique raisonnable sur le client : ce critère indique que le client peut utiliser des algorithmes asymétriques sans que cela n’ait d’impact trop important sur le serveur de ressources. Dans l’architecture A-DTLS sans cache de données, si le client utilise des algorithmes asymétriques, alors le serveur de ressources le devra également. Ce n’est pas le cas pour les autres architectures.
2. surcharge de la taille de messages sur le réseau contraint, dans le meilleur et le pire cas ; 3. taille de la charge utile : ce critère indique la taille maximale de la donnée transportée dans
l’architecture en un seul message. Cette taille prend en compte la taille d’en-tête de la couche liaison.
1. Premier cas : longues adresses (IP, lien), UDP sans compression de port. Second cas : adresses IP implicites (en-tête IPv6 de 3 octets), UDP compressé (en-tête de 4 octets).
A-DTLS A-DTLS (avec cache)
CASAN + DTLS CASAN-S entités du domaine client client client client client
entités du domaine serveur SR, AN, AZ SR, AN, AZ SR, AN, AZ, cache SR, AN, AZ, cache
Sécurité des communications
protection contre rejeu
oui oui oui oui
protection contre le DoS
cookie cookie cookie cookie
chiffrement métadonnées
oui oui oui oui
agilité cryptographique
oui oui oui oui
Éléments de sécurité
crypto. asymétrique raison-
nable sur le client non oui (communication
avec le cache)
oui oui
autorisation explicite
non non non non
granularité d’autorisation
SR SR ressource ressource
gestion automatique des clés
oui oui oui oui
contexte par client (SR)
oui oui non non
Contraintes
nb relations entre domaines 8 8 8 8
horloge requise (SR) oui *
non non non
service de cache de données
non oui oui oui
surcharge taille de messages
grande grande faible faible
sur le réseau contraint 6LoWPAN, UDP, DTLS, CoAP
6LoWPAN, UDP, DTLS, CoAP
DTLS, CoAP CASAN-S meilleur cas (octets) 40 : 3 + 4 + 29 + 4 40 : 3 + 4 + 29 + 4 29 + 4 17 pire cas (octets) 59 : 20 + 6 + 29 + 4 59 : 20 + 6 + 29 + 4 29 + 4 17 taille de la charge utile (octets) 45-641 45-641 71-85 (@ MAC
courtes)
87-101 (@ MAC courtes)
nb msg démarrage du réseau (SR)
4 (IPv6) 4 (IPv6) 13 (association CA- SAN)
5 (association CASAN-S)
nb msg 1èreconnexion (SR) 14 ** (10) 14 ** (10) 0 (connexion sur le
maître)
0 (connexion sur le maître)
nb msg 1èreconnexion (C) 14 ** (10) 14 ** (10) 14 ** (10) 14 ** (10)
nb msg à chaque requête (SR) 2 0 - 2 0 (cache) - 2 0 (cache) - 2
nb msg à chaque requête (C) 2 2 2 2
connexions maintenues (SR) 0 1 (avec le cache) 1 (avec le maître) 1 (avec le maître) influence du nb de msg (SR)
dépend du nb de clients et fréquence des requêtes
faible (cache) faible (cache) faible (cache)
Aspects généraux
protocoles utilisés DTLS + CoAP DTLS + CoAP DTLS + CASAN CASAN-S arch avec app spécifique
non non non non
découverte de ressources
non non oui oui
services réseau requis sur SR DHCP ou autoconf. IP, DNS
DHCP ou autoconf. IP, DNS
- -
mise à l’échelle
limitée limitée bonne (agrégation
des ressources sur le maître, chaînage des maîtres, maîtres multiples)
bonne (agrégation des ressources sur le maître, chaînage des maîtres, maîtres multiples)
Table 9.1 – Comparaison des architectures A-DTLS, CASAN et CASAN-S sur des aspects de sécurité et de contraintes. La couleur verte indique un avantage, la couleur rouge indique un inconvénient (ou alors le résultat dépend du déploiement), la couleur noire indique un résultat mitigé. * change au
9.1. Comparaison qualitative 95 4. nombre de messages au démarrage du réseau sur le serveur de ressources : au démarrage des architectures A-DTLS (avec et sans cache), le serveur de ressources doit récupérer une adresse IP, il utilise donc l’auto-configuration IPv6 qui nécessite 4 messages. L’architecture CASAN nécessite 13 messages pour l’association du maître et de son esclave (DTLS puis les messages CASAN). Enfin, l’architecture CASAN-S n’implique que les 5 messages d’association décrits dans la section précédente.
La cryptographie asymétrique n’est pas raisonnable dans l’architecture A-DTLS sans cache à cause du temps de calcul sur les serveurs de ressources. En revanche, l’authentification par clés asymétriques (ou avec des certificats) permet d’alléger le coût de maintenance, c’est-à-dire qu’il n’est pas nécessaire d’ajouter, de supprimer ou de renouveler des clés d’authentification pour chaque client sur chaque nœud qu’il contacte, un compromis est donc à faire suivant les besoins de déploiement. Dans tous les cas, A-DTLS avec cache, CASAN et CASAN-S ne nécessitent pas de cryptographie asymétrique sur les serveurs de ressources puisque la présence du maître est assurée.
Concernant la granularité de l’autorisation, A-DTLS (avec ou sans cache) assure que le serveur de ressources n’accepte que des requêtes venant de clients connus, puisque dans le cas contraire la connexion ne peut être établie. Tout client accepté a accès à toutes les ressources sur le serveur de ressources : il n’est pas prévu dans le mécanisme DTLS de gérer d’autorisation plus finement. CoAP permet de refuser l’accès à une ressource, mais dans ce cas cette gestion est faite sur chaque nœud, ou au niveau du cache de données, pas au niveau du protocole de communication sécurisée. CASAN et CASAN-S centralisent toute la gestion du contrôle d’accès sur le maître, avec une gestion fine jusqu’à la ressource, allégeant les serveurs de ressources de cette tâche.
Le nombre de relations entre les domaines est le même pour toutes les architectures, puisque le client se connecte avec le mécanisme DTLS dans tous les cas : sur le serveur de ressources ou le cache de données dans A-DTLS, et sur le maître dans CASAN et CASAN-S.
Le nombre de messages à la première connexion sur le serveur de ressources et sur le client diffèrent entre les architectures A-DTLS et CASAN. L’architecture A-DTLS nécessite au minimum 10 messages échangés entre le client et le serveur de ressources avec des clés pré-configurées, et jusqu’à 14 messages avec des certificats. CASAN et CASAN-S ne nécessitent que l’association de l’esclave au maître au démarrage du réseau, il n’y a pas de communication directe entre le client et l’esclave.
Le critère influence de messages sur le serveur de ressources indique de quoi dépend le nombre de messages sur le serveur de ressources. Dans l’architecture A-DTLS, le nombre de messages échangés avec le serveur de ressources dépend du nombre de clients et de leur fréquence de requête. Cette influence est limitée lorsqu’un cache de données est utilisé. Dans l’architecture A-DTLS avec un cache, le serveur de ressources se connecte au cache et la connexion reste active entre les requêtes.
Pour les protocoles utilisés dans le domaine contraint, A-DTLS nécessite une pile de communica- tion complète (réseau, transport, sécurité, application), CASAN-S ne requiert que CoAP. De ce fait, CASAN-S est plus simple, ce qui implique potentiellement moins d’erreurs et donc diminue le coût de maintenance. Enfin, CASAN-S réduit les en-têtes des messages, permettant de partager plus de données par paquet.
Finalement, la découverte de ressources fournie directement par l’architecture permet d’économiser du temps et de l’énergie. 6LoWPAN associé à CoAP permet au client de découvrir les ressources, mais cela nécessite un mécanisme de multicast, qui peut ne pas être permis dans le réseau contraint, et qui est géré actuellement sans sécurité. CASAN-S a un mécanisme intégré pour la découverte de ressources, ne nécessitant aucun message supplémentaire dans le réseau contraint : chaque serveur de ressources envoie sa liste de ressources au maître une seule fois au démarrage du nœud.
Client Domaine serveur Point de terminaison Routeur 6LoWPAN Serveur de ressources Passerelle Série
CoAPS get /temperature
CoAPS réponse "37,2 C"
CoAPS get /temperature
CoAPS réponse "37,2 C" IEEE 802.15.4 Ethernet
Figure 9.1 – Dispositif expérimental de l’architecture de référence (A-DTLS).