Métriques IPPM pour la mesure de la connexité

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

Notice de copyright

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

1. Introduction

La connexité est la substance de base dont est fait l’Internet. Donc, les métriques qui déterminent si des paires d’hôtes (des adresses IP) peuvent s’atteindre l’un l’autre doivent former la base d’une suite de mesures. On définit plusieurs de ces métriques, dont certaines qui servent principalement d’éléments de construction pour les autres.

Le présent mémoire définit une série de métriques pour la connexité entre une paire d’hôtes Internet. Il est bâtit sur les notions introduites et discutées dans la RFC2330, le document cadre de IPPM. Le lecteur est supposé être familiarisé avec ce document.

La structure du présent mémoire est la suivante :

+ Une métrique analytique, appelée connexité unidirectionnelle instantanée de type P (Type-P-Instantaneous-Unidirectional-Connectivity) sera introduite pour définir la connexité unidirectionnelle à un instant donné.

+ En utilisant cette métrique, une autre métrique analytique, appelée connexité bidirectionnelle instantanée de type P (Type-P-Instantaneous-Bidirectional-Connectivity) sera introduite pour définir la connexité bidirectionnelle à un instant donné.

+ En utilisant ces métriques, les métriques analytiques unidirectionnelle et bidirectionnelle correspondantes sont définies pour la connexité sur un intervalle de temps.

+ En utilisant ces métriques, une métrique analytique, appelée connexité d’intervalle temporel de type P1-P2 (Type-P1-P2-Interval-Temporal-Connectivity) sera introduite pour définir une notion utile de connexité bidirectionnelle entre deux hôtes sur un intervalle de temps.

+ Les méthodologies seront alors présentées et discutées pour estimer la connexité d’intervalle temporel de type P1-P2 dans divers réglages.

Une définition soigneuse de la connexité d’intervalle temporel de type P1-P2 et la discussion de la métrique et des méthodologies pour l’estimer sont les deux principales contributions du présent mémoire.

2. Connexité unidirectionnelle instantanée

2.1 Nom de la métrique

Connexité unidirectionnelle instantanée de type P

2.2 Paramètres de la métrique

+ Src, l’adresse IP d’un hôte

+ Dst, l’adresse IP d’un hôte

+ T, un instant

2.3 Unités de la métrique

Booléen.

2.4 Définition

Src a une *connexité unidirectionnelle instantanée de type P* avec Dst à l’instant T si un paquet de type-P transmis de Src à Dst à l’instant T va arriver à Dst.

2.5 Discussion

Pour la plupart des applications (par exemple, toute connexion TCP) la connexité bidirectionnelle est considérablement plus appropriée que la connexité unidirectionnelle, bien que celle-ci puisse être intéressante pour certaines applications de sécurité (par exemple, pour vérifier si un pare-feu filtre correctement des "ping de la mort"). La plupart des applications exigent aussi la connexité sur un intervalle, alors que cette métrique est instantanée, quoique là encore, pour certaines applications de sécurité, la connexité instantanée reste intéressante. Finalement, on peut ne pas avoir la connexité instantanée à cause d’un événement transitoire tel qu’une file d’attente pleine chez un routeur, même si à des instants voisins on avait la connexité. Ces points sont traités ci-dessous, en se servant de cette métrique comme matériau de construction.

Noter aussi qu’on n’a pas explicitement défini *quand* le paquet arrive à Dst. Le champ TTL dans les paquets IP est destiné à limiter la durée de vie des paquets IP à 255 secondes [RFC0791]. En pratique, le champ TTL peut être strictement un compte de bonds [RFC1812] la plupart des bonds Internet étant bien inférieurs à une seconde. Cela signifie que la plupart des paquets n’auront rien qui s’approche de la durée de vie de 255 secondes. En principe, cependant, il est aussi possible que des paquets puissent survivre plus longtemps que 255 secondes. Les considérations sur la durée de vie des paquets doivent être prises en compte pour tenter de mesurer la valeur de cette métrique.

