Résolution des problèmes de routage asymétrique et de partage de charge dans les pare-feux

Réslutin des prblèmes de rutage asymétrique et de partage de charge dans les pare-feux Cédric Aun * Olivier Paul ** Ahmed Serhruchni ** * * Nrtel Netwrks/ENST Paris cedric.aun@nrtelnetwrks.cm ** Institut Natinal des Télécmmunicatins livier.paul@int-evry.fr *** ENST Paris ahmed@enst.fr RÉSUMÉ. Les pare-feux (plus cnnus sus leur nm anglais de firewall) snt devenus indispensables dans la défense du périmètre de sécurité des réseaux. Les règles dynamiques installées sur les pare-feux nécessitent dans la plupart des cas que les paquets (d'un flux) entrants et srtants traversent le même pare-feu, le cas échéant les paquets entrants dans le réseau snt ignrés et dnc nn acheminés à leur destinatin. Ce prblème est dû au rutage asymétrique des paquets (les paquets srtent du réseau en suivant une certaine rute nn identique à la rute de retur). Le partage de charge utilisant les métriques de rutage peut induire qu'une règle dynamiquement sit créée sur un pare-feu et que les paquets de dnnées assciés traversant un autre pare-feu (ils sernt dnc ignrés). Dans ce papier les auteurs décrivent les slutins actuelles, leurs limites et prpsent une nuvelle slutin pur la réslutin des prblèmes du rutage asymétrique et du partage de charge. Les mécanismes prpsés snt applicables à tut service nécessitant l installatin dynamique de règles sur un ruteur (QS entre autres). MOTS-CLÉS : pare-feux, firewall, stateful, rutage asymétrique, partage d'états. CFIP 2005

2 CFIP 2005 1. Intrductin Les pare-feux cnstituent un élément essentiel de la défense du périmètre de sécurité, leur caractéristique principale est qu'ils empêchent des flux indésirables de pénétrer au sein du périmètre de sécurité. Les règles, utilisées par les pare-feux pur empêcher des intrus de cmmuniquer avec des machines internes au réseau, peuvent être dynamiques u statiques. Une règle est dite dynamique lrsqu'un événement induit sa créatin en temps réel, cet événement peut être dû à l'arrivée d'un paquet de dnnée u d'un message d'un prtcle de signalisatin de pare-feux [STI 04]. Un pare-feu utilisant des règles dynamiques est dit «stateful» (mt anglais signifiant que le pare-feu garde en mémire l état de la règle). Dans la plupart des pare-feux la règle utilisée par défaut est d'ignrer les flux ne crrespndant pas aux règles pré-installées (qu'elles sient statiques u dynamiques). Lrsque plusieurs pare-feux snt déplyés au(x) périmètre(s) de sécurité d'un réseau, il est très prbable que la règle dynamique assciée au flux ne sit pas installée sur le pare-feu traversé par le flux. Par cnséquent le flux traversant un pare-feu, nn cnfiguré avec la règle assciée au flux, sera ignré; ceci purrait au pire mettre fin à la sessin applicative u au mieux la dégrader. Dans le cas de dépliement de plusieurs pare-feux au niveau d'un périmètre de sécurité, l'incnsistance entre le pare-feu cnfiguré avec la règle adéquate et sn flux asscié peut être due: a) Au partage de charge (u «ECMP» pur Equal Cst Multi-Path) à pids égale entre les firewalls (partage dû à la métrique des prtcles de rutage [THA 00]). b) Au rutage asymétrique, dû à une incnsistance des métriques des rutes srtantes et des rutes entrantes (liés aux accrds entre Furnisseurs d'accès Internet u autres cntraintes techniques u administratives) Dans certains cas, l'incnsistance entre le pare-feu sur lequel est installé la règle dynamique et le flux asscié à cette dernière peut être liée aux deux raisns mentinnées ci-dessus. Dans certain cas b) peut être dû à un mélange d'incnsistances de métriques de rutage et de partage de charge. Dans la suite de ce dcument, nus examinns plus en détails ces prblèmes. Nus étudins par la suite quelles slutins purraient leur être apprtées. Nus nus penchns en particulier en sectin 3 sur les prtcles de synchrnisatin de cntextes. Nus mntrns quelles snt leurs limitatins et cmment ils peuvent être étendus en sectin 4. Pur finir nus cncluns en analysant les frces et faiblesses de ntre prpsitin. 2. Descriptin du prblème Dans cette sectin, deux types de règles dynamiques de pare-feux sernt évquées, les règles créent par la réceptin de paquets de dnnées applicatives ainsi que les règles créent par des facteurs externes (prtcle de signalisatin indépendant de l'applicatin générant les paquets de dnnées [STI 04] u par

Les pare-feux et les prblèmes de rutage 3 analyse des messages de l'applicatin c'est à dire une Applicatin Layer Gateway (ALG). Indépendamment du facteur cntribuant à leur créatin, si les règles ne snt pas installées sur le pare-feu traversé par les paquets de dnnées de la cmmunicatin applicative, les paquets sernt ignrés. Dans ce dcument lrsque partage de charges est évqué il s agira tujurs d un partage à charges égales au niveau des prtcles de rutage (i.e. ECMP). Pur la suite de ce dcument il est imprtant que le lecteur ait une cnnaissance de base sur les implémentatins d ECMP. Ainsi : Les mécanismes utilisés par les ruteurs implémentant la fnctinnalité ECMP assurent le séquencement des paquets des flux rutés. La plupart des ruteurs ayant la fnctinnalité ECMP utilisent un algrithme se basant sur l adresse surce et l adresse destinatin du paquet, certains ruteurs utilisent en plus des adresses surce et destinatin les prts surce et destinatin ainsi que le type de prtcle de transprt. 2.1 Prblèmes des règles dynamiques créées par des flux de dnnées applicatives La Figure 1 mntre l impact du rutage asymétrique avec TCP, les pare-feux A1 et A2 autrisent uniquement des cnnectins TCP établies par des machines internes au réseau de l usager Phil. Ainsi sur chacun des pare-feux A1 et A2, un segment TCP ayant pur indicateurs (flags en anglais) SYN et ACK est rejeté s il ne crrespnd pas à un segment TCP avec flag SYN envyé par une machine du périmètre de sécurité. Dans la Figure 1, le segment TCP avec flag SYN passe par le pare-feu A1 mais au retur le TCP SYN ACK passe par le pare-feu A2 à cause du rutage asymétrique. Certains pare-feux peuvent aussi avir des règles dynamiques pur UDP. Ainsi un paquet UDP émit par une machine du périmètre de sécurité peut créer (en fnctin de la cnfiguratin du pare-feu) une règle dynamique et cette machine ne purra recevir de répnse sur la même scket UDP que par la machine destinataire du paquet initial ayant crée la règle dynamique. Dans ce cas, cmme n le cnstate en Figure 2, à cause du rutage asymétrique les paquets émis par le destinataire initial passernt par le pare-feu A2 sur lequel aucune règle n a été créée ayant pur cnséquence le rejet de ces paquets. Phil Pare-feux A2 TCP SYN ACK Bb TCP SYN Pare-feux A1 Périmètre de sécurité de Phil.cm TCP SYN Figure 1. Prblèmes du rutage asymétrique pur TCP et les pare-feux «Stateful»

4 CFIP 2005 Phil Pare-feux A2 UDP datagram Bb UDP dagram Pare-feux A1 Périmètre de sécurité de Phil.cm UDP datagram Figure 2. Prblèmes du rutage asymétrique pur UDP et les pare-feux "Stateful" 2.2 Descriptin du prblème pur les règles dynamiques créées par des facteurs externes Lrsque les règles dynamiques ne snt pas créées par les paquets de dnnées applicatives, leur créatin est due sit au prtcle de signalisatin asscié à la signalisatin lrsqu une ALG est implémentée (par exemple pur SIP [ROS 02]) u un prtcle de signalisatin de pare-feux ([SRI 02], [STI 04]). Une ALG est un ensemble de prcessus cnsistant à intercepter les messages de signalisatin d'une applicatin, à les interpréter pur en déduire cmment le pare-feu dit agir sur les flux de dnnées de l'applicatin (ignrer u acheminer les paquets de dnnées). L'un des prblèmes principaux des ALGs est de nécessiter une cnnaissance minimale des applicatins et de puvir lire les messages de signalisatin des applicatins. Ainsi lrsque les messages de signalisatin de l'applicatin snt chiffrés les ALGs snt inutilisables. D'autres raisns (maintenance, cût de mise à jur, interpérabilité, cût de dévelppement) viennent s'ajuter au prblème de cnfidentialité pur frcer l'industrie à adpter une autre slutin : la signalisatin des pare-feux. Parmi les prtcles NSIS [HAN 04], le NSIS NATFW NSLP [STI 04] (par la suite nmmé NSIS pur simplifier), dévelppé par l'ietf, fait partie des slutins de signalisatin de pare-feux. La principale caractéristique d NSIS est que les entités cmmuniquant avec le pare-feu n'nt pas besin de cnnaître le pare-feu à l'avance, de ce fait cette slutin ne nécessite pas la cnfiguratin d'infrmatins décrivant la tplgie du réseau. En effet NSIS utilise le cncept "path-directed", qui cnsiste à envyer le message de signalisatin vers le destinataire final (et nn le pare-feu), les pare-feux sur le chemin du message interceptent le message et créent une entrée dans une table pur acheminer le message de retur de prche en prche. Le rutage des messages NSIS est géré par une cuche prtclaire cmmune définie par [SCH 04]. NSIS utilisé de but en but, ne subit pas les prblèmes liés au rutage asymétrique mais peut être impacté par les prblèmes de partage de charge (uniquement lrsque l implémentatin d ECMP utilise les adresses surce et destinatin ainsi que les prts de transprt surce et destinatin). L une des caractéristiques des prtcles NSIS est de suivre le chemin des dnnées. Cependant dans le cas ù ECMP est activé (et que les prts de transprt surce et destinatin snt utilisés) sur les ruteurs séparant un hôte NSIS des pare-

Les pare-feux et les prblèmes de rutage 5 feux, les messages NSIS ne suivrnt pas le même chemin que celui des dnnées. La Figure 3 mntre l impact d ECMP sur les pératins d NSIS. Par suci de lisibilité les messages NSIS ne snt pas tus affichés. Phil Pare-feux A2 NSI S Bb NSI NSIS S Pare-feux A1 Périmètre de sécurité de Phil.cm NSIS - Initié par Phil Flux de dnnées Figure 3. Prblème de NSIS de but en but avec ECMP Dans certains scénaris de dépliement, NSIS est utilisé en mde prxy; ceci est ntamment le cas lrsqu une des machines hôtes n a pas d implémentatin NSIS u dans le cas ù la signalisatin NSIS est terminée lcalement au sein d un périmètre de sécurité. Lrsque NSIS est utilisé en mde prxy, les messages NSIS risquent d être impactés par les prblèmes de rutage asymétrique et de rutage ECMP. Phil Initié par A1 Pare-feux A2 NSI S Bb b NSIS - Initié par Phil Périmètre de sécurité de Phil.cm NSI S Pare-feux A1 Flux de dnnées Figure 4. Impact du rutage asymétrique sur NSIS utilisé en mde prxy Le rutage ECMP impacte les messages NSIS en mde prxy puisque le parefeu (et nn la machine cmmuniquant avec Phil) est la surce des messages NSIS destinés à l hôte Phil dans la Figure 5. Phil Initié par A1 NSI S Pare-feux A2 NSI S NSIS - Initié par Phil NSI S NSI S Pare-feux A1 Périmètre de sécurité de Phil.cm Figure 5. Impact d'ecmp sur NSIS utilisé en mde prxy Flux de dnnées Les prblèmes évqués dans cette sectin peuvent être réslu par tris types de slutins :

6 CFIP 2005 a) Ancrage du flux par utilisatin d ptin IP de type 'surce rute'. b) Ancrage du flux par mdificatin de l adresse de destinatin. Dans ce cas un traducteur d adresse est utilisé ([SRI 99]). c) Synchrnisatin d états entre les pare-feux du périmètre de sécurité. a) et b) ne snt pas des slutins transparentes pur le client applicatif, dans le cas de b) la slutin est transparente uniquement lrsque ECMP n est pas utilisé. De plus la slutin a) nécessite l utilisatin d une ptin du paquet IP, cette utilisatin est très suvent critiquée par les administrateurs réseaux se suciant de déviler certaines parties de la tplgie de leur réseau. L utilisatin d un traducteur d adresse impacte énrmément d applicatins [HOL 01], en particulier celles transprtant des adresses et prts dans leurs paquets ; de plus cette utilisatin ne peut pas être justifiée dans le cadre de réseau ayant suffisamment d adresses publiques. La slutin c) apprte plus de transparence vis-à-vis des applicatins et ne dévile pas d infrmatin sur la tplgie du réseau. La suite du dcument décrit les techniques de synchrnisatin d états recmmandées pur résudre les prblèmes décrits dans cette sectin. 3. Techniques de synchrnisatin d'états Ces dernières années nt vu un travail imprtant sur la définitin de prtcles de gestin de panne. Des prtcles cmme HSRP (Ht Standby Ruter Prtcl) [LI 98], VRRP (Virtual Ruter Redundancy Prtcl) [HIN 04] u CARP (Cmmn Address Redundancy Prtcl) [BSD 03] permettent la détectin de pannes ainsi que l'électin d'un ruteur asscié à une adresse IP servant de ruteur/pare-feu par défaut. Ces prtcles permettent lrs de la panne du pare-feu "maître" de re-diriger les nuvelles cmmunicatins vers un pare-feu "secndaire". Cependant ces prtcles ne permettent pas tujurs de faire en srte que les cmmunicatins existantes puissent être acheminées par le pare-feu "secndaire". Dans le cas d'une re-directin du trafic, l'absence de ces infrmatins cntextuelles empêche le nuveau pare-feu de traiter les paquets des cmmunicatins existantes de manière satisfaisante cmme nus l avns mntré en sectin précédente. Une technique permettant de limiter ce prblème cnsiste à répliquer les états d'un pare-feu à l'autre de telle srte que les cntextes sient présents dans le cas d'une re-directin du trafic. Il n'existe pas à ce jur de prtcle standardisé pur l'échange d'infrmatins d'états. Cependant de nmbreux pare-feux implantent un prtcle de synchrnisatin d'état. 3.1. Un aperçu d'un prtcle de synchrnisatin: pfsync pfsync est le prtcle de synchrnisatin d'états asscié à OpenBSD. OpenBSD pssède depuis quelques années un mdule de filtrage prpre appelé pf [PF] (packet filter). Celui-ci gère les états de cnnexin en cnservant des infrmatins relatives à chaque cmmunicatin (adresses, prts, prtcle, numérs de séquence TCP attendus, timers,...) ainsi que sur la plitique de filtrage à appliquer à la cnnexin. La gestin des mises à jur dans pfsync se fait à chaque mdificatin sur la table

