Порядок создания СЗПДн. Требования к сетевым устройствам
 Скачать 1.38 Mb.
|
|
§1.2.1. Продолжающаяся эволюция Internet-системы Просто чудовищный рост Internet-сети вскрыл проблемы управления и масштабирования в больших сетях передачи данных с пакетной коммутацией и дейтаграммным режимом доставки. Эти проблемы продолжают исследоваться, и в результате, все происходящие изменения спецификаций представлены в данном стандарте. Такие изменения будут тщательно планироваться и контролироваться, так как существует всестороннее партнёрство и взаимопонимание в процессе планирования со стороны компаний/вендоров и организаций, отвечающих за функционирование сетей. Сегодня протоколы компьютерных сетей переживают своё совершенствование, развитие и изменение, и такая ситуация будет продолжаться в течение нескольких последующих лет. Компания/вендор, которая совершенствует ПО для установления соединений между компьютерами в рамках протоколов Internet-архитектуры (или какую-либо другую группу протоколов), и которая затем не сумеет поддерживать и обновлять такое ПО при изменении процедурной и логической характеристик протоколов, рискует оставить “за боротом несчастных потребителей”. Internet-сеть является огромной сетью передачи данных, и её пользователи находятся в постоянном контакте между собой. Опыт показал, что информация о недостатках в ПО компании/вендора очень быстро становится доступной всему техническому Internet-сообществу. §1.2.2. Принцип надёжности (живучести) Для протоколов каждого уровня Internet-архитектуры существует общее правило (принцип), выполнение которого может принести большие преимущества относительно надёжности и функциональной совместимости системы (RFC-791): “Beliberalinwhat you accept, and conservative in what yousend” (“Будьте снисходительны к тому, что вы получаете, и требовательны к тому, что вы передаёте”). ПО должно переписываться каждый раз, когда обнаруживается ошибка, и при этом не важно каким образом. Рано или поздно поступит пакет, в котором будет содержаться соответствующая комбинация ошибок и атрибутов. И до тех пор пока не будет исправлено ПО может возникнуть хаос. Вообще лучше полагать, что сеть “заполнена злопыхателями”, которые будут транслировать пакеты, способные принести максимально возможный негативный эффект. Это предположение влёчет за собой разработку приемлемой системы защиты, несмотря на то, что большинство серьёзных проблем в Internet-сети явилось следствием возникновения маловероятных событий и по причине использования непроанализированных способов и алгоритмов. Даже преступное намерение человека никогда бы не изменило выбранного курса! Адаптивность к изменениям должна быть предусмотрена в ПО ГВМ всех уровней Internet-архитектуры. В качестве простого примера рассмотрим описание протокола, которое содержит перечисление значений для соответствующего поля заголовка (например, тип поля, номер пòрта или код ошибки). Такое перечисление должно быть представлено не полным. Следовательно, если описание протокола определяет коды четырёх возможных ошибок, то прикладной (или системный) процесс, реализуемый соответствующим ПО, не должен прерываться при обнаружении кода пятой возможной ошибки. Неопределённый код может быть зарегистрирован, но он не должен стать причиной остановки (сбоя или нештатной ситуации). Вторая часть правила (принципа) тоже не менее важна: ПО в других ГВМ может содержать недостатки, которые сделают его неразумным для эксплуатации, но при этом не нарушат свойств и характеристик протокола. Такая неразумность может весьма далеко увести от необходимой прозрачности и простоты, и в результате могут где-то ещё появиться негативные последствия. Очевидный вывод — “остерегайся ГВМ, которые ведут себя дурно”. ПО ГВМ должно быть полностью проанализировано и протестировано и следовательно работоспособно, но не только для того, чтобы “выжить” среди других не корректно функционирующих ГВМ, но также и для способствования уменьшению числа нарушений в таких ГВМ, которые могут провоцировать нештатные ситуации в распределённых сетевых средствах связи. §1.2.3. Регистрация ошибок Internet-сеть включает широкий спектр систем, состоящих из различных ГВМ и шлюзов, при этом последние реализуют несколько протоколов, распределённых по уровням Internet-архитектуры, а некоторые из них содержат в ПО Internet-протоколов вредоносные закладки (“bugs”, “жучкѝ”) и компоненты. И результате сложности, разнообразия и распределённости их функционирования диагностика проблем в Internet-сети зачастую становится весьма затруднительной. Диагностика проблем будет полезной тогда, когда ПО ГВМ включает тщательно разработанное средство (программный модуль) регистрации ошибок или случаев “странного” поведения процедурной характеристики протокола. Очень важно, чтобы при регистрации ошибок хранилось достаточно большое количество диагностической информации. Соответственно, очень полезно записывать заголовок(вки) IP-пакета(ов), которые стали причиной возникновения ошибки. Однако, такое внимание к проблемам должно гарантировать, что регистрация ошибок не потребует использования чрезмерного числа ресурсов или, в противном случае, не будет “вмешиваться” в функционирование ГВМ. При записи чрезмерного числа файлов регистрации ошибок существует тенденция появления “ненормального”, но безобидного поведения процедурной характеристики протокола. Такое поведение может быть предотвращено путём использования так называемой циркулярной (“circular”) регистрации, или за счёт перенацеливания системы регистрации ошибок только на диагностику известных нештатных ситуаций. Может быть полезным использование процедуры фильтрации и подсчёта продублированных корректных сообщений. Стратегия такой процедуры, которая вполне приемлема для реализации, следующая: всегда вести учёт нештатных ситуаций и сделать такой учёт доступным с помощью протокола управления (RFC-1123); и обеспечить возможность селективной (выборочной) регистрации широко спектра событий. Например, может быть полезным реализовать “регистрацию всего” или “регистрацию всего для (в интересах) ГВМ Х”. Необходимо заметить, что различные системы управления могут реализовывать в ГВМ различные стратегии относительно числа зарегистрированных ошибок. Некоторые скажут, что “если это не вредит мне, я не желаю знать об этом”, в то время как другие пожелают быть более бдительными и занять более жёсткую позицию при обнаружении и преодолении нештатных ситуаций, возникающих в процедурной характеристике протокола. §1.2.4. Настройка Это была бы идеальная ситуация, когда совокупность встроенных в ГВМ Internet-протоколов могла бы полностью самонастраиваться. Это позволило бы записать всю совокупность протоколов в ПЗУ (ROM) или в кристалл кремния, а последнее могло бы упростить бездисковые рабочие станции, и могло бы стать “щедрым подарком” для администраторов ЛВС и продавцов систем, оставив их тем самым без работы. Но такой идеал недостижим, и фактически, к нему невозможно даже приблизиться. Во многих параграфах данного стандарта рассматривается требование, чтобы некоторый параметр мог быть дополнительно настраиваемым. Существует несколько различных причин в пользу таких требований. В отдельных случаях существует некоторая неопределенность и несогласованность относительно наилучшего значения параметра. И в этой связи возникает необходимость в последующем уточнении рекомендуемого значения параметра. В других случаях, значение параметра полностью зависит от внешних факторов (например, производительности ГВМ и распределения её внешней загрузки, или от быстродействия и топологии ближайших сетей) и самонастраивающихся алгоритмов, которые могут не приемлемыми и не эффективными. В некоторых случаях, существует необходимость изменения параметров в соответствие с административными требованиями. И в заключении, некоторые параметры должны быть обязательно настраиваемыми, в соответствие с требованиями к процедуре установления соединения с устаревшими или некорректными программными реализациями протоколов, распространяемых без указания источника, которые, к сожалению, продолжают существовать во многих частях Internet-сети. С целью обеспечения сосуществования корректных систем с такими проблемными системами администраторы очень часто должны некорректно настраивать корректные системы. Такая проблема будет решаться сама собой по мере “исчезновения” (устаревания) некорректных систем, но этот процесс не может игнорироваться компаниями/вендорами. Когда идёт речь о параметре, который должен быть настроен, это не означает требование, чтобы его значение в явной форме считывалось из файла настройки при каждой (пере)загрузке системы. Рекомендуется, чтобы разработчики устанавливали значение каждого параметра в режиме “по умолчанию”, и поэтому файл настройки необходим только при отмене значений “по умолчанию”, которые не приемлемы при соответствующей загрузке. Таким образом, требование по настройке является гарантией того, что при необходимости будет существовать возможность отмены значений “по умолчанию”, даже в случае использования двоичного кода или программы, записанной в ПЗУ. Этот стандарт требует, чтобы в отдельных случаях в режиме “по умолчанию” использовалось соответствующее значение. Выбор значения параметра в режиме “по умолчанию” является очень важной и критической проблемой, особенно в условиях, когда средство настройки параметров осуществляет согласование последних в существующих некорректных системах. Если объединение различных систем в Internet-сети происходит успешно, с точки зрения, обеспечения их полной функциональной совместимости, то значения параметров в режиме “по умолчанию”, встроенные в соответствующие внедряемые комплексы, должны быть указаны в официальных протоколах, а не в “некорректных настройках” для согласования параметров некорректных систем. Несмотря на то, что рыночные соглашения оставляют некоторым компаниям/вендорам выбрать некорректные значения параметров в режиме “по умолчанию”, данный документ категорически требует, чтобы компании/вендоры выбирали такие значения параметров в режиме “по умолчанию”, которые будут соответствовать представленным далее. И последнее, компаниям/вендорам необходимо подготовить корректную документацию о всех параметрах, их ограничениях и последствиях после их настройки. §1.3. Термины и определения В данном стандарте используются следующие технические термины и определения: Блок (segment). Под блоком понимается единица данных при сквозном ТСР-соединении. ТСР-блок состоит из ТСР-заголовка, за которым следует данные прикладного уровня. ТСР-блок транслируется в IP-пакете, путём процедуры обрамления (рис.1,в); Сообщение (message). В данном стандарте, в котором описываются протоколы нижних уровней, под сообщением понимается единица данных, которая передаётся с помощью транспортного протокола. Сообщение состоит из заголовка транспортного уровня, за которым следуют данные прикладного протокола. Для передачи по сквозному соединению через Internet-сеть, сообщение должно быть обрамлено и включено в состав IP-пакета; IP-дейтаграмма (пакет). IP-дейтаграмма — единица данных, которая доставляется по сквозному соединению с помощью IP-протокола (рис.1,б). IP-дейтаграмма состоит из IP-заголовка, за которым следуют данные UDP-протокола, то есть за IP-заголовком следует сообщение (UDP-дейтаграмма). Термин “дейтаграмма” целесообразно отождествлять с термином IP-дейтаграмма; IP-пакет. IP-пакет — единица данных, которая доставляется через канальный интерфейс (между сетевым и канальным уровнями). IP-пакет состоит из IP-заголовка и данных. IP-пакет может представлять собой целую IP-дейтаграмму или её фрагмент (рис.1,а); Кадр (frame). Кадр — единица данных, которая доставляется с помощью протокола канального уровня и включает заголовок канального уровня и следующий за ним IP-пакет (рис.1,а);  Рис.2. Понятия “кадр”, “пакет”, “дейтаграмма” и “блок” Присоединённая сеть. Сеть, по отношению к которой ГВМ имеет физический интерфейс. Такие сети именуются как ЛВС или подсети относительно ГВМ. Тем не менее, термин ЛВС и подсеть могут создать некоторую неоднозначность и поэтому в данном стандарте используется термин “Присоединённая сеть”; Многоадресная ГВМ (multihomed). ГВМ называется многоадресной, если она имеет несколько IP-адресов; Физическийинтерфейс. Это интерфейс для присоединённой сети, имеющий взаимно однозначное соответствие (возможно уникальное) с адресом канального уровня. Несколько физических интерфейсов в одной ГВМ могут соответствовать одному и тому же адресу канального уровня, но последний должен быть уникальным для различных ГВМ, которые подключены к одной и той же физической сети; Логический интерфейс. Этот интерфейс (в Интернет-литературе иногда называется “сетевой”) для логического маршрута, идентифицированного уникальным IP-адресом, для доступа в присоединённую сеть. Фактически это логическая пара из канального и физического интерфейсов; Специфический адрес получателя (specific-destinationaddress). Это наиболее эффективный адрес получателя (кратчайший с точки зрения выбранного критерия) IP-пакета, и даже в случае широковещательного или режима групповой адресации; Маршрут (path). В настоящее время, все IP-пакеты при их доставке от ГВМ-источника до ГВМ-получателя, как правило, будут ретранслироваться одной и той же группой промежуточных шлюзов. В этой связи “маршрут” представляет собой совокупность промежуточных ретрансляционных участков. Необходимо заметить, что маршрут не является однонаправленным. и нет ничего удивительного в том, что между конкретными ГВМ для каждого направления существует свой маршрут, причём эти маршруты различны; Максимально допустимый размер передаваемого сообщения (maximumtransmissionunit — MTU). Размер (длина в байтах или битах) наибольшего IP-пакета, который может быть передан. Рис.2,а,б,в иллюстрирует понятия кадр, пакет, дейтаграмма, сообщение и блок. II. КАНАЛЬНЫЙ УРОВЕНЬ §2.1. Введение Ко всем Internet-системам, и к ГВМ, и к шлюзам, предъявляются те же требования, которые предъявляются к протоколам канального уровня. Эти требования представлены в стандарте RFC-1009. Требования данного стандарта являются дополнением к требованиям стандарта RFC-1009. §2.2. Специфические проблемы §2.2.1. согласование протокола, определяющего использование “концевика” кадра В процедуре обрамления на канальном уровне может использоваться “концевик” кадра (КК, trailer), который представлен в стандарте RFC-893. Однако, его использование возможно только после обоюдного согласия систем (ГВМ или шлюз), которые допускают применение КК при сквозном соединении на канальном уровне. Если система не согласовала с противоположной стороной применение протокола, определяющего порядок использования КК, то в режиме по умолчанию применение такого протокола (то есть вставка КК) запрещается. Протокол вставки КК является способом формирования кадра канального уровня, который переупорядочивает данные пакетов сетевого уровня для их передаче в формате кадра по первичной (физической) сети связи. В некоторых случаях, КК повышают быстродействие протоколов верхних уровней за счёт снижения объёма данных, копируемых в операционной системе (ОС). Протоколы верхних уровней ничего “не знают” об использовании КК, но передающая и принимающая ГВМ обязаны “понимать” протокол вставки КК, если последний используется. Некорректное использование КК может привести к “неприятным симптомам”. Только те пакеты, которые имеют атрибуты специфического размера, могут размещаться в кадре с помощью КК, и обычно только небольшая часть пакетов, используемых в процедуре информационного обмена (ПИнО), имеют такие атрибуты. Таким образом, если система использует КК при обмене кадрами, содержащими пакеты, с системой, которая не использует КК, то некоторые пакеты просто исчезнут в “черной дыре”, в то время как другие будут успешно доставлены. В определённых типах локальных Ethernet-сетей (RFC-893) пакеты размещаются в кадрах с использованием КК, а согласование использования КК проводится в период проведения ARP-процедуры (An Ethernet Address Resolution Protocol, RFC-826) с целью определения адреса канального уровня системы-получателя. В частности, ПИнО ARP-протокола с использованием обычного типа IP-протокола завершается стандартным способом, но ГВМ, которая желает “обсудить” применение КК, будет передавать дополнительный пакет “ARP-ответ с указанием использования КК” (“trailer ARP reply”). Например, это может быть ARP-ответ с указанием типа протокола вставки КК, в противном случае это будет стандартный ARP-ответ. Если ГВМ, настроенная для обработки КК, получает от удалённой машины стандартный ARP-ответ, то она может занести эту машину в список машин, которые “не понимают” КК, например, путем простановки маркера в соответствующей ARP-записи в кэш-памяти. ГВМ, “желающие” получать кадры с КК, передают ARP-ответы с указанием использования КК, причём каждый раз, когда они завершают ПИнО ARP-протокола с использованием стандартных ARP-сообщений в интересах IP-протокола. Таким образом, ГВМ, получившая ARP-запрос для определения своего IP-адреса, могла бы передать “ARP-ответ с указанием использования КК” в дополнение к стандартному ARP-ответу. ГВМ, которая передаёт ARP-запрос для определения IP-адреса, могла бы передать ARP-ответ с указанием использования КК после того, как она получила ARP-ответ с соответствующим IP-адресом. Следовательно, и запрашивающая, и отвечающая ГВМ, участвующие в ПИнО ARP-протокола, могут указать в запросе, они готовы получать и обрабатывать кадры с КК. Рассмотренная схема, то есть передача ARP-ответов с указанием использования дополнительного КК, до отправки ARP-запроса для согласования протокола вставки КК, был разработана для предотвращения непрерывного обмена ARP-сообщениями с некорректно функционирующей ГВМ, которая вопреки процедурной характеристики какого-либо протокола или вообще здравому смыслу, отвечает на ARP-ответ с указанием использования КК другим ARP-ответом с указанием IP-адреса. Эта проблема решается путём передачи ARP-ответ с указанием использования КК в ответ на ARP-ответ с соответствующим IP-адресом, но только тогда, когда ARP-ответ с соответствующим IP-адресом отвечает на ранее не выполненный запрос. Это вполне обосновано, когда аппаратный адрес ГВМ по-прежнему остаётся неизвестен даже после получения ARP-ответ с соответствующим IP-адресом. ARP-ответ с указанием использования КК может всегда передаваться вместе с ARP-ответом с соответствующим IP-адресом при ответе на ARP-запрос для определения IP-адреса. |