Кратко
- LinkType выбирает формат метаданных и канального заголовка перед сохранённым пакетом. Он не подписывает файл и не подтверждает сенсор, место, время, направление или непрерывность хранения.
- Синтаксически правильный файл может быть переписан, объединён, воспроизведён или сфабрикован. Высокозначимое решение требует отдельного журнала приобретения, преобразований и ответственных лиц.
Эксперт получил файл по электронной почте. Заголовок PCAP был корректен, LinkType зарегистрирован, все записи разобрались, временные метки шли по порядку. В заключении появилось: «пакеты были зафиксированы пограничным датчиком в указанный момент и с тех пор не изменялись».
Из файла следовало только то, что кто-то записал правдоподобные поля в правильной структуре.
Не было исходного хеша при приобретении, подписи датчика, журнала передачи, конфигурации зеркала, идентификатора часов или доказательства того, что вложение совпадает с первоначальным экспортом. Правильная грамматика стала заменой отсутствующей цепочки хранения.
Такое повышение полномочий противоречит узкой роли, описанной в Link-Layer Types for PCAP-related Capture File Formats. Редакция 18 датирована 6 апреля 2026 года и истекает 8 октября 2026-го. На момент фиксации фактов 3 октября это был активный Internet-Draft OPSAWG с предполагаемым статусом Informational, в очереди RFC Editor в ожидании первого редактора и без номера RFC. Процесс публикации не удостоверяет отдельный файл или реализацию.
Проект предлагает реестр IANA для LinkType, используемых PCAP и pcapng. 16-битное значение выбирает одну из сотен схем метаданных и инкапсуляции второго уровня перед пакетом. Это позволяет читателю понять, где и как разбирать сохранённые байты.
Совместимость синтаксиса важна. Но свидетель обязан отвечать не только «как устроена запись», а ещё «кто её создал, что именно наблюдал, какие изменения произошли и кто отвечает за каждую передачу». LinkType этих вопросов не задаёт.
Правдоподобная запись может быть производной
LINKTYPE_ETHERNET не означает, что файл вышел с физического Ethernet-ответвителя. Виртуальный коммутатор может выдавать Ethernet-кадры. Конвертер может удалить локальный псевдозаголовок и представить пакет в общей форме. Сервис воспроизведения может создать такой кадр без живого наблюдения. Лаборатория может синтезировать весь поток.
Старый PCAP использует один LinkType на файл. В проекте PCAP-09 сказано, что это часто означает пакеты с одного интерфейса, поскольку не каждый LinkType умеет указывать интерфейс. Но «часто» — описание практики, а не гарантия формата. Несколько источников можно заранее привести к одной грамматике.
pcapng даёт более богатую структуру: Interface Description Blocks, локальные для Section Interface ID, имена, описания, фильтры и привязку расширенного пакетного блока к интерфейсу. Это делает заявление о происхождении точнее, но не истиннее автоматически. Имя вводит писатель. ID 0 в другой Section может означать другую интерфейсную запись.
Поэтому система должна хранить два слоя: что файл заявляет и чем заявление независимо подтверждено. Иначе аккуратные поля только делают подделку убедительнее.
Полнота не следует из успешного разбора
PCAP различает Captured Packet Length и Original Packet Length. SnapLen может сохранить лишь начало пакета. pcapng использует ту же идею на уровне интерфейса и записи.
LinkType позволяет разобрать присутствующие байты, но не восстанавливает отброшенный хвост. Если искомого содержимого нет после границы SnapLen, вывод должен быть «не наблюдалось в сохранённой части», а не «не было в исходном пакете».
Проект LinkType также предупреждает: внутренние поля длины могут описывать объект больше сохранённого буфера. Доверие к ним создаёт простые чтения за границей. Файл может содержать произвольный ввод, контролируемый злоумышленником. Корректный LinkType выбирает правильный код для атаки так же легко, как для честного файла.
Цепочка хранения должна поэтому включать не только хеши, но и среду безопасного разбора: версию парсера, версию определения, ошибки проверки, ограничения ресурсов и получившиеся производные артефакты.
Регистрация не является нотариатом
Значения 0–65000 предлагается выдавать по Expert Review RFC 8126, а 65001–65535 оставить для Experimental Use. Исторические частные значения 147–162 сохраняются, но новые частные форматы должны использовать экспериментальный диапазон. Экспериментальные номера обычно не следует выпускать за пределы использующей их организации.
Эксперт может заметить дубликат и потребовать ясного описания байтов перед IPv4 или IPv6. Стабильная ссылка на спецификацию поощряется. Но публичная спецификация не обязательна; допустима закрытая, а минимальное требование — контакт.
Это разумно для распределения пространства. Но именно поэтому запись в реестре не подтверждает открытость, качество кода, владельца файла или неизменность содержимого. Она координирует значение официального номера.
Экспериментальный номер ещё слабее за границей: две организации могут придать ему разные структуры. Без внешнего профиля число не способно выбрать между ними. Внешне успешный разбор может оказаться применением локального смысла к чужому файлу.
DLT добавляет похожую опасность. Его числовое значение часто совпадает с LinkType, но не всегда; некоторые значения зависят от ОС и не стандартизованы. Конверсия должна сохранять исходное пространство имён, систему, библиотеку, таблицу соответствия и результат.
Цепочка хранения — последовательность ответственных утверждений
Минимальный конверт начинается до создания аналитических полей. Кто приобрёл данные? Какой сенсор, интерфейс, tap или зеркало предполагались? Какая конфигурация и направление действовали? Как синхронизировались часы? Каков исходный хеш? Кто получил файл? Какие фильтры, SnapLen, конверсии и объединения применены? Где хранится оригинал? Какая подпись или журнал подтверждает каждый переход?
Ни одно поле не обязано отвечать на всё. Это соответствует Minimum Initial Specification: общий слой остаётся тонким—формат, LinkType, длины, Section и локальная Interface ID. Локальная организация добавляет доказательства хранения и принимает решения в пределах собственной ответственности. Ошибка начинается, когда общий числовой маркер выдаётся за весь институт доверия.
Running-Code Primacy требует испытать отрицательные свойства. Создайте одинаковые Ethernet-байты через tap, replay и генератор. Подмените if_name, сохранив валидную структуру. Переставьте Sections. Усеките пакет перед важной сигнатурой. Измените файл после первого хеша. Используйте столкновение экспериментальных значений и неправильное DLT-преобразование.
Система должна уметь сказать: «формат распознан; происхождение не подтверждено», «запись усечена», «цепочка прервана», «определение неоднозначно». Если она вместо этого повышает уверенность за счёт гладкого разбора, она создаёт институциональную иллюзию.
Файл разобрался без ошибок. Это достижение совместимости, а не свидетельство истории. История возникает только там, где каждый переход имеет проверяемого владельца.
Источники
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/history/
- https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-opsawg-pcaplinktype/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/references/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/referencedby/
- https://www.ietf.org/archive/id/draft-ietf-opsawg-pcaplinktype-18.txt
- https://www.ietf.org/archive/id/draft-ietf-opsawg-pcaplinktype-18.html
- https://www.ietf.org/archive/id/draft-ietf-opsawg-pcaplinktype-18.xml
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcap/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcap/history/
- https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-opsawg-pcap/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcap/references/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcap/referencedby/
- https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-09.txt
- https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-09.html
- https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-09.xml
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcapng/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcapng/history/
- https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-opsawg-pcapng/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcapng/references/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcapng/referencedby/
- https://www.ietf.org/archive/id/draft-ietf-opsawg-pcapng-06.txt
- https://www.ietf.org/archive/id/draft-ietf-opsawg-pcapng-06.html
- https://www.ietf.org/archive/id/draft-ietf-opsawg-pcapng-06.xml
- https://datatracker.ietf.org/doc/rfc8126/
- https://www.rfc-editor.org/rfc/rfc8126.txt
- https://github.com/IETF-OPSAWG-WG/pcapng
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