Les pare-feux et les prblèmes de rutage 7 d'états c'est à dire généralement à la réceptin de chaque paquet. Le prtcle utilisé par pfsync est situé dans la pile prtclaire immédiatement au dessus d'ip. Le numér de prtcle asscié est 240. Le prtcle définit plusieurs pératins de type requête-répnse u ntificatin permettant à un pare-feu de créer un nuvel état dans un pare-feu secndaire, de mettre à jur un état dans un pare-feu secndaire, de supprimer un état dans un pare-feu secndaire, de demander le transfert de tus les états de manière simultanée u d un état en particulier, de transférer tus les états de manière simultanée, de demander l'état du pare-feu ppsé. pfsync utilise plusieurs techniques afin de limiter la quantité de dnnées échangées d'un pare-feu à l'autre. Utilisatin d'un prtcle basé sur le multicast. L'ensemble des pare-feux participant au prtcle est asscié à une adresse multicast particulière (224.0.0.240). Cette idée permet de limiter le nmbre de paquets transprtés entre les pare-feux à un nmbre prprtinnel au nmbre de paquets reçus par le pare-feu. Dans le cas de l'utilisatin de flux unicast, ce nmbre serait multiplié par le nmbre de pare-feux du grupe. Utilisatin de techniques d'agrégatin d'états. L'agrégatin d'état a deux bjectifs. D'une part il s'agit de limiter le nmbre de paquets émis en faisant en srte que les paquets sient le plus remplis vis à vis de la valeur de la MTU entre les équipements. Ceci est réalisé en gardant en mémire une liste des mises à jur à envyer jusqu'à ce que la taille ttale crrespnde à la taille de la MTU. D'autre part cmme plusieurs mises à jur cncernant une même cnnexin peuvent être sumises à l'entité pfsync, il est pssible de supprimer u de mdifier l'infrmatin des mises à jur les plus anciennes afin de ne pas stcker les nuvelles. Cette slutin a cependant un incnvénient: les mises à jur peuvent être gardées indéfiniment sit car aucune mise à jur n'est reçue par pfsync sit car ces mises à jur cncernent tujurs la même cnnexin. Afin de régler ces prblèmes pfsync maintient deux paramètres limitant la durée de rétentin d'un paquet de mise à jur. Un cmpteur est asscié à chaque mise à jur cntenue dans un paquet, lrsque celui-ci atteint une valeur limite (128), le paquet est envyé indépendamment de sa taille. D'autre part un timer est maintenu pur chaque paquet, de telle srte qu'un paquet ne sit pas gardé plus d'une certaine durée (1 secnde). Utilisatin d'infrmatins d'état simplifiées. Certaines infrmatins snt redndantes entre les mises à jur puvant apparaître dans des paquets de mise à jur successifs. Le prtcle utilise cette particularité pur définir deux types d états : les mise à jur nrmales cntenant tutes les infrmatins relatives à un état et les mise à jur cmpressées cntenant uniquement les infrmatins généralement mdifiées. Afin de créer le lien entre mise à jur cmpressées et états n utilise un identifiant unique. En terme d'implantatin, l'implantatin de pfsync pssède plusieurs particularités intéressantes. Cntrairement à d'autres implantatins de prtcles du même type, pfsync est implanté dans l'espace nyau. Cette particularité permet d'éviter la duble