Finalement; on peut supposer que la connexité unidirectionnelle est difficile à mesurer en l’absence de connexité dans la direction inverse. Considérons cependant la possibilité qu’un processus chez l’hôte de Dst note quand il reçoit les paquets provenant de Src et rapporte ce fait soit en utilisant un canal externe, soit ultérieurement lorsque Dst n’a pas la connexité avec Src. Une telle méthodologie pourrait mesurer fiablement la connexité unidirectionnelle définie dans cette métrique.

3. Connexité bidirectionnelle instantanée

3.1 Nom de la métrique

Connexité bidirectionnelle instantanée de type P

3.2 Paramètres de la métrique

+ A1, l’adresse IP d’un hôte

+ A2, l’adresse IP d’un hôte

+ T, un instant

3.3 Unités de la métrique

Booléen.

3.4 Définition

Les adresses A1 et A2 ont la *connexité bidirectionnelle instantanée de type P* à l’instant T si l’adresse A1 a la connexité unidirectionnelle instantanée de type P avec l’adresse A2 et si l’adresse A2 a la connexité unidirectionnelle instantanée de type P avec l’adresse A1.

3.5 Discussion

Une autre définition possible serait que A1 et A2 soient pleinement connexes si à l’instant T l’adresse A1 a la connexité instantanée avec l’adresse A2, et si à l’instant T+dT l’adresse A2 a la connexité instantanée avec A1, où T+dT est lorsque le paquet envoyé de A1 arrive chez A2. Cette définition est plus utile pour la mesure, parce que cette mesure peut utiliser une réponse de A2 à A1 afin de d’attester la pleine connexité. C’est cependant une définition plus complexe parce qu’elle rompt la symétrie entre A1 et A2, et exige une notion de quantification du temps que met un certain paquet pour aller de A1 à A2. On repoussera la discussion de cette distinction au développement sur les métriques d’intervalle de connexité.

4. Connexité unidirectionnelle

4.1 Nom de la métrique

Connexité unidirectionnelle d’intervalle de type P

4.2 Paramètres de la métrique

+ Src, l’adresse IP d’un hôte

+ Dst, l’adresse IP d’un hôte

+ T, un instant

+ dT, une durée

{Commentaire : Donc, l’intervalle fermé [T, T+dT] note un intervalle de temps.}

4.3 Unités de la métrique

Booléen.

4.4 Définition

L’adresse Src a la *connexité unidirectionnelle d’intervalle de type P* avec l’adresse Dst durant l’intervalle [T, T+dT] si pour un temps T' compris dans [T, T+dT] il a la connexité unidirectionnelle d’intervalle de type P avec Dst.

5. Connexité bidirectionnelle

5.1 Nom de la métrique

Connexité bidirectionnelle d’intervalle de type P

5.2 Paramètres de la métrique

+ A1, l’adresse IP d’un hôte

+ A2, l’adresse IP d’un hôte

+ T, un instant

+ dT, une durée

{Commentaire : Donc, l’intervalle fermé [T, T+dT] note un intervalle de temps.}

5.3 Unités de la métrique

Booléen.

5.4 Définition

Les adresses A1 et A2 ont la *connexité bidirectionnelle d’intervalle de type P* entre eux durant l’intervalle [T, T+dT] si l’adresse A1 a la connexité bidirectionnelle d’intervalle de type P avec l’adresse A2 durant l’intervalle et si l’adresse A2 a la connexité bidirectionnelle d’intervalle de type P avec l’adresse A1 durant l’intervalle.

5.5 Discussion

Cette métrique n’est pas tout à fait ce dont on a besoin pour définir une connexité "d’utilité générale" – qui exige la notion qu’un paquet envoyé de A1 à A2 puisse obtenir une réponse de A2 qui va atteindre A1. Avec cette définition, il se pourrait que A1 et A2 aient une pleine connexité mais seulement, par exemple, à l’instant T1 assez tôt dans l’intervalle [T, T+dT] pour que A1 et A2 ne puissent pas répondre aux paquets envoyés par l’autre. Cette déficience motive la métrique suivante.

