Порядок создания СЗПДн. Требования к сетевым устройствам
 Скачать 1.38 Mb.
|
|
§3.2.2. Протокол доставки управляющих сообщений (InternetControlMessageProtocol — ICMP-протокол) ICMP-протокол определяет два класса ICMP-сообщений: ICMP-сообщения об ошибках: “Destination Unreachable” — получатель недостижим; “Redirect” — перенаправление; “SourceQuench” — источник не отвечает; “TimeExceeded” — время просрочено; “ParameterProblem” — параметрическая проблема; ICMP-запросы: “Echo” — Эхо-контроль; “Information” — Информация; “Timestamp” — метка времени; “Address Mask” — Адресная маска. Если принято ICMP-сообщение неизвестного типа, то оно должно по умолчанию удаляться. Каждое ICMP-сообщение об ошибке включает в себя IP-заголовок и, по крайней мере, первые восемь октетов данных IP-пакета, которые описывают ошибку (допускается передача более чем 8 таких октетов). Такой IP-заголовок и данные не должны отличаться от принятого IP-пакета. В тех случаях, когда сетевой (IP-)уровень требует доставки ICMP-сообщения об ошибке на транспортный уровень, из заголовка IP-пакета должен извлекаться номер протокола вышележащего уровня для последующего выбора соответствующего протокола транспортного уровня, программный модуль которого “устранит” ошибку. Целесообразно, чтобы в заголовке ICMP-сообщения об ошибке все биты TOS-субполя были нулевыми. ICMP-сообщение об ошибке не должно передаваться в качестве ответного после получения: ICMP-сообщения об ошибке; IP-пакета, который содержит широковещательный или групповой IP-адрес; IP-пакета, который передавался с использованием широковещательного адреса канального уровня; не начальный фрагмент большого исходного IP-пакета; IP-пакета, который содержит неопределённый для этой ГВМ IP-адрес (например, нулевой адрес, петлевой адрес, широковещательный адрес, групповой адрес или адрес класса Е). (Замечание. Эти ограничения являются более приоритетными по сравнению с любыми другими представленными в данном стандарте требованиями при передаче ICMP-сообщений об ошибках.) Выполнение этих правил предотвратит негативные последствия от возникновения чрезмерно большого трафика широковещательных сообщений, который может быть результатом отправки ГВМ ответных ICMP-сообщений об ошибке после получения ими IP-пакетов, которые содержали широковещательные IP-адреса. Например, широковещательная рассылка UDP-блоков на несуществующий транспортный порт может повлечь чрезмерный “поток” ответных ICMP-сообщений об ошибке “получатель недостижим”, сформированных всеми ГВМ, которые не имеют транспортного модуля с таким номером порта. В результате такой нештатной ситуации в большой Ethernet-сети, последняя может быть заблокирована в течении от одной до нескольких секунд. Каждый IP-пакет, транслируемый в широковещательном режиме в границах присоединённой сети, должен иметь действительный широковещательный IP-адрес в качестве IP-адреса получателя. Тем не менее, некоторые ГВМ нарушают это правило. Более того, чтобы быть уверенным в приёме широковещательных IP-пакетов, ГВМ требуют предварительной проверки широковещательного адреса канального уровня, помимо проверки широковещательного IP-адреса. Это означает, что канальный уровень должен информировать сетевой уровень о получении IP-пакета, переданного с использованием широковещательного адреса канального уровня. §3.2.2.1. ICMP-сообщение “получатель недостижим” (RFC-792) В этом сообщении используются следующие коды: “6” — неизвестная сеть получателя; “7” — неизвестная ГВМ-получатель; “8” — изолированная ГВМ-отправитель; “9” — соединение с сетью получателя запрещена административно; “10” — соединение с ГВМ-получателем запрещена административно; “11” — сеть недостижима по типу обслуживания; “12” — ГВМ недостижима по типу обслуживания. ГВМ должна формировать ICMP-сообщения“получатель недостижим” с использованием следующих кодов; “2” (протокол не поддерживается) — когда на ГВМ-получателе не поддерживается указанный в IP-пакете транспортный протокол; “3” (порт (номер порта) не поддерживается) — когда программный модуль транспортного протокола получателя (например, UDP-протокола) не способен демультиплексировать IP-пакеты, и к тому же не способен проинформировать об этом отправителя IP-пакета. Если получено ICMP-сообщение“получатель недостижим”, то необходимо проинформировать о нём транспортный уровень. Транспортный уровень должен использовать соответствующую информацию. Транспортный протокол, реализующий свой собственный способ оповещения отправителя, указавшего недостижимый транспортный порт (например, ТСР-протокол, который передаёт ТСР-блоки с установленным битом “RST” (reset) — запросы на повторное соединение), обязан тем не менее признавать ICMP-сообщение “порт не поддерживается”, используемого для аналогичной цели. Если получено ICMP-сообщение“получатель недостижим”, содержащее код “0” (сеть), “1” (ГВМ) или “5” (некорректный исходный маршрут), то оно могло стать ответом на IP-пакет, сформированный с применением процедуры изменяемой маршрутизации, и поэтому оно должно интерпретироваться только как “подсказка”, а не “доказательство” того, что указанный получатель не достижим. Например, оно не должно использоваться в качестве доказательства того, что шлюз вышел из строя. §3.2.2.2. ICMP-сообщение “перенаправление” (RFC-792) Целесообразно, чтобы ГВМ не передавала ICMP-сообщение “перенаправление”. Такие сообщения передаются только шлюзами. ГВМ, получившая ICMP-сообщение “перенаправление”, должна соответствующим образом дополнить свою маршрутную информацию. Каждая ГВМ должна быть настроена для приёма и обработки таких сообщений, причём поступивших, либо от сети, либо от другой ГВМ. ICMP-сообщение “перенаправление” должно уничтожаться “по умолчанию” если: содержащийся в нём адрес нового шлюза не совпадает с адресом присоединённой (суб)сети, из которой поступило это сообщение; источник этого сообщения не является текущим шлюзом первого ретрансляционного участка для указанного получателя. §3.2.2.3. ICMP-сообщение “источник не отвечает” (RFC-792) ГВМ может передать ICMP-сообщение “источник не отвечает” в том случае, когда она расположена “не далеко” от той логической точки, в которой принудительно уничтожаются входящие IP-пакеты в следствие нехватки памяти для сборки из них исходного “большого” IP-пакета или других ресурсов. При получении ICMP-сообщения “источник не отвечает” программный модуль сетевого (IP-)уровня должен проинформировать вышележащий транспортный уровень (или программный ICMP-модуль). Вообще-то, программные модули транспортного и прикладного уровней должны (целесообразно) иметь встроенные средства для формирования ответов на поступившие ICMP-сообщения “источник не отвечает” в рамках какого бы то ни было протокола, предусматривающего передачу последовательности IP-пакетов одному и тому же получателю, и который по каким-либо причинам может ожидать получение необходимой и достаточной информации о текущем состоянии, чтобы такая передачи была возможной. ICMP-сообщение “источник не отвечает” может формироваться ГВМ-получателем или некоторым шлюзом, расположенным на маршруте передачи IP-пакета. ГВМ, получившая ICMP-сообщение “источник не отвечает”, должна снизить свою скорость передачи в течении некоторого периода времени, и затем постепенно её увеличить. Способ передачи ответов на ICMP-сообщения “источник не отвечает” может быть реализован на транспортном уровне (например, в ТСР-протоколе, протокол с установлением соединения) или на прикладном уровне (в протоколах, которые функционируют над UDP-протоколом, дейтаграммный протокол). В стандарте RFC-1016 предложен способ, реализуемый программным модулем сетевого (IP-)уровня, который предусматривает прямое реагирование IP-уровня на поступившее ICMP-сообщение “источник не отвечает” путём управления скоростью передачи IP-пакетов. Однако, указанный способ является экспериментальным и в настоящее время не рекомендуется. §3.2.2.4. ICMP-сообщение “время просрочено” (RFC-792) Поступившее ICMP-сообщение “время просрочено” должно быть передано на транспортный уровень. Шлюз будет передавать ICMP-сообщение “время просрочено” с кодом “0” (In Transit — “В пути”) после того, как он уничтожит IP-пакет, к котором TTL-поле содержи нулевое значение. Это может произойти по двум причинам, либо маршрут оказался “петлевым”, либо было выбрано слишком малое TTL-значение. ГВМ может получить ICMP-сообщение “время просрочено” с кодом “1” (Reassembly Timeout — “восстановление Тайм-аута”) от ГВМ-получателя, которая получила и уничтожила IP-пакет с истекшим тайм-аутом. В дальнейшем получение такого сообщения может быть частью процедуры определения минимального MTU-значения (MTU-discovery), то есть для определения максимальной длины IP-пакета, который может быть передан по маршруту без фрагментации. §3.2.2.5. ICMP-сообщение “параметрическая проблема” (RFC-792) Целесообразно, чтобы каждая ГВМ была способна формировать ICMP-сообщения “параметрическая проблема”. Поступившее ICMP-сообщение “параметрическая проблема” должно быть передано на транспортный уровень, и об этом может быть сообщено пользователю. ICMP-сообщение “параметрическая проблема” передаётся ГВМ-отправителю только в том случае, когда возникшая проблема не может быть отражена с помощью какого-либо другого ICMP-сообщения. в общем, получение ICMP-сообщения “параметрическая проблема” указывает на наличие некоторой локальной или удалённой функциональной ошибки. §3.2.2.6. ICMP-сообщение “Эхо-контроль” (RFC-792) Каждая ГВМ должна иметь в своём ПО серверный программный модуль, реализующий функцию эхо-контроля, которая обеспечивает приём и соответствующую передачу ICMP-сообщений (запросов и ответов) “Эхо-контроль”. Целесообразно, чтобы в ПО ГВМ был встроен интерфейс прикладного уровня для передачи ICMP-запросов “Эхо-контроль” и приёма ICMP-ответов “Эхо-контроль” с целью функциональной диагностики. ICMP-запросы “Эхо-контроль”, переданные в широковещательном режиме или с использованием групповых IP-адресов, могут уничтожаться “по умолчанию”. Это естественное требование является результатом “яростных” дебатов между теми, кто полагает, что ICMP-запросы “Эхо-контроль”, переданные в широковещательном режиме, обеспечивают весьма полезной диагностическую функциональность, и теми, кто полагает, что злоупотребление этой функциональностью может легко сгенерировать вредоносный “шторм” (чрезмерный вредоносный трафик) IP-пакетов. IP-адрес отправителя в ICMP-ответе “Эхо-контроль” должен совпадать с IP-адресом получателя из соответствующего ICMP-запроса “Эхо-контроль”. Все данные из ICMP-запроса “Эхо-контроль” должны быть полностью включены в итоговый ICMP-ответ “Эхо-контроль”. Тем не менее, если передаваемый итоговый ICMP-ответ “Эхо-контроль” подлежит внешней фрагментации, но которая не предусмотрена на прикладном уровне, то длина IP-пакета должна быть уменьшена до максимально разрешённой для передачи. Все ICMP-ответы “Эхо-контроль” должны транслироваться на ICMP-интерфейс пользователя, если соответствующий ICMP-запрос “Эхо-контроль” не передавался программным модулем IP-уровня. Если в принятом ICMP-запросе “Эхо-контроль” имеют место дополнительные функции “Регистрация маршрута” и “Метка времени” (либо одна из них), то значения этих функций (либо одной из них) должны быть зафиксированы в ПО самой ГВМ и затем включены в IP-заголовок ICMP-ответа “Эхо-контроль” без каких-либо сокращений. Таким образом, зарегистрированный маршрут позволит определить полный циклический (“петлевой”) маршрут. Если в принятом ICMP-запросе “Эхо-контроль” имеет место дополнительная функция “Исходный маршрут”, то обратный маршрут должен дублировать исходный маршрут с точностью до наоборот и использоваться в качестве дополнительной функции “Исходный маршрут” в ICMP-ответе “Эхо-контроль”.о одный ированный маршрут позволит определить полный циклический () §3.2.2.7. ICMP-сообщение “Информация” (RFC-792) Целесообразно, чтобы ICMP-сообщения “Информация” не использовались. ICMP-сообщения “Информация” (запросы и ответы) ранее предназначались для обеспечения собственной настройки систем (например, бездисковые рабочие станции; в частности это позволяло им настраивать свои IP-адреса в период загрузки системы). Тем не менее, RARP- и BOOTP-протоколы предоставляют ГВМ более надёжные способы настройки их собственных IP-адресов. §3.2.2.8. ICMP-сообщение “Метка времени” (RFC-792) В ПО ГВМ может быть встроен программный модуль, реализующий функцию передачи и приёма ICMP-сообщений (запросов и ответов) “Метка времени”. Если такой модуль имеет место в ПО ГВМ, то должны выполняться следующие обязательные правила: каждый раз при получении ICMP-запроса “Метка времени” программный модуль должен передавать ICMP-ответ “Метка времени”. Если такая функция реализована, то целесообразно, чтобы она обеспечивала минимизацию колебаний задержки; В следующих случаях при использовании ICMP-сообщений (запросов и ответов) “Метка времени” должны выполняться правила, аналогичные правилам для ICMP-сообщений (запросов и ответов) “Эхо-контроль”, а именно: ICMP-запрос “Метка времени”, переданный в широковещательном режиме или с использованием групповых IP-адресов, может уничтожаться “по умолчанию”; IP-адрес отправителя в ICMP-ответе “Метка времени” должен полностью совпадать с IP-адресом получателя из принятого ICMP-запроса “Метка времени”; если в принятом ICMP-запросе “Метка времени” имеет место дополнительная функция “Исходный маршрут”, то обратный маршрут должен дублировать исходный маршрут с точностью до наоборот и использоваться в качестве дополнительной функции “Исходный маршрут” в ICMP-ответе “Метка времени”; Если в принятом ICMP-запросе “Метка времени” имеют место дополнительные функции “Регистрация маршрута” и “Метка времени” (либо одна из них), то значения этих функций (либо одной из них) должны быть зафиксированы в ПО самой ГВМ и затем включены в IP-заголовок ICMP-ответа “Метка времени”; все ICMP-ответы “Метка времени” должны транслироваться на ICMP-интерфейс пользователя. Наиболее предпочтительная форма для значения метки времени (так называемое стандартное значение) — это число миллисекунд с 0000 часов универсального времени. Однако, такую точность иногда весьма трудно обеспечить. Например, многие системы используют часы в качестве сигнала синхронизации электробытовое напряжение с частотой 50 или 60 Гц. Поэтому в стандартном значении времени допускаются некоторые отклонения: стандартное значение времени должно обновляться, по крайне мере, 15 раз за секунду (то есть не более шести битов значения времени могут быть не определены); точность стандартного значения времени должна приблизительно соответствовать точности системных часов ГВМ, которые настраиваются оператором. §3.2.2.9. ICMP-сообщение “Адресная маска” (RFC-950) ГВМ должна иметь возможность реализации следующих трёх способов определения адресной(ых) маски(ок), которая(ые) аналогична(ы) её IP-адресу(ам), при этом первый способ ГВМ должна реализовывать в обязательном порядке: на основе информации о статической настройке; на основе динамического получения адресной(ых) маски(ок), как побочного эффекта процедуры инициализации системы (RFC-1123); на основе передачи/приёма ICMP-сообщений (запросов и ответов) “Адресная маска”. Выбор используемого соответствующей ГВМ способа должен быть настраиваемым. При реализации третьего способа, то есть передачи/приёма ICMP-сообщений (запросов и ответов) “Адресная маска”, необходимо: в период инициализации ГВМ должна передать в широковещательном режиме ICMP-запрос “Адресная маска” в присоединённую сеть с соответствующим IP-адресом. ГВМ должна передавать этот запрос ещё несколько раз, если она сразу не получила соответствующего ICMP-ответа “Адресная маска”; до тех пор пока не получен соответствующий ICMP-ответ “Адресная маска”, целесообразно, чтобы ГВМ использовала маску соответствующего класса IP-адресов, то есть использовала маску той присоединённой сети, которая не разделена на подсети; первый полученный ICMP-ответ “Адресная маска” должен использоваться для определения адресной маски, которая соответствует конкретному локальному IP-адресу. Это справедливо, даже если первый полученный ICMP-ответ “Адресная маска” является “невостребованным”, то есть в том случае, когда он был передан в широковещательном режиме и мог поступить после приостановки ГВМ повторной передачи ICMP-запрос “Адресная маска”. После того как маска была определена на основе полученного ICMP-ответа “Адресная маска”, последующие ICMP-ответы “Адресная маска” должны игнорироваться “по умолчанию”. И наоборот, если передача/приём ICMP-сообщений (запросов и ответов) “Адресная маска” не реализован, то ГВМ не должна передавать ICMP-запросы “Адресная маска”, любые поступившие ICMP-ответы “Адресная маска” для некоторого локального IP-адреса должны игнорироваться “по умолчанию”. Целесообразно, чтобы ГВМ была способна проверить любую адресную маску, которая была в неё инсталлирована. Система не должна передавать ICMP-ответ “Адресная маска” до тех пор, пока она не станет авторизованным агентом для использования адресных масок. Авторизованным агентом может быть ГВМ или шлюз, но он должен быть однозначно настроен как агент адресной маски. Получение адресной маски с помощью ICMP-ответа “Адресная маска” не делает её получателя авторизованным и не позволяет ему выступать в роли субъекта, который распространяет ICMP-ответы “Адресная маска”. Если имеет место статически настраиваемая адресная маска, то целесообразно использовать дополнительный флаг настройки, который будет определять является ли ГВМ авторизованным агентом по распространению такой маски, то есть будет ли она отвечать на ICMP-запросы “Адресная маска” с использованием такой маски. Если ГВМ настроена как агент, то после своей инициализации она обязана передавать ICMP-ответы “Адресная маска” в широковещательном режиме через соответствующий интерфейс (при получении соответствующих запросов). ГВМ, которые непреднамеренно передают ICMP-ответы “Адресная маска” с указанием неприемлемых адресных масок, очень часто имеют “серьёзные неприятности”. Для предотвращения негативных последствий от таких событий, ICMP-ответы “Адресная маска” должны передаваться только авторизованными агентами, которые были отобраны в результате определённых административных процедур. Когда авторизованный агент получил ICMP-запрос “Адресная маска”, тогда он будет транслировать ICMP-ответ “Адресная маска” с однонаправленным IP-адресом, который будет копией IP-адреса из ICMP-запроса “Адресная маска”. Если сетевая часть IP-адреса (рис.3) является нулевой, то ICMP-ответ “Адресная маска” будет транслироваться в широковещательном режиме. Если ответ на соответствующий ICMP-запрос “Адресная маска” не поступил, то ГВМ будет “полагать”, что агент отсутствует, и будет использовать несегментированную маску, но на самом деле агент может быть только временно не достижим. Агент, каждый раз в период своей инициализации, может передавать в широковещательном режиме не запрашиваемый ICMP-ответ “Адресная маска” с целью обновления адресных масок всех ГВМ, которые к этому времени завершили процедуры своей инициализации. Рекомендуется использовать следующую “вполне очевидную” проверку адресной маски: маска не должна содержать все единичные биты, а также она недолжна быть нулевой, либо старшие 8 битов не должны быть нулевыми. |