4.1.1 Interfaces
La figure ci dessous permet de visualiser les trois
interfaces de l'API_IPsec qui ont interaction avec:
- La couche applicative : elle permet à l'API
de communiquer avec les applications de plus haut niveau. Un exemple de
dialogue est une application qui utilise les fonctionnalités de
l'API_IPsec pour gérer la mobilité/multihoming.
- Les API_IPsec distantes : elle permet à un
noeud de communiquer à une API_IPsec distante les opérations
à effectuer, ou d'informer l'API_IPsec distante d'un
événement pour que puissent être prises les actions de part
et d'autre. Pour cela, le transfert de Contexte sera
utilisé.
- La couche IPsec : elle permet a l'API_IPsec de
traduire au niveau des SPD, SAD et IKE les requêtes provenant des
précédentes interface.
Figure 12. Interfaces de l'API_IPSEC
4.1.2 Fonctionnement global
Le fonctionnement global de l'API_IPsec est
présenté dans la figure suivante qui met en évidence les
différentes bases de données (SPD, SAD, PAD) et le démon
IKEv2 qui interagissent avec l'API_IPsec. L'API_IPsec maintient à jour
une base de donnée qui contient des informations sur les SA's, les SP's
et les contextes d'IKE, de Mobilité, de Multihoming... liés
à chaque canal IPsec. En fonction de ces différentes
informations, l'API_IPsec va pouvoir gérer les différents cas de
mise à jour ou d'héritage des SA.
Figure 13. Fonctionnement global de
l'API_IPSEC
|
Etude d'IPsec
Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
4.1.3 La base de donées DB
La base de données DB de l'API _IPsec est
constituée par l'ensemble des tables suivantes:
- DBC: table Centrale de liaison entre toutes les autres
tables. Elle a comme index les SA _ID.
- DB_SA: table dynamique ou liste enchdinée
d'objets SA. Elle est une "image" de la SAD.
- DB_SP : table dynamique ou liste
enchaînée d'objets SP. Elle est une "image" de la SPD.
- DB_MH : table de MultiHoming. Chaque entrée
ajoutée est constitué par une SA de référence, une
liste de ses SA héritées et une indication du type de flux et des
données héritées. Pour l'instant, on considère une
méthode fixe de dérivation de la clé pour les SA
hérités.
DB_SA
|
INDEX SA
|
IPSEC
|
CRYPTO MATERIAL
|
LIFETIME
|
ID
|
*NEXT
|
SPI
|
@SRC
|
@DST
|
MODE
|
TYPE
|
SEQ
|
O THERS
|
ALGO
|
LEN
|
KEY
|
|
1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ID 2
ID N
NULL
&SA
&SA
N < DB_SA_MAXREGS
·
·
·
Liste enchainee
de N objets SA
"NEXT
INDEX SA
IPSEC
CRYPTO MATERIAL LIFETIME
INDEX SA
IPSEC
CRYPTO MATERIAL LIFETIME
DB_SP
|
INDEX SP
|
SELECTOR
|
POLICY
|
LIFETIME
|
ID
|
*NEXT
|
SPID
|
SEQ
|
Range
@SRC
|
Range
@DST
|
Port
SRC
|
Port
DS T
|
UPPER
PROTOCOL
|
MODE / TYPE / ...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
&SP
INDEX SP SELECTOR / POLICY LIFETIME
ID 2
"NEXT
M < DB_SP_MAXREGS
Liste enchainee
de M objets SP
·
·
·
&SP
INDEX SP SELECTOR / POLICY LIFETIME
ID M
NULL
DB_MH
SA REFERENCE
|
INHERITED SA LIST
|
FLOW ID
|
FLAG OF INHERITANCE
|
ID
|
SPI
|
@SRC
|
@DST
|
*DB_SA
|
(POIN TERS; MAX 3)
|
|
|
|
|
|
|
|
|
|
|
|
@src
@dst
ype
Mode
Lifetime
Algorithm
·
·
·
DBC
|
INDEX SA
|
STATUS
|
SFD_REMOTE
|
LINKS WITH OTHER TABLES (POINTERS)
|
ID
|
SPI
|
@SRC
|
@DST
|
|
|
"DB_SA
|
"DB_SP
|
"DB_MH
|
"DB_MIP
|
|
|
|
|
|
|
|
|
|
|
|
Figure 14. Tables de la base de données DB de
l'API_IPsec
On défini aussi les suivants tables, lesquelles
ne sont pas développées dans le premier prototype d'API_IPsec
mais elles sont envisagées lors d'un prochain stage ou thèse
:
- DB_IKE (Internet Key Exchange) :
Table de données avec le contexte relatif
à une négociation IKE entre deux adresses IP. En effet,
on se
place dans le cas oil la négociation d'une première SA dite SA
originelle se fait grâce à
|
Etude d'IPsec
Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
IKEv2. C'est ce protocole qui va permettre avec le
temps de lancer des renégociations, de changements de clés, etc.
Lorsque l'on crée une SA à partir de la SA originelle, il est
nécessaire qu'un contexte IKEv2 lui soit associé. La nouvelle SA
sera alors associée à une SA "normale", i.e. indépendante
et pouvant bénéficier des fonctionnalités de IKEv2 pour
une connexion établie. L'avantage est que on ne procédera pas
à la création de la nouvelle SA sans procéder à une
négociation par IKEv2, et ainsi économiser du temps
réseau. Cette table est très liée à
l'implémentation de IKEv2, car les paramètres du contexte IKEv2
comprennent des paramètres réseau mais aussi des
paramètres liés à l'implémentation. La table devra
tenir compte de cette distinction. On envisagera par exemple un contexte
générique, puis un contexte lié à chaque
implémentation. Dans un premier temps cette table sera liée
à OpenIKEv2, et les opérations sur les contextes de IKEv2 se
contenteront d'utiliser la librairie d'OpenIKEv2.
- DB_MIP (Mobilité IP)
Cette table prend un format similaire à la base
de données MSRD qu'on a vu dans l'état de l'art de l'Étude
Théorique (section 3.2.5), et elle doit maintenir des interactions
semblables avec PF_KEY, IKEv2 et MIPv6. Chaque entrée ajoutée est
constitué par un identificateur Mobile Parameter Index (MPI), et les
informations de mobilité du noeud Local et Distante :
o Type de noeud : communicant (CN) et/ou en
mobilité (MN)
o Status de la mobilité : REQUESTED /
PROCEEDED / ESTABLISHED;
o Éléments de MIP: Home Agent (HA), Home
of Address (HoA), Care of Address (CoA).
o Associations de sécurité : trois couples
de SA qu'on explique après de présenter la table.
|
DB_MIP
|
LOCAL
|
|
REMOTE
|
|
MPI
|
TYPE
|
STATUS
|
C
|
*SAs local
|
H
|
H
|
*SAs
|
H
|
H
|
*SAs
|
C
|
STATUS
|
TYPE
|
|
|
|
o
|
|
A
|
o
|
middle
|
o
|
A
|
remote
|
o
|
|
|
|
|
|
A
|
|
|
A
|
|
A
|
|
|
A
|
|
|
|
1
|
MN
|
ESTABLISHED
|
2.1
|
SAs21
|
1.0
|
1.1
|
SAs14
|
X
|
X
|
X
|
4.1
|
ESTABLISHED
|
CN
|
|
2
|
MN
|
ESTABLISHED
|
2.1
|
SAs21
|
1.0
|
1.1
|
SAs13
|
3.1
|
3.0
|
SAs34
|
4.1
|
ESTABLISHED
|
MN
|
Figure 15. Proposition de la table MIP de la base de
données DB de l'API_IPsec
En effet, il y a une couple de SAs entre la CoA et le
HA si un noeud est en mobilité, deux pour le noeud Local « SAs
local » et deux pour le noeud distante « SAs remote ». Dans le
cas qu'un seul noeud est en mobilité (type MN), les deux « SA
middle » sont entre la HoA du MN et l'adresse physique CoA de l'autre
noeud CN. Dans ce cas, le noeud CN n'a pas de HA, HoA et « SAs remote
». Dans le cas que les deux noeuds sont en mobilité, les deux sont
de type CN, et les deux disposent de CoA, HA, « SAs local / remote »
et HoA, et ils partagent des « SAs middle » entre les HoA de chacun.
On montre dans la table précédente ces deux possibles
cas.
- DB_HIP (Host Identity) : Les deux noeuds sont
identifiés par un identifiant et non plus une adresse IP ou "locator".
Des
|
Etude d'IPsec
Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
exemples d'identifiant pourront être les Host
Identity (HI) qui correspond à un clé publique ou au hash de
cette dernière, le Host Identity Tag (HIT). Cette table s'inspire de HIP
(Host Identity Protocol), et on envisage pour un prochain stage ou thèse
de regarder OpenHIP (une implémentation "open-source" en
développement) et étudier la relation avec
l'API_IPsec.
| 
