Network Working Group K

Option de configuration du protocole simple de l'heure du réseau pour DHCPv6

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document décrit une nouvelle option DHCPv6 pour passer à un client une liste d'adresses de serveurs du protocole simple de l'heure du réseau (SNTP, Simple Network Time Protocol).

Table des Matières

1. Introduction

2. Exigences

3. Terminologie

4. Option de serveurs du protocole simple de l'heure du réseau (SNTP)

5. Apparition de l'option

6. Considérations sur la sécurité

7. Considérations relatives à l'IANA

8. Remerciements

9. Références normatives

10. Références pour information

Adresse de l'auteur

Déclaration complète de droits de reproduction

Le présent document décrit une nouvelle option, appelée option de serveurs SNTP [RFC2030], pour passer les informations sur les serveurs SNTP dans DHCPv6 [RFC3315].

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Le présent document utilise la terminologie spécifique de IPv6 et DHCPv6 comme défini à la Section 4 "Terminologie" de la spécification DHCPv6 [RFC3315].

L'option Serveurs du protocole simple de l'heure du réseau donne une liste de une ou plusieurs adresses IPv6 de serveurs SNTP [RFC2030] disponibles au client pour la synchronisation. Les clients utilisent ces serveurs SNTP pour synchroniser leur heure système avec celle des serveurs de l'heure standard. Les clients DOIVENT traiter la liste de serveurs SNTP comme une liste ordonnée. Le serveur PEUT faire la liste des serveurs SNTP en ordre de préférence décroissante.

L'option définie dans le présent document ne peut être utilisée que pour configurer des informations sur les serveurs SNTP qui peuvent être joints en utilisant IPv6. L'option DHCP pour configurer les informations sur les serveurs SNTP IPv4 se trouve dans la [RFC2132]. Les mécanismes pour configurer les applications de double pile IPv4/IPv6 sont en cours d'examen, mais ne sont pas spécifiés dans le présent document.

Le format de l'option Serveurs du protocole simple de l'heure du réseau est montré ci-dessous :

Longueur d'option : longueur des champs "Serveur SNTP" en octets ; elle doit être un multiple de 16.

L'option Serveurs SNTP NE DOIT PAS apparaître dans des messages autres que les suivants : Solicit, Advertise, Request, Renew, Rebind, Information-Request, et Reply. Si cette option apparaît dans des messages autres que ceux spécifiés ici, le receveur DEVRAIT l'ignorer.

Le numéro d'option pour cette option PEUT apparaître dans l'option Demande d'option [RFC3315] dans les messages suivants : Solicit, Request, Renew, Rebind, Information-Request, et Reconfigure. Si ce numéro d'option apparaît dans l'option Demande d'option dans des messages autres que ceux spécifiés ici, le receveur DEVRAIT l'ignorer.

L'option Serveurs SNTP peut être utilisée par un serveur DHCPv6 intrus pour amener les clients DHCPv6 à contacter un serveur SNTP félon, résultant en une synchronisation invalide de l'heure chez le client, conduisant finalement à un fonctionnement inapproprié des applications pour lesquelles l'heure est critique dans la machine du client. La précision de l'heure peut être cruciale pour certains algorithmes de sécutité. Par exemple, des certificats périmés peuvent obtenir une nouvelle vie, rendant moins sûres les applications qui fonctionnent sur la machine du client. L'imprécision peut même être cause que les clients règlent leur heure de façon incorrecte, les rendant vulnérables aux attaques en répétition dans des protocoles qui utilisent des horodatages pour détecter les répétitions.

Pour éviter des attaques au moyen de ces options, le client DHCPv6 DEVRAIT utilier DHCPv6 authentifié (voir la Section 21 "Authentification des messages DHCP" dans la spécification DHCPv6 [RFC3315]).

L'IANA a alloué un code d'option de l'espace de codes d'options défini dans la section "Options DHCPv6" de la spécification DHCPv6 [RFC3315].

Merci au groupe de travail DHCP qui a passé du temps et contribué à la spécification. En particulier, merci à (par ordre alphabétique) Jim Bound, Ralph Droms, Robert Elz, Thomas Narten, Pekka Savola, Bernie Volz, et Margaret Wasserman de leur relecture attentive.

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2030] D. Mills, "Protocole simple de l'heure du réseau (SNTP) version 4 pour IPv4, IPv6 et OSI", RFC 2030, octobre 1996. (Rendue obsolète par la RFC 4330)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .

Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.

Groupe de travail Réseau	V. Kalusivalingam, Cisco Systems (India) Private Ltd
Request for Comments : 4075	mai 2005
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Nom d'option	Valeur	Décrite dans
OPTION_SNTP_SERVERS	31	Section 4.