8 CFIP 2005 cpie des infrmatins de cntexte entre l'espace nyau et l'espace utilisateur. La sélectin des cmmunicatins à dupliquer se fait au travers de la plitique de filtrage du mdule pf. A chaque règle, il est pssible d asscier une directive cmmandant la synchrnisatin de tutes les cmmunicatins dérivées. 3.2. Prblèmes dans le cas d'un rutage asymétrique Nus cnsidérns dans la suite de ce dcument deux pare-feux M et N pur lesquels les cmmunicatins subissent un rutage asymétrique et utilisent un prtcle de synchrnisatin tel que pfsync. Dans le cas d'un rutage asymétrique, des paquets peuvent arriver sur l'interface d'un pare-feu n'ayant pas traité les paquets précédents d'une cmmunicatin. Ce cas peut se présenter lrsque le paquet reçu par N est une répnse au paquet traité par M. Si le temps d'aller retur entre M, la destinatin et N u entre N, la surce et M est plus faible que le temps d'installatin d'état entre M et N, aucun état ne permettra de valider ce paquet. Un exemple est le cas de l'uverture de cnnexin TCP. Si le paquet SYN est reçu par M et le paquet SYN-ACK est reçu par N, un état dit être présent en N afin de valider ce secnd paquet. Une apprche naïve afin de régler ce premier prblème purrait cnsister à utiliser une technique de partage de charge telle que nus l'avns présentée dans la sectin précédente et à lier le rythme d'émissin des mises à jur à celui d'arrivée des paquets au lieu de le cnditinner à une ptimisatin du remplissage des paquets de mise à jur. Cependant, cette apprche implique que le débit nécessaire pur les mises à jur sera prprtinnel au nmbre de paquets sumis au grupe de parefeux. Un paquet cntenant une mise à jur sus pfsync a une taille d'envirn 160 ctets. En suppsant un trafic typique rencntré sur Internet (taille de paquet de 300 ctets) et un vlume de trafic de 10Gb/s réparti entre des pare-feux en parallèle, les pératins de synchrnisatin généreraient envirn un vlume 5Gb/s de trafic. Ceci n'est généralement pas acceptable. Un deuxième prblème lié au mde de cmpressin des paquets peut se prduire lrs du filtrage de paquets TCP. Un critère de filtrage des paquets TCP utilisé par tutes les implantatins pen surce prte sur leurs numérs de séquence et d'acquittement [ROO01]. Pur chaque cnnexin n définit un intervalle de validité pur ces deux variables. Les brnes de ces intervalles (m s,m s et m a, M a respectivement les numérs de séquence et numérs d'acquittements) pur les segments TCP allant de la surce vers la destinatin dépendent des numérs acquittés par les segments allant de la destinatin vers la surce de la manière suivante: M s <max(a d +w s ), m s >max(a d ) M a <max(n s ), m a >max(n s ) - MAXWIN Où a d est le numér d'acquittement des paquets de la destinatin vers la surce, w s la taille de la fenêtre chez la destinatin, n s le numér de séquence du dernier ctet des paquets reçus par la surce et MAXWIN dépend de la taille maximale pssible pur la fenêtre et de la taille maximale des segments (MSS). Réciprquement une frmule analgue est utilisée pur valider les segments TCP allant de la destinatin vers la surce. Dans le cas d'une mise à jur trp lente (par exemple lrsque le timer est utilisé pur prvquer la mise à jur), les brnes des intervalles restent fixes. En parallèle, le numér de séquence maximal, des

Les pare-feux et les prblèmes de rutage 9 segments envyés, peut avancer en fnctin du débit. Dans le cas ù celui-ci est supérieur à w s durant la durée du timer, les paquets sernt rejetés. Dans le cas de pfsync la durée maximale peut atteindre une secnde sit un débit de 500kbits/s envirn pur une taille de fenêtre de 65535 ctets. 4. Améliratin de la technique de synchrnisatin Afin d'essayer d'amélirer la technique de synchrnisatin existante, regardns d'abrd dans quel cas les deux prblèmes précédents peuvent se présenter. Vis-à-vis du premier prblème, n peut estimer que le temps d aller-retur est supérieur au temps de cmmunicatin entre les pare-feux (le temps d'installatin d'un état sur des équipements mdérément chargés au travers d'un réseau lcal nn cngestinné est de l'rdre de 1ms). De ce fait il est tujurs pssible de mettre à jur les infrmatins de cntexte avant la réceptin d un paquet de retur à cnditin que la mise à jur sit envyée sans attente. Cette apprche pse le prblème du vlume de trafic de synchrnisatin cmme indiqué en sectin précédente. Une cntrainte sur la méthde de synchrnisatin est dnc d'essayer de minimiser le vlume de trafic asscié aux mises à jur sans utiliser de méthde d'agrégatin telle que celle utilisée par pfsync. 4.1. Mde de validatin des paquets dans les pare-feu à états. Il nus faut entrer dans le détail des méthdes de validatin des cmmunicatins afin de vir quelles slutins nus purrins apprter. Le mde de validatin des cmmunicatins dépend du prtcle utilisé. Les infrmatins assciées aux cntextes pur réaliser cette validatin snt indiquées dans le Tableau 1. Tableau 1. Infrmatins utilisées pur le filtrage des paquets. Prtcle TCP UDP ICMP (ind.) ICMP (req.-rep.) Infrmatins Etat curant (autmate), brne inférieure/supérieure numér de séquence émetteur/récepteur, taille de fenêtre émetteur/récepteur, multiplicateur taille de fenêtre émetteur/récepteur, date d expiratin (valeur du timer d expiratin), directin, actin à appliquer. Date d expiratin (valeur du timer d expiratin), directin, actin à appliquer. Date d expiratin (valeur du timer d expiratin), directin, actin à appliquer. Etat curant (autmate), Date d expiratin (valeur du timer d expiratin), directin, actin à appliquer. Les infrmatins d'état, de brnes de fenêtres et de date d'expiratin snt mises à jur à chaque réceptin de paquet. Ces infrmatins snt utilisées de la manière suivante: En fnctin du cntenu du paquet et de l'état curant, l'autmate change d'état. Les paquets prtant des infrmatins nn chérentes vis à vis de l'état curant snt rejetés.

10 CFIP 2005 Dans TCP, la spécificatin de l'autmate TCP pssède 11 états mais les autmates de validatin en pssèdent généralement mins. Dans le cas de pf 5 états snt utilisés (SYN_SENT, ESTABLISHED, CLOSING, FIN_WAIT2, TIME_WAIT). Un autmate est maintenu par directin. Le passage de SYN à SYN_SENT se fait du côté surce après la réceptin du paquet SYN et du côté destinatin à la réceptin du SYN/ACK. Le passage de SYN_SENT à ESTABLISHED se fait dès la réceptin du SYN/ACK du côté destinatin et à la réceptin du ACK du côté surce. Pur la fermeture de cnnexin, le passage de ESTABLISHED à CLOSING se fait à la réceptin d'un FIN du côté surce u destinatin. Le passage de CLOSING à FIN_WAIT_2 se fait alrs à la réceptin d'un ACK. Enfin l'état TIME_WAIT est atteint à la réceptin d'un RST à partir de n'imprte quel état. Dans ICMP, les échanges de type requête-répnse utilisent généralement un état par type de message. Le passage de l'état fermé à l'état uvert se fait lrs de réceptin d'une requête. L'pératin inverse se fait à la réceptin de la répnse. Les répnses arrivant dans l'état fermé snt rejetées. A l'expiratin d'un timer, le cntexte asscié à la cmmunicatin est détruit. Les paquets arrivant après expiratin snt sumis à la plitique de filtrage pur décider de la créatin d'un nuveau cntexte. Pur TCP, une valeur différente de timer est assciée à chaque état. Ainsi dans pf la durée du timer asscié à l'état ESTABLISHED est de 24 heures alrs que celui asscié à l'état SYN_RECEIVED est de 30 secndes. Pur UDP, un timer est généralement utilisé indépendamment de l'état de la cmmunicatin. Dans pf la durée du timer asscié aux cmmunicatins UDP est de 60 secndes. Pur ICMP, la durée du timer dépend du type de message. Dans pf les messages de type requête-répnse pssèdent une durée de timer de 20 secndes cntre 10 secndes pur les messages de type indicatin. Pur TCP, les numérs de séquence, d'acquittement et tailles de fenêtre snt utilisés pur cnstruire des intervalles de validité des numérs de séquence et d'acquittement. les segments arrivant avec des numérs hrs des intervalles d acceptatins snt rejetés. 4.2. Diminutin du nmbre de mise à jur Nus cnsidérns par la suite deux pare-feu M et N pur lesquels les cmmunicatins snt asymétriques. Le classement précédent nus mntre que tus les prtcles n'nt pas des besins similaires en terme fréquence de la mise à jur. Ainsi si n cnsidère UDP,

Les pare-feux et les prblèmes de rutage 11 une fis l'état installé, une mise à jur ne s'impse que tutes les 60 secndes dans le pire des cas. Ceci nus mntre que, vis à vis de la première apprche naïve, nus puvns diminuer le vlume de mise à jur en adaptant la fréquence de mise à jur aux événements. D'une manière générale n peut distinguer parmi les événements décrits précédemment, ceux liés à la réceptin d'un paquet (autmate, intervalles des numérs de séquence et d'acquittement) et ceux liés au temps (timers). Parmi ces événements n peut également distinguer ceux ayant une influence sur l'acceptatin d'un paquet et ceux n'en ayant pas. Les événements de type autmate ne nécessitent un envi immédiat qu'en cas de changement d'état (Tableau 2). Ceci est vrai car l'absence de changements d'état n'a pas d'influence sur l'acceptatin d'un paquet. Les événements de type changement d'intervalles ne nécessitent une mise à jur que si le segment suivant le segment reçu ne valide pas les intervalles du pare-feu hmlgue. C'est tujurs le cas pur les segments TCP SYN et SYN-ACK (Tableau 3) puisque ces segments permettent de définir les rigines des intervalles. Tableau 2. Evènements liés aux autmates et nécessitant une actin. Evénement Réceptin TCP SYN/SYN-ACK Réceptin TCP FIN/FIN-ACK, RST Réceptin UDP, Etat nn existant Réceptin ICMP requête Réceptin ICMP répnse Actin Envi mise à jur; Pur les autres segments, cette cnditin peut être déterminée plus facilement par le pare-feu hmlgue. Si n se place sur le pare-feu N, pur un paquet prtant S, A, W (S numér de séquence du dernier ctet du segment, A numér de séquence acquitté, W fenêtre) et en utilisant la cnnaissance des intervalles de validité lcaux ([n s,n s ] [n a,n a ]), il est pssible de déterminer les distances S-N a et A-N s. Lrsque ces distances snt inférieures à une brne prédéfinie D, une mise à jur est nécessaire. N peut alrs demander cette mise à jur à M. Tableau 3. Evènements liés aux intervalles et nécessitant une actin. Evénement Réceptin TCP SYN/SYN-ACK Réceptin TCP ACK S, A [ns,ns] [na,na] Actin Envi mise à jur; Si (S-Ns)<MSS u (A-Na)<D Demande de mise à jur; Sinn / Les événements liés aux timers snt de deux types. Les événements cnduisant à définir une durée de vie initiale pur une cmmunicatin et ceux visant à la mdifier. Les premiers divent être envyés immédiatement car l'absence de durée de vie cnduit au rejet des paquets liés à la cmmunicatin. Parmi les secnds, n peut distinguer les événements cnduisant à une augmentatin de la durée de vie (passage de l'état SYN-SENT à ESTABLISHED pur TCP) de la cmmunicatin et ceux la réduisant (passage de ESTABLISHED à CLOSING) cmme indiqué en Figure 6.

12 CFIP 2005 T T T+Tc-e T+T-e Augmentatin T+T e T+Tc T+T-e T+Tc-e Diminutin T+T e T+T T+T T+Tc M N Figure 6. Mise à jur des timers entre deux pare-feux M et N en fnctin de l'pératin réalisée et des valeurs des timers. M N Si au temps T n cnsidère la nuvelle durée T et la durée restante Tc pur une cmmunicatin alrs les premiers événements divent être signalés avant T+Tc afin d'éviter l'expiratin du timer en N. Dans le secnd cas, la mise à jur dit être signalée avant min(t+t,t+tc) afin de ne pas accrder plus de temps à la cmmunicatin que la nuvelle valeur du timer (Tableau 4). Il faut par ailleurs cnsidérer le temps de synchrnisatin (e) de telle srte que la mise à jur n'arrive pas après l'expiratin du timer sur le pare-feu hmlgue. Tableau 4. Evènements liés aux timers et nécessitant une actin. Evénement Actin Réceptin TCP SYN (Tc, T, T) Envi mise à jur; Réceptin UDP (Tc, T, T) Etat nn existant Réceptin ICMP requête (Tc, T, T) Réceptin TCP SYN-ACK (Tc, T, T) Envi mise à jur T+T-e; Réceptin TCP ACK (Tc, T, T) Réceptin UDP (Tc, T, T) Etat existant Réceptin TCP FIN/FIN-ACK, RST (Tc, T, T) Envi mise à jur à min(t+t,t+tc)-e; L'exemple des timers nus mntre que d'une manière générale, la décisin de mise à jur devrait être séparée du cntenu des dnnées envyées. Ainsi il est pssible après avir prgrammé une mise à jur à la date T que de nuveaux paquets de la même cmmunicatin amènent à repusser la date d'expiratin du timer. Cependant ces paquets ne divent pas mdifier la date d'envi de la mise à jur qui dépend de la date d'expiratin du timer dans le pare-feu hmlgue et nn de la valeur d'expiratin lcale. L'actin à réaliser à chaque évènement peut être déterminée en utilisant l'actin la plus cntraignante définie pur chaque type de cntrainte (autmate, intervalles, timer). 4.3. Améliratin du rythme d'émissin Afin de limiter le nmbre de paquets générés par les mises à jur nus prpsns d adapter le rythme d émissin au type d évènement. En effet, tus les événements ne nécessitent pas une même réactivité de mise à jur. Ainsi l'expiratin des timers

Les pare-feux et les prblèmes de rutage 13 peut être prévue et il imprte peu par exemple dans le cas d'udp que la mise à jur parte dans la millisecnde. Ceci mntre que l'agrégatin temprelle que l'n peut réaliser sur les états devrait également dépendre du type d'événement à signaler. Cntrairement aux événements imprévisibles (uverture d'une cnnexin) les événements prévisibles (expiratin de timer, dépassement d'intervalles) peuvent être anticipés et agrégés. Nus prpsns dnc de lier le rythme d'émissin des mises à jur au type d'événement prtclaire à signaler. Nus prpsns tris files d'émissins. Les émissins "express" pur lesquelles le temps de cnservatin du paquet avant émissin est inférieur à 1ms. Cette file est liée aux pératins de mise à jur de l'autmate. La cntrainte de temps liée à cette file pur deux parefeux hmlgues M et N est la valeur minimale entre le temps d'aller retur entre M, la destinatin et N et le temps d'aller retur entre N, la surce et M. Les émissins "myennes" pur lesquelles le temps de cnservatin du paquet avant émissin est de l'rdre de 10ms. Cette file est liée aux pératins de mise à jur de valeurs d'intervalles d'acceptatin de segments. Il est à nter que le temps de mise à jur entre deux pare-feux hmlgues N et M dit être inférieur à la durée de réceptin par N de D a = S-N a ctets u de D s = A-N s acquittements. Pur un temps d'attente de 10ms, n peut représenter les valeurs pssibles de D en fnctin du débit unidirectinnel B de la cnnexin et du temps du temps de synchrnisatin e seln la frmule suivante. B(D,e) = (8.D)/2.(e+10.10-3 ) En chisissant une valeur de D égale à la mitié de la valeur maximale de la fenêtre (32768), et une valeur de temps de synchrnisatin égale à e=1ms n btient une valeur de B de l'rdre de 13Mb/s. Les émissins "lentes" pur lesquelles le temps de cnservatin du paquet avant émissin est de l'rdre de 100ms. Cette file est liée aux pératins de mise à jur des timers. La cntrainte de temps pur cette file est liée à la durée e et au timer de durée minimale. 4.4. Evaluatin du prtcle avant agrégatin Afin d'évaluer cette évlutin du prtcle pfsync pur la prise en cmpte du rutage asymétrique, nus prpsns d'évaluer le vlume de trafic généré par le prtcle de synchrnisatin. Nus évaluns tut d'abrd le nmbre d'événements tels que définis en sectin 4.2. Afin de définir le trafic asscié à chaque prtcle, nus utilisns un ensemble de traces NLANR capturées en 2003 et cmprenant envirn 100 millins de paquets ainsi que l'analyse des trafics Internet réalisée par Sprint dans le cadre du prjet IPMON [SPR 04] en 2004. Nus utilisns une distributin des paquets par prtcles de 86% pur TCP, 10% pur UDP, 1% pur ICMP et 3% pur les autres prtcles. Au myen des traces, nus puvns définir la prprtin de paquets liés aux événements précédemment définis (Tableau 5).

14 CFIP 2005 Tableau 5. Calcul du nmbre d évènements en fnctin de sn type. Evénement % paq. par % paq. Evènements dans prt. ttal un réseau 10Gb/s Réceptin TCP SYN 5 4.3 172.10 3 Réceptin TCP SYN-ACK 2 1.7 68.10 3 Réceptin TCP FIN/FIN-ACK, RST 3 2.5 100.10 3 Réceptin UDP, Etat nn existant 5 0.5 20.10 3 Réceptin ICMP requête 35 0.3 14.10 3 Réceptin ICMP répnse 27 0.2 10.10 3 Vis-à-vis des évènements dépendant des mdificatins d intervalles, le nmbre d événements dépend d une part de la valeur du timer asscié aux cnnexins TCP. Cependant ce timer est tellement imprtant dans la pratique (24 heures), que ce premier paramètre peut être cnsidéré cmme négligeable. L autre paramètre est le nmbre d ctets transprtés W-D u W est la taille de la fenêtre. Le nmbre myen d ctets transprtés par les cnnexins TCP dans les traces examinées est de l rdre de 11000 ctets avec une taille myenne des fenêtres utilisées W=25500. Nus examinns dnc la prprtin de cmmunicatins transprtant plus de dnnées que W-D. Pur les valeurs (D = W/2) ces cmmunicatins cnstituent 2% des cnnexins TCP et 6% des segments. Elles transprtent en myenne 206k ctets dans le sens serveur-client et 19k ctets dans le sens client-serveur. En utilisant ces paramètres et en suppsant une taille de MSS de 1000 ctets nus puvns déterminer le nmbre myen de demandes de mise à jur par secnde. Ce résultat est dnné dans le Tableau 6. Tableau 6. Calcul du nmbre d évènements liés aux mdificatins d intervalles. Evénement % paq. % paq. % paq. % paq. Evènements par Ttal cnnexins générant dans un prt. lngue demandes réseau 10Gb/s Réceptin 90 77 4.6 0.4 15.10 3 TCP ACK Cncernant les mises à jur liées aux timers, le nmbre de mises à jur dépend du nmbre d états créés pur les cmmunicatins dnt les évènements utilisent des timers. Les traces en ntre pssessin ne nus ayant pas permis de définir une valeur réaliste pur la durée de vie myenne des cmmunicatins UDP. Nus utilisns les indicateurs calculés par Chang et al. [CHA 04] dnnant une durée de vie myenne de m=9 secndes. En utilisant la li de Little, nus puvns définir à partir de cette durée myenne et du nmbre de nuvelles cmmunicatins UDP par secnde, le nmbre myen d états. Celui-ci est de l rdre de 180000. Celui-ci nus permet par la suite de déterminer le nmbre de mises à jur par secnde en prenant une durée de mise à jur T=60s, e=1s (Tableau 7).

Les pare-feux et les prblèmes de rutage 15 Tableau 7. Calcul du nmbre d évènements liés aux timers. Evénement Réceptin UDP, Etat existant Durée vie Nuvelles Nmbre Evènements dans myenne cm. par sec. myens états un réseau 10Gb/s 9s 20. 10 3 180. 10 3 3. 10 3 4.5. Evaluatin du système d'agrégatin A partir du nmbre d évènements calculés dans la sectin précédente, nus puvns évaluer le nmbre de mises à jur par files. Les événements assciés à une file snt stckés dans un paquet jusqu à ce que, sit le paquet sit plein, sit la durée de stckage lcale maximale du paquet sit atteinte. Si n suppse une utilisatin maximale du réseau, la secnde cntrainte n est jamais atteinte. En suppsant une MTU de 1500 ctets et une taille de cntexte similaire à celle utilisée dans pf, n peut alrs déterminer le nmbre de mise à jur par secnde et le débit glbal nécessaire. Cmme indiqué dans le Tableau 8, le vlume glbal de trafic est de l rdre de 550Mb/s pur un réseau de 10Gb/s. Cmparé à une méthde naïve, ntre apprche permet dnc une divisin par 10 du débit nécessaire en limitant le cût de la synchrnisatin à 5% du débit glbal. Tableau 8. Nmbre d évènements et débit asscié à chaque file. File Evènements Evènements Paquets IP Paquets IP Débit par sec. par durée de par durée par sec. stckage de stckage Express 384. 10 3 384 43 43000 516Mb/s Myenne 30. 10 3 300 33 3300 39Mb/s Lente 3. 10 3 300 33 330 4Mb/s 5. Cnclusin Dans ce dcument nus avns explré les prblèmes que puvaient pser aux pare-feux le rutage asymétrique lrsque le service de filtrage est rendu de manière cntextuelle et lrsque celui-ci est cmpsé de plusieurs équipements. Nus avns analysé les slutins pssibles avec une attentin particulière pur les techniques de synchrnisatin d états. Nus avns mntré que les prtcles actuels ne permettent pas de résudre le prblème psé par le rutage asymétrique de manière adéquate. Nus avns dnc mntré cmment ces prtcles puvaient être amélirés afin de limiter d une part la latence de mise à jur et d autre part le débit généré par le prtcle de synchrnisatin. Dans ce dmaine, la prise en cmpte des types d évènements dans la définitin de l agenda des envis ainsi que dans leur traitement dans le prtcle de transprt permet d btenir un système de synchrnisatin plus efficace.

16 CFIP 2005 6. Remerciements Nus remercins Elwyn Davies pur ses cmmentaires. 7. Bibligraphie [STI 04] Stiemerling M., Tschfenig H., Martin M., Aun C., NAT/Firewall NSIS Signaling Layer Prtcl (NSLP), IETF draft, draft-ietf-nsis-nslp-natfw-04, ctbre 2004 [THA 00] Thaler D., Hpps C., Multipath Issues in Unicast and Multicast Next-Hp Selectin, IETF Infrmatinal dcument, RFC 2991, nvembre 2000 [ROS 02] Rsenberg J., Schulzrinne H., Camarill, G., Jhnstn A., Petersn J., Sparks R., Handley M,, Schler E., SIP: Sessin Initiatin Prtcl, IETF Standards Track, RFC 3261, juin 2004 [SRI 02] Srisuresh P., Kuthan J., Rsenberg J., Mlitr A., Rayhan A., IETF Infrmatinal dcument, RFC 3303, Aût 2002 [HAN 04] Hancck R., Karagiannis G., Lughney J., van den Bsch S., IETF draft, Next Steps in Signaling: Framewrk, draft-ietf-nsis-fw-06, juillet 2004 [SCH 04] Schulzrinne H,. Hancck R,, Internet Draft, GIMPS: General Internet Messaging Prtcl fr Signaling, draft-ietf-nsis-ntlp-04, ctbre 2004 [SRI 99] Srisuresh P., Hldrege M., IP Netwrk Address Translatr (NAT) Terminlgy and Cnsideratins, IETF Infrmatinal dcument, RFC 2663, aût 1999 [HOL 01] M. Hldrege, P. Srisuresh, Prtcl Cmplicatins with the IP Netwrk Address Translatr, IETF Infrmatinal dcument, RFC 3027, janvier 2001 [PF] PF. The OpenBSD Packet Filter, http://www.penbsd.rg/faq/pf/ [LI 98] Li. T, Cle B., Mrtn P., Li D., Cisc Ht Standby Ruter Prtcl (HSRP), IETF Infrmatinal dcument, RFC 2281, mars 1998 [BSD 03] carp - Cmmn Address Redundancy Prtcl, Open BSD man pages, http://www.penbsd.rg/cgi-bin/man.cgi?query=carp, ctbre 2003 [HIN 04] Hinden R., Virtual Ruter Redundancy Prtcl (VRRP), IETF Standards Track, RFC 3768, avril 2004 [ROO 01] Guid van Rij, Real Stateful Packet Filtering with IP Filter, Usenix Security 2001. [SPR 04] Sprint Labs, IP Mnitring Prject, dispnible à http://ipmn.sprint.cm. [CHA 04] Apprximate Packet Classificatin Caching, Francis Chang, Kang Li, Wu-chang Feng. IEEE INFOCOM 2004.