Scenario 1 : Un flux AH en mode Tunnel et NA(P)T

5.5.1.1 L’authentification

Dans ce scenario, nous étudions l’interaction entre un mécanisme qui met en œuvre AH (Authentication Header) en mode tunnel et le mécanisme NA(P)T. Ce scenario présentera l’encapsulation (tunneling) et montrera la détection de conflit en utilisant GAM sans avoir de connaissance a priori dans le domaine.

Notre étude consiste donc à analyser la chaine de transformation

, qui affecte un flux de données {} {} où les ensembles AUTHN et CONF sont vides.

réseau de Pétri et associé à la mise en œuvre du protocole AH en mode tunnel. Comme nous l’avons indiqué dans notre formalisme, les opérations de transformation du flux peuvent être impactées par des attributs contextuels « _{» figurant dans une règle de configuration du mécanisme « M ». Nous}

considérons que ces attributs contextuels pourraient être communs à plusieurs mécanismes. En conséquence ils figurent dans « Memory ».

Le résultat « F’ » est un flux authentifié qui doit traverser NA(P)T et dont naturellement la sortie devrait être « F’’ ».

Figure 42. La détection des conflits : état initial

Nous supposons qu’après avoir injecté le flux « F » dans IPsec, la condition [ ] de l’application du protocole AH en mode tunnel est validée et doit donc être satisfaite.

En conséquence, l’ doit alors être engagée. Elle nécessite l’exécution de la fonction ApplyIPsec (F, proto-IPsec, mode, gw,algo). Cette fonction est instanciée avec le flux de données « F », où « proto-IPsec » est le protocole AH, où le mode est tunnel, en donnant la passerelle impactée, et l’algorithme cryptographique à exécuter pour protéger ce qui doit l’être (cf section 5.2.1.3). L’exécution de cette fonction aura pour conséquence la création du flux « F’ ». Nous rappelons ici que :

Le flux de données « F » a été transformé en « F’ » (Figure 43) avec : F’ _{{} et où :}

 { }

ces valeurs sont soulignées en bleu et en haut dans la Figure 43.  { } { } { } { } { } { }

Figure 43. La détection des conflits : un flux de données après l’application de AH

5.5.1.2 L’analyse des conflits

A l’issue du passage par la fonctionnalité IPsec AH en mode tunnel, le flux « F’ » est injecté dans le mécanisme NAPT. En conséquence la fonction est instanciée. Trois appels consécutifs à la primitive de base Modify_Attribute() vont être effectués, l’un portant sur la demande de modification de l’adresse destination, le second pour modifier le port destination et enfin le dernier pour modifier l’attribut checksum (voir l’exemple de mise en œuvre d’un mode tunnel, cf. section 5.2.1.3).

Figure 44. La détection des conflits : AH en mode tunnel bloqué dans NAPT

Lorsqu’on analyse le fonctionnement du réseau de Pétri coloré décrit dans la Figure 44, le jeton de couleur rouge associé au flux de données « F’ » se trouve bloqué à l’intérieur du NAPT- GAM. En conséquence, les flux de données « F’ » ne peut pas être transformé, que ce soit par la tentative de transformation par du NAPT trivial, ou bien par du NAPT évolué. Les raisons en sont les suivantes :

1) Le flux AH en passant par NAPT trivial :

La mise en œuvre du NAPT trivial n’est pas possible car la pré-condition 1 n’est pas vérifiée. La pré-condition1 stipule que le protocole capable de traiter le contenu du datagramme est soit TCP, soit UDP. Si cette pré-condition est vérifiée, il est alors possible de mener une opération de substitution des numéros de ports par les appels consécutifs des primitives GetAttribute() et « Modify_Attribute() ».

Or le protocole cité comme celui capable de traiter le contenu du datagramme IP étant AH (valeur soulignée en jaune dans le flux « F’ » de la Figure 43), AH est donc le protocole invoqué après IP1 (matérialisé par le soulignement en rouge du flux « F’ » dans la Figure 43), AH ne contenant

aucun attribut nommé ports l’opération GetAttribute() ne retourne donc pas les attributs attendus et donc le changement de place n’est pas opéré. Il y a donc blocage ; le flux résultant « F’’ » est vide.

2) Le flux AH en passant par NAPT évolué :

En supposant maintenant que le flux « F’ » soit traité par une fonctionnalité NAPT évoluée, nous devrions être capables de récupérer la valeur des attributs ports. Les opérations de substitution devraient être réalisées et le blocage constaté dans la situation précédente devrait être levé. En conséquence l’obtention du flux de données « F’’ » devrait être l’aboutissement du réseau de Pétri coloré. Nous rappelons que:

{} , où :  { } { }  { } { }

Dans notre formalisme de représentation d’un flux, nous avons introduit l’ensemble AUTHN, qui contient la liste des attributs pour lesquels les valeurs sont certifiées authentique. Rappelons que dans notre notation si (a1, p1, a2, p2, s) AUTHN, alors l’attribut a1, du protocole p1, garantit

l’intégrité de l’attribut a2, du protocole p2 à travers l’algorithme de sécurité « s » (cf.Définition 2).

A l’issue du traitement assuré par le protocole AH de IPsec, nous avons les éléments suivant :  ( ) qui stipule que l’attribut ad du protocole ah

protège le champ ips de valeur old généré par le protocole ip1 en utilisant l’algorithme s

 ( ) qui stipule que l’attribut ad du protocole

ah protège le champ checksum de valeur old généré par le protocole ip1 en utilisant s

 qui stipule que l’attribut ad du protocole ah protège le champ ports de valeur old généré par le protocole tcp en utilisant l’algorithme s

 qui stipule que l’attribut ad du protocole

ah protège le champ checksum de valeur old généré par le protocole tcp en utilisant

l’algorithme s

A l’issue de l’opération de transformation comme AH est utilisé en mode tunnel, un nouvel entête IP est calculé el le calcul du champ d’authentification ad est réalisé en tenant compte des valeurs contenues dans ce nouvel entête. En conséquence :

 qui stipule que l’attribut ad du protocole ah protège le champ ips’ de valeur new généré par le protocole ip2 en utilisant l’algorithme

s

 qui stipule que l’attribut ad du protocole

ah protège le champ checksum’ de valeur new généré par le protocole ip2 en utilisant s

L’opération de transformation NAPT doit apporter une modification sur les valeurs d’adresse et

de numéro de port. A l’issue de l’opération de transformation, comme nous l’avons rappelé plus haut

Comme nous avons considéré que la version de NAPT est évoluée, les pré-conditions sont satisfaites. L’encapsulation porte sur des datagrammes générés par TCP ou UDP, et l’accès aux champs d’adresses est théoriquement possible. Le problème d’intégrité va toutefois rendre impossible la substitution des adresse et numéro de port, car lors de l’invocation de la fonction Modify_Attribute(), les appels consécutifs à Get_Attribute() et Get_Protocol() vont détecter que ces attributs font partie de l’ensemble AUTHN, que ces attributs sont protégés par le champ ad du protocole ah exécuté en mode tunnel. A titre illustratif l’attribut « ports » appartient à l’ensemble AUTHN. Il figure souligner en couleur rose dans la Figure 43.

En conséquence l’exploitation de la transformation NAPT évoluée n’est pas possible, après exécution de AH en mode tunnel.