RFC 7011 : Specification of the IP Flow Information export (IPFIX) Protocol for the Exchange of Flow Information

Transcription

1 RFC 7011 : Specification of the IP Flow Information export (IPFIX) Protocol for the Exchange of Flow Information Stéphane Bortzmeyer <stephane+blog@bortzmeyer.org> Première rédaction de cet article le 16 septembre 2013 Date de publication du RFC : Septembre 2013 Le système IPFIX, successeur désigné de Netflow avait été normalisé dans le RFC , que notre RFC met légèrement à jour. Des routeurs de différentes marques peuvent donc désormais envoyer des informations statistiques à des machines d administration de différentes origines. L idée de base, héritée de Netflow, est d agréger les informations de trafic, pour que le routeur n ait à envoyer qu une synthèse, et pas la totalité du trafic. Comme Netflow, IPFIX peut servir à la gestion du réseau, à la supervision mais aussi à l espionnage. Un cahier des charges pour IPFIX avait été spécifié dans le RFC Le système IPFIX lui-même est normalisé depuis le RFC 5101, ce nouveau RFC prenant en charge le protocole d autres RFC s occupant du modèle d informations (RFC 7012 et RFC 5610) ou bien de l architecture des différents composants d IPFIX. C est ainsi qu IPFIX a des extensions rigolotes comme la technique de compression du RFC 5473, les données complexes du RFC 6313 ou le stockage de donnéees dans des fichiers permanents du RFC La terminologie d IPFIX est en section 2. Il est recommandé de lire le document d architecture, le RFC Un point d observation ( Observation Point ) est l endroit du réseau d où on observe (le port d un routeur, par exemple). Un domaine d observation ( Observation Domain ) est l ensemble des points d observation dont les observations vont être agrégées en un seul message IPFIX (un routeur, par exemple). Un flot ( flow ) est un ensemble de paquets, passant par le même point d observation, et ayant des caractéristiques communes. la définition est volontairement très ouverte. Un flot ne correspond donc pas forcément à une connexion TCP. Par exemple, un flot peut être défini par : 1. Pour voir le RFC de numéro NNN, par exemple rfc/rfc5101.txt 1

2 2 Les en-têtes du paquet : adresses IP de source et de destination, bien sûr, mais aussi les ports, et/ou des champs applicatifs. Donc, tous les paquets depuis ou vers [2001:db8:1:2]:53 est un flot, identifiant le trafic DNS de 2001:db8:1:2. Les caractéristiques du traitement du paquet : prochain routeur ou interface de sortie. Un enregistrement de flot ( flow record ) est composé de la définition du flot et des valeurs mesurées (nombre total de paquets appartenant à ce flot qui ont été vus, nombre total d octets). Un gabarit ( template ) est une structure de données qui décrit ce qui est contenu dans les enregistrements. Un exporteur ( exporter ), typiquement le routeur, va émettre ces enregistrements, contenant le résultat de ses observations, vers un collecteur ( collector ) où on fabriquera de jolis graphes. Notre RFC normalise ensuite le format des paquets (section 3). Comme avec d autres protocoles, les paquets commencent par un numéro de version, 10 ici (inchangé depuis le RFC 5101), IPFIX marquant sa descendance depuis Netflow, dont la dernière version était la 9. Le RFC décrit aussi l encodage des données exportées par l observateur IPFIX (section 6). Des exemples d encodage sont fournis dans l annexe A. Par exemple, A.2.1 utilise des éléments enregistrés à l IANA < (IPFIX permet aussi de définir les siens) : Adresse IP source sourceipv4address, Adresse IP destination destinationipv4address, Routeur suivant ipnexthopipv4address, Nombre de paquets packetdeltacount, Nombre d octets octetdeltacount. Les trois premiers identifient le flot et les deux derniers sont les mesures par flot. Le gabarit va donc lister ces cinq élements, avec leur taille (quatre octets chacun). Enfin, notre RFC décrit le mécanisme de transport, au dessus d UDP, le protocole traditionnel de Netflow, mais aussi de TCP ou bien du protocole recommandé, SCTP. Pour répondre au cahier des charges, qui insistait sur la sécurité, la section 11.1 décrit aussi l utilisation de TLS. À propos de sécurité, la section 11 se penche aussi sur la confidentialité (IPFIX permet de transporter des informations sur les méta-données d une communication, permettant l analyse de trafic ; même si on n a pas le contenu des communications, cela peut être très indiscret). Elle attire aussi l attention du programmeur sur l importance de s assurer de l intégrité des données. IPFIX pouvant être utilisé pour la facturation, un client malhonnête peut avoir une bonne motivation pour modifier ces données. La section 1.1 décrit les changements depuis le premier RFC, le RFC Ils sont de peu d importance et deux logiciels suivant les deux RFC pourront interagir. Il y a eu plusieurs corrections d erreurs dans la spécification < table>, les définitions d élements d information situées dans l ancien RFC ont toute été sorties, vers le registre IANA < qui fait désormais seul autorité. Une nouvelle section, la 5.2, traite le problème du débordement de certains types temporels, débordement qui se produira en 2032 ou 2038 selon les cas (cela semble loin dans le futur mais les logiciels durent longtemps, rappelez-vous le bogue de l an 2000). IPFIX est déjà mis en œuvre dans plusieurs systèmes. Un exemple de mise en œuvre en logiciel libre est Maji < Mais, apparemment Cacti ne sait pas exporter de l IPFIX, juste du vieux Netflow. Ntop sait faire mais il faut passer à nprobe l option -V 10 (plein d exemple dans cet article < recommended-nprobe-templates/>, merci à Andrew Feren pour les informations). Si vous voulez voir des traces IPFIX, il y en a deux sur pcapr < Wireshark sait analyser de l IPFIX < html>, il faut lui demander de décoder comme < juniper-nsp/2012-march/ html> du cflow <

