UNIX: разработка сетевых приложений

Запись сообщения в сокет

95-98 Мы выводим сообщение на экран вызовом функции print_sadb_msg, после чего записываем его в сокет.

Считывание ответа

99-111 Мы считываем все сообщения из сокета до тех пор, пока не будет получено сообщение, адресованное нашему процессу (проверяется по PID) и имеющее тип SADB_ADD. Это сообщение выводится на экран функций print_sadb_msg, после чего программа завершает работу.

Пример

Мы запускаем программу, требуя от нее установки соглашения о безопасности, касающегося трафика между узлами 127.0.0.1 и 127.0.0.1 (то есть локального трафика):

 macosx % add 127.0.0.1 127.0.0.1 HMAC-SHA-1-96 160 \
   0123456789abcdef0123456789abcdef01234567
 Sending add message:
 SADB Message Add, errno 0, satype IPsec AH, seq 0, pid 6246
 SA: SPI=39030 Replay Window=0 State=Mature
 Authentication Algorithm: HMAC-SHA-1
 Encryption Algorithm: None
 Source address: 127.0.0.1/32
 Dest address: 127.0.0.1/32
 Authentication key. 160 bits: 0x0123456789abcdef0123456789abcdef01234567
 Reply returned:
 SADB Message Add, errno 0, satype IPsec AH, seq 0, pid 6246
 SA: SPI=39030 Replay Window=0 State=Mature
 Authentication Algorithm: HMAC-SHA-1
 Encryption Algorithm: None
 Source address: 127.0.0.1/32
 Dest address: 127.0.0.1/32

Обратите внимание, что в ответе системы отсутствует ключ. Дело в том; что ответ направляется на все сокеты PF_KEY, которые, однако, могут принадлежать к разным доменам, а данные о ключах не должны передаваться между доменами. После добавления записи в базу данных мы даем команду ping 127.0.0.1, чтобы проверить, задействуется ли соглашение о безопасности, после чего запрашиваем дамп базы данных и смотрим, что в ней изменилось.

 macosx % dump
 Sending dump message:
 SADB Message Dump, errno 0, satype Unspecified, seq 0, pid 6283
 Messages returned:
 SADB Message Dump, errno 0, satype IPsec AH, seq 0, pid 6283
 SA: SPI=39030 Replay Window=0 State=Mature
 Authentication Algorithm: HMAC-SHA-1
 Encryption Algorithm: None
 [unknown extension 19]
 Current lifetime:
 36 allocations. 0 bytes
 added at Thu Jun 5 21:01:31 2003, first used at Thu Jun 5 21:15:07 2003
 Source address: 127.0.0.1/128 (IP proto 255)
 Dest address: 127.0.0.1/128 (IP proto 255)
 Authentication key. 160 bits: 0x0123456789abcdef0123456789abcdef01234567

Из этого дампа видно, что ядро изменило значение протокола с 0 на 255. Это артефакт реализации, а не общее свойство сокетов PF_KEY. Кроме того, ядро изменило длину префикса с 32 на 128. Это какая-то проблема, связанная с протоколами IPv4 и IPv6. Ядро возвращает расширение (с номером 19), которое не обрабатывается нашей программой выведения дампа. Неизвестные расширения пропускаются (их длина имеется в соответствующем поле). Наконец, возвращается расширение времени жизни (листинг 19.7), содержащее информацию о текущем времени жизни соглашения о безопасности.

Листинг 19.7. Структура расширения времени жизни

 struct sadb_lifetime {
  u_int16_t sadb_lifetime_len; /* длина расширения / 8 */
  u_int16_t sadb_lifetime_exttype; /* SADB_EXT_LIFETIME_{SOFT,HARD,CURRENT} */
  u_int32_t sadb_lifetime_allocations; /* количество соединений, конечных
  точек или потоков */
  u_int64_t sadb_lifetime_bytes; /* количество байтов */
  u_int64_t sadb_lifetime_addtime; /* время создания либо время от создания
  до устаревания */
  u_int64_t sadb_lifetime_usetime; /* время первого использования или время от
  первого использования до устаревания */
 };

Расширения времени жизни бывают трех типов. Расширения SADB_LIFETIME_SOFT и SADB_LIFETIME_HARD задают гибкое и жесткое ограничения на время жизни соглашения. Сообщение SADB_EXPIRE отправляется ядром в случае превышения гибкого ограничения на время жизни. После достижения жесткого ограничения использование соглашения прекращается. Расширение SADB_LIFETIME_CURRENT возвращается в ответ на SADB_DUMP, SADB_EXPIRE и SADB_GET и описывает соответствующие параметры текущего соглашения.

19.5. Динамическое управление SA

Для повышения безопасности требуется периодическая смена ключей. Обычно для этого используется протокол типа IKE (RFC 2409 [43]).

ПРИМЕЧАНИЕ

В момент написания этой книги рабочая группа IETF по IPSec разрабатывала замену для протокола IKE.

Демон, обеспечивающий безопасность, регистрируется в ядре при помощи сообщения SADB_REGISTER, указывая в поле sadb_msg_satype(см. табл. 19.2) тип соглашения о безопасности, которое он умеет обрабатывать. Если демон может работать с несколькими типами соглашений, он должен отправить несколько сообщений SADB_REGISTER, зарегистрировав в каждом из них ровно один тип SA. В ответном сообщении SADB_REGISTER ядро указывает поддерживаемые алгоритмы шифрования или аутентификации (в отдельном расширении), а также длины ключей для этих алгоритмов. Расширение поддерживаемых алгоритмов описывается структурой sadb_supported, представленной в листинге 19.8. Структура содержит заголовок, за которым следуют описания алгоритма шифрования или аутентификации в полях sadb_alg.

Листинг 19.8. Структура, описывающая поддерживаемые алгоритмы

 struct sadb_supported {
  u_int16_t sadb_supported_len; /* длина расширения и списка алгоритмов / 8 */
  u_int16_t sadb_supported_exttype; /* SADB_EXT_SUPPORTED_{AUTH,ENCRYPT} */
  u_int32_t sadb_supported_reserved; /* зарезервировано для расширения в будущем */
 };