Форматы пакетов протоколов DPT/SRP

Существует два формата пакетов — для управляющих пакетов и для пакетов данных. Максимальный блок передачи (Maximum Transfer Unit — MTU) протокола SRP имеет размер 9216 байтов, а минимальный 55 байтов. Стандартным размером блока Cisco в настоящее время является значение 4470 байтов. Оба типа пакетов имеют одинаковый обший заголовок.

Общий формат заголовка протокола SRP версии 2

Все SRP-пакеты имеют общий 16-битовый формат заголовка, показанный на рис. 25.4.

Рис. 25.4. Общий формат заголовка протокола SRP версии 2

Этот заголовок имеет следующие поля:

•          Время существования пакета (Time to live — TTL). 8 битов. Значение этого поля уменьшается на единицу каждый раз, когда пакет проходит через какой-либо узел. Для предотвращения бесконечного движения пакета по сети при достижении полем TTL нулевого значения пакет удаляется из кольца. Для обработки ситуаций сворачивания значение TTL должно быть вдвое больше числа узлов в кольце. Поэтому максимальное количество узлов в кольце равно 256/2=128.

•          Идентификатор кольца (ring identifier — R). 1 бит. Указывает с какого кольца был отправлен пакет — с внутреннего или с внешнего. Значению 0 соответствует внешнее кольцо, а значению 1 — внутреннее кольцо.

•          Режим (Mode). 3 бита. Указывает тип пакета — управляющий пакет или пакет данных. Возможные значения приведены в табл. 25.1.

•          Приоритет (Priority, Pri). 3 бита. Значение приоритета пакета в диапазоне от 0 до 7, которое заимствуется из поля очередности при отбрасывании протокола IP. Протокол SRP имеет только два уровня приоритетов, в которые преобразуются восемь уровней очередности, используемых протоколом IP.

•          Четность (Parity). 1 бит. Значение четности, вычисляемое на основе общего заголовка протокола SRP.

Пакет данных протокола SRP

На рис. 25.5 показан формат пакета данных протокола SRP. Следует обратить внимание на то, что поле Mode (режим) в заголовке равно 0x7 (соответствует бинарному значению 111), указывая на то, что пакет является пакетом данных.

Рис. 25.5. Формат пакета данных протоком SRP версии 2

Данный формат, по сравнению с общим заголовком SRP-пакета, содержит приведенные ниже дополнительные поля:

•          МАС-адрес пункта назначения (Destination MAC-address — DA). 48 битов. Глобально уникальный МАС-адрес, устанавливаемый IEEE.

•          МАС-адрес источника (Source MAC-address — SA). 48 битов. Глобально уникальный МАС-адрес, устанавливаемый IEEE.

[1]      Тип протокола. (Protocol type). 16 битов. Следует обратить внимание на то, что значение этого поля не может быть равно 0 х 2007, поскольку это значение используется для управляющих пакетов. Возможные значения приведены в табл. 25.2.

•          Полезная нагрузка (payload). Это поле имеет переменную длину и содержит передаваемые полезные данные.

•          Контрольная сумма фрейма (Frame Check Sum — FCS). 32 бита. 32-битовая контрольная сумма CRC.

Значение             Описание

0x2007                  Управление SRP (обсуждается в последующем рвзделе)

0x0800                  Протокол IP V4

Рис. 25.6. Управляющий пакет протокола SRP версии 2

Данный формат, по сравнению с общим заголовком SRP-пакета содержит приведенные ниже дополнительные поля.

[1] МАС-адрес пункта назначения (Destination MAC-address — DA). 48 битов. Глобально уникальный МАС-адрес, устанавливаемый IEEE.

0x0806                  Протокол ARP

Управляющий пакет протокола SRP

На рис. 25.6 показан формат управляющего пакета протокола SRP. Следует отметать, что в общем заголовке полю TTL обычно задается значение, равное единице, поскольку управляющее сообщение в любом случае будет обработано следующим узлом. Поле приоритета должно быть установлено равным 7 для того, чтобы управляющие пакеты всегда имели в кольце максимальный приоритет.

