Quelques commentaires :
1. Une porte dérobée pour faire un déni de service (arrêt du service) peut-être masquée comme un bug involontaire, bien que ce soit un improbable - les vendeurs le savent, ça serait prendre un trop gros risque que de laisser ce genre de chose à la merci d’une découverte fortuite. Sous forme d’une séquence de paquets bien définis et très peu probable d’être découverte à moins de pouvoir accéder au code des ASIC (qui eux-même pourraient notifier le contrôler d’une situation irrécupérable nécessitant un arrêt système), c’est plus probable.
2. Il est peu probable que le mécanisme d’analyse prenne la forme d’un équipement physique supplémentaire - ça se ferait en logiciel - avec l’arrivée des équipements réellement programmables (Arista, OpenFlow/SDN et co.), on peut faire ce qu’on veut.
3. Ne pas oublier qu’on ne peut (sauf exception) copier le traffic venant d’un port sur une carte dédiée, vers un autre port qui ne soit pas sur la même carte - ça limite les possibilités
4. Enfin, tout trafic sortant représentant une copie voir même un condensé des autre flux ne va pas passer inaperçu - il faut bien stocker les choses quelque part. Une solution plus subtile serait d’envoyer des requêtes à l’équipement du type : « est-ce que telle IP communique avec telle IP/bloc sur tel(s) port(s) ? » Envoyer un source quench avec tel payload si oui à telle adresse, avec tel payload sinon - et ceci chaque heure où cet échange est observé. Le code pour implémenter un tel mouchard ne serait pas très gros...