Extension d’identifiant d’accès de réseau IP mobile pour IPv4

Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions d’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 normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Copyright

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

Résumé

Les serveurs d’authentification, autorisation et comptabilité (AAA, Authentication, Authorisation and Accounting) sont aujourd’hui utilisés dans l’Internet pour fournir des services d’authentification et d’autorisation pour les ordinateurs accessibles par numérotation. De tels services seront probablement précieux pour les nœuds mobiles qui utilisent IP mobile lorsque le nœud essaye de se connecter à des domaines étrangers avec des serveurs AAA. Les serveurs AAA identifient aujourd’hui les clients en utilisant l’identifiant d’accès réseau (NAI, Network Access Identifier). Notre proposition définit un moyen pour que le nœud mobile s’identifie, en incluant le NAI avec la demande d’enregistrement IP mobile. Le présent mémoire met aussi à jour la [RFC2290] qui spécifie l’option de configuration IPv4 mobile pour IPCP, en permettant au champ Adresse de rattachement du nœud mobile de cette option d’être à zéro.

1. Introduction

Les serveurs AAA sont utilisés aujourd’hui dans l’Internet pour fournir des services d’authentification et d’autorisation pour les ordinateurs accessibles par numérotation. De tels services seront probablement également précieux pour les nœuds mobiles qui utilisent IP mobile lorsque les nœuds tentent de se connecter à des domaines étrangers avec des serveurs AAA. Les serveurs AAA identifient aujourd’hui les clients en utilisant l’identifiant d’accès réseau (NAI, Network Access Identifier) [RFC2486]. Le présent document spécifie l’extension NAI de nœud mobile au message de demande d’enregistrement IP mobile [RFC2002] provenant du nœud mobile.

Comme le NAI est normalement utilisé pour identifier de façon univoque le nœud mobile, l’adresse de rattachement du nœud mobile n'est pas toujours nécessaire pour assurer cette fonction. Donc, il est possible qu’un nœud mobile s’authentifie lui-même, et soit autorisé à se connecter au domaine étranger, sans même avoir d’adresse de rattachement. Un message qui contient l’extension NAI de nœud mobile PEUT établir le champ Adresse de rattachement à zéro (0) dans la demande d’enregistrement, pour demander que soit allouée une adresse de rattachement.

L’option "Configuration IPv4 mobile" de IPCP a été spécifiée dans la [RFC2290] pour une interaction appropriée entre un nœud mobile et un homologue, à travers lequel le nœud mobile se connecte au réseau en utilisant PPP. Selon cette spécification, le champ Adresse de rattachement de nœud mobile de l’option NE DOIT PAS être à zéro. Cependant, dans le contexte du présent mémoire qui permet à un mobile d’être identifié par son NAI et d’obtenir une adresse après la phase d’établissement de la connexion, il est permis au champ Adresse de rattachement d’être à zéro tout en maintenant tous les autres aspects de la RFC2290. L’interprétation des divers scénarios d’après la RFC2290 est donnée à la section 4.

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 la [RFC2119].

2. Extension NAI de nœud mobile

L’extension NAI de nœud mobile, montrée à la figure 1, contient le nom d’utilisateur en utilisant le format défini dans la [RFC2486]. Lorsque il est présent dans la demande d’enregistrement, le champ Adresse de rattachement PEUT être réglé à zéro (0). L’extension NAI de nœud mobile DOIT apparaître dans la demande d’enregistrement avant les deux extensions Authentification de rattachement mobile et Authentification de mobile étranger, si elles sont présentes.

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

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

| Type | Longueur | MN-NAI ...

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

Figure 1 : extension NAI de nœud mobile

Type : 131 (peut être sauté) [RFC2002]

Longueur : Longueur en octets du champ MN-NAI

MN-NAI : Chaîne en format de NAI définie dans la [RFC2486].

3. Considérations d’agent étranger

Si l’adresse de rattachement est zéro dans la demande d’enregistrement, l’agent étranger DOIT utiliser le NAI à sa place dans ses enregistrements de demande d’enregistrement en instance, avec le champ Identification usuel. Si l’agent étranger ne peut pas gérer de cette façon les enregistrements de demande d’enregistrement en instance, il DOIT retourner une Réponse d’enregistrement avec le code qui indique NONZERO_HOMEADDR_REQD (voir la section 5).

