АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Path MTU Discovery

Экспертиза РАН

Logo-ran.pngLogo-ran-black.png
Проводится экспертиза
Российской академией наук
Подробнее
Times2.svg

Экспертиза РАН

Arrow-Right.png
Logo-ran.png
Проводится экспертиза
Российской академией наук
Подробнее

Path MTU Discovery (PMTUd) — это метод, позволяющий определить в компьютерной сети размер максимального блока передачи (MTU) на всём пути между двумя хостами по протоколу IP, чтобы избежать фрагментации пакетов. Для протокола ICMP метод определён в стандарте , для ICMPv6 — в .

Фрагментация IP-пакетов негативно влияет на производительность[1][2] маршрутизаторов и также создаёт проблемы для безопасности[3][4].

Принцип работы

Определение MTU пути работает посредством установки бита DF (Don't Fragment) в заголовке IP у всех исходящих пакетов. Если на маршруте прохождения найден узел с MTU меньше, чем размер пакета, такой пакет будет отброшен, а источнику отправляется ICMP-сообщение, содержащее MTU узла-отправителя. Это сообщение:

  • тип 3 / код 4, «Destination Unreachable» / «Fragmentation Needed and Don't Fragment was Set» в ICMP;
  • тип 2 / код 0, «Packet Too Big» в ICMPv6.

Источник затем уменьшает размер пакета согласно полученному значению MTU в ICMP-сообщении. Процесс повторяется до тех пор, пока источник не сможет доставить пакеты до пункта назначения.

Если MTU пути меняется (например, из-за смены маршрута), и становится меньше ранее определённого, первый слишком большой пакет вызовет новое ICMP-сообщение, и процесс Path MTU Discovery запустится заново. Также, во время соединения источник может периодически повторно зондировать путь, чтобы узнать, возможно ли теперь использовать больший MTU.

Хотя подобные изменения бывают нечасто, они зачастую связаны с динамическими протоколами маршрутизации или изменениями топологии вручную.

Проблемы

Несмотря на полезность, Path MTU Discovery сталкивается с рядом проблем — в основном связанных с требованиями безопасности, а также влиянием на производительность передачи данных в интернете.

Блокировка ICMP промежуточными устройствами

Многие устройства, такие как маршрутизаторы или межсетевые экраны, позволяют блокировать всё или часть ICMP-трафика либо по умолчанию, либо по решению администратора. Из-за ряда уязвимостей, связанных с ICMP, часто встречается подход, при котором весь ICMP считается такой же уязвимостью, как, например, Telnet или rsh. Однако блокировка всех ICMP-сообщений может привести к серьёзным сбоям сетевой инфраструктуры.

Если сообщения ICMP типа 3/кода 4 блокируются, Path MTU Discovery перестаёт работать: хосты будут продолжать слать слишком большие пакеты, которые будут теряться, но об ошибке источник так и не узнает — пакеты «проваливаются в чёрную дыру».

Эту проблему трудно обнаружить, поскольку частичная фильтрация не мешает ping или traceroute, а некоторые TCP-соединения могут ещё работать, пока не отправляются большие сегменты. Основной симптом — TCP-соединения, которые не могут передавать данные долгие периоды времени.

Вопрос широко обсуждался ещё в 1990-х и 2000-х, в частности в и . В начале 2000-х годов была организована инициатива, побудившая крупные сайты, действовавшие как «чёрные дыры», устранить проблему[5].

Взаимодействие с TCP

Хотя воспользоваться Path MTU Discovery могут любые транспортные протоколы, именно TCP наиболее часто использует этот механизм и наибольшую долю проблем с ним испытывает. RFC 2923 полностью посвящена взаимодействию TCP с Path MTU Discovery.

Одна из серьёзных проблем — связь между MTU и MSS. MSS определяет максимальный размер сегмента в TCP, который способна принять сторона. Многие системы используют результат Path MTU Discovery для указания MSS другой стороне при установлении соединения. Однако многочисленные исследования[6] показали, что асимметричные маршруты распространены, а значит, MTU отличаться для прямого и обратного пути, и использование Path MTU Discovery для вычисления MSS может привести к субоптимальной производительности. Хотя это допустимо стандартами, предпочтительнее использовать MTU локальных интерфейсов для определения MSS.

Для дальнейших примеров и пояснений см. .

Один из обходных путей — ограничение максимального размера сегмента, чтобы тот точно не превышал MTU Ethernet (1500 байт). Это вынуждает удалённого хоста не отправлять сегменты длиннее 1500 байт. Такой способ известен как MSS Clamping[7] и позволяет обойтись без Path MTU Discovery.

Поле MSS Clamping — это опция TCP в пакете SYN при установлении соединения между двумя узлами.

Угрозы безопасности

В и , описывающих Path MTU Discovery для IPv4 и IPv6, рассматриваются возможные виды атак. Наиболее критична атака типа отказ в обслуживании («лоуслоу»): злоумышленник, выдавая себя за получателя, присылает жертве специальные ICMP-сообщения, вынуждая принять минимально допустимый MTU (68 байт для IPv4, 1280 байт для IPv6, включая IP-заголовок и данные). В RFC рекомендуется не пытаться повысить величину MTU чаще, чем раз в 10 минут; таким образом, для сильного падения производительности злоумышленнику достаточно раз в 10 минут отправлять поддельное ICMP-сообщение.

Пропускная способность соединения заметно снижается, но главная опасность в другом: чтобы поддерживать скорость, жертва начинает отправлять чрезмерно большое количество маленьких пакетов, что создаёт «бурю прерываний» на всех задействованных устройствах, особенно на атакуемом. Это может привести к отказу оборудования, если атака идёт на множество соединений.

В 2005 году Фернандо Гонт описал ряд атак на TCP с использованием ошибочных ICMP-сообщений[8], в том числе вышеописанную. В качестве защиты он предложил разделить функцию Path MTU Discovery на две стадии: Initial Path-MTU и Path-MTU Update, а также ввести новые переменные TCP: maxsizesent (максимальный размер отправленного пакета) и maxsizeacked (максимальный размер принятого пакета).

Initial Path-MTU — этап в начале соединения, когда MTU неизвестен. Path-MTU Update — этап при установленной величине MTU, когда входящие ICMP-сообщения требуют особой проверки:

  • Если MTU, указанный в ICMP, больше maxsizesent, ICMP-сообщение игнорируется.
  • Если MTU равен или больше maxsizeacked, сообщение учитывается и MTU корректируется (Initial Path-MTU).
  • Если MTU меньше maxsizeacked, сообщение отмечается, а уменьшение MTU откладывается; если за это время приходит подтверждение TCP-сегмента, ICMP игнорируется, иначе применяется.

Задержка перед уменьшением MTU определяется количеством превышений времени ожидания (RTO) для данного TCP-сегмента — стандартная метрика для определения проблем передачи.

Такой подход реализован в NetBSD и OpenBSD с 2005 года.

Реализации

Path MTU Discovery входит в стандарты IETF. Хост, корректно реализующий ICMP, поддерживает Path MTU Discovery. В зависимости от операционной системы могут различаться внутренние счетчики.

RFC 1191 и RFC 1981 требуют, чтобы попытка увеличения MTU происходила не ранее, чем через 5 минут, и не позднее, чем через 1 минуту после получения ICMP-сообщения. Для практической реализации рекомендуется удвоить эти значения (соответственно, 10 и 2 минуты)[9].

Linux и FreeBSD следуют этой рекомендации.

Примечания

  1. ↑ J. Heffner, M. Mathis, B. Chandler. IPv4 Reassembly Errors at High Data Rates (англ.). IETF. Дата обращения: 22 июня 2024.
  2. ↑ Christopher A. Kent, Jeffrey C. Mogul. Fragmentation Considered Harmful (англ.). IETF. Дата обращения: 22 июня 2024.
  3. ↑ Tim Newsham, Thomas Ptacek. Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection (англ.). ACIRI. Дата обращения: 22 июня 2024.
  4. ↑ Michal Zalewski. A new TCP/IP blind injection technique? (англ.). Neohapsis. Дата обращения: 22 июня 2024.
  5. ↑ MSS Initiative (англ.). Phildev.net. Дата обращения: 22 июня 2024.
  6. ↑ Vern Paxson. End-to-end Routing Behavior in the Internet (англ.). LBNL. Дата обращения: 22 июня 2024.
  7. ↑ Linux Advanced Routing & Traffic Control HOWTO: Adjusting the TCP MSS (англ.). LARTC. Дата обращения: 22 июня 2024.
  8. ↑ Fernando Gont. ICMP attacks against TCP (англ.). IETF (26 июля 2005). Дата обращения: 22 июня 2024.
  9. ↑ J. Mogul, S. Deering. Path MTU discovery - Host specification (англ.). IETF. Дата обращения: 22 июня 2024.

Ссылки

Категории