•          МАС-адрес источника (Source MAC-address — SA). 48 битов. Глобально уникальный МАС-адрес, устанавливаемый IEEE.

•          Тип протокола. (Protocol type). 16 битов. Для управляющих пакетов протокола SRP это значение равно 0 х 2007.

•          Версия типа управления (Control Version). 8 битов. Номер версии для поля типа управляющего пакета. В настоящее время все типы управляющих сообщений относятся к версии 0.

•          Тип управляющего пакета (Control Туре). 8 битов. Возможные значения приведены в табл. 25.3.

•            Контрольная сумма (Control Checksum). 16 битов.

•          Контроль времени существования пакета (Control TTL). 16 битов. Это значение должно быть установлено таким же, как и TTL общего заголовка SRP, который инициатор управляющего сообщения использует для пакетов данных (т.е. как минимум вдвое большим числа узлов в кольце). TTL общего заголовка SRP по- прежнему устанавливается равным 1.

•            Полезная нагрузка (payload). Это поле имеет переменную длину.

•            Контрольная сумма фрейма (Frame Check Sum — FCS). 32 бита. 32-битовая CRC.

1 Таблица 25.3. Значения типов управляющих па^ов | Ь у                                 J

Значение                    Описание

0x00                            Зарезервировано

0x01                            Анализ топологи и

0x02                            IPS-сообщение

0x03 до OxFF            Зарезервировано

Поддержка многоадресатной рассылки

Протокол SRP непосредственно поддерживает многоадресатную рассылку пакетов протокола IP (пакетов класса D). Для многоадресатной рассылки зарезервированы МАС-адреса 00:00:5Е:хх:хх:хх. Кроме этого, младший бит в старшем байте устанавливается как бит многоадресатной рассылки, младшие 23 бита IP-адреса класса D преобразуются в оставшуюся часть МАС-адреса.

Все IP-адреса узлов, обладающих функциями многоадресатной рассылки, отображаются в DA-адреса типа 01:00:5Е:хх:хх:хх, которые используются как для отправки, так и для получения пакетов. Как уже говорилось ранее, пакет многоадресатной рассылки в конечном итоге распаковывается источником, после того как полностью пройдет все кольцо.

Резюме

Корпорация Cisco разработала протокол динамической транспортировки пакетов/эффективного использования полосы пропускания в качестве эффективной технологии, оптимизированной для передачи пакетов. Узлы подсоединены к двум кольцам оптоволоконных кабелей, имеющих противоположные направления. Оба этих кольца осуществляют передачу пакетов. Поскольку пакеты распаковываются только в

пункте назначения, а для доступа к кольцу не используется маркер, несколько узлов сети могут вести одновременную передачу по различным сегментам кольца, что позволяет увеличить доступную полосу пропускания.

Формат пакета SRP поддерживает восемь уровней приоритетов, которые копируются из битов очередности при отбрасывании протокола IP и могут быть использованы для установки внутренней очередности пакетов при передаче их узлом. В действительности интерфейсы протокола SRP имеют только два уровня очередности — очереди с низким и высоким приоритетами для передачи собственных и транзитных потоков данных. 8 уровней приоритета протокола IP преобразуются в эти два уровня очередности. Алгоритм справедливой очередности протокола SRP обеспечивает равноправный доступ к кольцу при переполнении, но при отсутствии переполнения позволяет использовать большую часть всей полосы пропускания.

Протокол DPT/SRP обладает значительной гибкостью и поддерживает технологию "plug-and-play" благодаря своей способности самовосстановления за счет сворачивания кольца при обрыве и функциям режима сквозной передачи.

Дополнительные источники

•          Белая книга: Технология и функционирование протокола динамической транспортировки пакетов (Dynamic Packet Transport Technology and Performance). Cisco Systems, 2000.

•          Белая книга: Технология эффективного использования полосы пропускания (Spatial Reuse Protocol Technology), Cisco Systems, 2000.