6. Connexité temporelle bidirectionnelle

6.1 Nom de la métrique

Connexité d’intervalle temporel de type P1-P2

6.2 Paramètres de la métrique

+ Src, l’adresse IP d’un hôte

+ Dst, l’adresse IP d’un hôte

+ T, un instant

+ dT, une durée

{Commentaire : Donc, l’intervalle fermé [T, T+dT] note un intervalle de temps.}

6.3 Unités de la métrique

Booléen.

6.4 Définition

L’adresse Src a la *connexité d’intervalle temporel de type P1-P2* avec l’adresse Dst durant l’intervalle [T, T+dT] si il existe des temps T1 et T2, et des intervalles de temps dT1 et dT2, tels que :

+ T1, T1+dT1, T2, T2+dT2 soient tous dans [T, T+dT].

+ T1+dT1 ≤ T2.

+ À l’instant T1, Src a la connexité instantanée de type-P1 avec Dst.

+ À l’instant T2, Dst a la connexité instantanée de type P2 avec Src.

+ dT1 est le temps mis par un paquet de type P1 envoyé par Src à l’instant T1 pour arriver à Dst.

+ dT2 est le temps mis par un paquet de type P2 envoyé par Dst à l’instant T2 pour arriver à Src.

6.5 Discussion

Cette métrique définit la connexité "d’utilité générale" -- Src peut envoyer un paquet à Dst qui obtient une réponse. Comme de nombreuses applications utilisent différents types de paquets pour transmettre et renvoyer du trafic, il est possible (et vraisemblable) que les réponses désirées à un paquet de type P1 seront d’un type différent P2. Donc, dans cette métrique, on permet des types de paquet différents dans les directions de transmission et de retour.

6.6 Méthodologies

On présente ici une classe de méthodologies pour estimer la connexité d’intervalle temporel de type P1-P2. C’est une classe plutôt qu’une seule méthodologie parce que les particularités vont dépendre des types P1 et P2.

6.6.1 Entrées

+ Types P1 et P2, adresses A1 et A2, intervalle [T, T+dT].

+ N, nombre de paquets à envoyer comme sondes pour déterminer la connexité.

+ W, "temps d’attente", qui limite la durée pendant laquelle il est utile d’attendre une réponse à un paquet. Valeurs exigées : W ≤ 255, dT > W.

6.6.2 Valeurs recommandées

dT = 60 secondes.

W = 10 secondes.

N = 20 paquets.

6.6.3 Algorithme

+ Calculer N *heures d’envoi* qui sont uniformément distribuées au hasard sur [T, T+dT-W].

+ À chaque heure d’envoi, transmettre à partir de A1 un paquet bien formé de type P1 à A2.

+ Inspecter le trafic réseau entrant pour A1 pour déterminer si une réponse réussie est reçue. Les particularités de ce comportement dépendent des types P1 et P2, qu’on discute plus loin. Si une réponse réussie est reçue, la valeur de la mesure est "vrai". À ce moment, la mesure peut se terminer.

+ Si aucune réponse réussie n’est reçue à l’instant T+dT, la valeur de la mesure est "faux".

6.6.4 Discussion:

L’algorithme est inexact parce qu’il ne sonde pas (et ne peut pas le faire) la connexité temporelle à chaque instant sur [T, T+dT]. La valeur de N fait un compromis entre la précision de mesure et la charge de la mesure du réseau. L’état de l’art de la recherche Internet n’offre pas pour l’instant de directives solides pour choisir N. Les valeurs données ci-dessus sont de simples lignes directrices.

6.6.5 Méthodologie spécifique pour TCP

