Arrivés aux limites matérielles de leur solution logicielle, de nombreux fournisseurs de sondes réseaux, se sont tournés vers le FPGA au cours de la dernière décennie. Cette approche devait alors permettre de contourner leur incapacité à suivre la complexification croissante des réseaux.

Le FPGA (pour Field Programmable Gate Array) est une technologie dont les performances et les qualités sont reconnues. Notre expérience a cependant démontré que dans un cadre d’analyse des paquets réseau à des fins de cybersécurité, cette technologie ne répond pas forcément aux exigences d’un cadre Zero Trust, à savoir une analyse intégrale d’absolument chaque paquet sur chaque couche, qui plus est quand la sécurité doit prendre en compte un déport progressif vers le Cloud.

Plus particulièrement, les limites du FPGA, dans le cadre de l’analyse des réseaux, méritent d’être mises dans le contexte de nouveaux défis comme la généralisation croissante de la virtualisation ou le tunneling, qui imposent aux solutions de maitriser les couches basses. A cette problématique, s’ajoute à la fois celle des empilements protocolaires complexes ainsi que celle de l’évolution constante des réseaux, car de nouveaux protocoles apparaissent régulièrement alors qu’il en existe déjà une multitude !

Nos arguments sur l’imperfection d’un emploi exclusif du FPGA pour adresser les besoins de monitoring et de protection des réseaux sont double, à la fois technique et commercial.

Arguments Techniques

Pour rappel, le FPGA est un circuit composé d’Arrays qui peuvent être reprogrammées après fabrication (ce qui n’est pas le cas du CPU). Il est donc possible de configurer ces Arrays et d’en définir, pour un usage donné, les interconnexions. Alors qu’un CPU exécutera plusieurs millions d’instructions en fonction de ce qui lui est demandé, un FPGA pourra arriver au même résultat en seulement quelques cycles.

Idéal dans le secteur de l’automobile, de la finance ou dans l’environnement du réseau (LUA chip), il devient cependant plus compliqué d'utiliser un FPGA lorsque les problèmes que l’on souhaite adresser sont à chercher dans une intrication complexe de traitements conditionnels de la donnée.