•          Информационный выпуск RFC 2892: The Cisco SRP MAC Layer Protocol. — August 2000.

Глоссарий

Transiting traffic. Транзитные потоки данных. Пакеты, которые узел DPT получает на своем DPT-интерфейсе и в неизмененном виде отправляет следующему DPT-узлу на кольце. Примером может служить пакет с МАС-адресом пункта назначения для станции, отличной от данного узла.

Transmitted traffic. Передаваемые потоки данных. Пакеты, для которых данный узел DPT является станцией MAC-источника. В их число входят как пакеты, генерируемые самим узлом, так и потоки данных, которые узел получает на других своих интерфейсах и пересылает с DPT-интерфейса.

Протокол расширяемой аутентификации (Extensible lAulhentication Protocol — ЕАР)

Протокол расширяемой аутентификации (Extensible Authentication Protocol — ЕАР)

[1] Бьл разработан для поддержки нескольких механизмов аутентификации. Соединения протокола "точка — точка" (Point-to-Point Protocol — РРР) обычно обсуждают прото- l кол аутентификации на стадии установки соединения протокола управления каналом | (Link Cotitrol Protocol — LCP). Такой подход требует, чтобы протокол РРР подцержи- Чвал используемый метод аутентификации.

If., Хотя для соединений,протокола РРР аутентификация на этапе установки соединения протокола LCP не требуется, конечные точки обсуждают какой протокол аутентификации будет использован для установки соединения. При этом могут быть выбраны разные варианты: без аутентификации, аутентификация по протоколу РАР или по протоколу CHAP. В протоколе ЕАР обсуждение механизма аутентификации откладывается до того момента, когда будет собрано больше информации о соединении. В последнее время возникали опасения в отношении целостности механизмов аутентификации и протокол ЕАР представляет собой попытку создать базу безопасной ра- боты этой части управления доступом к сети. Многие производители встраивают под- 1рдер4ку протокола ЕАР в приложения как клиента, так и сервера.

В настоящей главе рассматривается сам протокол ЕАР, определенный в спецификации RFC 2284. В данной главе рассматриваются некоторые его специфические черты, определенные в данной спецификации RFC, что облегчит понимание основ даннЬго протокола. В ней наряду с проблемами защиты сети описываются преимущества использования протокола ЕАР, которые в ряде случаев делают этот протокол ^столь привлекательным. Для решения этих задач защиты сети может оказаться полезной служба ^входного доступа пользователя с удаленной аутентификацией (Remote Authentication Dial-In User Service — RADIUS). В настоящей главе описывается, карм образом служба RADIUS может быть использована в качестве конечной службы поддержки аутентификации пользователя. На основе этой более полной картины процесса аутентификации в протоколе ЕАР будут рассмотрены различные ^Сетевые реализации протокола ЕАР.

Протокол ЕАР

Спецификация протокола ЕАР несложна. Процесс аутентификации состоит всего лишь из нескольких этапов. Далее будут подробно рассмотрены эти этапы и различные опции, которые доступны для клиента и аутентификатора.

Протокол ЕАР начинает свою работу, после того, как установка связи (канала) закончена. Обсуждение протокола ЕАР происходит в информационном поле пакета данных канального уровня протокола РРР. На рис. 26.1 показаны различные поля пакетов протокола ЕАР и длина каждого поля в октетах.

Рис. 26.1 Формат пакета протокола ЕАР

На рис. 26.1 показаны пять различных элементов пакета ЕАР. Первые три поля являются обязательными. В зависимости от типа посылаемого ЕАР-пакета остальные поля могут присутствовать или отсутствовать. Каждое поле обсуждается в ниже приведенном списке.

•          Код Поле кода пакета ЕАР идентифицирует тип посылаемого ЕАР-пакета. Это поле имеет длину один октет и содержит одно из четырех значений:

—                       Запрос;

—                       Ответ;

—                       Успешно;

—                       Неудачно.

