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

10  mypid = getpid();
11  /* формирование и отправка запроса SADB_REGISTER */
12  bzero(&msg, sizeof(msg));
13  msg.sadb_msg_version = PF_KEY_V2;
14  msg.sadb_msg_type = SADB_REGISTER;
15  msg.sadb_msg_satype = type;
16  msg.sadb_msg_len = sizeof(msg) / 8;
17  msg.sadb_msg_pid = mypid;
18  printf("Sending register message:\n");
19  print_sadb_msg(&msg, sizeof(msg));
20  Write(s, &msg, sizeof(msg));
21  printf("\nReply returned:\n");
22  /* Чтение и вывод ответа SADB_REGISTER, игнорирование всех прочих
       сообщений */
23  for (;;) {
24   int msglen;
25   struct sadb_msg *msgp;
26   msglen = Read(s, &buf, sizeof(buf));
27   msgp = (struct sadb_msg*)&buf;
28   if (msgp->sadb_msg_pid == mypid &&
29    msgp->sadb_msg_type == SADB_REGISTER) {
30    print_sadb_msg(msgp, msglen);
31    break;
32   }
33  }
34  close(s);
35 }
Открытие сокета PF_KEY
1-9
 Мы открываем сокет PF_KEY.
Сохранение PID
10
 Поскольку ядро будет адресовать нам свои сообщения по идентификатору процесса, нам необходимо сохранить его, чтобы иметь возможность впоследствии отбирать интересующие нас сообщения.
Создание сообщения SADB_REGISTER
11-17
 Подобно 
SADB_DUMP
, сообщение 
SADB_REGISTER
 не требует никаких расширений. Мы обнуляем сообщение, после чего заполняем интересующие нас поля структуры.
Вывод и отправка сообщения
18-20
 Мы отображаем подготовленное сообщение на экране при помощи функции 
print_sadb_msg
, после чего записываем сообщение в сокет.
Ожидание ответа
23-30
 Мы считываем сообщения из сокета, ожидая ответа на наше сообщение о регистрации. Ответ адресован по идентификатору процесса и представляет собой сообщение 
SADB_REGISTER
. Он содержит список поддерживаемых алгоритмов, который выводится нашей функцией 
print_sadb_msg
.
  
Пример
 
Мы запускаем программу 
register
 в системе, поддерживающей на несколько протоколов больше, чем описано в RFC 2367.
macosx % <b>register -t ah</b>
  
Sending register message:
SADB Message Register, errno 0, satype IPsec AH, seq 0, pid 20746
Reply returned:
SADB Message Register, errno 0, satype IPsec AH, seq 0, pid 20746
Supported authentication algorithms:
HMAC-MD5 ivlen 0 bits 128-128
HMAC-SHA-1 ivlen 0 bits 160-160
Keyed MD5 ivlen 0 bits 128-128
Keyed SHA-1 ivlen 0 bits 160-160
Null ivlen 0 bits 0-2048
SHA2-256 ivlen 0 bits 256-256
SHA2-384 ivlen 0 bits 384-384
SHA2-512 ivlen 0 bits 512-512
Supported encryption algorithms:
DES-CBC ivlen 8 bits 64-64
3DES-CBC ivlen 8 bits 192-192
Null ivlen 0 bits 0-2048
Blowfish-CBC ivlen 8 bits 40-448
CAST128-CBC ivlen 8 bits 40-128
AES ivlen 16 bits 128-256
Если ядру требуется связаться с собеседником, а соответствующая политика требует наличия соглашения о безопасности, но соглашение таковое отсутствует, ядро отправляет на зарегистрировавшиеся для данного типа соглашения сокеты управления ключами сообщение 
SADB_ACQUIRE
, в расширениях которого содержатся предлагаемые ядром алгоритмы и длины ключей. Предложение может представлять собой комбинацию поддерживаемых системой средств безопасности и политики, ограничивающей набор средств для конкретного собеседника. Алгоритмы, длины ключей и времена жизни объединяются в список в порядке предпочтительности использования. Когда демон-ключник получает сообщение 
SADB_ACQUIRE
, он выполняет действия, необходимые для выбора ключа, удовлетворяющего одной из предложенных ядром комбинаций, и устанавливает этот ключ в ядро. Для выбора SPI из нужного диапазона демон отправляет ядру сообщение 
SADB_GETSPI
. В ответ на это сообщение ядро создает соглашение о безопасности в состоянии 
SADB_SASTATE_LARVAL
. Затем демон согласовывает параметры безопасности с удаленным собеседником, используя предоставленный ядром SPI, после чего отправляет ядру сообщение 
SADB_UPDATE
 для завершения создания соглашения и перевода его в рабочее состояние (
SADB_SASTATE_MATURE
). Динамически создаваемые соглашения обычно снабжаются гибким и жестким ограничениями на время жизни. Когда истекает один из этих сроков, ядро отправляет сообщение 
SADB_EXPIRE
, в котором указывается, какое именно достигнуто ограничение. По достижении гибкого ограничения соглашение переходит в состояние 
SADB_SASTATE_DYING
, в котором оно еще может использоваться, однако процессу следует получить новое соглашение. Если же достигнуто жесткое ограничение, соглашение переходит в состояние 
SADB_SASTATE_DEAD
, в котором оно больше не может использоваться для обеспечения безопасности и должно быть удалено из базы данных.
  
19.6. Резюме
 
Сокеты управления ключами используются для взаимодействия с ядром, демонами-ключниками и другими обеспечивающими безопасность сущностями (такими как маршрутизирующие демоны). Соглашения о безопасности могут создаваться статически или динамически посредством протокола согласования ключей. Динамические ключи обычно характеризуются определенным временем жизни, по истечении которого (гибкое ограничение) демон-ключник получает соответствующее уведомление. Если соглашение не обновляется до достижения жесткого ограничения, оно становится недействительным.