Руководство по технологиям объединенных сетей Cisco (953103), страница 97
Текст из файла (страница 97)
8 уровней приоритета протокола 1Р преобразуются в эти два уровня очередности. Алгоритм справедливой очередности протокола БКР обеспечивает равноправный доступ к кольцу при переполнении, но при отсутствии переполнения позволяет использовать большую часть всей полосы пропускания. Протокол 0РТ/БКР обладает значительной гибкостью и поддерживает технологию "р!ц8-апг)-р!ау" благодаря своей способности самовосстановления за счет сворачивания кольца при обрыве и функциям режима сквозной передачи. Контрольные вопросы 1.
Чем отличается протокол 0РТ/БКР от других кольцевых технологий, таких как То)геп К!п8 и Р001? 2. Каким образом устанавливаются приоритеты пакетов в протоколе 0РТ/БКР? 3. Какой механизм используется для определения того, какое кольцо должен использовать узел для отправки пакета другому узлу? 4. Как происходит самовосстановление кольца 0РТ/БКР в случае обрыва кабеля? Дополнительные источники ° Белая книга: Технология и функционирование протокола динамической транспортировки пакетов (Оупаппс Расхег Тгапзроп Тес)гпо!ову апд Рег?оппапсе). С!зсо $узгепв, 2000.
° Белая книга: Технология эффективного использования полосы пропускания (Брава! Ксиве Ргогосо! Тесйпо1оку), С!зсо Бузгешз, 2000. ° Информационный выпуск КРС 2892: Тйе Сасо БКР МАС 1луег Ргогосо!.— Ацкцзг 2000. Глоссарий Тгала!11ак Ггайс. Транзитные потоки данных. Пакеты, которые узел 0РТ получает на своем 0РТ-интерфейсе и в неизмененном виде отправляет следующему 0РТ-узлу на кольце. Примером может служить пакет с МАС-адресом пункта назначения для станции, отличной от данного узла. Тгалаа((гей 1га(йс.
Передаваемые потоки данных. Пакеты, для которых данный узел РРТ является станцией МАС-источника. В их число входят как пакеты, генерируемые самим узлом, так и потоки данных, которые узел получает на других своих интерфейсах и пересылает с 0РТ-интерфейса. г Глава 25. Протоколы динамической транспортировки пакетов... 465 .~~)Ф ф ~'~'.-'-'.ф'ЗЬф:-: ~г~ ° Описан протокодчруззгФ ф Я'-'1~ус' ' пге* „'Ф ° Рассматриваефф:поддержка РК1 с помощьаз протокола ЕАР ° ОписываЛу6~$езопаснофть (Тгапзроп 1гауег Бесипгу — „Дф) протокола ЕАР на транснфтнф уровне ф~ ф,нж'йр~" ф ° Ра~сКатрфется защиязенный п~т4элЗгАР (ргогесгег) еАР"' РеАР) ° фивояяф~ начальныууфйЯя о различных реализациях",ЕАРг ;Ф-',ф 'р~- 4"' г;; 'Ъ, 4 .Ф фк .~'1 ° 6' :4:.
У Ф-'., 'ф '*~~ ~ „ф я гя.ф,*,.„ ф Ф" гф '~ уф Ф з44 -,' ф'.. у.:.;.1)ф4$ 4.., 'Ф=': .. ф(~ "„чл ° ° Протокол расширяемой ,- утентификации (Ех$епяЫе Ьо1Ьепбса1! оп Рго1осо! — ЕАР) 'Ф,' о) г8(„протокол'"расаирлемой аутеитификаиии (Ехгепзгые Аиг(гепггеагlоп Ргогоео! — ЕАР) 'был.разработан для поддержки нескольких механизмов аутентификации. Соединения протокола "точка — точка" (Ропп-го-Ро)п! Ргогосо! — РРР) обычно обсуждают проток кол аутентификации на стадии установки соединения протокола управления каналом ' (1)п)г Сошго! Ргогосо! — ' ! СР). Такой подход требует, чтобы протокол РРР поддерживал используемый метод аутентификации.
тл.. Хотя для соединений, протокола РРР аутентификация на этапе установки соединеКиия протокола ЕСР не требуется, конечные точки обсуждают какой протокол аутентификации будет использован для установки соединения. При этом могут быть выбраны разные варианты: без аутентификации, аутентификация по протоколу РАР или ло протоколу СНАР. В протоколе ЕАР обсуждение механизма аутентификации откладывается до того момента, когда будет собрано больше информации о соединении, В последнее время возникали опасения в отношении целостности механизмов аутентификации и протокол ЕАР прелставляет собой попытку создать базу безопасной работвгэтой части управления доступом к сети. Многие производители встраивают подФдерзЗку протокола ЕАР в приложения как клиента, так и сервера.
В настоящей главе рассматривается сам протокол ЕАР, определенный в спецификации КГС 2284. В'данной главе рассматриваются некоторые его специфические черты, определенные в'данной спецификации КГС, что облегчит понимание основ дан((ого протокола. В ней наряду с проблемами защиты сети описываются преимущества использования протокола ЕАР, которые в ряде случаев делают этот протокол ст(иЫ привлекательным. Для решения этих задач защиты сети может оказаться парь| лезпой служба;-.входного доступа пользователя с удаленной аутентификацией (Кегпоге Ацг(зепг(саг!оп 0)а(-(и (Ззег 8егисе — КА()П)8).
В настоящей главе описывается, каким образом служба КАРШ8 может быть использована в качестве конечной службы поддержки аутентификации пользователя. На основе этой более полной ка)зтины процесса аутентификации в протоколе ЕАР будут рассмотрены различные 4 сетевые реализации протокола ЕАР. Протокол ЕАР Спецификация протокола ЕАР несложна.
Пропесс аугснтификации состоит всего лишь нз нескольких этапов. Далее будут подробно рассмотрены эти этапы и различныс опции, которые доступны для клиента и аутентифнкатора. Протокол ЕАР начинает свою работу, после того, как установка связи (канала) закончена. Обсуждение протокола ЕАР происходит в информационном поле пакета данных канального уровня протокола РРР. На рис. 26.
! показаны различные поля пакетов протокола ЕАР и длина каждого поля в окгетах. 1 ! г 1 >=О Рис 26 ! Формат пакета протокола ЕАР На рис. 26.! показаны пять различных элементов пакета ЕАР. Первые три поля являются обязательными. В зависимости от типа посылаемого ЕАР-пакета остальные полн могут присутствовать или отсутствовать. Каждое поле обсуждается в ниже приведенном списке. ° Код. Поле кода пакета ЕАР идентифицирует тип посылаемого ЕАР-пакета. Это поле имеет длину один октет и содержит одно из четырех значений: — Запрос; Ответ; — Успешно; — Неудачно.
° Идентификатор. Поле идентификатора имеет длину один октет. Оно содержит номер идентификатора для данного пакета. Это поле используется для установления соответствия между пакетами запросов и пакетами ответов. Может возникнуть необходимость в том, чтобы клиент повторил запрос. При нов~орной передаче требуется использовать тот же самый идентификатор, как н в предыдущей попытке, с тем, чтобы аутентификатор мог различить пакеты повторной передачи и пакеты нового запроса.
° Длина. Поле длины составляет два окгета и определяет длину ЕАР-пакета. Значение поля длины равно сумме длин следующих полей ЕАР-пакета: полей кода, идентификатора, длины и данных. Все остальные данные после поля длины рассматриваются как заполнитель канального уровня протокола РРР и игнорируются протоколом ЕАР. ° Тип. Поле "тип" ЕАР-пакета указывает тип, содержащихся в нем данных. Значение этого поля зависит от поля кода пакета. Код запроса или ответа указывает, по значение поли типа было установлено.
Это поле типа имеет длину один октет. Тип "негативное подтверждение" (ХейаФе Ас)1поа)еййтепг — )ЧАК) 488 Часть 1зг'. Технологии мультисервисного доступа может быть использован только в ответном пакете лля указания того, что запрошенный тип аутентификации не поддерживается. Поддержка вышеперечисленных четырех типов требуется от всех реализаций протокола ЕАР. Отметим, что если пакет представляет собой пакет с сообщением об успешности или неудачности кода, то это поле не является обязательным. Возможными типами являются следующие: 1.
Идеитичиветь. Аутентификатор обычно использует тип идентичности в первом пакете процесса аутентификации лля запроса идентификационных данных клиента. Он представляет собой первоначальный запрос клиенту на отправку его аутентификационных данных. 2. Уведомление. Представляет собой сообщение от аутентификатора, которое будет отображено у клиента.
Оно может быть сообщением-предупреждением или сообщением об истечении срока действия пароля. Отправка такого сообщения не является обязательной, хотя реализация протокола ЕАР должна поддерживать использование таких сообщений. 3. Негативвве подтверждение (Хейайле Ас)ао!ефешев1 — ХАК), Этот тип поля действителен только в ответных пакетах. Он используется в тех случаях, когда запрашивается неприемлемый тип аутентификации. Например, аутентификатор может запросить аутентификацию РАР, а клиент поддерживает только аутентификацию СНАР. В этом случае клиент отправляет негативное подтверждение ХАК лля того, чтобы аутентификатор запросил альтернативный тип аутентификации.
4. Запрос М))-5. Это поле представляет собой запрос к одноранговому устройству, подобно запросу СНАР в стандартном обсуждении аутентификации протокола РРР. Это одноранговое устройство должно ответить либо дру~им запросом М0-5, либо негативным подтверждением ХАК. 5. Одноразовый пароль (Ове-Т!ше Раззмогг) — ОТР). Это сообщение является запросом относительно аутентификации через систему ОТР. Ответом на пакет типа ОТР должно быть либо негативное подтверждение ХАК, либо сообщение о типе пароля ОТР. б.
Типовая карта маркера (бепепс Тойев Сап1). Этот тип определен для использования с различными реализациями карты маркера. Аугентификатор отправляет этот тип сообщения, в котором содержится запрос ввода данных пользователем. 7. Тив-давиые. Поле "тип-данные" может иметь длину 0 байтов, либо больше, в зависимости от поля типа ЕАР-пакета. Как правило, это поле в пакете запроса содержит сообщение для отображения клиенту. Если этот пакет представляет собой пакет негативного подтверждения ХАК, то поле "типданные" содержит информацию о том, какой метод аутентификации является приемлемым. Если поле типа (Туре йе1г!) представляет собой запрос МО- 5, то содержимое поля тип-данные должно соответствовать следующим полям протокола СНАР РРР: значение-размер (Ча1ие-мхе), значение (Ча!ие) и имя (Хате) (см. спецификацию йРС [1994] для РРР СНАР).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
