RFC2610 Options DHCP pour SLP Perkins & Guttman

Groupe de travail Réseau

C. Perkins & E. Guttman

Request for Comments : 2610

Sun Microsystems

Catégorie : En cours de normalisation

juin 1999

Traduction Claude Brière de L’Isle



Options DHCP pour le protocole de localisation de service



Statut du présent mémoire

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 "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.


Notice de Copyright

Copyright (C) The Internet Society (1999). Tous droits réservés.


Résumé

Le protocole de configuration dynamique d’hôte fournit un cadre pour passer les informations de configuration aux hôtes sur un réseau TCP/IP. Les entités qui utilisent le protocole de localisation de service ont besoin de trouver l’adresse des agents de répertoire afin de traiter les messages. Une autre option fournit une allocation de portée pour la configuration de l’utilisateur de SLP et des agents de service.


1. Introduction


Le protocole de configuration dynamique d’hôte [2] donne un cadre pour passer les informations de configuration aux hôtes sur un réseau TCP/IP. Les entités qui utilisent le protocole de localisation de service, version 2 [3] et le protocole de localisation de service, version 1 [4] ont besoin d’obtenir l’adresse des agents de répertoire et la configuration de la portée. Le protocole de localisation de service (SLP, Service Location Protocol) fournit une configuration par défaut pour les portées et les agents de répertoire peuvent être découverts en utilisant la diffusion ou la diffusion groupée. Il est utile dans un plus grand déploiement d’être capable de configurer les agents SLP en utilisant DHCP, afin de centraliser l’administration et de déployer SLP dans des résaux où l’acheminement en diffusion groupée n’est pas disponible.


Les mots-clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans [1].


2. Introduction


Les options DHCP décrites ci-dessous sont utilisées pour configurer les agents avec le protocole de localisation de service, version 2 [3] et version 1 [4].


L’option Agent de répertoire SLP est utilisée pour configurer les agents d’utilisateur et les agents de service avec la situation des agents de répertoire dans le réseau.


L’option Portée SLP prend la préséance sur la configuration de portée aussi bien par défaut que statique des agents SLP.


3. Option Agent de répertoire SLP


Cette option spécifie la situation d’un ou plusieurs agents de répertoire SLP.


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Code = 78 | Longueur | Obligatoire | a1 |

+---------------+---------------+---------------+---------------+

| a2 | a3 | a4 | ...

+---------------+---------------+---------------+---------------+


L’option Agent de répertoire SLP spécifie une liste d’adresses IP pour les agents de répertoire. Les agents de répertoire DOIVENT être énumérés dans l’ordre de préférence, si il y a un ordre de préférence.


La valeur Longueur doit inclure un pour l’octet 'Obligatoire' et inclure quatre pour chaque adresse d’agent de réperetoire qui suit. Donc, la longueur moins un de l’option DOIT toujours être divisible par 4 et a une valeur minimum de 5.


L’adresse de l’agent de répertoire est donnée dans l’ordre des octets du réseau.


L’octet 'Obligatoire' dans l’option Agent de répertoire peut être réglé à 0 ou à 1. Si il est réglé à 1, l’agent d’utilisateur SLP ou l’agent de service ainsi configuré NE DOIT PAS employer la découverte active ou passive d’agents de répertoire en diffusion groupée.


Noter que pour la rétro compatibilité avec certains logiciels déployés, l’octet Obligatoire NE DOIT PAS être réglé à une valeur d’octet pour laquelle le bit de poids fort (0x80) est établi.


Les agents de répertoire énumérés dans cette option DOIVENT être configurés avec un sous-ensemble non vide de la liste de portées avec laquelle est configuré l’agent qui reçoit l’option Agent de répertoire. Voir les notes ci-dessous.


La spécification SLPv2 [3] définit comment utiliser cette option.


4. Option Portée du service SLP


La liste des portées est une liste délimitée par des virgules qui indique les portées qu’un agent SLP est configuré à utiliser.


0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Code = 79 | Longueur | Obligatoire |<Liste de portées>..

+---------------+---------------+---------------+---------------+


