NetCore

NetCore (Network Core Programming Language) [Monsanto et al., 2012]est un langage qui fait suite aux travaux menés sur Frenetic. L’apport principale de NetCore, par rapport à Frenetic, consiste en la proposition de nouveaux algorithmes de compilation qui permettent

de mieux gérer les interactions entre les commutateurs OpenFlow et le contrôleur SDN.

Plus concrètement, NetCore essaye de traiter le plus possible de paquets au niveau des commutateurs OpenFlow et de ne remonter vers le contrôleur que les paquets qui sont expressément souhaités.

Pour ce faire, NetCore permet aux administrateurs de spécifier des règles de commutation qui utilisent des filtres incomplets (ou joker), sachant que la partie incomplète d’un filtre est générique et peut s’appliquer sur n’importe quelle valeur. La possibilité d’utiliser des filtres incomplets a pour conséquence directe que, d’une part NetCore aura besoin d’installer moins de règles sur les commutateurs (une règle avec un filtre incomplet peut couvrir plusieurs règles avec des filtres complètement spécifiés), et d’autre part, l’utilisation des filtres incomplets est un moyen pour traiter des flux dont on n’a pas forcement une connaissance précise.

2.2.5.1 Politiques de commutation de base

Dans NetCore, une politique de commutation consiste en la spécification d’un prédicat (un filtre) qui capture un flux de paquets, puis l’associer à un ensemble de localisations qui désignent les emplacements vers lesquels ces paquets doivent être transmis. L’extrait ci-dessous montre un exemple simple d’une politique NetCore qui indique que tous les paquets qui proviennent du sous-réseau "10.0.0.0/8" (filtre avec une partie générique), excepté ceux de l’hôte "10.0.0.1" (filtre complètement spécifié) et les flux web, doivent être transmis au commutateur numéro 1.

SrcAddr : 1 0 . 0 . 0 . 0 / 8 \ ( SrcAddr : 1 0 . 0 . 0 . 1 ∪ DstPort : 8 0 ) → s w i t c h{ Switch 1}

Par ailleurs, on peut aussi remarquer dans l’exemple ci-dessus qu’un administrateur a la possibilité de construire des prédicats complexes en utilisant les opérateurs d’union (∪), d’intersection(∩), négation(¬) ou différence (\).

2.2.5.2 Politiques dynamiques

La partie dynamique du langage NetCore permet de spécifier des politiques dont le comportement dépend de l’état du réseau (c.-à-d. l’historique du trafic réseau). En effet, NetCore fournit un prédicat spécial appeléinspectqui interroge l’historique du trafic réseau.

Pour en expliquer son utilisation, nous allons considérer le cas d’utilisation suivant, où l’objectif global est de spécifier une politique d’authentification. La figure 9 schématise le réseau physique sur lequel sera appliquée cette politique. Dans ce cas d’utilisation, les utilisateurs internes qui sont dans le réseau N1 doivent d’abord s’authentifier auprès du serveur afin de pouvoir accéder à Internet (représenté par le réseauN2). On suppose aussi qu’un hôte est considéré comme authentifié si et seulement s’il a reçu un paquet qui provient du serveur d’authentification. En dernier, les hôtes du réseauN2n’ont pas le droit d’accéder au serveur d’authentification.

Le prédicat inspect e fprend toujours en entrée deux paramètres : un filtree, qui est appliqué sur l’historique du trafic et une fonction booléennef. Le filtreegénère un étatΣ qui est une collection de statistiques, représentée abstraitement par un ensemble de couples

Chapitre 2 : État de l’art des langages de contrôle sur l’interface nord de SDN

commutateur-paquet. Par la suite, la fonctionfreçoit notamment cet état comme entrée afin de l’utiliser dans son processus de prise de décision.

( I n P o r t : Network 1 ∩ i n s p e c t ps auth → { Network 2})

∪ ( I n P o r t : Network 1 ∩ ¬ ( i n s p e c t ps auth ) → { S e r v e r A})

∪ ( I n P o r t : S e r v e r A ∪ I n P o r t : Network 2 → { Network 1}) ps = I n P o r t : S e r v e r A

auth (Σ, s , p ) = any ( i s A d d r p ) Σ

i s A d d r p (_ , p ’ ) = p . SrcAddr == p ’ . DstAddr

Dans l’exemple ci-dessus, un paquetpqui arrive du réseauN1sur le commutateurSest transmis au contrôleur qui l’évalue sur le prédicatinspect ps auth. Le filtrepscapture tous les paquets de l’historique qui proviennent du serveur d’authentification. Ce résultat est passé à la fonctionauthqui teste si l’adresse IP source dy paquet actuelpest inclut dans cet ensemble.

Si la fonctionauthretourne une réponse positive, alors une règle de commutation est installée pour l’hôte en question, sinon le paquet sera rejeté.

FIGURE9.NetCore - Exemple topologie[Monsanto et al., 2012]

2.2.5.3 Compilation

Lors de la compilation des politiques de contrôle, l’environnement d’exécution de NetCore essaye de faire en sorte d’installer des règles qui remontent le moins possible de paquets vers le contrôleur SDN. Pour ce faire, en plus de permettre l’utilisation des filtres incomplets, l’environnement d’exécution de NetCore commence d’abord par compiler les politiques qui ne contiennent pas de prédicat de typeinspect, puis il génère les règles de bas-niveau correspondantes et les installe sur les commutateurs. Pour les paquets qui ne peuvent pas être gérés par les commutateurs et doivent être transmis au contrôleur, ce qui inclus le cas du prédicatinspect, le compilateur identifie deux situations :

• La politique qui concerne le paquet est invariante. En d’autres termes, quand elle est appliquée sur ce paquet elle retournera toujours le même résultat d’actions pour les paquets de ce même flux, indépendamment du temps et de l’état du réseau.

• La politique qui concerne le paquet (et tous ceux qui appartiennent au même flux que lui) est volatile. En d’autres termes, les actions qui peuvent être appliquées sur les paquets d’un même flux peuvent changer dans le futur.

Dans le premier cas, le compilateur installe des règles qui prennent en charge les paquets qui sont semblables à celui qui vient d’être traité au niveau du contrôleur. Par exemple, dans le cas d’utilisation précédemment présenté, si un hôte est authentifié il va le rester tout le long de la période d’exécution, donc le compilateur va installer une règle qui se chargera de commuter tous les paquets de l’hôte. Dans le second cas, le compilateur ne peut pas se permettre d’installer des règles sur les commutateurs, étant donné que le prochain paquet pourrait être traité différemment. Ainsi, pour le second cas de figure, les paquets sur lesquels s’applique une politique volatile sont toujours envoyés vers le contrôleur SDN.

Par ailleurs, le compilateur a toujours besoin qu’un administrateur lui fournisse, manuellement, des informations sur l’invariance d’une fonction. Ces informations prennent la forme d’une fonction, écrite par l’administrateur, qui indique si une fonction est invariante ou non. Par exemple, dans le cas d’utilisation précédent, la fonction d’invarianceauth_invest triviale, comme cela est montré ci-dessous, étant donné que c’est une fonction qui retourne vrai si la fonctionauthest vrai (un hôte reste toujours authentifié).

auth_inv (Σ, s , p ) = auth (Σ, s , p )