Une méthodologie TCP-port-N1-port-N2 envoie des paquets TCP SYN avec l’accès de source N1 et l’accès de destination N2 à l’adresse A2. Le trafic réseau entrant en A1 est interprété comme suit :

+ Un paquet SYN-ack provenant de A2 à A1 avec les champs d’accusé de réception et l’accès appropriés indique une connexité temporelle. La mesure se termine immédiatement avec une valeur de "vrai". {Commentaire : Si, par un effet collatéral de la méthodologie, une pleine connexion TCP a été établie entre A1 et A2 – c’est-à-dire, si la pile TCP de A1 accuse réception du paquet SYN-ack de A2, achevant la prise de contact à trois étapes – alors le mieux pour supprimer la connexion maintenant établie entre A1 et A2 est d’utiliser la prise de contact FIN usuelle, et non d’utiliser un paquet RST, parce que les paquets RST ne sont pas livrés de façon fiable. Cependant, si la prise de contact à trois étapes n’est pas achevée, ce qui va survenir si l’outil de mesure sur A1 synthétise son propre paquet SYN initial plutôt que de passer à travers la pile TCP de A1, alors la pile TCP de A1 va automatiquement terminer la connexion de façon fiable lorsque A2 continue de transmettre le SYN-ack en tentant d’établir la connexion. Finalement, on note qu’utiliser la pile TCP de A1 pour conduire les mesures complique la méthodologie car la pile peut retransmettre le paquet SYN initial, altérant le nombre de paquets sondes envoyés.}

+ Un paquet RST de A2 à A1 avec les accès appropriés indique la connexité temporelle entre les adresses (et un *manque* de connexité de service pour TCP-port-N1-port-N2 – quelque chose qui devrait probablement être traité avec une autre métrique).

+ Un message ICMP Accès injoignable de A2 à A1 indique la connexité temporelle entre les adresses (et encore un *manque* de connexité de service pour TCP-port-N1-port-N2). {Commentaire : Les mises en œuvre de TCP n’ont généralement pas besoin d’envoyer des messages ICMP Accès injoignable parce que un mécanisme distinct est disponible (l’envoi d’un RST). Cependant, la [RFC1122] déclare qu’un TCP qui reçoit un accès injoignable ICMP DOIT le traiter de la même façon que le mécanisme équivalent de niveau transport (pour TCP, un RST).}

+ Un message ICMP Hôte injoignable ou Réseau injoignable à A1 (pas nécessairement de A2) avec un en-tête IP inclus qui correspond à celui envoyé de A1 à A2 *suggère* un manque de connexité temporelle. Si à l’instant T+dT aucune preuve de connexité temporelle n’a été recueillie, alors la réception du message ICMP peut être utilisée comme information supplémentaire pour la valeur de mesure de "faux".

{Commentaire : Des méthodologies similaires sont nécessaires pour l’écho ICMP, UDP, etc.}

7. Remerciements

Les commentaires de Guy Almes, Martin Horneffer, Jeff Sedayao et de Sean Shapira ont été appreciés.

8. Considérations pour la sécurité

Comme on l’a noté dans la [RFC2330] des techniques de mesure actives, telles que celles définies dans le présent document, peuvent être détournées pour des attaques de déni de service déguisées en activités de mesure légitimes. De plus, des essais de connexité peuvent être utilisés pour sonder les points faibles des pare-feu et autres mécanismes de sécurité.

9. Références

[RFC0791] J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.

[RFC1122] R. Braden, "Exigences pour les hôtes Internet – couches de communication", STD 3, octobre 1989. (MàJ par la RFC6633)

[RFC1812] F. Baker, "Exigences pour les routeurs IP version 4", juin 1995. ( (MàJ par les RFC2644, RFC6633)

[RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Cadre pour la mesure des performances d'IP", mai 1998. (Information)

10. Adresse des auteurs

11. 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 copyright ci-dessus et le présent et 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 copyright 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 copyright 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 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.