La longueur indique le nombre d’octets qui suivent. Comme la chaîne Liste de portées est codée avec des caractères UTF-8 [5], il peut se trouver que Longueur ne soit pas le nombre de caractères qui figurent dans la chaîne Liste de portées. La valeur de Longueur doit inclure un pour l’octet 'Obligatoire'.


L’octet 'Obligatoire' détermine si les agents SLP outrepassent leur configuration statique pour les portées avec la chaîne <Liste de portées> fournie par l’option. Cela permet aux administrateurs DHCP de mettre en œuvre une politique d’allocation d’un ensemble de portées aux agents pour la fourniture de service. Si le bit Obligatoire est à 0, la configuration statique prend la préséance sur la liste de portées fournie par DHCP. Si le bit Obligatoire est à 1, la <Liste de portées> fournie dans cette option DOIT être utilisée par l’agent SLP.


La syntaxe et l’usage de la chaîne Liste de portées sont définis dans la spécification SLPv2 [3].


4.1 Configuration de la chaîne Liste-de-portée de longueur zéro


Une option Portée de service SLP qui indique une Longueur de 1 (en d’autres termes, omettant entièrement la chaîne <Liste de portées>) configure validement l’agent d’utilisateur SLP à utiliser des "portées choisies par l’usager".


L’agent SLP va utiliser la liste des portées agrégées de tous les DA connus. Si aucun DA n’est connu, l’UA va utiliser la découverte de SA pour déterminer la liste des portées sur le réseau, comme défini dans [3].


Noter que cette configuration est équivalente à retirer tout contrôle centralisé de la configuration de portées des hôtes du réseau. Cela rend possible à tout agent d’utilisateur de voir tous les services. Cela peut n’être pas souhaitable car les usagers peuvent n’être pas capables ou désireux de décider quels services sont appropriés pour eux.


5. Considérations pour la sécurité


Si un hôte malveillant est capable d’insérer des informations frauduleuses dans les paquets DHCPOFFER envoyés à un agent SLP prospecteur, celui-ci sera alors dans l’incapacité d’obtenir le service, ou peut être amené contre son gré à utiliser des services incorrects.


Il existe de nombreuses opportunités de déni de service. Un agent de service pourrait faire confiance à des agents de répertoire frauduleux ou malveillants pour les annonces de services. Les DHCPOFFER pourraient empêcher le fonctionnement régulier du cadre SLP en amenant les clients à ne pas utiliser la diffusion groupée, à utiliser des agents de répertoire qui n’existent pas, et ainsi de suite.


Ces difficultés sont héritées de problèmes beaucoup plus vastes et sérieux, à savoir que sécuriser ou authentifier toutes les informations quelles qu’elles soient provenant d’un serveur (ou client !) DHCP n’est pas possible dans les déploiements courants de DHCP.


Références


[1] [RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.


[2] [RFC2131] R. Droms, "Protocole de configuration dynamique d'hôte", mars 1997. (MàJ par RFC 3396 et 4361)


[3] [RFC2608] E. Guttman et autres, "Protocole de localisation de service, version 2", juin 1999. (MàJ par RFC3224) (P.S.)


[4] [RFC2165] J. Veizades et autres, "Protocole de localisation de service", juin 1997. (MàJ par RFC2608, RFC2609) (P.S.)


[5] [RFC2279] F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", janvier 1998. (Obsolète, voir RFC3629) (D.S.)


Adresse des aiteurs


Charles E. Perkins

Erik Guttman

Technology Development Group

Technology Development Group

Mail Stop MPK15-214

Mail Stop UFRA02

Sun Microsystems, Inc.

Sun Microsystems, Inc.

15 Network Circle

Bahnstr. 2

Menlo Park, CA 94025

74915 Waibstadt, Germany

téléphone : +1 650-786-6464

téléphone : +49 7263 911 701

Fax : +1 650-786-6445

ou +1 650 786 5992

mél : Charles.Perkins@Sun.Com

mél : Erik.Guttman@Sun.Com

Web: http://www.svrloc.org/~charliep



Déclaration complète de droits de reproduction


Copyright (c) The Internet Society (1999). Tous droits réservés.


Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent et paragraphe soient inclus dans toutes les copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour les besoins du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society, ses successeurs ou ayant droits.


Le présent document et les informations contenues sont fournis 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.


Remerciement

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

page - 4 -