Je progresse au niveau de ma lecture de
odhcpd en lisant le code et les RFC afférentes.
Je pense que j'aurais bientôt la réponse à la question ci-dessous.
Quel est le rôle du symbole DHCPV4_OPT_AUTHENTICATION ?
Les messages DHCP FORCERENEW doivent être authentifiés via les procédures décrites dans le RFC 3118. [1] Cela pourrait expliquer le fait qu'un mécanisme d'authentification ait été
ajouté dans
odhcpd. Effectivement, on retrouve ce symbole dans la fonction
dhcpv4_fr_send (DHCPV4_MSG_FORCERENEW). Il faut que je lise le RFC 3118 pour éclaircir les choses
afin d'estimer le niveau de complexité.
On observe également la structure de type dhcpv4_auth_forcerenew auth dans cette fonction.
struct dhcpv4_auth_forcerenew auth = {
.protocol = 3,
.algorithm = 1,
.rdm = 0,
.replay = {htonl(time(NULL)), htonl(++serial)},
.type = 2,
.key = {0},
};
[03/11]
Le protocole « RKAP » (Reconfiguration Key Authentication Protocol) fournit une protection relative contre les tentatives malveillantes de
reconfiguration par envoi d'un message « Reconfigure ». Plusieurs protocoles peuvent être supportés dans l'option d'authentification.
Le protocole « Configuration Token » offre une protection rudimentaire contre des configurations diffusées par erreur mais peut aussi
servir à authentifier la source d'un message. L'information d'authentification envoyée par le serveur est déjà connue au préalable
par le client et inversement. Si le message peut être intercepté lors de sa transmission, alors ce protocole n'offre aucune protection
contre les actes malveillants ou proscrits.
Un message ne peut contenir qu'une seule option d'authentification. Je ne sais pas si on peut alterner les protocoles dans différents
messages envoyés par le même serveur.
[1] RFC 3203, page 4, section 6. Security Considerations.
OpenWrt