RFC 5101

RFC 5101 — это запрос на комментарии (Request for Comments, RFC) номер 5101, опубликованный в 2008 году, который определяет протокол IP Flow Information Export (IPFIX) — стандарт для экспорта информации о сетевых потоках. RFC 5101 является основным документом, описывающим формат данных, модель данных и процедуры передачи записей о потоках от сетевых устройств (экспортеров) к системам сбора и анализа (коллекторам). Протокол IPFIX, определённый в RFC 5101, стал развитием и стандартизацией проприетарного протокола NetFlow v9, разработанного компанией Cisco Systems, и был принят как стандарт Интернета (Internet Standard) Рабочей группой по инженерным вопросам Интернета (IETF).

История

Разработка IPFIX началась в начале 2000-х годов в рамках IETF, когда возникла потребность в универсальном, вендоронезависимом протоколе для экспорта информации о сетевых потоках. До этого доминировал протокол NetFlow, но его версии (особенно v9) были проприетарными и не полностью открытыми. Рабочая группа IPFIX (IPFIX Working Group) была создана в 2001 году. В 2004 году был опубликован RFC 3917 «Requirements for IP Flow Information Export», который определил требования к новому протоколу. RFC 5101, опубликованный в феврале 2008 года, стал результатом этой работы, представив протокол, основанный на архитектуре и формате NetFlow v9, но с существенными улучшениями и расширениями. Впоследствии RFC 5101 был обновлён и уточнён рядом последующих RFC, в частности RFC 7011, который в 2013 году заменил RFC 5101 в качестве основного стандарта IPFIX.

Основные понятия

Сетевой поток

В контексте IPFIX сетевой поток (network flow) определяется как набор пакетов, проходящих через точку наблюдения в сети в течение определённого интервала времени, которые имеют общий набор из семи ключевых атрибутов:

• IP-адрес источника
• IP-адрес назначения
• Порт источника (для TCP/UDP)
• Порт назначения (для TCP/UDP)
• Протокол транспортного уровня (например, TCP, UDP, ICMP)
• Тип сервиса (Type of Service, ToS) или DSCP (Differentiated Services Code Point)
• Интерфейс, на котором пакет был принят (входной интерфейс)

Экспортер и коллектор

Протокол IPFIX предполагает архитектуру «клиент-сервер», где:

• Экспортер (exporter) — сетевое устройство (маршрутизатор, коммутатор, межсетевой экран), которое собирает информацию о проходящих через него потоках, агрегирует её и отправляет в виде сообщений IPFIX.
• Коллектор (collector) — сервер или программное обеспечение, которое принимает, хранит и анализирует данные от экспортеров.

Формат сообщений IPFIX

Сообщения IPFIX передаются поверх транспортного протокола, обычно SCTP (Stream Control Transmission Protocol) или TCP/UDP. Каждое сообщение состоит из заголовка и одной или нескольких записей данных (data records).

Заголовок сообщения

Заголовок имеет фиксированную длину 16 байт и содержит:

• Версия протокола (10 для IPFIX)
• Длина сообщения
• Метка времени (время экспорта)
• Идентификатор наблюдения (Observation Domain ID) — позволяет различать несколько точек наблюдения на одном экспортере
• Идентификатор последовательности (Sequence Number) — для обнаружения потери пакетов

Шаблоны и записи данных

IPFIX использует механизм шаблонов (templates), аналогичный NetFlow v9. Это позволяет гибко определять формат экспортируемых данных. Шаблон описывает набор полей (field specifiers), каждое из которых соответствует определённому типу информации (например, IP-адрес источника, количество байт, время начала потока). Экспортер сначала отправляет шаблон коллектору, а затем отправляет записи данных, которые ссылаются на этот шаблон. Такой подход позволяет:

• Передавать только те поля, которые необходимы для конкретного приложения
• Добавлять новые типы полей без изменения протокола
• Экономить пропускную способность, так как шаблоны передаются редко, а записи данных — только значения полей

Информационные элементы

Типы полей в IPFIX называются информационными элементами (Information Elements). Они определены в реестре IANA (Internet Assigned Numbers Authority) и включают сотни стандартных элементов, таких как:

• sourceIPv4Address, destinationIPv4Address
• sourceTransportPort, destinationTransportPort
• protocolIdentifier
• packetDeltaCount, octetDeltaCount
• flowStartSeconds, flowEndSeconds
• и многие другие (включая элементы для IPv6, MPLS, VLAN, прикладных протоколов)

Отличия от NetFlow v9

Хотя IPFIX основан на NetFlow v9, он внёс ряд улучшений:

• Поддержка SCTP — более надёжный транспорт, чем UDP, с возможностью управления потоком и обнаружения потерь.
• Переменная длина полей — в IPFIX поля могут иметь переменную длину, что позволяет более эффективно кодировать данные (например, строки переменной длины).
• Расширенная система типов — введены новые типы данных (например, дата и время с микросекундной точностью, IPv6-адреса).
• Поддержка нескольких точек наблюдения — через Observation Domain ID.
• Улучшенная модель данных — более строгое определение семантики полей и их взаимосвязей.

Применение

IPFIX широко используется в системах мониторинга и управления сетями для:

• Учета трафика (billing) — определение объёмов трафика по различным критериям (пользователи, приложения, сервисы).
• Обнаружения аномалий и атак — анализ потоков позволяет выявлять DDoS-атаки, сканирование портов, распространение вредоносного ПО.
• Анализа производительности сети — выявление узких мест, задержек, потерь пакетов.
• Планирования ёмкости (capacity planning) — прогнозирование роста трафика и оптимизация сетевой инфраструктуры.
• Форензики (forensics) — расследование инцидентов безопасности на основе исторических данных о потоках.

Критика и ограничения

Несмотря на широкое распространение, IPFIX имеет некоторые недостатки:

• Высокая нагрузка на экспортер — сбор и экспорт информации о потоках требует значительных вычислительных ресурсов, особенно на высокоскоростных интерфейсах (10 Гбит/с и выше).
• Потеря данных — при использовании UDP возможна потеря пакетов, особенно при перегрузке сети или экспортера.
• Сложность настройки — для эффективного использования требуется тонкая настройка шаблонов, интервалов экспорта и фильтрации потоков.
• Отсутствие полной информации о приложениях — IPFIX оперирует на сетевом и транспортном уровнях, не всегда позволяя точно идентифицировать прикладной протокол (например, HTTP vs HTTPS).

Связанные стандарты

• RFC 3917 — Requirements for IP Flow Information Export
• RFC 5102 — Information Model for IP Flow Information Export
• RFC 7011 — Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information (заменил RFC 5101)
• RFC 7012 — Information Model for IP Flow Information Export (заменил RFC 5102)
• RFC 7013 — Guidelines for Authors and Reviewers of IPFIX Information Elements

Источники

1. RFC 5101 — Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information (2008).
2. RFC 7011 — Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information (2013).
3. RFC 3917 — Requirements for IP Flow Information Export (2004).
4. IANA — IPFIX Information Elements Registry.
5. Cisco Systems — NetFlow and IPFIX documentation.