La route est encore longue vers un réseau qui s’adapte aux applications

Si les besoins applicatifs sont aujourd’hui pris en compte par des appliances réseaux de niveau 4 à 7, telles que les appliances d’optimisation de réseau WAN ou les Firewall, il faudra encore du temps pour mettre en œuvre des politiques coordonnées d’optimisation des trafics applicatifs entre ces équipements. Pire, l’intelligence applicative au niveau 2 et 3, qui pourrait être cruciale, est loin d’être une réalité.

Vers des réseaux capables de traiter de façon intelligente le trafic applicatif 

Il y a dix à quinze ans, la visibilité au niveau 4 était jugée comme suffisante pour router un trafic applicatif. Si un routeur pouvait voir le port de destination, il pouvait faire un pari raisonnable sur la nature de l’application et appliquer un niveau de QoS (quality of service) en conséquence. En s’appuyant sur la même information, un pare-feu pouvait décider d’autoriser ou de bloquer un trafic. S’il était destiné au port 80, par exemple, il était clair qu’il s’agissait d’un trafic http et qu’une politique de type «best effort» était adaptée.

Aujourd’hui, une politique du « best effort » n’est plus suffisante. Des centaines d’applications de natures très différentes s’appuient sur le protocole HTTP, qu’il s’agisse de vidéoconférence ou d’applications métiers comme SalesForce.com et SAP. De ce fait, le réseau doit devenir plus intelligent et analyser plus en profondeur le trafic applicatif afin d’adapter ses performances aux besoins spécifiques de ces applications. Il faut se poser des questions telles que «comment séparer la vidéo d’une session de vidéoconférence de celle d’un match de football ? » s’interroge ainsi Christian Moses, le directeur technique d’E.K. Riley Investments, une société d’investissement basée à Seattle.

«Dans un réseau traditionnel, les deux flux ressemblent à de la vidéo, mais d’un point de vue métier, nous savons tous que des salariés vont regarder des vidéos YouTube sur le réseau d’entreprise. Il faut simplement pouvoir distinguer les deux sous peine d’accorder une priorité indue à des flux inutiles ». L’aptitude à traiter des informations de niveau 4 à 7 existe, mais elle doit évoluer.

Les contrôleurs ADC et les équipements d’optimisation WAN sont de plus en plus à même de séparer les trafics applicatifs et incluent des fonctions de plus en plus sophistiquées pour optimiser et accélérer les applications. De la même façon, les firewalls ont grimpé dans les couches du modèle OSI et sont désormais capables de traiter des informations de niveau 7 pour s’adapter au nouvel environnement de menaces.

«Les firewalls à l’ancienne sont morts. Il n’y a plus de firewall du tout » affirme ainsi Doug Tamasanis, architecte en chef et directeur réseau et sécurité de Kronos un éditeur de solutions de gestion RH. «Dès que vous ouvrez 3 ou 4 ports, vous pouvez jeter votre vieux firewall. Votre seul espoir est de commencer à regarder en profondeur le trafic applicatif »

Pour sécuriser et optimiser son réseau, Tamasanis a adopté des technologies à même d’analyser le trafic au-delà des simples ports et protocoles à savoir des firewalls applicatifs de Palo Alto Networks et des appliances WAN signées Silver Peak. Les trois catégories d’appliances - firewalls, ADC et contrôleurs d’optimisation WAN - gèrent le trafic en fonction de ce qu’ils comprennent de la nature des applications, mais ils fonctionnent de façon isolée dans l’infrastructure, ce qui réduit leur efficacité.

« Ce serait bien de pouvoir dire ‘voici une application et je souhaite que ces trois catégories d’équipements la reconnaissent comme importante et appliquent un jeu de règles cohérentes à ce trafic’ », indique Frey. «Certains arguent du fait que l’on ne verra pas forcément les mêmes applications depuis chaque type d’appliance, et c’est probablement vrai. Mais avec un groupe réduit d’applications critiques, c’est ce qui se produira ».

Citrix Systems, dont la gamme de produits inclut les Application Delivery Controllers NetScaler, les produits d’optimisation WAN Branch Repeater et les contrôleurs SSL VPN Access Gateway, envisage ainsi un futur où la matrice de livraison d’applications formée par ces produits pourrait devenir le plan de contrôle du reste du réseau. «Dans une fabric hétérogène, on peut imaginer que les différents composants se parleront via un protocole dérivé d’OpenFlow», explique ainsi Sunil Potti, vice-président du marketing produit de Citrix. «Aujourd’hui, OpenFlow est un protocole qui permet à des commutateurs hétérogènes d’être contrôlés selon le standard, mais cela se limite au niveau 2-3».

