Network Working Group I

Signalisation d’état de modem en garde
dans le protocole de tunnelage de couche 2 (L2TP)

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 pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" 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.

Le protocole de tunnelage de couche 2 (L2TP, Layer 2 Tunneling Protocol) définit un mécanisme pour tunneler des sessions du protocole point à point (PPP). Il est courant que ces sessions PPP soient établies en utilisant des modems connectés au réseau téléphonique public commuté.

Une des normes qui gouvernent le fonctionnement des modems définit les procédures qui permettent à un modem client de mettre l’appel en garde et ultérieurement, de rétablir la liaison du modem avec un délai minimal et sans avoir à renuméroter. Tandis que le modem est en garde, la ligne téléphonique du client peut être utilisée pour passer ou recevoir d’autres appels.

Le protocole L2TP de base ne donne aucun moyen pour signaler ces événements à partir du contrôleur d’accès L2TP (LAC, L2TP Access Controller) où le modem est physiquement connecté, au serveur de réseau L2TP (LNS, L2TP Network Server) où est traitée la session PPP.

Le présent document décrit une méthode pour faire savoir au LNS qu’un modem client connecté à un LAC a mis l’appel en garde.

Table des Matières

1. Introduction 2

1.1 Spécification des exigences 2

1.2. Terminologie 2

2. Fonctionnement du protocole 2

2.1 Scénario normal d’utilisation de modem en garde 3

2.2 Négociation de capacités 3

2.3 Modem en garde 3

2.4 Modem en ligne 3

3. Nouveaux messages de commande 3

3.1 État du modem (MDMST) 4

4. Nouvelles paires attribut-valeur 4

4.1 AVP Modem capable de mise en garde 4

4.2 AVP État de modem en garde 4

5. Exemples d’actions du LNS 5

6. Considérations relatives à l’IANA 6

7. Considérations pour la sécurité 6

8. Références 6

8.1 Références normatives 6

8.2 Références pour information 6

9. Remerciements 7

Appendice A. Allocations spécifiques de fabricant 7

Adresse de l’auteur 7

Déclaration complète de droits de reproduction 7

Le protocole de tunnelage de couche 2 L2TP) [RFC2661] définit un mécanisme d’utilité générale pour tunneler les sessions point à point (PPP) [RFC1661] sur divers supports. Par sa conception, le fonctionnement de L2TP est isolé des détails du support duquel est originaire la session PPP.

Il est courant que les sessions PPP soient établies en utilisant des modems connectés au réseau téléphonique public commuté (RTPC). La Recommandation UIT-T V.92 [V92] est une des normes qui gouvernent le fonctionnement des modems et elle définit les procédures qui permettent à un modem client de mettre l’appel en garde et plus tard, de rétablir la liaison du modem sans avoir à renuméroter. Tandis que l’appel du modem est en garde, la ligne téléphonique du client peut être utilisée pour un autre appel téléphonique.

Le protocole L2TP de base ne fournit aucun moyen pour signaler ces événements à partir du contrôleur d’accès L2TP (LAC, L2TP Access Controller) où le modem est physiquement connecté, au serveur de réseau (L2TP, LNS, L2TP Network Server) où est traitée la session PPP. Il peut être souhaitable que ces informations (qui ne sont disponibles que sur le LAC) soient fournies au LNS.

Le présent document fournit des paires d’attribut valeur (AVP, Attribute Value Pair) L2TP et des messages de commande supplémentaires qui peuvent être utilisés pour communiquer des informations de modem du LAC au LNS. Cependant, il ne définit pas ce que le LNS (s’il doit en faire quelque chose) devrait faire de ces informations. Un échantillon des actions possibles que peut envisager un LNS figure à la section 5.

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].

La définition des termes utilisés dans le présent document se trouve dans le document du protocole L2TP [RFC2661].