3 3 c/cflow.html>. Le RFC 5153 donne des conseils aux programmeurs qui veulent créer ou lire de l IP- FIX. Les RFC 5471 et RFC 5472 sont utiles aux administrateurs réseaux qui voudraient déployer IP- FIX. Toutefois, aujourd hui, des années après la sortie du premier RFC, il semble que peu d opérateurs utilisent IPFIX (v10). La plupart sont restés bloqués sur Netflow (v9). Les grands routeurs (Juniper ou Cisco) savent faire de l IPFIX mais pas forcément les routeurs de bas de gamme. Voici un exemple vu par Wireshark. C est du vrai IPFIX (numéro de version 10). [Premier paquet, avec les gabarits] Cisco NetFlow/IPFIX Version: Timestamp: Jul 8, :18: CEST ExportTime: FlowSequence: 0 Observation Domain Id: 0 Set 1 FlowSet Id: Data Template (V10 [IPFIX]) (2) FlowSet 48 Template (Id = 47104, Count = 25) Template Id: Field Count: 25 Field (1/25): flowstartmilliseconds = Type: flowstartmilliseconds (152) Field (2/25): flowendmilliseconds = Type: flowendmilliseconds (153) Field (3/25): BYTES_TOTAL = Type: BYTES_TOTAL (85) Field (4/25): BYTES_TOTAL [Reverse] = Type: BYTES_TOTAL (85) [Reverse] Field (5/25): PACKETS_TOTAL = Type: PACKETS_TOTAL (86) Field (6/25): PACKETS_TOTAL [Reverse] = Type: PACKETS_TOTAL (86) [Reverse] Field (7/25): IPV6_SRC_ADDR = Type: IPV6_SRC_ADDR (27) 6 Field (8/25): IPV6_DST_ADDR = Type: IPV6_DST_ADDR (28) 6 Field (9/25): IP_SRC_ADDR = Type: IP_SRC_ADDR (8) Field (10/25): IP_DST_ADDR = Type: IP_DST_ADDR (12)

4 4 Field (11/25): L4_SRC_PORT = Type: L4_SRC_PORT (7) Field (12/25): L4_DST_PORT = Type: L4_DST_PORT (11) Field (13/25): PROTOCOL = Type: PROTOCOL (4) Field (14/25): flowendreason = Type: flowendreason (136) Field (15/25): paddingoctets = Type: paddingoctets (210) Length: 6 Field (16/25): 21 [pen: CERT Coordination Center] = Type: 21 [pen: CERT Coordination Center] Field (17/25): TCP_SEQ_NUM = Type: TCP_SEQ_NUM (184) Field (18/25): TCP_SEQ_NUM [Reverse] = Type: TCP_SEQ_NUM (184) [Reverse] Field (19/25): 14 [pen: CERT Coordination Center] = Type: 14 [pen: CERT Coordination Center] Field (20/25): 15 [pen: CERT Coordination Center] = Type: 15 [pen: CERT Coordination Center] Field (21/25): [pen: CERT Coordination Center] = Type: [pen: CERT Coordination Center] Field (22/25): [pen: CERT Coordination Center] = Type: [pen: CERT Coordination Center] Field (23/25): SRC_VLAN = Type: SRC_VLAN (58) Field (24/25): SRC_VLAN [Reverse] = Type: SRC_VLAN (58) [Reverse] Field (25/25): Unknown(32767) = Type: Unknown (32767) Length: [i.e.: "Variable Length"] Template (Id = 49155, Count = 3) Template Id: 49155