Citrix explore de nouvelles voies pour rendre le trafic applicatif plus transparent aux équipements réseau en découplant le plan de contrôle de ses ADC NetScaler afin d’appliquer son intelligence au niveau 2 et 3 de l’infrastructure, de la même façon qu’OpenFlow permet à un serveur de servir de plan de contrôle pour un réseau de niveau 2-3. Le NetScaler SDX, par exemple, embarque un hyperviseur permettant à des tiers de déployer des services réseau dans l’ADC.

«Si vous avez un NetScaler SDX dans le datacenter et un contrôleur Wi-Fi dans le réseau de Campus, vous pourriez imaginer de déclarer ce contrôleur dans le SDX et d’échanger des protocoles de contrôle avec lui, » indique Potti. «Le NetScaler sait en effet détecter une session VDI dans le datacenter mais il n’a aucune idée de la nature du réseau client depuis laquelle émane la session ». Si l’on pouvait construire un protocole capable de dire au contrôleur Wi-Fi qu’il s’agit d’une session VDI, alors on pourrait appliquer tout un tas de politiques intéressantes.

Identifier le trafic applicatif au niveau 2 et 3 : un besoin pas limité aux fournisseurs de services

Si l’aptitude à détecter les trafics applicatifs émerge au niveau 4-7, l’intelligence applicative au niveau 2-3 pourrait demander plus de temps et coûter bien plus cher. «Analyser le trafic applicatif n’est pas économique en termes de ressources. Il faut des capacités d’analyse profonde de trafic pour décoder un en-tête HTTP ou décoder une chaîne FTP. Cela veut dire que l’aptitude à reconnaître le trafic applicatif est typiquement réservée à des équipements qui ont bien plus de capacité processeur que les processeurs réseaux programmables. Dans la couche d’accès, l’usage des composants est compté. C'est un vrai problème du fait de l’intérêt que cela aurait de surveiller le trafic mobile », explique Adam Powers, le CTO de Lancope, qui vend le produit d’analyse réseau StealthWatch NetFlow.

Cisco Systems a également élargi le nombre de ses équipements supportant les protocoles NetFlow v9 et IPFIX, les protocoles qui permettent à des routeurs ou à des commutateurs de remonter des informations de niveau applicatif à la couche d’administration réseau. La version à 2 terabits du Catalyst 6500, le nouveau Catalyst 6800, les Catalyst 3750-X et le Catalyst 4500 sont tous capables d’exporter ces informations NetFlow, par exemple vers la console Cisco Prime ou vers une plate-forme tierce capable d'exploiter ces informations.

En fait, Cisco considère l’aptitude à traiter les informations applicatives comme si fondamental qu’il va porter les capacités d’analyse de paquets en profondeur (deep packet inspection) sur l’ensemble de son portefeuille de routeurs d’entreprise. «Nous pensons que l’aptitude à traiter les informations applicatives est devenue un attribut cœur des routeurs de bordure sur les sites distants et les sites centraux », indique Scott Harrell, le directeur senior des produits réseaux chez Cisco. La solution Cisco Application Visibility and Control (AVC) est désormais intégrée à l’ensemble de la gamme (ISR) et à son système d’application.

La gestion des informations AVC dans une infrastructure WLAN Cisco

«Dans l’ancien monde, le monde niveau 3-4, avoir une visibilité sur le port était suffisant. Je pouvais m’appuyer sur cette information pour en savoir beaucoup sur la nature de l’application transportée. Je pouvais décider comment appliquer des contrôles à cette application et comment optimiser son transport. Dans un monde Web, Il faut de plus en plus être à même de traiter des informations de niveau 7 et appuyer vos services réseau sur les informations provenant de cette couche. Nous étudions aussi la possibilité de détecter la nature des flux média et pas seulement les flux applicatifs de façon à gérer la priorité en fonction de la nature des flux média » explique Harrel. Cette capacité s’étend même aux équipements sans-fil de la marque, via le support d’AVC, de NetFlow et d’une technologie d’analyse de paquets baptisée NBAR2 (Network Based Application Recognition). Encore une fois, l’ensemble peut-être piloté depuis la console Cisco Prime.

«Si je suis dans une agence aujourd’hui avec un ISR connecté à un ASR (Agregation Service Router) et qu’une politique de QoS dit que le trafic HTTP doit être traité en best effort, le problème est qu’aujourd’hui mon trafic SAP Business Objects est aussi sur HTTP. Mes services de vidéoconférence aussi. (…) Tous ces trafics cohabitent sur le port 80. Je veux donc pouvoir différencier ces différents types de flux dans cette classe afin de les séparer en fonction de leur valeur métier. Aujourd’hui, cela est difficile à réaliser dans un univers web en perpétuel changement ».

Adapté d'un article en anglais de Shamus McGillicuddy, SearchNetworking.com