Si le nœud mobile inclut l’extension NAI de nœud mobile dans sa demande d’enregistrement, la réponse d’enregistrement provenant de l’agent de rattachement DOIT inclure l’extension NAI de nœud mobile. Sinon, l’agent étranger DEVRAIT envoyer la réponse d’enregistrement au nœud mobile, en changeant le code pour la valeur MISSING_NAI (voir la section 5). La réponse d’enregistrement DOIT inclure une adresse d’agent de rattachement non à zéro et l’adresse de rattachement du nœud mobile. Sinon, l’agent étranger DEVRAIT envoyer la réponse d’enregistrement au nœud mobile, en changeant le code en la valeur, respectivemen, MISSING_HOME_AGENT, ou MISSING_HOMEADDRt (voir section 5).

4. Interactions avec l’option Configuration IPv4 mobile à IPCP

Dans l’option Configuration IPv4 mobile à IPCP [RFC2290], le champ Adresse de rattachement du nœud mobile peut être zéro. Dans cette section, on spécifie l’action à entreprendre dans ce cas, lorsque le nœud mobile utilise l’extension NAI de nœud mobile dans la demande d’enregistrement IP mobile. Que l’option Configuration d’adresse IP contienne ou non une adresse IP non à zéro, le nœud mobile va ensuite tenter d’obtenir une adresse de rattachement de la réponse d’enregistrement IP mobile.

Si l’option Configuration d’adresse IP pour IPCP a une adresse IP égale à zéro, l’homologue PPP est supposé allouer et affecter une adresse d’entretien colocalisée au nœud mobile. Si, d’un autre côté, l’option Configuration d’adresse IP pour IPCP a une adresse IP différente de zéro, l’homologue PPP est supposé allouer cette adresse au nœud mobile comme adresse d’entretien colocalisée.

Finalement, si l’option Configuration d’adresse IP est laissée en dehors de la demande de configuration IPCP, aucune adresse d’entretien colocalisée n’est allouée durant IPCP. Le nœud mobile va acquérir une adresse d’entretien colocalisée durant une étape de configuration ultérieure ou va utiliser une adresse d’entretien localisée chez l’agent étranger.

5. Valeurs d’erreur

Chaque entrée du tableau qui suit contient le nom et la valeur du code [RFC2002] à retourner dans une réponse d’enregistrement, et la section dans laquelle le code d’erreur est mentionné pour la première fois dans cette spécification.

Nom de l’erreur Valeur Section du document

NONZERO_HOMEADDR_REQD 96 3

MISSING_NAI 97 3

MISSING_HOME_AGENT 98 3

MISSING_HOMEADDR 99 3

6. Considérations relatives à l’IANA

L’extension NAI de nœud mobile définie à la Section 2 est une extension d’enregistrement IP mobile comme définie dans la [RFC2002] et étendue dans la [RFC2356]. L’IANA devrait allouer une valeur de 131 à cette fin.

Les valeurs de code définie à la Section 5 sont des codes d’erreur, comme défini dans la [RFC2002] et étendu dans la [RFC2344] et la [RFC2356]. Elles correspondent aux valeurs d’erreur conventionnellement associées au rejet par l’agent étranger (c’est-à-dire, des valeurs dans la gamme 64-127). L’IANA devrait enregistrer les valeurs comme défini dans la Section 5.

7. Considérations sur la sécurité

Les messages d’enregistrement IP mobile sont authentifiés, et l’authentification est vérifiée par le receveur. Cette proposition n’interdit pas au nœud mobile d’envoyer son NAI en clair sur le réseau, mais cela n’est pas supposé constituer un problème de sécurité.

8. Considérations relatives à IPv6

La prise en charge des enregistrements fondés sur le NAI pour IPv6 mobile [RFC3775] sort du domaine d’application du présent document. Cette section contient quelques idées sur la façon dont l’autoconfiguration d’adresse sans état [RFC2462] et DHCPv6 [RFC3315] peuvent être étendus pour prendre en charge les enregistrements IPv6 mobile fondés sur le NAI.

Pour les nœuds mobiles qui utilisent IPv6, il n’y a pas de mécanisme actuellement développé qui permette à un nœud mobile de présenter ses accréditifs, comme il en existe aujourd’hui avec IPv4. Néanmoins, un nœud mobile qui utilise la mobilité IPv6 peut souhaiter spécifier le domaine dans lequel ses accréditifs peuvent être vérifiés, en utilisant un NAI tout comme le propose la présente spécification pour IPv4. Dans le cas de IPv6, cependant, il n’y a pas d’agent étranger en place pour gérer la connexité du nœud mobile, et donc pour gérer la vérification des accréditifs offerts par le nœud mobile. Pour identifier que la HDAF (voir l’Appendice A) a la relation attendue avec le nœud mobile, le NAI devra avoir été transmis à un AAA local par l’agent local impliqué dans la configuration de l’adresse d’entretien du nœud mobile.