5 5 Field Count: 3 Field (1/3): TCP_SEQ_NUM = Type: TCP_SEQ_NUM (184) Field (2/3): 14 [pen: CERT Coordination Center] = Type: 14 [pen: CERT Coordination Center] Field (3/3): 15 [pen: CERT Coordination Center] = Type: 15 [pen: CERT Coordination Center] Template (Id = 49171, Count = 6) Template Id: Field Count: 6 Field (1/6): TCP_SEQ_NUM = Type: TCP_SEQ_NUM (184) Field (2/6): 14 [pen: CERT Coordination Center] = Type: 14 [pen: CERT Coordination Center] Field (3/6): 15 [pen: CERT Coordination Center] = Type: 15 [pen: CERT Coordination Center] Field (4/6): [pen: CERT Coordination Center] = Type: [pen: CERT Coordination Center] Field (5/6): [pen: CERT Coordination Center] = Type: [pen: CERT Coordination Center] Field (6/6): TCP_SEQ_NUM [Reverse] = Type: TCP_SEQ_NUM (184) [Reverse] Template (Id = 49176, Count = 2) Template Id: Field Count: 2 Field (1/2): 18 [pen: CERT Coordination Center] = Type: 18 [pen: CERT Coordination Center] Length: [i.e.: "Variable Length"] Field (2/2): [pen: CERT Coordination Center] = Type: [pen: CERT Coordination Center] Length: [i.e.: "Variable Length"] Template (Id = 49156, Count = 2) Template Id: Field Count: 2 Field (1/2): SRC_MAC = Type: SRC_MAC (56) Length: 6 Field (2/2): DESTINATION_MAC

6 = Type: DESTINATION_MAC (80) Length: 6 [Deuxième paquet, avec les données] Cisco NetFlow/IPFIX Version: Timestamp: Jul 8, :18: CEST ExportTime: FlowSequence: 0 Observation Domain Id: 0 Set 1 FlowSet Id: (Data) (45840) FlowSet 48 Flow 1 [Duration: seconds] StartTime: Jun 7, :22: CEST EndTime: Jun 7, :22: CEST Permanent Octets: 220 Permanent Octets: 276 (Reverse Type 85 BYTES_TOTAL) Permanent Packets: 4 Permanent Packets: 4 (Reverse Type 86 PACKETS_TOTAL) SrcAddr: ( ) DstAddr: ( ) SrcPort: DstPort: Enterprise Private entry: (CERT Coordination Center) Type 21: Value (hex bytes): (Reverse Type 58 SRC_VLAN) [Enterprise Private entry: ((null)) Type 32767: Value (hex bytes): 00 c d 68 ed 12 Flow 2 [Duration: seconds] StartTime: Jun 7, :22: CEST EndTime: Jun 7, :22: CEST Permanent Octets: 336 Permanent Octets: 164 (Reverse Type 85 BYTES_TOTAL) Permanent Packets: 5 Permanent Packets: 3 (Reverse Type 86 PACKETS_TOTAL) DstAddr: ( ) SrcPort: DstPort: Enterprise Private entry: (CERT Coordination Center) Type 21: Value (hex bytes): dd (Reverse Type 58 SRC_VLAN) [Enterprise Private entry: ((null)) Type 32767: Value (hex bytes): 00 c a3 c6 5c Flow 3 [Duration: seconds] StartTime: Jun 7, :22: CEST EndTime: Jun 7, :22: CEST Permanent Octets: 336 Permanent Octets: 164 (Reverse Type 85 BYTES_TOTAL) Permanent Packets: 5 Permanent Packets: 3 (Reverse Type 86 PACKETS_TOTAL) DstAddr: ( ) SrcPort: DstPort: 50006

7 7... Enterprise Private entry: (CERT Coordination Center) Type 21: Value (hex bytes): (Reverse Type 58 SRC_VLAN) [Enterprise Private entry: ((null)) Type 32767: Value (hex bytes): 00 c cc ca Flow 4 [Duration: seconds] StartTime: Jun 7, :22: CEST EndTime: Jun 7, :22: CEST Permanent Octets: 60 Permanent Octets: 40 (Reverse Type 85 BYTES_TOTAL) Permanent Packets: 1 Permanent Packets: 1 (Reverse Type 86 PACKETS_TOTAL) DstAddr: ( ) SrcPort: DstPort: Enterprise Private entry: (CERT Coordination Center) Type 21: Value (hex bytes): a2 (Reverse Type 58 SRC_VLAN) [Enterprise Private entry: ((null)) Type 32767: Value (hex bytes): 00 c f2 6b Flow 5 [Duration: seconds] StartTime: Jun 7, :22: CEST EndTime: Jun 7, :22: CEST Permanent Octets: 60 Permanent Octets: 40 (Reverse Type 85 BYTES_TOTAL) Permanent Packets: 1 Permanent Packets: 1 (Reverse Type 86 PACKETS_TOTAL) DstAddr: ( ) SrcPort: DstPort: Enterprise Private entry: (CERT Coordination Center) Type 21: Value (hex bytes): f (Reverse Type 58 SRC_VLAN) [Enterprise Private entry: ((null)) Type 32767: Value (hex bytes): 00 c a0 86 d