Кратко

  • RFC 5393 описал, как менее десяти корректных SIP-сообщений могли подготовить дерево с потенциальными 2^71 сообщениями; в варианте с несколькими AOR трафик превышает N! до повторения пути даже при повсеместном поиске циклов.
  • Max-Breadth удерживает число незавершённых ветвей, но возвращает бюджет после финального ответа. Пик снижается, а совокупный трафик, по прямому указанию RFC, не обязательно уменьшается.
  • Граф регистраций, история Via, решение «цикл или спираль», активная ширина, накопленные ветви и сохранение истории через B2BUA являются разными квитанциями.

Мгновенный снимок скрыл оборот

Для каждого response context RFC определяет входящий Max-Breadth и исходящую сумму, выделенную запросам без финального ответа. Исходящая сумма не может превышать полученный бюджет.

При восьми целях и бюджете четыре прокси запускает четыре транзакции. Ошибка освобождает единицу, и открывается пятая цель. Так можно последовательно проверить все восемь, ни разу не показав пять активных ветвей.

Вариант без возврата бюджета обсуждался и был отвергнут. Он дал бы постоянный предел на число транзакций одного корня, но резко сузил бы нормальную достижимость и мог нарушить существующие схемы. Стандарт сохранил последовательный поиск и ограничил только пик.

Поэтому число четыре требует единицы измерения: активные ветви, все цели за жизнь, хопы или корневые запросы. RFC гарантирует только первое.

Исполнимое состояние было записано в AOR

В простом сценарии два proxy/registrar обслуживали четыре AOR. Каждая запись на P1 указывала на обе записи P2, и наоборот. Один INVITE превращался в два запроса, затем в четыре и восемь.

Все REGISTER могли быть допустимыми. Рост создавался не синтаксической ошибкой, а композицией связей. До обнуления Max-Forwards дерево продолжалось; при рекомендуемом значении 70 оно содержало 2^71 - 1 запросов. Превышение Timer C добавляло 408 и CANCEL.

RFC сообщает о запуске схемы на SIPit: более двух прокси, Max-Forwards 20, несколько часов взаимной бомбардировки. Завершение одного INVITE оценивалось почти в десять дней. Некоторые перезапущенные узлы снова вступали в процесс, если регистрационное состояние сохранялось.

Перезапуск изменил процесс, но не полномочие. Пока долговечный граф разрешает тот же маршрут, работа возвращается.

Идентичный прошлый путь и новый путь — разные задачи

В бинарной схеме поиск цикла эффективен. При поддержке всеми узлами RFC указывает 14 стимулированных сообщений в первом варианте и 10 в односерверном. Поэтому разветвляющий прокси должен проверять возврат в тот же контекст.

Вторая часть Via branch зависит от Request-URI, Route и других полей, реально влияющих на location service. Совпадение при повторном проходе означает цикл и ответ 482. Различие означает спираль с изменившимися входами маршрутизации.

Такая проверка требует сохранённой истории. Удаление или изменение Via лишает предыдущий узел возможности узнать собственную метку. Два скрывающих историю посредника способны создать контур, который не видит ни один из них.

Но N AOR, каждая из которых ветвится ко всему множеству, создают проблему до повтора. Возможны все перестановки остальных N-1 адресов; последний fork добавляет N запросов к каждому пути. Только этот слой даёт N!. Таблица RFC показывает 64 запроса для четырёх AOR, 1 956 для шести, 109 600 для восьми и 9 864 100 для десяти.

Это не прогноз обычной сети. Это граница дедупликации: она останавливает известное прошлое, но не ограничивает число ещё уникальных историй.

Глубина, ширина и сумма требуют трёх счетчиков

Max-Forwards ограничивает глубину. Max-Breadth — одновременную ширину. RFC запрещает уменьшать ширину на каждом хопе и превращать её во второй счётчик расстояния. Суммарное число ветвей остаётся третьей величиной.

Ответ 440 Max-Breadth Exceeded означает, что параллельный план не помещается, а прокси не выбрал последовательность или redirect. Он не подтверждает прекращение будущей работы. При значении один последовательный fork разрешён.

Раздел безопасности прямо говорит: Max-Breadth не уменьшает совокупный трафик атаки, а растягивает его во времени. Несколько корней могут постепенно накопить неприемлемую нагрузку.

Польза — время для оператора. Можно увидеть рост незавершённых транзакций по ресурсу или по системе и временно отключить причину. Без такого действия медленный поток остаётся усилением, только менее заметным.

B2BUA может выдать старой работе новую биографию

B2BUA завершает UAS-сторону и формирует новую UAC-сторону. Топологическая скрытность может быть законной целью, но исчезновение Via и лимитов разрывает общий путь. RFC 5393 предупреждает: два таких элемента могут лишить Max-Forwards, loop detection и Max-Breadth общей истории.

RFC 7332 позднее потребовал копировать и уменьшать Max-Forwards, переносить и соблюдать Max-Breadth и рекомендовал обнаружение из RFC 5393. Он также показал конфликт между обфускацией и обнаружимостью.

Текст стандарта не доказывает работающую конфигурацию. Приоритет running code требует провести тест через настоящий B2BUA, сравнить обе стороны и увидеть, что параллельные запросы делят один входящий бюджет.

Граница доказательств

Источники подтверждают RFC, изложенный в нём опыт SIPit, расчёты и требования. Они не подтверждают современную поддержку у конкретного поставщика, частоту атак или причину аварии. 2^71, N! и 9 864 100 действуют только вместе со своими предпосылками.

Надёжный вывод прост: одновременность — фотография, общий труд — бухгалтерская книга. Для заявления о безопасности нужны обе и запись о том, кто потратил каждый возвращённый кредит.