Cet agent peut être un routeur qui envoie des annonces de routeur [RFC2462], ou un serveur DHCPv6. Dans le premier cas, le routeur pourrait signaler sa capacité à traiter le NAI en joignant une option (qui reste à définir) à l’annonce de routeur. Dans le second cas, pour les liaisons gérées, le nœud mobile pourrait inclure une extension NAI (non encore définie) dans son message de sollicitation DHCP. Une telle extension de NAI et l’authentification appropriée seraient aussi exigées sur la demande DHCP ultérieure envoyée par le nœud mobile au serveur DHCP choisi sur la base des annonces DHCP reçues. Une fois qu’a été obtenue une adresse d’entretien sur le réseau étranger, le nœud mobile peut utiliser le MIPv6 régulier [RFC3775].

9. Remerciements

Les auteurs tiennent à remercier Gabriel Montenegro et Vipul Gupta pour leurs utiles discussions. Merci à Basaravaj Patil et Pete McCann pour le texte de description des actions à entreprendre lorsque l’adresse de rattachement est zéro mais que le nœud mobile souhaite utiliser l’option Configuration IPv4 mobile à IPCP définie dans la [RFC2290].

Références

[RFC2002] C. Perkins, éd., "Prise en charge de la mobilité sur IP", octobre 1996. (Obsolète, voir RFC3220) (P.S.)

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

[RFC2290] J. Solomon, S. Glass, "Option de configuration IPv4 mobile pour IPCP PPP", février 1998. (MàJ par RFC2794) (P.S.)

[RFC2344] G. Montenegro, éd., "Tunnelage inverse pour IP mobile", mai 1998. (Obsolète, voir RFC3024) (P.S.)

[RFC2356] G. Montenegro, V. Gupta, "Traversée de pare-feu SKIP de Sun pour IP mobile", juin 1998. (Information)

[RFC2462] S. Thomson, T. Narten, "Autoconfiguration d'adresse IPv6 sans état", décembre 1998. (Obsolète, voir RFC4862) (D.S.)

[RFC2486] B. Aboba, M. Beadles, "Identifiant d'accès réseau", janvier 1999. (Obsolète, voir RFC4282) (P.S.)

[RFC3315] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins et M. Carney, "Protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)", juillet 2003. (MàJ par RFC6422 et RFC6644, RFC7227)

[RFC3775] D. Johnson, C. Perkins, J. Arkko, "Prise en charge de la mobilité dans IPv6", juin 2004. (P.S.) (Obs., voir RFC6275)

Appendice A. Fonction d’allocation de domaine de rattachement (HDAF)

Cet Appendice introduit une nouvelle fonction appelée fonction d’allocation de domaine de rattachement (HDAF, Home Domain Allocation Function) qui peut allouer de façon dynamique une adresse de rattachement au nœud mobile.

La Figure 2 illustre la HDAF, qui reçoit des messages des agents étrangers (par exemple, FA) et alloue une adresse de rattachement au sein du domaine de rattachement. La HDAF n’effectue aucun traitement IP mobile sur la demande d’enregistrement, mais transmet simplement la demande à un agent de rattachement (HA, Home Agent) au sein du réseau qui est capable de traiter la demande.

+------+

| |

+---+ HA-1 |

+------+ +------+ +------+ | | |

| | | | | | | +------+

| MN |-------| FA |-------| HDAF +---+ ...

| | | | | | | +------+

+------+ +------+ +------+ | | |

+---+ HA-n |

| |

+------+

Figure 2 : Fonction d’allocation de domaine de rattachement (HDAF)

À réception de la demande d’enregistrement du nœud mobile (MN, mobile node), FA extrait le NAI et trouve le nom de domaine qui lui est associé. FA trouve alors la HDAF qui traite les demandes pour le domaine du nœud mobile. Le protocole de découverte sort du domaine d’application de la présente spécification. Par exemple, FA pourrait cependant déléguer la tâche de trouver une HDAF à un serveur AAA local. Le serveur AAA local peut aussi aider FA dans le processus de vérification des accréditifs du nœud mobile, utilisant des protocoles non spécifiés dans ce document.

Adresses

Le groupe de travail peut être contacté via les présidents actuels :

Les questions sur le présent mémoire peuvent être adressées à :

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2000). 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 paragraphe soient inclus dans toutes telles 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 le besoin 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 ou ses successeurs ou ayant droits.

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

Remerciement

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