TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
вернуться

Фейт Сидни М.
Шрифт:

■ использования секретных ключей (клиента и сервера), зарегистрированных на сервере безопасности Kerberos и распространяемых как ключи сеансов DES для клиентов и серверов

■ применения ключа сеанса DES для шифрования аутентификационной информации клиента и сервера

15.10 Пример сообщении RPC версии 2

На рис. 15.6 показан результат обработки монитором Sniffer компании Network General заголовка UDP и полей RPC из сообщения запроса к NFS о выводе атрибутов файла. Заголовки уровня связи данных и IP опущены, чтобы не загромождать рисунок.

UDP: -- UDP Header --

UDP:

UDP: Source port = 1023 (Sun RPC)

UDP: Destination port = 204 9

UDP: Length = 124

UDP: No checksum

UDP:

RPC: -- SUN RPC header --

RPC:

RPC: Transaction id = 641815012

RPC: Type = 0 (Call)

RPC: RPC version = 2

RPC: Program = 100003 (NFS), version = 2

RPC: Procedure = 4 (Look up file name)

RPC: Credentials: authorization flavor = 1 (Unix)

RPC: len = 32, stamp = 642455371

RPD: machine = atlantis

RPC: uid = 0, gid = 1

RPC: 1 other group id(s) :

RPC: gid 1

RPC: Verifier: authorization flavor = 0 (Null)

RPC: [Verifier: 0 byte(s) of authorization data]

RPC:

RPC: [Обычное завершение заголовка "SUN RPC".]

RPC:

NFS: -- SUM NFS --

NFS:

NFS: [Параметры для процедуры 4 (Look up file name) follow]

NFS: File handle = 0000070A00000001000A0000000091E3

NFS: 5E707D6A000A0000000044C018F294BE

NFS: File name = README

NFS:

NFS: [Обычное завершение "SUN NFS".]

NFS:

Рис. 15.6. Формат сообщения RPC с запросом к NFS

Заметим, что запрос RPC имеет тип сообщения 0. Ответ будет иметь тип 1. Протокол RPC периодически обновляется, поэтому в сообщении указывается версия RPC (в нашем случае это версия 2).

Вызывающая сторона использует мандат Unix, определяющий реальные идентификаторы пользователя и группы (userid и groupid). Имеется дополнительный идентификатор группы. Штампом служит произвольный идентификатор, созданный вызывающей стороной. Поле проверочных сведений аутентификации имеет оттенок 0 (не обеспечивает никакой дополнительной информации). NFS часто реализуется с частичной аутентификацией, поскольку более полная зашита снижает производительность.

За идентификатором программы 100003 (NFS) и процедуры 4 (просмотр имен файлов) следуют параметры: описатель файла (file handle) и имя файла.

Описатель файла — это специальный идентификатор, связанный с каталогом или файлом сервера. В версии 2 протокола RPC описатель файла представлен строкой фиксированной длины в 32 бита, в версии 3 он задается строкой переменной длины с максимальной длиной в 64 бита. В запросе указан файл README, расположенный в каталоге, идентифицированном описателем файла.

Поля в сообщении запроса кодируются по правилам форматирования XDR (см. следующий раздел).

Мы можем получить представление о работе XDR, рассмотрев некоторые шестнадцатеричные коды в сообщении запроса:

Тип сообщения = 0, кодируется (в шестнадцатеричных значениях) как:

00 00 00 00

Версия RPC = 2, кодируется как:

00 00 00 02

Машина = atlantis, кодируется как:

(длина строки =8) atlantis

00 00 00 08 61 74 6С 61 6E 74 69 73

RPC: -- SUN RPC header --

RPC:

RPC: Transaction id = 641815012

RPC: Type = 1 (Reply)

RPC: Status = 0 (Accepted)

RPC: Verifier: authorization flavor = 0 (Null)

RPC: [Verifier: 0 byte(s) of authorization data]

RPC: Accept status = 0 (Success)