4. Paires Attribut-Valeur des Messages de Contrôle
Pour maximiser l'extensibilité tout en permettant l'interopérabilité, une méthode uniforme pour encoder les types et corps de messages est utilisée dans tout L2TP. Cet encodage sera appelé AVP (Attribute-Value Pair, Paire Attribut-Valeur) dans le reste de ce document.
4.1 Format AVP
Chaque AVP est encodé comme suit :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Attribute Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[jusqu'à ce que Length soit atteint]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les six premiers bits sont un masque de bits, décrivant les attributs généraux de l'AVP.
Deux bits sont définis dans ce document, les autres sont réservés pour de futures extensions. Les bits réservés DOIVENT être définis à 0. Un AVP reçu avec un bit réservé défini à 1 DOIT être traité comme un AVP non reconnu.
Bit Mandatory (M) : Contrôle le comportement requis d'une implémentation qui reçoit un AVP qu'elle ne reconnaît pas. Si le bit M est défini sur un AVP non reconnu dans un message associé à une session particulière, la session associée à ce message DOIT être terminée. Si le bit M est défini sur un AVP non reconnu dans un message associé au tunnel global, le tunnel entier (et toutes les sessions à l'intérieur) DOIT être terminé. Si le bit M n'est pas défini, un AVP non reconnu DOIT être ignoré. Le message de contrôle doit alors continuer à être traité comme si l'AVP n'avait pas été présent.
Bit Hidden (H) : Identifie le masquage des données dans le champ Attribute Value d'un AVP. Cette capacité peut être utilisée pour éviter le passage de données sensibles, telles que les mots de passe utilisateur, en texte clair dans un AVP. La section 4.3 décrit la procédure pour effectuer le masquage d'AVP.
Length : Encode le nombre d'octets (y compris les champs Overall Length et masque de bits) contenus dans cet AVP. La Length peut être calculée comme 6 + la longueur du champ Attribute Value en octets. Le champ lui-même fait 10 bits, permettant un maximum de 1023 octets de données dans un seul AVP. La longueur minimale d'un AVP est 6. Si la longueur est 6, alors le champ Attribute Value est absent.
Vendor ID : La valeur IANA attribuée "SMI Network Management Private Enterprise Codes" [RFC1700]. La valeur 0, correspondant aux valeurs d'attributs adoptées par l'IETF, est utilisée pour tous les AVP définis dans ce document. Tout fournisseur souhaitant implémenter ses propres extensions L2TP peut utiliser son propre Vendor ID avec des valeurs d'Attribute privées, garantissant qu'elles n'entreront pas en collision avec les extensions d'un autre fournisseur, ni avec les futures extensions IETF. Notez que 16 bits sont alloués pour le Vendor ID, limitant ainsi cette fonctionnalité aux 65 535 premières entreprises.
Attribute Type : Une valeur de 2 octets avec une interprétation unique à travers tous les AVP définis sous un Vendor ID donné.
Attribute Value : C'est la valeur réelle comme indiqué par le Vendor ID et l'Attribute Type. Elle suit immédiatement après le champ Attribute Type et s'étend sur les octets restants indiqués dans la Length (c'est-à-dire Length moins 6 octets d'en-tête). Ce champ est absent si la Length est 6.
4.2 AVPs Obligatoires
La réception d'un AVP inconnu dont le bit M est défini est catastrophique pour la session ou le tunnel auquel il est associé. Ainsi, le bit M ne devrait être défini que pour les AVP qui sont absolument cruciaux pour le bon fonctionnement de la session ou du tunnel. De plus, dans le cas où le LAC ou le LNS reçoit un AVP inconnu avec le bit M défini et ferme la session ou le tunnel en conséquence, il incombe entièrement au pair qui envoie l'AVP obligatoire d'accepter la faute pour avoir causé une situation non interopérable. Avant de définir un AVP avec le bit M défini, en particulier un AVP spécifique au fournisseur, assurez-vous que c'est la conséquence prévue.
Lorsqu'une alternative adéquate à l'utilisation du bit M existe, elle devrait être utilisée. Par exemple, plutôt que d'envoyer simplement un AVP avec le bit M défini pour déterminer si une extension spécifique existe, la disponibilité peut être identifiée en envoyant un AVP dans un message de requête et en attendant un AVP correspondant dans un message de réponse.
L'utilisation du bit M avec de nouveaux AVP (ceux non définis dans ce document) DOIT fournir la possibilité de configurer la fonctionnalité associée comme désactivée, de sorte que l'AVP ne soit pas envoyé ou soit envoyé sans le bit M défini.
4.3 Masquage des Valeurs d'Attribut AVP
Le bit H dans l'en-tête de chaque AVP fournit un mécanisme pour indiquer au pair récepteur si le contenu de l'AVP est masqué ou présent en texte clair. Cette fonctionnalité peut être utilisée pour masquer les données de message de contrôle sensibles telles que les mots de passe utilisateur ou les ID utilisateur.
Le bit H NE DOIT être défini que si un secret partagé existe entre le LAC et le LNS. Le secret partagé est le même secret qui est utilisé pour l'authentification du tunnel (voir section 5.1.1). Si le bit H est défini dans un ou plusieurs AVP d'un message de contrôle donné, un AVP Random Vector doit également être présent dans le message et DOIT précéder le premier AVP ayant un bit H de 1.
Le masquage d'une valeur AVP se fait en plusieurs étapes. La première étape consiste à prendre les champs de longueur et de valeur de l'AVP original (texte clair) et à les encoder dans un sous-format AVP masqué comme suit :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Original Value | Original Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Padding ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of Original Attribute Value : C'est la longueur de la valeur d'attribut originale à obscurcir en octets. Cela est nécessaire pour déterminer la longueur originale de la valeur d'attribut qui est perdue lorsque le rembourrage supplémentaire est ajouté.
Original Attribute Value : Valeur d'attribut qui doit être obscurcie.
Padding : Octets supplémentaires aléatoires utilisés pour obscurcir la longueur de la valeur d'attribut qui est masquée.
Pour masquer la taille des données masquées, le sous-format résultant PEUT être rembourré comme indiqué ci-dessus. Le rembourrage ne modifie PAS la valeur placée dans le champ Length of Original Attribute Value, mais modifie la longueur de l'AVP résultant qui est créé.
Ensuite, un hachage MD5 est effectué sur la concaténation de :
- le numéro d'attribut de 2 octets de l'AVP
- le secret partagé
- un vecteur aléatoire de longueur arbitraire
La valeur du vecteur aléatoire utilisée dans ce hachage est passée dans le champ de valeur d'un AVP Random Vector. Cet AVP Random Vector doit être placé dans le message par l'expéditeur avant tout AVP masqué.
La valeur de hachage MD5 est ensuite XORée avec le premier segment de 16 octets (ou moins) du sous-format AVP masqué et placée dans le champ Attribute Value de l'AVP masqué.
Si le sous-format est plus long que 16 octets, un second hachage MD5 unidirectionnel est calculé sur un flux d'octets constitué du secret partagé suivi du résultat du premier XOR. Ce hachage est XORé avec le second segment de 16 octets (ou moins) du sous-format et placé dans les octets correspondants du champ Value de l'AVP masqué.
Si nécessaire, cette opération est répétée, avec le secret partagé utilisé avec chaque résultat XOR pour générer le hachage suivant pour XORer le segment suivant de la valeur.
La méthode de masquage a été adaptée du RFC 2138 [RFC2138] qui a été tiré de la section "Mixing in the Plaintext" du livre "Network Security" de Kaufman, Perlman et Speciner [KPS]. Une explication détaillée de la méthode suit :
Appelons le secret partagé S, le vecteur aléatoire RV et la valeur d'attribut AV. Divisez le champ de valeur en morceaux de 16 octets p1, p2, etc. avec le dernier rembourré à la fin avec des données aléatoires jusqu'à une limite de 16 octets. Appelons les blocs de texte chiffré c(1), c(2), etc. Nous définirons également les valeurs intermédiaires b1, b2, etc.
b1 = MD5(AV + S + RV) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor bi
La chaîne contiendra c(1)+c(2)+...+c(i) où + désigne la concaténation.
À la réception, le vecteur aléatoire est tiré du dernier AVP Random Vector rencontré dans le message avant l'AVP à démasquer. Le processus ci-dessus est alors inversé pour obtenir la valeur originale.
4.4 Résumé AVP
Les sections suivantes contiennent une liste de tous les AVP L2TP définis dans ce document.
Après le nom de l'AVP suit une liste indiquant les types de messages qui utilisent chaque AVP. Après chaque titre d'AVP suit une brève description du but de l'AVP, un détail (y compris un graphique) du format pour la valeur d'attribut, et toute information supplémentaire nécessaire pour une utilisation appropriée de l'AVP.
4.4.1 AVPs Applicables à Tous les Messages de Contrôle
Message Type (Tous les messages)
L'AVP Message Type, Attribute Type 0, identifie le message de contrôle ici et définit le contexte dans lequel la signification exacte des AVP suivants sera déterminée.
Le champ Attribute Value pour cet AVP a le format suivant :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Message Type est un entier non signé de 2 octets.
L'AVP Message Type DOIT être le premier AVP dans un message, immédiatement après l'en-tête du message de contrôle (défini dans la section 3.1). Voir la section 3.2 pour la liste des types de messages de contrôle définis et leurs identifiants.
Le bit Mandatory (M) dans l'AVP Message Type a une signification spéciale. Plutôt qu'une indication pour savoir si l'AVP lui-même doit être ignoré s'il n'est pas reconnu, c'est une indication pour savoir si le message de contrôle lui-même doit être ignoré. Ainsi, si le bit M est défini dans l'AVP Message Type et que le Message Type est inconnu de l'implémentation, le tunnel DOIT être effacé. Si le bit M n'est pas défini, alors l'implémentation peut ignorer un type de message inconnu. Le bit M DOIT être défini à 1 pour tous les types de messages définis dans ce document. Cet AVP ne peut pas être masqué (le bit H DOIT être 0). La longueur de cet AVP est 8.
Random Vector (Tous les messages)
L'AVP Random Vector, Attribute Type 36, est utilisé pour permettre le masquage de l'Attribute Value d'AVP arbitraires.
Le champ Attribute Value pour cet AVP a le format suivant :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octet String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La chaîne d'octets aléatoires peut être de longueur arbitraire, bien qu'un vecteur aléatoire d'au moins 16 octets soit recommandé. La chaîne contient le vecteur aléatoire à utiliser pour calculer le hachage MD5 afin de récupérer ou de masquer l'Attribute Value d'un AVP masqué (voir section 4.2).
Plus d'un AVP Random Vector peut apparaître dans un message, auquel cas un AVP masqué utilise l'AVP Random Vector le plus proche qui le précède. Cet AVP DOIT précéder le premier AVP avec le bit H défini.
Le bit M pour cet AVP DOIT être défini à 1. Cet AVP NE DOIT PAS être masqué (le bit H DOIT être 0). La longueur de cet AVP est 6 plus la longueur de la chaîne d'octets aléatoires.
(Suite : Définitions AVP supplémentaires suivent...)