Notre expérience tend à montrer que le FPGA n'est plus au rendez-vous des performances attendues lorsqu'il est nécessaire de développer des processus de traitement construits sur des suites d’imbrications conditionnelles parallélisées (algorithmes à base d'arbre de décision complexe et récursif, par exemple).

Le FPGA est très performant lorsqu’il faut tester un ensemble de conditions simultanément. Ce qui en fait un excellent outil dans le traitement du signal réseau, par exemple (Couche 1 du modèle OSI) ou quand il est question de paralléliser les traitements.

En revanche, quand le nombre et la diversité des protocoles à classifier est trop complexe (protocoles multiplexés, enchainements protocolaires complexes, etc.), les solutions à base de FPGA auront alors tendance à ne pas classifier les protocoles qui ne s'annoncent pas. Ce qui a pour conséquence d’augmenter l'imprécision et de provoquer une perte de visibilité.

Parmi les raisons qui nous font penser que le FPGA a de nombreuses limitations techniques dans le domaine de la visibilité des réseaux, voici pour nous, ceux que nous avons jugé les plus marquant ou limitant :

• Le FPGA ne s’est pas montré performant sur la parallélisation séquentielle de boucle conditionnelle dynamique avec comme conséquence de se concentrer exclusivement sur la gestion de certaines couches basses. Celles qui annoncent correctement les protocoles qui les suivent (et plus les couches protocolaires s'empilent de manière dynamiques et imprécises, moins le FPGA devient pertinent). Au-delà de la couche 4, il devient alors rarement possible au FPGA de classifier correctement des protocoles réseau. De la même manière, les environnements à base d'empilement de protocoles virtualisés, quand ils sont traités, ne le sont que pour un nombre d’itérations données. Rendant le déploiement de telles solutions en cœur de réseau, de type data center, moins pertinent.
• Limité sur les couches hautes et sur les protocoles ne s'annonçant pas, il devient difficile de créer certains filtres complexes avec du FPGA. De nombreuses solutions se contentent de ne traiter que quelques protocoles de couches basses et uniquement sous certaines conditions (MPLS si c'est le protocole IP qui le suit, ou VxLAN, mais sur les ports uniquement).
• Les réseaux sont devenus très dynamiques, et il n’est pas rare de voir certaines aberrations en termes d’empilement de réseaux (virtuels ou physiques), surtout en environnements hybrides. Le FPGA étant quant à lui quasiment stateless, il lui est alors compliqué de classifier correctement des protocoles lorsque qu’il est nécessaire d’en détenir plusieurs paquets, surtout lorsque le débit est élevé et que la mémoire de la carte est limitée.
• Le FPGA aura les plus grandes difficultés à dépiler une succession d’empilement de protocoles de tunneling et de protocoles multiplexés.
• Les FPGA ne sont pas agiles. Les protocoles réseaux ne sont pas immutables. Ils changent constamment et il n’est parfois pas rare qu’ils évoluent ou que de nouveaux protocoles apparaissent. Le Time-To-Update avec du FPGA est plus élevé et il aura du mal à gérer les erreurs inconnues.
• Une solution “compilée” pour un FPGA ne fonctionnera pas en dehors de la même carte FPGA.
• A une époque où une part croissante des applications migrent vers le cloud, il est toujours impossible de virtualiser des FPGA, ce qui rend définitivement le FPGA incompatible avec l’un des avantages majeurs du cloud à savoir la scalabilité dans l’architecture de ses solutions.

Si le FGPA répond à des problématiques de visibilité bien délimitées, son approche n’est pas Zero Trust, puisqu’elle accepte de sacrifier l’observabilité au profit d’un traitement de volumes de données plus élevés.

Argument Commerciaux

Notre solution, le Zero Trust Trafic Analysis, répond aux problèmes techniques évoqués ci-dessus. Elle permet en outre de construire un argumentaire commercial solide autour des réalités techniques suivantes :

• Le FPGA est dit “Vendor Locked” et “Machine locked” (Il devient impossible de transférer sa solution d’analyse de protocoles sur une autre machine à distance si celle-ci n'a pas la même carte FPGA ni même des caractéristiques hardware équivalentes)
• Le FPGA interdit toute forme de scalabilité hormis par l’achat de matériel supplémentaire (vous souhaitez augmenter le débit ou rajouter des interfaces, il faut repasser à la caisse).
• La pénurie de semi-conducteur impacte plus encore les puces spécialisées comme le FPGA
• Une solution FPGA engendre un TCO (Total Cost Ownership) plus élevé : un serveur puissant, coûteux et plusieurs cartes FPGA sont indispensables pour les environnements à haute densité (Data Centers) où l’overhead est à bannir
• L'orchestration de solutions construites pour des architectures comme les CSP/Data Center est impossible.

A la lecture de ces arguments, nous espérons vous avoir convaincu ou tout du moins avoir ouvert le débat. Ces propos peuvent sembler incendiaires. Ils ne le sont pas. Le FPGA reste un outil formidable. Mais nous pensons sincèrement qu'il est devenu trop contraignant de l'utiliser pour de l'analyse de réseau.

Nous estimons que le FPGA se prête mal à l’analyse Zero Trust de protocoles car son utilisation est restrictive et sa capacité de déploiement limitée aux infrastructures propriétaire. Or le contexte des réseaux est amené à se complexifier continuellement (nouveaux usages) et les infrastructures à se mutualiser (shift vers le cloud). Dans ce contexte, la seule approche qui fait sens sera celle devant privilégier une très haute capacité d’adaptation et une plus grande intégration. L’approche choisie par NANO Corp.