•          Идентификатор. Поле идентификатора имеет длину один октет. Оно содержит номер идентификатора для данного пакета. Это поле используется для установления соответствия между пакетами запросов и пакетами ответов. Может возникнуть необходимость в том, чтобы клиент повторил запрос. При повторной передаче требуется использовать тот же самый идентификатор, как и в предыдущей попытке, с тем, чтобы аутентификатор мог различить пакеты повторной передачи и пакеты нового запроса.

•          Длина. Поле длины составляет два октета и определяет длину ЕАР-пакета. Значение поля длины равно сумме длин следующих полей ЕАР-пакета: полей кода, идентификатора, длины и данных. Все остальные данные после поля длины рассматриваются как заполнитель канального уровня протокола РРР и игнорируются протоколом ЕАР.

•          Тип. Поле "тип" ЕАР-пакета указывает тип, содержащихся в нем данных. Значение этого поля зависит от поля кода пакета. Код запроса или ответа указывает, что значение поля типа было установлено. Это поле типа имеет длину один октет. Тип "негативное подтверждение" (Negative Acknowledgment — NAK)

может быть использован только в ответном пакете для указания того, что запрошенный тип аутентификации не поддерживается. Поддержка вышеперечисленных четырех типов требуется от всех реализаций протокола ЕАР. Отметим, что если пакет представляет собой пакет с сообщением об успешности или не- удачности кода, то это поле не является обязательным. Возможными типами являются следующие:

1.    Идентичность. Аутентификатор обычно использует тип идентичности в первом пакете процесса аутентификации для запроса идентификационных данных клиента. Он представляет собой первоначальный запрос клиенту на отправку его аутентификационных данных.

2.     Уведомление. Представляет собой сообщение от аутентификатора, которое будет отображено у клиента. Оно может быть сообщением-предупреждением или сообщением об истечении срока действия пароля. Отправка такого сообщения не является обязательной, хотя реализация протокола ЕАР должна поддерживать использование таких сообщений.

3.     Негативное подтверждение (Negative Acknoledgement — NAK). Этот тип поля действителен только в ответных пакетах. Он используется в тех случаях, когда запрашивается неприемлемый тип аутентификации. Например, аутентификатор может запросить аутентификацию РАР, а клиент поддерживает только аутентификацию CHAP. В этом случае клиент отправляет негативное подтверждение NAK для того, чтобы аутентификатор запросил альтернативный тип аутентификации.

4.     Запрос MD-5. Это поле представляет собой запрос к одноранговому устройству, подобно запросу CHAP в стандартном обсуждении аутентификации протокола РРР. Это одноранговое устройство должно ответить либо другим запросом MD-5, либо негативным подтверждением NAK.

5.     Одноразовый пароль (One-Time Password—OTP). Это сообщение является запросом относительно аутентификации через систему OTP. Ответом на пакет типа OTP должно быть либо негативное подтверждение NAK, либо сообщение о типе пароля OTP.

6.     Типовая карта маркера (Generic Token Card). Этот тип определен для использования с различными реализациями карты маркера. Аутентификатор отправляет этот тип сообщения, в котором содержится запрос ввода данных пользователем.

7.     Тип-данные. Поле "тип-данные" может иметь длину 0 байтов, либо больше, в зависимости от поля типа ЕАР-пакета. Как правило, это поле в пакете запроса содержит сообщение для отображения клиенту. Если этот пакет представляет собой пакет негативного подтверждения NAK, то поле "тип- данные" содержит информацию о том, какой метод аутентификации является приемлемым. Если поле типа (Type field) представляет собой запрос MD- 5, то содержимое поля тип-данные должно соответствовать следующим полям протокола CHAP РРР: значение-размер (Value-size), значение (Value) и имя (Name) (см. спецификацию RFC [1994] для РРР CHAP). Если поле типа представляет собой запрос OTP или типовую карту маркера, то поле тип-данные содержит информацию, которую запрашивает сервер для аутентификации.

Литература:

Руководство по технологиям объединенных сетей, 4-е издание. : Пер. с англ. — М.: Издательский дом «Вильяме», 2005. — 1040 с.: ил. – Парал. тит. англ.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100