Какие методы используются для вычисления полей IP ID?

Question

Я немного изучаю методы генерации поля идентификаторов заголовков IP.

Я прочитал источники и другие документы и подтвердил, что Linux генерирует случайное число для каждого однорангового узла (IP), с которым он связывается, а затем увеличивает идентификатор на 1 для последующих IP-пакетов, которые он отправляет этому узлу.

У меня вопрос, знаете ли вы причины / методы такого поведения? Зачем отслеживать одноранговые узлы, с которыми общалось ядро (с помощью памяти и процессорного времени, необходимого для всего этого)?

Я начал это исследование, потому что я немного играю с методами сканирования на холостом ходу.

Ссылки с более подробной информацией являются предпочтительными.

Answer 1

Порядковый номер (см. RFC 6528) должен быть неосуществим для того, кто не имеет доступа к потоку данных (некоторые атаки, в частности, известная Митником, основаны на его угадывании и подражании коллеге). Вот почему Linux использует здесь случайное число. Другие операционные системы намного медленнее, nmap проверяет, насколько тщательно они это делают (и, вероятно, включает обширную базу данных о том, как системы это делают). Отсутствие надежного источника случайных чисел особенно беспокоит такие машины, как WiFi-маршрутизаторы.

(Да, такого рода уязвимости были известны и предупреждены с самых первых версий TCP; да, из-за своей бесконечной лени многие пишущие операционные системы / сетевые стеки просто использовали фиксированные или регулярно увеличивали их, или что-то подобное) умный », в основном ради" производительности ".)

Answer 2

Когда ваш компьютер обращается к одноранговому компьютеру (или даже к "удаленному" серверу), а затем получает ответ от этого однорангового или удаленного компьютера, недостаточно знать ВОЗ, откуда поступил этот ответ. Вы также должны знать, на какой разговор вы отвечаете.

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

Все это необходимо отслеживать, чтобы при получении ответа можно было определить, к какому "разговору" он принадлежит.

Я не смог найти конкретную ссылку на это для описанного вами случая, но это похоже на то, как IMAP ожидает от клиента предоставления "тега", который обычно увеличивается с каждой новой "командой". Для этого, и я подозреваю, что в случае, о котором вы спрашиваете, не требуется "увеличивать" тег при каждом использовании (и, следовательно, никаких ссылок, вероятно, не будет найдено). Единственное требование - тег должен быть уникальным для каждого использования. Начиная с уникальной строки (или числа), а затем увеличивая ее при каждом использовании, вы гарантируете, что она уникальна, без необходимости специально запоминать, какие "теги" уже использовались. (IMAP RFC 3501: раздел 2.2.1).