RFC: 4884
Оригинал: Extended ICMP to Support Multi-Part Messages
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , ,
Перевод: Николай Малых

RFC 4884, Страница 9 из 16

5.1. Классическое приложение получает сообщение ICMP с расширениями

Когда классическое приложение получает сообщение ICMP с расширением, приложение будет некорректно интерпретировать это расширение, как часть поля «исходной дейтаграммы». К счастью, расширения начинаются не ранее 128 октетов от начала поля «исходной дейтаграммы». Поэтому проблемы могут возникать только у тех приложений, которые обрабатывают более 128 окетов поля «исходной дейтаграммы». На момент публикации этого документа было известно только два таких приложения, причем степень негативного влияния расширений минимальна.

Некоторые варианты стека TCP при получении сообщения ICMP проверяют контрольную сумму поля «исходной дейтаграммы» [ATTACKS]. Если эта сумма некорректна, стек TCP отбрасывает сообщение ICMP по соображениям безопасности. Если завершающие октеты поля «исходной дейтаграммы» переписаны расширением ICMP, такой стек TCP будет отбрасывать сообщения ICMP, которые не были бы отброшены в обычных условиях. Негативное влияние такого отбрасывания считается минимальным, поскольку множество сообщений ICMP отбрасывается по другим причинам (например, фильтрация ICMP, перегрузка в сети, некорректная контрольная сумма в результате «усекновения» исходной дейтаграммы).

Другой, теоретически возможный, но весьма маловероятный случай возникает, когда расширения ICMP переписывают часть поля «исходной дейтаграммы», которая представляет заголовок TCP, что приводит стек TCP к работе с некорректным соединением TCP. Такие случаи маловероятны, поскольку для их возникновения нужно, чтобы заголовок TCP выходил за пределы первых 128 октетов поля «исходной дейтаграммы», а расширение напоминало бы корректный заголовок TCP.

Страница 9 из 16

2007 - 2022 © Русские переводы RFC, IETF, ISOC.