M est le modem client et peut faire partie intégrante du système distant. Si ce modem met en œuvre V.92, il peut demander au modem serveur SM (qui fait partie du serveur d'accès réseau (NAS, Network Access Server)) si l’appel peut être placé en garde pour un certain temps.

Si le modem serveur en est d’accord, le modem client peut signaler au RTPC de mettre l’appel en garde (habituellement, un signal lumineux clignotant). L’utilisateur du système distant utilise alors la même ligne téléphonique traditionnelle que si le modem client était connecté pour passer ou recevoir un autre appel.

Dans le scénario ci-dessus, le module de modem serveur peut notifier au reste du NAS ces événements via son mécanisme de signalisation habituel. Les couches de NAS peuvent alors agir comme désiré sur ces informations. Voir à la section 5 une liste d’échantillons d’actions possibles.

Dans le cas de L2TP, le présent document examine la topologie particulière suivante :

Si le LAC met en œuvre la fonctionnalité décrite ici, il peut signaler au LNS quand le modem client est passé en garde et quand il revient en ligne.

Le présent document ne définit pas ce que le LNS devrait faire avec ces informations (s’il doit en faire quelque chose). Un échantillon des actions possibles que PEUT considérer un LNS figure à la Section 5. Cependant, le LNS NE DOIT PAS arrêter le traitement des paquets de données par ailleurs valides qui arrivent du LAC, sans considération de l’état en cours des indications du modem en garde.

Un usager se connecte à son fournisseur de service Internet avec un modem à capacité V.92. Il commence alors le téléchargement d’un gros fichier dont il va lui falloir plusieurs minutes pour venir à bout.

Pendant que le fichier se télécharge, un ami l’appelle. Si l’usager a activé le service d’appel en attente, son modem peut lui faire savoir qu’il y a un appel entrant et il peut choisir de prendre l’appel entrant ou de le rejeter. Disons qu’il choisit de prendre le téléphone pour parler à son ami, par exemple parce qu’il a reconnu le numéro de téléphone de l’appelant.

Avant que l’usager décroche son téléphone, il dit à son modem de passer en garde et de passer à l’appel entrant (habituellement signalé par un "signal lumineux clignotant"). Son modem va alors notifier au modem serveur (rattaché au LAC) qu’il est sur le point de passer en garde. Si le modem serveur en est d’accord, le client effectue un signal clignotant afin que l’usager puisse parler à son ami.

Après avoir conversé avec son ami, l’usager fait savoir à son modem qu’il peut retourner à l’appel d’origine (sur lequel le modem serveur a attendu patiemment). Après un autre clignotement lumineux, les modems sont connectés à nouveau et le téléchargement peut continuer.

Un LAC NE DOIT PAS envoyer un message de commande d’état de modem (MDMST, Modem Status) à un LNS qui n’a pas indiqué la capacité de traiter de tels messages de commande. Cette capacité est indiquée par l’ajout d’une AVP "Modem capable de mise en garde" sur le SCCRQ ou SCCRP envoyé au LAC lorsque le tunnel est construit.

Lorsque le modem client demande au LAC de passer en garde, le LAC DEVRAIT envoyer un message de commande MDMST au LNS avec le champ H (en garde) réglé à 1 et la durée maximum négociée de la garde.

Lorsque le modem client revient en ligne après avoir été mis en garde, le LAC DEVRAIT envoyer un message de commande MDMST au LNS avec le champ H (en garde) réglé à 0. Le LAC DOIT envoyer ce message si il a précédemment envoyé un message MDMST avec le champ H (en garde) réglé à 1.

Les messages de commande suivants DOIVENT être envoyés avec le bit M réglé à 0 dans l’AVP Type de message pour prévenir les problèmes d’interopérabilité.

Les messages avec des valeurs inconnues dans l’AVP Type de message avec le bit M réglé à 0 devraient être ignorés par les homologues L2TP conformes [RFC2661].

Le message de commande État du modem (MDMST) est utilisé par le LAC pour notifier au LNS quand l’état de mise en garde du modem client change.

Le message de commande MDMST NE DOIT PAS être envoyé aux homologues qui n’ont pas inclus l’AVP "Capacité de mise en garde du modem" dans leurs messages de commande Demande de début de commande de connexion (SCCRQ, Start-Control-Connection-Request) ou Réponse de début de commande de connexion (SCCRP, Start-Control-Connection-Reply).

De plus, le message de commande MDMST ne peut être envoyé qu’après la réussite de l’établissement de la session (c’est-à-dire, après que le LAC a envoyé un message de commande soit Appel entrant connecté (ICCN, Incoming-Call-Connected) soit Appel sortant connecté (OCCN, Outgoing-Call-Connected) et avant que la session ne se termine du point de vue du LAC (c’est-à-dire avant que le LAC ait envoyé ou reçu un message de commande Notification de déconnexion d’appel (CDN, Call-Disconnect-Notify)).

Noter qu’à cause de conditions de compétition de protocoles, il est possible qu’un LAC envoie un message de commande MDMST à peu près en même temps que le LNS envoie un CDN. Un LNS DOIT ignorer les messages de commande MDMST reçus après l’envoi d’un CDN.

Le bit M sur l’AVP Type de message pour ce message de commande DOIT être réglé à 0.

La présente section contient la liste des nouveaux AVP L2TP définis dans le présent document.

L’AVP Modem capable de mise en garde, type d’attribut 53, indique que l’envoyeur (un LNS) est capable de recevoir des messages de commande MDMST. Cette AVP DOIT être incluse dans le message de commande SCCRQ ou SCCRP pour indiquer que l’envoyeur met en œuvre la présente spécification.

Cette AVP PEUT être cachée (le bit H sur l’en-tête d’AVP PEUT être 0 ou 1). Le bit M pour cette AVP DOIT être réglé à 0. La longueur est 6.

L’AVP État de modem en garde, type d’attribut 54, indique l’état en garde actuel du modem client. Cette AVP DOIT être présente dans le message de commande MDMST.

L’AVP État de modem en garde est une quantité de 16 bits, contenant deux champs qui indiquent si le modem client a placé l’appel en garde et la durée maximum de mise en garde permise à l’appel.

Le champ H (Hold, garde) est un seul bit qui indique si le modem client a placé l’appel en garde. Si le bit H (Garde) est à 1, le modem client est en garde. Si le bit H est à 0, le modem client est revenu en ligne.

Le champ Tempo(risation) est une quantité de 4 bits qui indique la durée négociée maximum pendant laquelle l’appel peut rester en garde. Il n’est valide que si le bit H (garde) est à 1 et il DOIT être ignoré si le bit H est à 0. Les valeurs pour le champ Tempo. sont définies dans [V92] et sont reproduites ici pour en faciliter la référence:

Les bits 1 à 11 sont réservés. Ces bits DOIVENT être réglés à 0 à l’envoi de cette AVP et DOIVENT être ignorés à réception.

Cette AVP PEUT être cachée (le bit H dans l’en-tête d’AVP PEUT être 0 ou 1). Le bit M pour cette AVP DOIT être mis à 0. La longueur est 8.

Les actions spécifiques entreprises par un LNS à réception d’une AVP État de modem en garde dépendent de la mise en œuvre. Le présent document ne rend pas obligatoire ce que le LNS devrait faire avec ces informations, s’il doit en faire quelque chose.

Le choix des actions entreprises par le LNS peut avoir un impact sur les protocoles de couche supérieure. Par exemple, les connexions TCP et d’autres applications en mode connexion peuvent arriver en fin de temporisation ou se déconnecter durant le temps de mise en garde. L’impact que ces choix peuvent avoir sur ce ou ces autres protocoles n’est pas examiné par le présent document.

La liste qui suit est un échantillon des actions possibles que peut envisager une mise en œuvre de LNS. Noter que certaines de ces actions ne sont pas réellement substituables, car certaines des possibilités s’excluent mutuellement.

* Arrêter temporairement d’interroger des protocoles comme Demandes d’écho LCP, Surveillance de qualité de liaison (LQM ; Link Quality Monitoring), PPP multi liaison (MP, Multilink PPP), etc.

* Éliminer les paquets de données dirigés sur le client distant maintenant en garde.

* Commencer une nouvelle session comptable, pour tenir compte du temps de garde.

* Arrêter ou mettre en garde la comptabilité jusqu’à ce que le modem revienne en ligne.

* Commencer une comptabilité séparée pour le temps pendant lequel le modem est en garde.

* Mettre en mémoire tampon les paquets de données dirigés sur le client distant maintenant en garde.

Raison : Combien de paquets de données devraient être mis en mémoire ? Quel serait l’impact sur les protocoles de couche supérieure tels que TCP ? Quel serait l’impact des délais introduits lorsque le client revient en ligne ?

Raison : Cela peut interférer avec la récupération de TCP une fois que le client revient en ligne.

* Arrêter le traitement des paquets de données par ailleurs valides provenant du client.

Raison : Il y a une condition de compétition entre la notification du modem qui revient en ligne et le premier paquet provenant du client parce que ils sont livrés sur des canaux indépendants. Éliminer des paquets client valides peut conduire à une récupération plus lente après être revenu en ligne du fait des réessais forcés.

Le présent document requiert qu’un nouveau numéro de "Type de message" L2TP soit alloué par l’IANA :

Il requiert aussi que deux nouveaux "Attributs d’AVP" soient alloués par l’IANA :

L’AVP État de modem en garde contient un ensemble de bits réservés (bits 1 à 11) qui sont alloués par l’IANA par consensus de l’IETF [RFC2026].

L’intégrité et la confidentialité de la méthode décrite dans le présent document s’appuie sur les mécanismes sous-jacents de sécurité L2TP. Le nouveau message de commande et les AVP sont destinés à indiquer quand un modem client est passé en garde et ne peut pas recevoir de données. Il ne définit pas ce que le LNS devrait faire (s’il doit en faire quelque chose) de ces informations. Un échantillon des actions possibles qu’un LNS peut envisager figure à la Section 5.

On pense que l’extension définie ne fournit pas d’informations qui seraient utiles à un attaquant, et à ce titre, elle ne devrait pas présenter de menace pour la sécurité du modem.

Si désiré, les nouveaux AVP PEUVENT être cachés comme décrit au paragraphe 4.3 de la [RFC2661].

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

[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)

[RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn et B. Palter, "Protocole de tunnelage de couche 2 "L2TP"", (P.S.)

[V92] Recommandation UIT-T V.92, "Améliorations à la Recommandation V.90", novembre 2000

Josh Bailey, Emmanuel Hislen et Marc Bongartz de Lucent Technologies ont fourni une aide inestimable en relisant ce document et en revoyant sa mise en œuvre.

Thomas Narten de IBM Corporation ont fourni des suggestions précieuses et perspicaces

Les premières mises en œuvre de cette spécification ont utilisé des valeurs spécifiques de fabricant pour le nouveau message de commande et les AVP. Cet appendice décrit les allocations initiales spécifique de fabricant dans le seul but de la référence historique.

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.

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

Groupe de travail Réseau	I. Goyret, Lucent Technologies
Request for Comments : 3573	juillet 2003
Catégorie : En cours de normamisation	Traduction Claude Brière de L’Isle