RFC 4308 Cryptographic Suites for IPsec

Network Working Group                                     P. Hoffman
Request for Comments: 4308                            VPN Consortium
Category: Standards Track                              December 2005

Шифронаборы для IPsec

Cryptographic Suites for IPsec

PDF

Статус документа

В этом документе описан предлагаемый стандарт протокола для сообщества Internet; документ служит приглашением к дискуссии в целях развития протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Данный документ может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (2005).

Тезисы

Протоколы IPsec, IKE1 и IKEv2 основаны на алгоритмах защиты, обеспечивающих сохранение тайны и аутентификацию между инициатором и отвечающей стороной. Существует множество таких алгоритмов и две системы IPsec не смогут взаимодействовать между собой, если они не будут использовать одинаковые алгоритмы. Данный документ определяет дополнительные наборы алгоритмов и атрибуты, которые могут использоваться для упрощения администрирования IPsec при работе в ручном режиме обмена ключами2 с IKEv1 или IKEv2.

1. Введение

Этот документ используется совместно с IPsec [RFC24013] и двумя протоколами обмена ключами IKE [RFC2409] и IKEv2 [IKEv2]. Подобно многим другим протоколам защиты, IPsec, IKE и IKEv2 позволяют пользователям выбрать используемый криптографический алгоритм в соответствии со своими потребностями.

Опыт разработки IPsec с ручным обменом ключами и IKE показывает, что для типовых систем существует множество вариантов выбора и это затрудняет решение задачи обеспечения интероперабельности без предварительного соглашения. По этой причине рабочая группа IPsec согласилась с тем, что следует выбрать небольшое число именованных наборов, подходящих для типовых ситуаций. Эти наборы могут быть представлены в интерфейсе администратора систем IPsec. Такие наборы, часто называемые UI suite4, являются необязательными и не запрещают разработчикам предоставлять возможность выбора отдельных алгоритмов защиты.

Хотя перечисленные здесь наборы UI не являются обязательными для реализации, этот документ внесен как предложенный стандарт, поскольку разработчики называют конкретные наборы перечисленными здесь именами для подтверждения соответствия наборам, перечисленным в этом документе. Эти наборы следует рассматривать не как расширения IPsec, IKE и IKEv2, а как административные методы описания набора конфигураций.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), следует (SHOULD), не нужно (SHOULD NOT), возможно (MAY), в данном документе интерпретируются в соответствии с [RFC2119].

2. Наборы UI

В этой главе перечислены необязательные наборы, которые могут представляться системным администраторам для упрощения задачи выбора среди множества опций в системах IPsec. Эти наборы не перекрывают всех опций, которые требуется выбрать администратору. Наборы представляют собой лишь подмножества таких опций.

Отметим, что эти наборы UI представляют собой лишь значения для некоторых опций IPsec. Использование наборов UI не вносит каких-либо изменений в протоколы IPsec, IKE и IKEv2. В частности, должна использоваться подструктура преобразования в IKE и IKEv2 для задания значения каждой указанной опции независимо от использования наборов UI.

Использующим наборы UI реализациям следует также обеспечивать интерфейс управления для задания значений отдельных криптографических опций. Таким образом, маловероятно, чтобы наборы UI давали полное решение для создания политики безопасности большинства пользователей IPsec и, следовательно, весьма желательно также наличие интерфейса с более полным набором опций.

Реализациям IPsec, использующим наборы UI, следует применять для наборов имена, приведенные в этом документе. Реализациям IPsec не следует использовать для описанных здесь наборов имена, отличающиеся от приведенных ниже, и недопустимо использовать приведенные в этом документе имена для наборов, не соответствующих этому документу. Эти требования важны из соображений обеспечения интероперабельности.

Отметим, что перечисленные здесь наборы предназначены для использования IPsec в виртуальных частных сетях (VPN5). Для иных приложений IPsec могут быть определены свои наборы с другими именами.

Дополнительные наборы могут определяться в RFC. Имена, используемые для идентификации наборов UI, регистрируются в IANA.

2.1. Набор VPN-A

Этот набор соответствует наиболее распространенным на момент подготовки документа системам VPN, использующим IKEv1.

IPsec:

Протокол ESP6 [RFC2406]

Шифрование ESP TripleDES в режиме CBC [RFC2451]

Целостность ESP HMAC-SHA1-96 [RFC2404]

IKE и IKEv2:

Шифрование TripleDES в режиме CBC [RFC2451]

Псевдослучайная функция HMAC-SHA1 [RFC2104]

Целостность HMAC-SHA1-96 [RFC2404]

Группа Diffie-Hellman 1024-bit Modular Exponential (MODP) [RFC2409]

Функции Rekeying of Phase 2 (для IKE) или CREATE_CHILD_SA (для IKEv2) должны поддерживаться обеими частями этого набора. Инициатор обмена может включать новый ключ Diffie-Hellman. Если ключ включен, он должен представлять собой 1024-битовую группу MODP. Если инициатор обмена включает ключ Diffie-Hellman, отвечающая сторона должна включить ключ Diffie-Hellman и этот ключ должен быть 1024-битовой группой MODP.

2.2. Набор VPN-B

Этот набор соответствует системам VPN, которые будут наиболее массово применяться в ближайшие несколько лет после публикации этого документа.

IPsec:

Протокол ESP [RFC2406]

Шифрование ESP AES со 128-битовыми ключами в режиме CBC [AES-CBC]

Целостность ESP AES-XCBC-MAC-96 [AES-XCBC-MAC]

IKE и IKEv2:

Шифрование AES со 128-битовыми ключами в режиме CBC [AES-CBC]

Псевдослучайная функция AES-XCBC-PRF-128 [AES-XCBC-PRF-128]

Целостность AES-XCBC-MAC-96 [AES-XCBC-MAC]

Группа Diffie-Hellman 2048-bit MODP [RFC3526]

Функции Rekeying of Phase 2 (для IKE) или CREATE_CHILD_SA (для IKEv2) должны поддерживаться обеими частями этого набора. Инициатор обмена может включать новый ключ Diffie-Hellman. Если ключ включен, он должен представлять собой 2048-битовую группу MODP. Если инициатор обмена включает ключ Diffie-Hellman, отвечающая сторона должна включить ключ Diffie-Hellman и этот ключ должен быть 2048-битовой группой MODP.

2.3. Время жизни для IKEv1

IKEv1 имеет два параметра защиты, которые отсутствуют в IKEv2, а именно — время жизни ассоциаций SA7 для фазы 1 и фазы 2. Системы, использующие IKEv1 с наборами VPN-A или VPN-B, должны задавать для времени жизни SA значение 86400 секунд (1 сутки) для фазы 1 и 28800 секунд (8 часов ) для фазы 2.

3. Благодарности

Большая часть текста этого документа и идеи заимствованы из ранних версий документа IKEv2 под редакцией Charlie Kaufman. Остальной текст и идеи были включены другими членами рабочей группы IPsec.

4. Вопросы безопасности

Этот документ наследует все связанные с безопасностью аспекты документов IPsec, IKE и IKEv2.

Некоторые из указанных в наборах опций защиты в будущем могут быть сочтены существенно более слабыми, нежели считалось во время создания этого документа.

5. Согласование с IANA

Агентство IANA создало и поддерживает реестр «Cryptographic Suites for IKEv1, IKEv2, and IPsec». Этот реестр состоит из текстовых строк и номеров RFC, в которых описаны соответствующие преобразования. Новые записи добавляются в реестр лишь после публикации RFC и одобрения экспертов, назначенных IESG.

Начальными значениями реестра являются:

Идентификатор  Документ
VPN-A          RFC 4308
VPN-B          RFC 4308

6. Нормативные документы

[AES-CBC] Frankel, S., Glenn, R., and S. Kelly, «The AES-CBC Cipher Algorithm and Its Use with IPsec», RFC 3602, September 2003.

[AES-XCBC-MAC] Frankel, S. and H. Herbert, «The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec», RFC 3566, September 2003.

[AES-XCBC-PRF-128] Hoffman, P., «The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)», RFC 3664, January 2004.

[IKEv2] Kaufman, C., Ed., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2401] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 24019, November 1998.

[RFC2404] Madson, C. and R. Glenn, «The Use of HMAC-SHA-1-96 within ESP and AH», RFC 2404, November 1998.

[RFC2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 240610, November 1998.

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 240911, November 1998.

[RFC2451] Pereira, R. and R. Adams, «The ESP CBC-Mode Cipher Algorithms», RFC 2451, November 1998.

[RFC3526] Kivinen, T. and M. Kojo, «More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)», RFC 3526, May 2003.

Адрес автора

Paul Hoffman

VPN Consortium

127 Segre Place

Santa Cruz, CA 95060

USA

EMail: paul.hoffman@vpnc.org


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Internet Key Exchange — обмен ключами в Internet.

2В оригинале — manual keying mode. Прим. перев.

3Этот документ устарел и заменен RFC 4301. Прим. перев.

4User interface suite — набор пользовательских интерфейсов.

5Virtual private network.

6Encapsulating Security Payload.

7Security association.

9Этот документ устарел и заменен RFC 4301. Прим. перев.

10Этот документ устарел и заменен RFC 4303 и RFC 4305. Прим. перев.

11Этот документ устарел и заменен RFC 4306. Прим. перев.




RFC 4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)

Network Working Group                                    J. Schiller
Request for Comments: 4307     Massachusetts Institute of Technology
Category: Standards Track                              December 2005

Криптографические алгоритмы для использования с IKEv2

Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)

PDF

Статус документа

В этом документе описан предлагаемый стандарт протокола для сообщества Internet; документ служит приглашением к дискуссии в целях развития протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Данный документ может распространяться свободно.

Авторские права

Copyright (C) The Internet Society (2005).

Тезисы

Группа протоколов IPsec использует различные криптографические алгоритмы для обеспечения защиты информации. Протоколы IKE1 (RFC 2409) и IKEv2 обеспечивают механизм согласования алгоритма, который должен использоваться для данного соединения (association). Однако для обеспечения интероперабельности между независимыми реализациями необходимо задать набор обязательных для реализации алгоритмов, чтобы по крайней мере один алгоритм поддерживался всеми реализациями. В этом документе определяется набор алгоритмов, являющихся обязательными для реализации, как часть IKEv2, а также алгоритмы, которые следует реализовать потому, что они могут стать обязательными в будущем.

1. Введение

Протокол IKE обеспечивает согласование криптографических алгоритмов между конечными точками криптографической ассоциации2. Различные реализации IPsec и IKE могут поддерживать разные алгоритмы. Однако IETF желает обеспечить между всеми реализациями тот или иной вариант интероперабельности. В частности, требуется, чтобы протокол IKE определял набор обязательных для реализации алгоритмов, поскольку сам протокол IKE использует такие алгоритмы как часть процесса согласования. По этой причине некий набор алгоритмов требуется задать в качестве обязательного для реализации в IKE.

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

Наконец, следует принимать во внимание, что обязательные для реализации алгоритмы могут изменяться с течением времени для адаптации к меняющимся условиям. По этой причине выбор обязательных для реализации алгоритмов был удален из спецификации протокола IKEv2 и помещен в данный документ. При изменении набора обязательных алгоритмов требуется обновить лишь данный документ.

В идеальном варианте алгоритмы, обязательные завтра для реализации, уже доступны сегодня в большинстве реализаций IPsec. Для достижения этой цели мы попытаемся идентифицировать такие алгоритмы (известные сегодня) в этом документе. Нет никакой гарантии, что алгоритмы, которые мы предполагаем обязательными в будущем, станут таковыми на самом деле. Все алгоритмы, известные сегодня, являются объектами криптографических атак и могут быть отвергнуты в будущем.

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

В этом документе определены также дополнительные уровни требований:

SHOULD+ Этот термин обозначает то же, что и SHOULD. Однако, алгоритм, помеченный как SHOULD+, в будущем перейдет в число обязательных (MUST).

SHOULD- Этот термин обозначает то же, что и SHOULD. Однако, алгоритм, помеченный как SHOULD-, может перейти на уровень разрешенных (MAY) в будущих версиях этого документа.

MUST- Этот термин обозначает то же, что и MUST. Однако мы предполагаем, что в какой-то момент этот алгоритм перестанет быть обязательным и может перейти на уровень SHOULD или SHOULD-.

3. Выбор алгоритма

3.1. Выбор алгоритма IKEv2

3.1.1. Алгоритмы шифрования данных

Шифрование данных IKEv2 требует как алгоритма обеспечения конфиденциальности, так и алгоритма обеспечения целостности. Для обеспечения конфиденциальности реализация должна (MUST-) поддерживать 3DES-CBC и следует (SHOULD+0 также поддерживать AES-128-CBC. Для обеспечения целостности должен поддерживаться алгоритм HMAC-SHA1.

3.1.2. Группы Diffie-Hellman

Существует несколько групп MODP3, определенных для использования в IKEv2. Эти группы определены как в базовом документе [IKEv2], так и в документе, посвященном расширениям MODP. Группы идентифицируются номерами. Все группы, не указанные здесь, рассматриваются как возможные для реализации.

Номер группы Длина в битах Статус Документ

2

1024

MUST- [RFC2409]

14

2048

SHOULD+ [RFC3526]

3.1.3. Алгоритмы преобразования IKEv2 типа 1

IKEv2 определяет несколько алгоритмов для Transfer Type 1 (шифрование). Ниже эти алгоритмы перечислены с указанием статуса для каждого.

Имя Номер Документ Статус
Резерв

0

ENCR_3DES

3

[RFC2451]

MUST-

ENCR_NULL

11

[RFC2410]

MAY

ENCR_AES_CBC

12

[AES-CBC]

SHOULD+

ENCR_AES_CTR

13

[AES-CTR]

SHOULD

3.1.4. Алгоритмы преобразования IKEv2 типа 2

Алгоритмы Transfer Type 2 являются псевдослучайными функциями для генерации случайных значений.

Имя Номер Документ Статус
Резерв

0

PRF_HMAC_MD5

1

[RFC2104]

MAY

PRF_HMAC_SHA1

2

[RFC2104]

MUST

PRF_AES128_CBC

4

[AESPRF]

SHOULD+

3.1.5. Алгоритмы преобразования IKEv2 типа 3

Алгоритмы Transfer Type 3 служат для обеспечения целостности и защищают данные от подделки.

Имя Номер Документ Статус
NONE

0

AUTH_HMAC_MD5_96

1

[RFC2403]

MAY

AUTH_HMAC_SHA1_96

2

[RFC2404]

MUST

AUTH_AES_XCBC_96

5

[AES-MAC]

SHOULD+

4. Вопросы безопасности

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

Этот документ посвящен выбору криптографических алгоритмов для использования с IKEv2, а именно — выбору алгоритмов, обязательных для реализации. Алгоритмы, для которых указано MUST (необходимо) и SHOULD (следует), приняты к считаются безопасными в настоящее время и криптографические исследования позволяют надеяться на то, что они останутся безопасными в обозримом будущем. Однако это предположение может не оправдаться. Следовательно, в будущем могут появляться пересмотренные варианты этого документа, отражающие накопленный опыт.

5. Нормативные документы

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, November 1998.

[IKEv2] Kaufman, C., Ed., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC3526] Kivinen, T. and M. Kojo, «More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)», RFC 3526, May 2003.

[RFC2451] Pereira, R. and R. Adams, «The ESP CBC-Mode Cipher Algorithms», RFC 2451, November 1998.

[RFC2410] Glenn, R. and S. Kent, «The NULL Encryption Algorithm and Its Use With IPsec», RFC 2410, November 1998.

[AES-CBC] Frankel, S., Glenn, R., and S. Kelly, «The AES-CBC Cipher Algorithm and Its Use with IPsec», RFC 3602, September 2003.

[AES-CTR] Housley, R., «Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)», RFC 3686, January 2004.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

[AESPRF] Hoffman, P., «The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)», RFC 3664, January 2004.

[RFC2403] Madson, C. and R. Glenn, «The Use of HMAC-MD5-96 within ESP and AH», RFC 2403, November 1998.

[RFC2404] Madson, C. and R. Glenn, «The Use of HMAC-SHA-1-96 within ESP and AH», RFC 2404, November 1998.

[AES-MAC] Frankel, S. and H. Herbert, «The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec», RFC 3566, September 2003.

Адрес автора

Jeffrey I. Schiller

Massachusetts Institute of Technology

Room W92-190

77 Massachusetts Avenue

Cambridge, MA 02139-4307

USA

Phone: +1 (617) 253-0161

EMail: jis@mit.edu


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Internet Key Exchange – обмен ключами в Internet.

2Шифрованное соединение. Прим. перев.

3Modular Exponential – модульная экспоненциальная.




RFC 4306 Часть 2

Часть 1

3. Форматы заголовков и данных

3.1. Заголовок IKE

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                       IKE_SA Initiator's SPI                  !
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                       IKE_SA Responder's SPI                  !
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                          Message ID                           !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                            Length                             !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат заголовка IKE

Сообщения IKE используют протокол UDP через порты 500 и/или 4500, передается по одному сообщению IKE в дейтаграмме UDP. Информация от начала пакета до завершения заголовка UDP большей частью игнорируется, исключения составляют адреса IP и номера портов UDP в заголовках, которые сохраняются и используются для передачи ответных пакетов. При передаче через порт UDP 500 сообщение IKE начинается непосредственно после заголовка UDP. При передаче через порт UDP 4500 перед сообщением IKE помещается четыре октета с нулевыми значениями. Эти октеты не являются частью сообщения IKE и не учитываются в размерах и контрольных суммах IKE. Каждое сообщение IKE начинается с заголовка IKE, обозначаемого в данном документе HDR. После заголовка следует один или множество элементов данных IKE, каждый из которых идентифицируется полем Next Payload в предыдущем элементе данных. Элементы данных обрабатываются в порядке их следования в сообщении IKE путем вызова соответствующей процедуры, согласно значению поля Next Payload в заголовке IKE, потом согласно значению Next Payload в первом элементе данных IKE и так далее, пока в поле Next Payload не будет обнаружено нулевое значение, показывающее отсутствие следующего элемента данных. При обнаружении элемента данных типа Encrypted этот элемент дешифруется и результат расшифровки разбирается, как дополнительные элементы данных. Элемент Encrypted должен быть последним элементом в пакете и включать в зашифрованные элементы другие элементы типа Encrypted недопустимо.

Значение Recipient SPI в заголовке идентифицирует экземпляр защищенной связи IKE. Следовательно, один экземпляр IKE может мультиплексровать различные сессии с множеством партнеров.

Многооктетные поля, представляющие собой целые числа используют сетевой порядок байтов (или big endian — старший байт сначала).

Рисунок 4 показывает формат заголовка IKE.

  • Initiator’s SPI (8 октетов) — значение, выбранное инициатором для уникальной аутентификации защищенной связи IKE. Нулевое значение недопустимо.

  • Responder’s SPI (8 октетов) — значение, выбранное ответчиком для уникальной аутентификации защищенной связи IKE. Это значение должно быть нулевым в первом сообщении начального обмена IKE (включая повторы этого сообщения, содержащие cookie), для всех остальных сообщений нулевое значение недопустимо.

  • Next Payload (1 октет) — показывает тип элемента данных, расположенного сразу после заголовка. Форматы и значения всех типов описаны ниже.

  • Major Version (4 бита) — задает старшую часть номера версии используемого протокола IKE. Реализации на основе данной версии IKE, должны устанавливать Major Version=2. Реализации, основанные на предыдущих версиях IKE и ISAKMP, должны устанавливать Major Version=1. Основанные на этой версии протокола IKE реализации должны отвергать или игнорировать пакеты со значением этого поля, превышающим 2.

  • Minor Version (4 бита) — задает младшую часть номера версии IKE. Реализации на основе этого документа должны устанавливать Minor Version = 0 и игнорировать младшую часть номера в принимаемых сообщениях.

  • Тип обмена

    Значение

    Резерв

    0-33

    IKE_SA_INIT

    34

    IKE_AUTH

    35

    CREATE_CHILD_SA

    36

    INFORMATIONAL

    37

    Резерв IANA

    38-239

    Резерв для частного использования

    240-255

    Exchange Type (1 октет) — показывает тип обмена, который будет использоваться. Тип ограничивает набор элементов данных в каждом сообщении и порядок сообщений в обмене. Типы показаны в таблице справа.

  • Flags (1 октет) — показывает специфические опции, установленные для сообщения. Наличие опции указывается установкой соответствующего флага. Биты флагов начинаются с младшего, т. е. Бит 0 является младшим битом октета Flags. В приведенном ниже описании термин «установлен» означает значение бита 1, а термин «сброшен» — значение 0.

    • X(резерв) (биты 0-2) — эти биты должны сбрасываться при передаче и игнорироваться на приеме.

    • I(nitiator) (бит 3 поля Flags) — этот бит должен устанавливаться в сообщениях, передаваемых исходным инициатором IKE_SA, и должен сбрасываться в сообщениях, передаваемых исходным ответчиком. Этот бит позволяет получателю определить, какие восемь октетов SPI были созданы получателем.

    • V(ersion) (бит 4 поля Flags) — этот флаг показывает, что передающий узел способен поддерживать большее значение старшей части номера версии, нежели указано в поле Major Version. Реализации IKEv2 должны сбрасывать этот бит при передаче и игнорировать его во входящих сообщениях37.

    • R(esponse) (бит 5 поля Flags) — этот бит показывает, что данное сообщение является откликом на сообщение с таким же идентификатором. Этот бит должен сбрасываться во всех запросах и устанавливаться во всех откликах. Для конечной точки IKE недопустима генерация откликов на сообщения, помеченные, как отклик.

    • X(резерв) (биты 6-7) — эти биты должны сбрасываться при передаче и игнорироваться на приеме.

  • Message ID (4 октета) — идентификатор сообщения служит для управления повторной передачей потерянных пакетов и связывания запросов с откликами. Это поле важно для безопасности протокола, поскольку оно используется для предотвращения атак с повторным использованием перехваченных пакетов (replay-атаки). См. также параграфы 2.1 и 2.2.

  • Length (4 октета) — размер всего сообщения (заголовок и элементы данных) в октетах.

3.2. Базовый заголовок элемента данных

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Формат базового заголовка данных

Каждый из элементов данных (payload) IKE, определенных в параграфах 3.3 — 3.16, начинается с базового заголовка38 (Рисунок 5). Рисунки в описании каждого элемента включают базовый заголовок, но описания полей этого заголовка для краткости опущены и приводятся только в этом параграфе.

  • Тип Next Payload

    Обозначение

    Значение

    No Next Payload

    0

    Резерв

    1-32

    Security Association

    SA

    33

    Key Exchange

    KE

    34

    Identification — Initiator

    IDi

    35

    Identification — Responder

    IDr

    36

    Certificate

    CERT

    37

    Certificate Request

    CERTREQ

    38

    Authentication

    AUTH

    39

    Nonce

    Ni, Nr

    40

    Notify

    N

    41

    Delete

    D

    42

    Vendor ID

    V

    43

    Traffic Selector — Initiator

    TSi

    44

    Traffic Selector — Responder

    TSr

    45

    Encrypted

    E

    46

    Configuration

    CP

    47

    Extensible Authentication

    EAP

    48

    Резерв IANA

    49-127

    Для частного применения

    128-255

    Next Payload (1 октет) — идентификатор типа следующего элемента данных в сообщении. Если текущий элемент является последним, это поле имеет значение 0. Это поле позволяет создавать «цепочки», когда дополнительный элемент просто добавляется в конец сообщения и устанавливается значение поля Next Payload в предыдущем элементе для индикации типа нового элемента. Элемент типа Encrypted, который всегда должен быть последним в сообщении, является исключением. Он содержит структуры данных в формате дополнительных элементов. В заголовке элемента Encrypted поле Next Payload устанавливается в соответствии с типом первого вложенного элемента (вместо 0).

    Значения Payload Type показаны в таблице справа.

    Значения типов 1-32 не следует использовать во избежание перекрытия со значениями, применяемыми в IKEv1. Типы 49-127 зарезервированы IANA для будущего распределения в IKEv2 (см. параграф 6). Типы 128-255 выделены для частного применения по согласованию сторон.

  • Critical (1 бит) — это поле должно иметь значение 0, если отправитель хочет, чтобы получатель пропустил этот элемент, если он не понимает код в поле Next Payload предыдущего элемента. Если получатель понимает тип элемента, он должен игнорировать этот флаг. Это поле должно устанавливаться в 0 для определенных в документе типов элементов данных. Отметим, что флаг критичности относится к текущему элементу данных, а не к следующему, чей тип указывается в первом октете. Причина сбрасывания бита критичности для определенных здесь элементов заключается в том, что все реализации должны поддерживать все типы элементов, определенные в этой спецификации, и, следовательно, должны игнорировать значение флага Critical. Предполагается, что пропускаемые элементы будут иметь корректные значения полей Next Payload и Payload Length.

  • RESERVED (7 битов) — должно иметь нулевое значение при передаче и игнорироваться на приеме.

  • Payload Length (2 октета) — размер текущего элемента данных в октетах с учетом базового заголовка.

3.3. Элементы данных SA

Данные защищенной связи39, обозначаемые в этом документе SA, служат для согласования атрибутов защищенной связи. Сборка элементов данных SA требует внимания. Элемент SA может включать множество предложений. Если предложений больше одного, они должны быть упорядочены в порядке снижения предпочтительности. Каждое предложение может включать множество протоколов IPsec (протоколами являются IKE, ESP, AH), каждый протокол может включать множество преобразований, а каждое преобразование может включать множество атрибутов. При разборе SA реализация должна проверить соответствие значения Payload Length размерам и числу отдельных компонент. Предложения (Proposal), преобразования (Transform) и атрибуты (Attribute) используют свое представление с различными размерами. Они вкладываются в элемент так, чтобы значение поля Payload Length элемента SA учитывало данные SA, Proposal, Transform и Attribute. Размер Proposal включает размер всех содержащихся в нем Transform и Attribute. Размер Transform включает размеры всех содержащихся в нем Attribute.

Синтаксис элементов SA, Proposal, Transform и Attribute основан на ISAKMP, однако семантика их слегка отличается. Причина использования иерархической структуры заключается в том, что такая структура позволяет представлять в одной SA множество возможных комбинаций алгоритмов. Иногда предоставляется выбор из множества алгоритмов, в других случаях — комбинация алгоритмов. Например, инициатор может предложить использование комбинации (AH w/MD5 И ESP w/3DES) ИЛИ (ESP w/MD5 И 3DES).

Одной из причин изменения семантики элементов SA по сравнению с ISAKMP и IKEv1 является повышение уровня компактности представления в наиболее распространенных случаях.

Структура Proposal включает Proposal # (номер предложения) и идентификатор протокола IPsec. Каждая структура должна использовать значение Proposal #, совпадающее со значением в предыдущей структуре или увеличенное на 1. Первый элемент Proposal должен иметь Proposal # = 1. Если две структуры подряд имеют одинаковый номер предложения, это значит, что предложение включает первую И вторую структуры40. Так, для предложения AH И ESP будут использоваться две структуры (одна для AH, другая для ESP) с одинаковым номером Proposal #1. Для предложения AH ИЛИ ESP будут использоваться две структуры — для AH с номером Proposal #1 и для ESP с номером Proposal #2.

За каждой структурой Proposal/Protocol следует одна или множество структур преобразований. Число разных преобразований обычно определяется элементом Protocol. Протокол AH обычно имеет одно преобразование — алгоритм контроля целостности. ESP обычно имеет два преобразования — алгоритм шифрования и алгоритм контроля целостности. IKE в общем случае имеет четыре преобразования — группа Diffie-Hellman, алгоритм контроля целостности, алгоритм prf и алгоритм шифрования. Если предлагаются комбинированные алгоритмы шифрования и защиты целостности, он должен предлагаться, как алгоритм шифрования, а предлагать в таком случае алгоритм защиты целостности недопустимо. Для каждого протокола набору допустимых преобразования присваиваются идентификаторы, включаемые в заголовок каждого преобразования.

Если имеется множество преобразований одного типа (одно значение Transform Type), они должны комбинироваться в одно предложение с помощью операции ИЛИ41. При наличии множества преобразований различных типов, группы объединяются операцией И. Например, чтобы предложить ESP с (3DES или IDEA) и (HMAC_MD5 или HMAC_SHA), предложение ESP будет включать два кандидата Transform Type 1 (один для 3DES, второй для IDEA) и два кандидата Transform Type 342 (для HMAC_MD5 и HMAC_SHA). Это обеспечивает эффективное предложение четырех комбинаций алгоритмов. Если инициатор хочет предложить только подмножество этого — например, (3DES и HMAC_MD5) или (IDEA и HMAC_SHA), — не существует возможности представить это в виде множества преобразований в одном предложении. Взамен инициатор будет создавать два разных предложения по паре преобразований в каждом.

Преобразование может иметь один или множество атрибутов (Attribute). Атрибуты требуются, когда преобразование может использоваться множеством способов (например, алгоритм шифрования с переменным размером ключей — в этом случае преобразование будет задавать алгоритм, а атрибут — размер ключа). Большинство преобразований не имеет атрибутов. Для преобразования недопустимо наличие множества однотипных атрибутов. Чтобы предложить варианты значения для атрибута (например, множество размеров ключа для алгоритма шифрования AES), реализация должна включать множество преобразований с общим значением Transform Type, каждое из которых имеет один атрибут (Attribute).

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                          <Proposals>                          ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Элемент данных SA

Отметим, что семантика Transform и Attribute достаточно сильно отличается от IKEv1. В IKEv1 одно преобразование задает множество алгоритмов для протокола и один из них передается в Transform, а другие в Attribute.

  • Proposals (переменный размер) — одна или множество субструктур Proposal.

    Идентификатор типа для элемента SA имеет значение 33.

3.3.1. Субструктура Proposal

  •                      1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! 0 (last) or 2 !    Резерв     !         Proposal Length       !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Proposal #    !  Protocol ID  !    SPI Size   !# of Transforms!
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                        SPI (переменный)                       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                                                               !
    ~                        <Transforms>                           ~
    !                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Рисунок 7. Субструктура Proposal

    0 (последнее) или 2 (не последнее) (1 октет) — показывает, является ли предложение последним в субструктуре предложений элемента SA. Синтаксис унаследован от ISAKMP, не это поле не является необходимым, поскольку последнее предложение можно идентифицировать по размеру SA. Значение 2 соответствует типу элемента Proposal в IKEv1 и первые четыре октета структуры Proposal организованы так, чтобы они выглядели, подобно заголовку Payload.

  • Резерв (1 октет) — должно устанавливаться в 0 при передаче и игнорироваться на приеме.

  • Proposal Length (2 октета) — размер данного предложения, включая все входящие в него преобразования и атрибуты.

  • Proposal # (1 октет) — номер предложения. Первое предложение в элементе SA должно иметь номер 1, а номера последующих должны совпадать с номером предшественника (И — пересечение двух предложений) или быть на 1 больше (ИЛИ — объединение двух предложений). Когда предложение принимается, все номера предложений в элементе SA должны совпадать и соответствовать номеру переданного предложения, которое было принято.

  • Протокол

    Protocol ID

    Резерв

    0

    IKE

    1

    AH

    2

    ESP

    4

    Резерв IANA

    4 — 200

    Частное применение

    201 — 255

    Protocol ID (1 октет) — задает идентификатор протокола IPsec для текущего согласования. Определенные значения идентификаторов показаны в таблице справа.

  • SPI Size (1 октет) — для начального согласования IKE_SA это поле должно иметь нулевое значение; значение SPI получается из внешнего заголовка. При последующих согласованиях это поле показывает размер (в октетах) SPI для соответствующего протокола (8 для IKE, 4 для ESP и AH).

  • # of Transforms (1 октет) — показывает число преобразований в данном предложении.

  • SPI (переменный размер) — SPI передающей стороны. Даже если значение SPI Size не кратно 4, для элементов данных не используется заполнения. При нулевом значении SPI Size это поле не включается в элемент SA.

  • Transforms (переменный размер) — одна или множество субструктур Transform.

3.3.2. Субструктура Transform

  •                      1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! 0 (last) or 3 !    Резерв     !        Transform Length       !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !Transform Type !    Резерв     !          Transform ID         !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                                                               !
    ~                      Transform Attributes                     ~
    !                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Рисунок 8. Субструктура Transform

    0 (последнее) или 3 (не последнее) (1 октет) — показывает, является ли это преобразование последним в предложении. Синтаксис унаследован от ISAKMP, не это поле не является необходимым, поскольку последнее предложение можно идентифицировать по размеру Proposal43. Значение 2 соответствует типу элемента Transform в IKEv1 и первые четыре октета структуры организованы так, чтобы они выглядели, подобно заголовку Payload.

  • Резерв (1 октет) — должно устанавливаться в 0 при передаче и игнорироваться на приеме.

  • Transform Length — размер субструктуры Transform (в октетах) с учетом заголовка и атрибутов.

  • Transform Type (1 октет) — показывает тип преобразования, задаваемого этим элементом. Различные протоколы поддерживают разные типы преобразований. Для некоторых протоколов часть преобразований может быть опциональной. Если преобразование является необязательным и инициатор предлагает его пропустить, преобразования этого типа не включаются в предложение. Если инициатор желает отдать решение вопроса об использовании необязательного преобразования ответчику, он включает субструктуру этого преобразования с нулевым идентификатором (Transform ID = 0) в качестве одной из опций.

  • Transform ID (2 октета) — указывает конкретный экземпляр предлагаемого преобразования.

Типы преобразований перечислены ниже в таблице.

Тип преобразования

Используется

Резерв

0

Encryption Algorithm (ENCR) — алгоритм шифрования

1

IKE и ESP

Pseudo-random Function (PRF) — псевдослучайная функция

2

IKE

Integrity Algorithm (INTEG) — алгоритм защиты целостности

3

IKE, AH, опционально в ESP

Diffie-Hellman Group (D-H) — группа Diffie-Hellman

4

IKE, опционально в AH и ESP

Extended Sequence Numbers (ESN) — расширенные порядковые номера

5

AH и ESP

Резерв IANA

6 — 240

Частное применение

241-255

Для преобразований типа 1 (Transform Type 1 — алгоритм шифрования) определены следующие идентификаторы (Transform ID):

Имя

Значение

Определение

Резерв

0

ENCR_DES_IV64

1

RFC1827

ENCR_DES

2

RFC2405, [DES]

ENCR_3DES

3

RFC2451

ENCR_RC5

4

RFC2451

ENCR_IDEA

5

RFC2451, [IDEA]

ENCR_CAST

6

RFC2451

ENCR_BLOWFISH

7

RFC2451

ENCR_3IDEA

8

RFC2451

ENCR_DES_IV32

9

Резерв

10

ENCR_NULL

11

RFC2410

ENCR_AES_CBC

12

RFC3602

ENCR_AES_CTR

13

RFC3664

Резерв IANA

14 — 1023

Резерв для частного использования по соглашению сторон

1024-65535

Для преобразований типа 2 (псевдослучайная функция) определены идентификаторы:

Имя

Значение

Определение

Резерв

0

PRF_HMAC_MD5

1

RFC2104, [MD5]

PRF_HMAC_SHA1

2

RFC2104, [SHA]

PRF_HMAC_TIGER

3

RFC2104

PRF_AES128_XCBC

4

RFC3664

Резерв IANA

5 — 1023

Резерв для частного использования по соглашению сторон

1024-65535

Для преобразований типа 3 (алгоритм защиты целостности) определены идентификаторы:

Имя

Значение

Определение

NONE

0

AUTH_HMAC_MD5_96

1

RFC2403

AUTH_HMAC_SHA1_96

2

RFC2404

AUTH_DES_MAC

3

AUTH_KPDK_MD5

4

RFC182844

AUTH_AES_XCBC_96

5

RFC3566

Резерв IANA

5 — 1023

Резерв для частного использования по соглашению сторон

1024-65535

Для преобразований типа 4 (группа Diffie-Hellman) определены идентификаторы:

Имя

Значение

NONE

0

Определены в Приложении B

1 — 2

Резерв

3 — 4

Определены в [ADDGROUP]

5

Резерв IANA

6 — 13

Определены в [ADDGROUP]

14 — 18

Резерв IANA

19 — 1023

Частное применение

1024-65535

Для преобразований типа 5 (расширенные порядковые номера) определены идентификаторы:

Имя

Значение

No Extended Sequence Numbers — нет расширенных номеров

0

Extended Sequence Numbers — расширенные номера

1

Резерв

2 — 65535

3.3.3. Приемлемые типы преобразований по протоколам

Протокол

Обязательные типы

Опциональные типы

IKE

ENCR, PRF, INTEG, D-H

ESP

ENCR, ESN

INTEG, D-H

AH

INTEG, ESN

D-H

Число и тип преобразований в элементах SA зависит от типа протокола в самой SA. Элемент данных SA, предлагающий организацию SA имеет обязательные и опциональные типы преобразований. Совместимая с требованиями реализация должна понимать все обязательные и дополнительные типы для каждого поддерживаемого ею протокола (хотя принимать предложения с неподходящими наборами не требуется). Предложение может опускать необязательные типы, если единственным воспринимаемым значением этого типа является NONE.

3.3.4. Обязательные Transform ID

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

Важным результатом использования IKEv1 является понимание того, что системам не следует реализовать только обязательные алгоритмы и ждать, что они явятся лучшим выбором для всех пользователей. Например, во время подготовки этого документа многие разработчики IKEv1 начали переход на AES в режиме CBC45 для приложений VPN46. Многие системы IPsec на базе IKEv2 будут поддерживать AES, дополнительные группы Diffie-Hellman и дополнительные алгоритмы хэширования, а некоторым пользователям IPsec уже требуются эти алгоритмы в дополнение к перечисленным выше.

Очевидно, что IANA будет добавлять новые преобразования, а некоторые пользователи могут применять приватные шифронаборы, особенно для IKE, где разработчикам следует обеспечивать поддержку различных параметров, вплоть до некоторых ограничений размера. В поддержку этой идеи всем реализациям IKEv2 следует включать средства управления, которые позволяют (пользователю или системному администратору) задавать параметры Diffie-Hellman (генератор, модуль, размер и значения экспоненты) для новых групп DH. Разработчикам следует поддерживать интерфейс управления, через который могут задаваться эти параметры и связанные с ними Transform ID (пользователем или системным администратором) для обеспечения возможности согласования таких групп.

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

3.3.5. Атрибуты преобразования

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A!       Attribute Type        !    AF=0  Attribute Length     !
!F!                             !    AF=1  Attribute Value      !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                   AF=0  Attribute Value                       !
!                   AF=1  Not Transmitted                       !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 9. Атрибуты преобразования

Каждое преобразование в элементе SA может включать атрибуты, меняющие или дополняющие спецификацию преобразования. Эти атрибуты представляют собой пары «тип-значение» и определены ниже. Например, если алгоритм шифрования имеет ключи переменного размера, этот размер может задаваться в качестве атрибута. Атрибуты могут иметь значение фиксированного (2 октета) или переменного размера. В последнем случае для представления атрибута используется формат «тип-размер-значение».

  • Attribute Type (2 октета) — уникальный идентификатор для каждого типа атрибутов (см. ниже).

    Старший бит этого поля является флагом формата атрибута (AF47), показывающим использование полного (TLV48) или сокращенного (TV49) формата. При AF = 0, для атрибута используется формат TLV, при AF = 1 — TV.

  • Attribute Length (2 октета) — размер поля Attribute Value в октетах. При AF = 1, размер Attribute Value всегда составляет 2 октета и поле Attribute Length отсутствует.

  • Attribute Value (переменный размер) — значение атрибута, связанное с Attribute Type. Если AF = 0, размер этого поля указывается в поле Attribute Length. При AF = 1 размер поля Attribute Value всегда равен 2 октетам.

Отметим, что в настоящее время определен только один тип атрибута — размер ключа (Key Length) и для него используется фиксированный размер. Спецификации атрибутов переменной длины включены только для будущих расширений. Из определенных в этом документе алгоритмов атрибуты принимают только основанные на AES функции шифрования, защиты целостности и генерации случайных чисел — им нужен один атрибут, задающий размер ключа.

Атрибуты, описанные в качестве базовых, недопустимо представлять с использованием переменного размера. Атрибуты переменного размера недопустимо представлять в качестве базовых, даже если их значение может быть помещено в два октета. Это отличается от IKEv1 в том, что повышается гибкость и упрощается создание сообщений, но несколько усложняется их разбор.

Тип

Значение

Формат

Резерв

0-13

Key Length (в битах)

14

TV

Резерв

15-17

Резерв IANA

18-16383

Для частного применения

16384-32767

Значения 0-13 и 15-17 использовались в аналогичном контексте IKEv1 и их не следует выделять во избежание конфликтов. Значения 18-16383 зарезервированы для IANA. Диапазон 16384-32767 выделен для частного применения по согласованию сторон.

Key Length — размер ключа

При использовании алгоритма шифрования с ключами переменного размера этот атрибут показывает размер ключа в битах (должен использоваться сетевой порядок байтов). Этот атрибут недопустимо использовать с алгоритмами шифрования, имеющими фиксированный размер ключа.

3.3.6. Согласование атрибутов

При согласовании защищенной связи инициаторы вносит свои предложения ответчикам. Ответчики должны выбрать из предложений один полный набор параметров (или отвергнуть все предложения, если они не подходят). Если имеется множество предложений, ответчик должен выбрать номер одного из них и вернуть инициатору все субструктуры Proposal с этим номером предложения. Если имеется множество однотипных преобразований, ответчик должен выбрать одно из них. Все атрибуты выбранного преобразования должны возвращаться в неизменном виде. Инициатор обмена должен убедиться в том, что принятое предложение согласуется со сделанными им предложениями. При наличии расхождений отклик должен быть отвергнут.

Согласование групп Diffie-Hellman имеет некоторые особенности. SA включает предлагаемые атрибуты и открытое значение Diffie-Hellman (KE50) в одном сообщении. Если в начальном обмене инициатор предлагает использовать одну из нескольких групп Diffie-Hellman, ему следует выбрать ту, которую ответчик с высокой вероятностью примет, и включить соответствующее этой группе значение KE. Если предсказание окажется неверным, ответчик укажет в отклике корректную группу и инициатору следует найти для своего KE элемент в этой группе при повторе сообщения. Однако ему следует по-прежнему предлагать полный набор поддерживаемых групп, чтобы предотвратить возможность организации атак, направленных на снижение уровня защиты.

Примечание для разработчиков. Некоторые согласуемые атрибуты могут включать диапазоны, со множеством подходящих значений (например, размеры ключа переменной длины для симметричного шифра). Для повышения уровня интероперабельности и обеспечения возможности независимого обновления конечных точек разработчикам реализаций этого протокола следует принимать значения, которые они считают обеспечивающими лучшую защиту. Например, если партнер настроен на принятие шифра с переменным размером ключа для размера X (битов) и предлагается более длинный ключ, реализации следует принять такое предложение, если она может работать с более длинным ключом.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!          DH Group #           !            Резерв             !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       Key Exchange Data                       ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 10. Формат элемента Key Exchange

Поддержка такой возможности позволяет реализации выражать концепции защиты не ниже определенного уровня — «ключ размером не менее X битов для шифра Y».

3.4. Обмен ключами

Элемент данных Key Exchange (KE) служит для обмена открытыми номерами Diffie-Hellman при обмене ключами Diffie-Hellman. Элемент KE включает базовый заголовок IKE, за которым следует открытое значение Diffie-Hellman.

Элемент данных обмена ключами создается путем копирования открытого значения Diffie-Hellman в поле Key Exchange Data. Размер открытого значения Diffie-Hellman должен быть равен размеру первичного модуля, для которого выполняется возведение в степень, дополненного при необходимости нулями в начале.

Поле DH Group # идентифицирует группу Diffie-Hellman в которой было рассчитано значение Key Exchange Data (см. параграф 3.3.2). Если выбранное предложение использует другую группу Diffie-Hellman, сообщение должно быть отвергнуто с возвратом элемента Notify типа INVALID_KE_PAYLOAD.

Тип элемента для обмена ключами KE имеет значение 34.

3.5. Идентификация

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!   ID Type     !                  Резерв                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                   Identification Data                         ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 11. Формат идентификации

Элемент данных Identification (ID), обозначаемый в этом документе IDi и IDr, позволяет партнерам предъявлять свою идентификацию другой стороне. Эта идентификация может использоваться при просмотре политики, но не обязана соответствовать информации в элементе CERT — оба эти поля могут использоваться реализацией для контроля доступа.

Примечание. В IKEv1 использовались два элемента ID в каждом направлении для данных селекторов трафика (TS) для данных, передаваемого через SA. В IKEv2 эта информация передается в элементах TS (см. параграф 3.13).

  • ID Type (1 октет) — задает тип используемой идентификации.

  • Резервдолжно обнуляться при передаче и игнорироваться на приеме.

  • Identification Data (переменный размер) — значение, указанное полем Identification Type. Размер данных идентификации рассчитывается по размеру в заголовке элемента ID.

Тип элемента для Identification может принимать значение 35 (Idi) и 36 (IDr).

В таблице приведен список выделенных значений поля ID Type с описанием соответствующего поля Identification Data.

ID Type

Значение

Описание Identification Data

Резерв

0

ID_IPV4_ADDR

1

Один четырехоктетный адрес IPv4.

ID_FQDN

2

Строка полного доменного имени (например, example.com). В строку недопустимо включать символы завершения (NULL, CR и т. п.).

ID_RFC822_ADDR

3

Строка полного почтового адреса RFC822 (например, jsmith@example.com). В строку недопустимо включать символы завершения.

Резерв IANA

4

ID_IPV6_ADDR

5

Один шестнадцатиоктетный адрес IPv6.

Резерв IANA

6-8

ID_DER_ASN1_DN

9

Двоичное представление в формате DER51 для ASN.1 X.500 Distinguished Name [X.501].

ID_DER_ASN1_GN

10

Двоичное представление в формате DER для ASN.1 X.500 GeneralName [X.509].

ID_KEY_ID

11

Неструктурированный поток октетов, который может использоваться для передачи связанной с производителем информации, требуемой для некоторых фирменных вариантов идентификации.

Резерв IANA

12-200

Резерв для частного использования

201-255

Две реализации будут совместимы только в том случае, когда каждая может генерировать тип ID, приемлемый для другой стороны. Для обеспечения максимальной совместимости реализация должна быть настраиваемой на передачу по крайней мере одного из типов ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_KEY_ID и восприятие всех этих типов. Реализациям следует обеспечивать возможность генерации и восприятия всех этих типов. Поддерживающие IPv6 реализации должны дополнительно иметь возможность настройки восприятия ID_IPV6_ADDR. Реализации, поддерживающие только IPv6, можно настраивать на передачу только ID_IPV6_ADDR.

3.6. Сертификат

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding !                                               !
+-+-+-+-+-+-+-+-+                                               !
~                       Certificate Data                        ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 12: Формат сертификата

Элемент данных Certificate (CERT) обеспечивает способ передачи сертификатов или других, связанных с аутентификацией данных через IKE. Элементы Certificate следует включать в обмен, если сертификаты доступны отправителю до того, как партнер указал возможность получения аутентификационной информации иным путем с использованием элемента Notify типа HTTP_CERT_LOOKUP_SUPPORTED. Отметим, что термин «Certificate Payload» может вводить в заблуждение, поскольку не все механизмы аутентификации используют сертификаты и в этом элементе могут передаваться иные данные.

Кодирование сертификата

Значение

Резерв

0

Сертификат X.509 с PKCS #7

1

Сертификат PGP

2

Подписанный ключ DNS

3

Сертификат X.509 — подпись

4

Маркер Kerberos

6

CRL

7

ARL

8

Сертификат SPKI

9

СертификатX.509 — атрибут

10

Неразобранный ключ RSA

11

Хэш и URL сертификата X.509

12

Хэш и URL связки (bundle) X.509

13

Резерв IANA

14 — 200

Для частного применения

201 — 255

Элемент данных Certificate имеет следующие поля:

  • Certificate Encoding (1 октет) — это поле показывает тип представления сертификата или иной информации, содержащейся в поле Certificate Data (см. таблицу на врезке справа).

  • Certificate Data (переменный размер) — представление данных сертификата. Тип сертификата указывается в поле Certificate Encoding.

Идентификатор типа элемента данных Certificate имеет значение 37.

Конкретный синтаксис ряда перечисленных типов сертификатов в этом документе не определяется. К числу сертификатов, синтаксис которых определен здесь относятся:

Сертификат X.509 — подпись (4) содержит сертификат X.509 (в представлении DER), открытый ключ которого используется для проверки элемента данных AUTH отправителя.

Список отозванных сертификатов (7) содержит представление DER для списка отозванных сертификатов X.509.

Неразобранный ключ RSA (11) содержит ключ RSA в представлении PKCS #1 (см. [RSA] и [PKCS1]).

Хэш и URL52 (12-13) позволяют включать в сообщения IKE замену больших структур данных с 20-октетным хэшем SHA-1 (см.[SHA]) значением URL переменной длины, которое преобразуется в структуру данных (в представлении DER). Это повышает эффективность в тех случаях, когда конечные точки имеют хэшированные сертификаты и снижает эффект воздействия на IKE атак на отказ служб, которые становились бы проще в реализации при использовании достаточно больших сообщений IKE, требующих фрагментации на уровне IP [KPS03].

Ниже приведено представление сборки X.509 в формате ASN.1.

CertBundle
  { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5)
    pkix(7) id-mod(0) id-mod-cert-bundle(34) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
  Certificate, CertificateList
  FROM PKIX1Explicit88
     { iso(1) identified-organization(3) dod(6) internet(1) security(5)
       mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } ;

CertificateOrCRL ::= CHOICE {
  cert [0] Certificate,
  crl  [1] CertificateList }

CertificateBundle ::= SEQUENCE OF CertificateOrCRL

END

Реализации должны обеспечивать возможность настройки передачи и восприятия до четырех сертификатов X.509 в поддержку аутентификации, а также должны обеспечивать возможность настройки передачи и восприятия двух первых форматов Hash and URL (с HTTP URL). Реализациям следует обеспечивать возможность настройки передачи и восприятия ключей Raw RSA. При передаче множества сертификатов первый из них должен содержать открытый ключ, используемый для подписывания элемента AUTH. Остальные сертификаты можно передавать в любом порядке.

3.7. Запрос сертификата

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding !                                               !
+-+-+-+-+-+-+-+-+                                               !
~                    Certification Authority                    ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 13. Формат запроса сертификата

Элемент Certificate Request (CERTREQ) обеспечивает возможность запросить предпочитаемые сертификаты через IKE и может появляться в откликах IKE_INIT_SA и запросах IKE_AUTH. Элементы Certificate Request могут включаться в обмен, когда отправителю нужен сертификат получателя. При наличии множества доверенных CA53, если поле Cert Encoding не разрешает список, следует передавать множество элементов Certificate Request.

Элемент Certificate Request содержит следующие поля:

  • Certificate Encoding (1 октет) — задает тип представления запрашиваемого сертификата. Возможные значения перечислены в параграфе 3.6.

  • Certification Authority (переменный размер) — указывает подходящий удостоверяющий центр для запрашиваемого типа сертификата.

Идентификатор типа для элемента данных Certificate Request имеет значение 38.

Поле Certificate Encoding имеет такие же значения, как описано в параграфе 3.6. Поле Certification Authority содержит индикатор удостоверяющего центра для данного типа сертификата. Значение Certification Authority представляет собой конкатенацию хэш-значений SHA-1 для открытых ключей удостоверяющих центров (CA). Каждое значение представляет собой хэш SHA-1 для элемента Subject Public Key Info (см. параграф 4.1.2.7 работы [RFC3280]) из каждого сертификата Trust Anchor. Двадцатиоктетные хэш-значения объединяются (конкатенация) и помещаются в поле без дополнительного форматирования.

Отметим, что термин Certificate Request (запрос сертификата) может вводить в заблуждение, поскольку запрашиваться с помощью этого элемента могут не только сертификаты, но и другие данные, как было указано в описании элемента Certificate. Синтаксис элемента Certificate Request для таких случаев не определяется в этом документе.

Элемент Certificate Request обрабатывается путем проверки поля Cert Encoding для определения наличия у обрабатывающего сертификатов этого типа. Если такие сертификаты имеются, просматривается поле Certification Authority для проверки наличия у обрабатывающего сертификатов, которые могут быть подтверждены в одном из указанных удостоверяющих центров. Это может быть цепочка сертификатов.

Если существует сертификат конечного объекта, который удовлетворяет критериям, заданным в CERTREQ, этот сертификат или цепочку сертификатов следует передать назад запрашивающему сертификат узлу, при условии, что получатель CERTREQ:

  • настроен на использование аутентификации по сертификатам;

  • имеет разрешение на передачу элемента CERT;

  • имеет соответствующую политику доверия к CA для текущего согласования;

  • имеет по крайней мере один действующий (time-wise) и подходящий сертификат конечного объекта, связанный с CA из CERTREQ.

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

Не ставится задачи блокирования связи на основе строгого соответствия выбора сертификата предложенному в CERTREQ — отправитель может выбирать другие сертификаты, которые получатель может проверить и которым он сможет доверят на основе кросс-сертификации, списков отзыва и других способов. Таким образом, обработке CERTREQ следует выглядеть, как предложению на выбор сертификата (не обязательно одного). Если сертификата нет, элемент CERTREQ игнорируется. С точки зрения протокола это не является ошибкой. Могут возникать случаи, когда при наличии предпочтительного CA, указанного в CERTREQ, подходящим оказывается другой удостоверяющий центр (возможно, в результате выбора оператора).

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Auth Method   !                 Резерв                        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                      Authentication Data                      ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Формат аутентификации

3.8. Аутентификация

Элемент данных Authentication (AUTH) содержит данные, которые используются для аутентификации. Синтаксис Authentication Data меняется в соответствии с выбором Auth Method, как описано ниже.

Элемент Authentication имеет следующие поля:

  • Auth Method (1 октет) — задает используемый метод аутентификации и может принимать значения:

RSA Digital Signature (1) — рассчитывается, как указано в параграфе 2.15, с использованием приватного ключа RSA и хэш-значения PKCS#1 с заполнением (см. [RSA] и [PKCS1]).

Shared Key Message Integrity Code (2) — рассчитывается, как указано в параграфе 2.15, с использованием разделяемого ключа, связанного с объектом из элемента ID, и согласованной функции prf.

DSS Digital Signature (3) — рассчитывается, как указано в параграфе 2.15, с использованием приватного ключа DSS (см. [DSS]) и хэш-значения SHA-1.

Значение 0 и 4-200 зарезервированы IANA. Значения 201-255 выделены для частных приложений.

  • Authentication Data (переменный размер) — см. параграф 2.15.

Идентификатор типа элемента Authentication имеет значение 39.

3.9. Элемент Nonce

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                            Nonce Data                         ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 15. Формат Nonce

Элементы Nonce, обозначаемые в этом документе Ni и Nr (для инициатора и ответчика, соответственно), содержат случайные значения, служащие для обеспечения жизнестойкости в процессе обмена и защиты от атак с повторным использованием пакетов.

Элемент Nonce имеет одно поле:

  • Nonce Data (переменный размер) — случайное значение, созданное передающей стороной.

Идентификатор типа элемента Nonce имеет значение 40.

Размер Nonce должен находиться в диапазоне от 16 до 256 октетов, включительно. Недопустимо повторное использование значений Nonce.

3.10. Уведомление

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Protocol ID  !   SPI Size    !      Notify Message Type      !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                Security Parameter Index (SPI)                 ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       Notification Data                       ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 16. Формат уведомления

Элемент Notify (N) используется для передачи служебной информации (ошибки, смена состояния) партнеру IKE. Элемент Notify может появляться в откликах на отвергнутые запросы (обычно с указанием причины отказа), обмене INFORMATIONAL (для сообщений об ошибках, не относящихся к запросу IKE) и в других сообщениях для индикации возможностей отправителя или изменения трактовки запроса.

Элемент Notify имеет следующие поля:

  • Protocol ID (1 октет) — если уведомление относится к существующей SA, это поле указывает тип данной SA. Для уведомлений IKE_SA это поле должно иметь значение 1. Для уведомлений, касающихся IPsec SA, это поле должно содержать значение 2 для протокола AH или 3 для ESP. Для уведомлений, не относящихся к существующим SA, это поле должно сбрасываться в 0 при передаче и игнорироваться на приеме. Все остальные значения зарезервированы IANA для использования в будущем.

  • SPI Size (1 октет) — размер SPI (в октетах) в соответствии с идентификатором протокола IPsec или 0, если SPI не применим. Для уведомлений, касающихся IKE_SA, поле SPI Size должно иметь значение 0.

  • Notify Message Type (2 октета) — задает тип уведомления.

  • SPI (переменный размер) — список параметров защиты.

  • Notification Data (переменный размер) — информация или данные об ошибке, передаваемые в дополнение к Notify Message Type. Значения этого поля зависят от типа и описаны нижеэ

Идентификатор типа элемента Notify имеет значение 41.

3.10.1. Типы уведомлений

Уведомления могут сообщать о причинах ошибок, не позволивших организовать SA. Они могут также содержать данные о состоянии, которые процесс, управляющий базой данных SA, желает передать процессу партнера. Приведенная ниже таблица содержит список сообщений Notification и их идентификаторов. Число различных ошибочных состояний существенно снижено по сравнению с IKEv1 в целях упрощения и сокращения объема информации для зондирования54.

Типы 0 — 16383 предназначены для передачи сообщений об ошибках. Реализация, получившая элемент Notify с одним из таких типов, который она не способна распознать, при отклике должна предполагать, что соответствующий запрос не удалось обработать совсем. Непонятные типы ошибок в запросах и типы состояний в запросах и откликах должны игнорироваться, но при этом их следует заносить в системный журнал.

Элементы Notify с типами, относящимися к состоянию, можно добавлять в любые сообщения. Непонятные элементы таких типов должны игнорироваться. Такие сообщения предназначены для индикации возможностей и, как часть процесса согласования SA, используются для согласования параметров, не являющихся криптографическими.

Сообщение Notify — ошибки

Значение

Описание

Резерв

0

UNSUPPORTED_CRITICAL_PAYLOAD

1

Передается в тех случаях, когда не распознан элемент с флагом Critical. Поле Notification Data содержит октет типа элемента.

INVALID_IKE_SPI

4

Показывает, сообщение IKE, полученное с нераспознанным SPI адресата. Это обычно говорит о перезагрузке партнера с утратой существующей IKE_SA.

INVALID_MAJOR_VERSION

5

Показывает, что получатель не может обрабатывать версию IKE, указанную в заголовке. В заголовке отклика указывается ближайший номер версии, поддерживаемой получателем.

INVALID_SYNTAX

7

Указывает сообщения полученные IKE, которые неприемлемы по причине выхода за допустимые пределы типа, размера или значения, а также были отвергнуты по соображениям политики. Для предотвращения атак на службы с использованием обманных сообщений этот код можно возвращать только для шифрованных сообщений (в шифрованных сообщениях), если идентификатор сообщения и криптографическая контрольная сумма корректны. Во избежание утечки информации к зондирующему это сообщение должно передаваться в ответ на любую ошибку, для которой не выделено кода. Для отладки следует выводить более детальную информацию об ошибке на консоль или в системный журнал.

INVALID_MESSAGE_ID

9

Передается при получении сообщения IKE, идентификатор которого не попадает в поддерживаемое окно. Такое уведомление недопустимо передавать в отклике, поскольку подтверждение некорректного запроса недопустимо. Вместо этого другую сторону можно проинформировать с помощью обмена INFORMATIONAL с поле Notification, содержащим четыре октета некорректного идентификатора сообщения. Передача этого уведомления является опциональной и должна быть ограничена по частоте.

INVALID_SPI

11

Может передаваться в обмене INFORMATIONAL, когда узел получает пакет ESP или AH с некорректным SPI. Поле Notification Data содержит SPI из полученного пакета. Обычно такое сообщение говорит о перезагрузке узла с потерей SA. Если такое сообщение передается вне контекста IKE_SA, его следует использовать только в качестве «совета», поскольку подделать такое сообщение достаточно просто.

NO_PROPOSAL_CHOSEN

14

Ни один из предложенных шифронаборов не может быть принят.

INVALID_KE_PAYLOAD

17

Поле D-H Group # элемента KE не совпадает с номером группы, выбранным ответчиком для этого обмена. С таким уведомлением связаны два октета (в сетевом порядке) данных, указывающие номер приемлемой группы D-H.

AUTHENTICATION_FAILED

24

Передается в ответ на сообщение IKE_AUTH, когда аутентификация не прошла. Связанных данных нет.

SINGLE_PAIR_REQUIRED

34

Это сообщение показывает, что запрос CREATE_CHILD_SA не принят потому, что отправитель согласен принимать только селекторы трафика, задающие одну пару адресов. Предполагается, что запрашивающая сторона ответит запросом SA только для конкретного трафика.

NO_ADDITIONAL_SAS

35

Это сообщение показывает, что запрос CREATE_CHILD_SA не принят потому, что ответчик не хочет создавать дополнительные CHILD_SA для данной IKE_SA. Некоторые минимальные реализации могут принимать организацию только одной CHILD_SA в контексте начального обмена IKE и отвергают все последующие попытки организации связей.

INTERNAL_ADDRESS_FAILURE

36

Показывает ошибку при выделении внутреннего адреса (INTERNAL_IP4_ADDRESS или INTERNAL_IP6_ADDRESS) в процессе обработки ответчиком элемента Configuration. Если это сообщение создано в контексте обмена IKE_AUTH, связи CHILD_SA не будут организованы.

FAILED_CP_REQUIRED

37

Передается ответчиком в тех случаях, когда CP(CFG_REQUEST) предполагалось, но не было получено в результате конфликта с локальной политикой. Связанных данных нет.

TS_UNACCEPTABLE

38

Показывает неприемлемость всех адресов/протоколов/портов в селекторе трафика.

INVALID_SELECTORS

39

Может передаваться в обмене INFORMATIONAL, когда узел получает пакет ESP или AH, в котором селекторы не соответствуют использованной SA (это приводит к отбрасыванию пакета). Поле Notification Data содержит начало ошибочного пакета (как в сообщениях ICMP), а в поле SPI помещается значение SPI для IPsec SA.

Резерв IANA — типы ошибок

40 — 8191

Для частного применения — типы ошибок

8192 — 16383

Сообщения NOTIFY — состояния

Значение

Описание

INITIAL_CONTACT

16384

Данное уведомление заявляет, что данная IKE_SA является единственной активной IKE_SA между аутентифицированными сторонами. Уведомление может передаваться при создании IKE_SA после аварии и получатель может использовать эту информацию для удаления всех прочих IKE_SA с тем же аутентифицированным партнером без ожидания. Недопустима передача таких уведомлений со стороны реплицируемых объектов (например, представление мобильного пользователя, которому разрешено подключаться к корпоративному шлюзу с двух удаленных систем одновременно).

SET_WINDOW_SIZE

16385

Это уведомление заявляет, что передающая сторона способна сохранять состояние для множества незавершенных обменов, что позволяет получателю отправлять множество запросов без ожидания ответа на первый запрос. Данные, связанные с SET_WINDOW_SIZE, должны иметь размер 4 октета (сетевой порядок байтов) и содержать представление числа сообщений, которые могут сохраняться. До завершения начального обмена размер окна всегда равен 1.

ADDITIONAL_TS_POSSIBLE

16386

Это уведомление заявляет, что передающая сторона сужает предложенный набор селекторов трафика, и говорит о возможности использования других селекторов через отдельные SA (см. параграф 2.9). С этим типом уведомлений не связано данных. Уведомление может передаваться только в качестве дополнительного элемента сообщения, включающего подходящие TS.

IPCOMP_SUPPORTED

16387

Это уведомление можно включать только в сообщения, содержащие элемент SA для согласования CHILD_SA, где указано желание использовать IPComp в данной SA. Связанные с уведомлением данные включают двухоктетное значение IPComp CPI, за которым следует однооктетный идентификатор преобразования (возможно, с атрибутами, размер и формат которых определяются идентификатором преобразования). Сообщение, предлагающее SA, может включать множество уведомлений IPCOMP_SUPPORTED для индикации поддержки разных алгоритмов. Сообщение, принимающее SA, может содержать не более одного такого уведомления.

Идентификаторы преобразований показаны ниже.

Имя Номер Определение

Резерв 0

IPCOMP_OUI 1

IPCOMP_DEFLATE 2 RFC 2394

IPCOMP_LZS 3 RFC 2395

IPCOMP_LZJH 4 RFC 3051

Значения 5-240 зарезервированы IANA, значения 241-255 предназначены для часто применения по согласования сторон.

NAT_DETECTION_SOURCE_IP

16388

Это уведомление используется получателем для проверки нахождения его отправителя за устройством NAT. Данные, связанные с этим уведомлением, представляют собой подпись SHA-1 для значений SPI (в порядке их следования в заголовке), адреса IP и номера порта, куда пакет был послан. Возможно наличие множества уведомлений этого типа в сообщении, если отправитель не знает, какое из соединений с сетью будет использоваться для передачи пакета. Получатель уведомления может сравнить полученное значение с хэшем SPI, адреса IP и порта получателя — при несовпадении следует включить режим работы через NAT (см. параграф 2.23). Если работа через NAT не поддерживается, попытка соединения может быть отвергнута.

Сообщения NOTIFY — состояния

Значение

Описание

NAT_DETECTION_DESTINATION_IP

16389

Это уведомление используется его получателем для проверки своего нахождения за устройством NAT. Данные, связанные с этим уведомлением, представляют собой подпись SHA-1 для значений SPI (в порядке их следования в заголовке), адреса IP и номера порта, куда пакет был послан. Получатель уведомления может сравнить полученное значение с хэшем SPI, адреса IP и порта получателя — при несовпадении следует включить режим работы через NAT (см. параграф 2.23). Несоответствие говорит о том, что данная сторона расположена за устройством NAT и ей следует начать передачу пакетов keepalive, как определено в [Hutt05]. Если работа через NAT не поддерживается, попытка соединения может быть отвергнута.

USE_TRANSPORT_MODE

16391

Это уведомление может быть включено в запрос, содержащий также элемент SA для создания CHILD_SA. Уведомление запрашивает для CHILD_SA использование транспортного режима, вместо туннельного55. Если запрос принимается, отклик на него должен включать уведомление USE_TRANSPORT_MODE. Если ответчик отвергает запрос, CHILD_SA будет создаваться для туннельного режима. Если это неприемлемо для инициатора, он должен удалить SA.

Примечание. Для всех SA с туннельным режимом, создаваемых IKEv2, должна выполняться декапсуляция, измененная в соответствии с [RFC4301].

HTTP_CERT_LOOKUP_SUPPORTED

16392

Это уведомление может включаться в любое сообщение, которое содержит элемент CERTREQ, и показывает, что отправитель может находить сертификаты по URL на основе HTTP (и, следовательно, будет предпочитать получение сертификатов в таком формате).

REKEY_SA

16393

Это уведомление должно включаться в обмен CREATE_CHILD_SA, если задачей обмена является замена существующей SA (ESP или AH). Поле SPI аутентифицирует SA, для которой будут меняться ключи. Уведомление не включает данных/

ESP_TFC_PADDING_NOT_SUPPORTED

16394

Это уведомление заявляет, что передающая точка не будет принимать пакеты с заполнением TFC56.

NON_FIRST_FRAGMENTS_ALSO

16395

Служит для контроля фрагментации (см. [RFC4301]).

Резерв IANA — типы состояний

16396 — 40959

Для частного применения — типы состояний

40960 — 65535

3.11. Удаление

Элемент Delete (D) содержит определяемый протоколом идентификатор защищенной связи, которую отправитель удаляет из базы данных (следовательно, связь перестает быть корректной). Рисунок 17 Показывает формат элемента Delete. В этом элементе данных можно передавать множество SPI, однако все SPI должны относиться к одному протоколу. Смешивание идентификаторов протоколов в элементе Delete недопустимо. Однако в одном обмене INFORMATIONAL допускается использование множества уведомлений Delete с SPI для разных протоколов.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID   !   SPI Size    !           # of SPIs           !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~               Security Parameter Index(es) (SPI)              ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 17. Формат удаления

Удаление IKE_SA указывается значением идентификатора протокола 1 (IKE), а не значениями SPI. Удаление CHILD_SA (таких, как ESP или AH) будет включать идентификатор протокола IPsec (2 для AH, 3 для ESP) и значение SPI, которое передающая точка ожидает во входящих пакетах ESP ил AH.

Элемент Delete включает поля:

  • Protocol ID (1 октет) — 1 для IKE_SA, 2 для AH, 3 для ESP.

  • SPI Size (1 октет) — размер (в октетах) SPI, определенного идентификатором протокола. Это поле должно иметь нулевое значение для IKE (SPI в заголовке сообщения) или 4 для AH и ESP.

  • # of SPIs (2 октета) — число SPI в данном элементе Delete. Размер каждого значения SPI определяется полем SPI Size.

  • Security Parameter Index(es) (переменный размер) — идентифицирует удаляемую защищенную связь (связи). Размер этого поля определяется значением поля SPI Size и числом полей SPI.

Идентификатор типа для элемента Delete имеет значение 42.

3.12. Vendor ID

Элемент данных Vendor ID (далее, V) содержит определенные производителем константы, которые служат для идентификации и распознавания удаленных экземпляров реализаций данного производителя. Этот механизм позволяет производителям экспериментировать с новыми возможностями, обеспечивая совместимость со старыми версиями.

Элемент Vendor ID может анонсировать возможность отправителя работать с некими расширениями протокола57. Возможна передача множества элементов Vendor ID. Реализации не обязана передавать элементы Vendor ID и может не использовать их совсем.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                        Vendor ID (VID)                        ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 18. Формат элемента Vendor ID

Элемент Vendor ID может передаваться в любом сообщении. Получение понятного элемента Vendor ID дает реализации возможность использовать значения, выделенные в этом документе для частного применения — частные элементы данных, типы обмена, уведомления и т. п. Непонятные элементы Vendor ID должны игнорироваться. Разработчики проектов протоколов (Internet-Draft), желающие расширить данный протокол, должны определить элемент Vendor ID для анонсирования возможности реализовать расширение из Internet-Draft. Предполагается, что получившие признание документы Internet-Draft, будут стандартизоваться с выделением значений из резервных блоков IANA и использование данного Vendor ID будет прекращаться.

Элемент Vendor ID имеет одно поле:

  • Vendor ID (переменный размер) — несмотря на отсутствие реестра идентификаторов, на выбравшего значение Vendor ID ложится ответственность за уникальность этого идентификатора. Хорошим тоном является включение в идентификатор названия компании, имени разработчика и т. п. Можно также использовать географическую широту и долготу в комбинации со временем выбора значения или придумать иной уникальный идентификатор. Использование цифровой сигнатуры взамен длинных строк является предпочтительной практикой.

Идентификатор типа элемента данных Vendor ID имеет значение 43.

3.13. Элемент данных TS

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Number of TSs !                   Резерв                      !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       <Traffic Selectors>                     ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 19: Формат элемента данных Traffic Selector

Элемент данных Traffic Selector (TS) позволяет партнерам идентифицировать потоки пакетов для обработки службами IPsec.

Элемент TS состоит из базового заголовка IKE, за которым следуют отдельные селекторы трафика.

  • Number of TSs (1 октет) — число представляемых селекторов трафика.

  • Резерв — это поле должно иметь нулевое значение при передаче и игнорироваться на приеме.

  • Traffic Selectors (переменный размер) — один или множество индивидуальных селекторов трафика.

Размер элемента TS учитывает заголовок TS и все селекторы трафика.

Идентификатор типа элемента TS имеет значение 44 для адресов на стороне инициатора и 45 для адресов на стороне ответчика.

3.13.1. Субструктура селектора трафика

  • TS Type (1 октет) — задает тип селектора трафика.

  • IP protocol ID (1 октет) — значение, показывающее идентификатор связанного протокола IP ID (например, UDP/TCP/ICMP). Нулевое значение говорит о неприменимости идентификатора протокола к данному селектору трафика (SA может передавать все протоколы).

  • Selector Length — задает размер данной субструктуры Traffic Selector с учетом заголовка.

  • Start Port (2 октета) — задает минимальный номер порта, допустимый для данного селектора. Для протоколов, где порт не определен или разрешается использовать любые порты, это поле должно иметь значение 0. Для протокола ICMP два однооктетных поля Type и Code трактуются, как 16-битовое целое число (Type занимает старшие 8 битов, а Code — младшие), задающее номер порта для целей фильтрации по данному полю.

  •                      1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   TS Type     !IP Protocol ID*|       Selector Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Start Port*         |           End Port*           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                                                               !
    ~                         Starting Address*                     ~
    !                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                                                               !
    ~                         Ending Address*                       ~
    !                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Рисунок 20: Селектор трафика

    * Все поля, за исключением TS Type и Selector Length зависят от значения TS Type. Здесь поля показаны для TS Type 7 и 8 (единственные значения, определенные в настоящий момент).

    End Port (2 октета) — — задает максимальный номер порта, допустимый для данного селектора. Для протоколов, где порт не определен или разрешается использовать любые порты, это поле должно иметь значение 65535. Для протокола ICMP два однооктетных поля Type и Code трактуются, как 16-битовое целое число (Type занимает старшие 8 битов, а Code — младшие), задающее номер порта для целей фильтрации по данному полю.

  • Starting Address — Наименьший адрес, включенный в данный селектор (размер определяется полем TS type).

  • Ending Address — Наибольший адрес, включенный в данный селектор (размер определяется полем TS type).

Системы, соответствующие [RFC4301] и желающие показать все порты (ANY), должны устанавливать для начального порта значение 0, а для конечного — 65535 (отметим, что, согласно [RFC4301], ANY включает OPAQUE). Системы, работающие с [RFC4301] и желающие показать порты OPAQUE, но не ANY, должны установить для начального порта значение 65535, а для конечного — 0.

В таблице показаны определенные к настоящему моменту значения поля Traffic Selector Type и соответствующие им адресные данные.

TS Type

Значение

Резерв

0 — 6

TS_IPV4_ADDR_RANGE

7

Диапазон адресов IPv4, представленный двумя четырехоктетными значениями. Первое значение указывает начальный адрес диапазона, второе — конечный. Обе границы и все адреса между ними включаются в диапазон.

TS_IPV6_ADDR_RANGE

8

Диапазон адресов IPv4, представленный двумя шестнадцатиоктетными значениями. Первое значение указывает начальный адрес диапазона, второе — конечный. Обе границы и все адреса между ними включаются в диапазон.

Резерв IANA

9 — 240

Частное применение

241 — 255

3.14. Элемент Encrypted

Элемент Encrypted, обозначаемый в этом документе SK{…} или E, содержит другие элементы в зашифрованном виде. При наличии в сообщении элемента Encrypted этот элемент должен быть последним в сообщении. Часто этот элемент является единственным элементом данных в сообщении.

Алгоритмы шифрования и защиты целостности согласуются при организации IKE_SA, а ключи рассчитываются в соответствии с параграфами 2.14 и 2.18.

Алгоритмы шифрования и защиты целостности разработаны после алгоритмов ESP, описанных в RFC 2104 [KBC96], 4303 [RFC4303] и 2451 [ESPCBC]. В данном документе полностью описана криптографическая обработка данных IKE, а упомянутые документы следует рассматривать в качестве обоснования устройства протокола. Мы требуем использования блочного шифрования с фиксированным размером блока и алгоритма защиты целостности с фиксированным размером контрольной суммы для сообщений разных размеров.

Идентификатор типа для элемента Encrypted имеет значение 46. Элемент Encrypted включает базовый заголовок IKE и перечисленные ниже поля.

  •                      1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !C!   Резерв    !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                     Initialization Vector                     !
    !            (размер блока для алгоритма шифрования)            !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                    Шифрованные элементы IKE                   ~
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !               !             Padding (0-255 октетов)           !
    +-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
    !                                               !  Pad Length   !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                    Integrity Checksum Data                    ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Рисунок 21: Формат зашифрованных данных

    Next Payload — тип первого вложенного элемента данных. Отметим, что это отличается от стандартного формата заголовка IKE — элемент Encrypted является в сообщении последним и, следовательно, значение поля Next Payload в обычных условиях было бы равно 0. Но, поскольку этот элемент содержит в себе другие элементы и нет другого логичного места для указания типа первого элемента, было выбрано это поле.

  • Payload Length — размер элемента с учетом заголовка IV, Encrypted IKE Payloads, Padding, Pad Length и Integrity Checksum Data.

  • Initialization Vector — случайное значение, размер которого совпадает с размером блока используемого алгоритма шифрования. Получатели должны воспринимать любые значения. Отправителям следует следует генерировать псевдослучайное значение независимо для каждого сообщения или использовать для выбора значений шифрованный блок предыдущего сообщения. Для отправителя недопустимо использовать одно значение для всех сообщений, последовательности с малым расстоянием Хэмминга58 (например, порядковые номера) или шифрованные данные из предыдущего принятого сообщения.

  • IKE Payloads в соответствии с приведенным выше описанием. Это поле шифруется с использованием согласованного алгоритма.

  • Поле Padding может содержать любое значение, выбранное отправителем и должно иметь размер, делающий суммарный размер шифрованных элементов, поля Padding и поля Pad Length кратным размеру блока шифрования. Это поле шифруется с использованием согласованного алгоритма.

  • Pad Length — размер поля Padding. Отправителю следует устанавливать в поле Pad Length минимальное значение, которое делает размер полей шифрованных элементов, Padding и Pad Length кратным размеру блока шифрования, но получатель должен принимать любые значения, обеспечивающие требуемое выравнивание. Это поле шифруется с использованием согласованного алгоритма.

  • Integrity Checksum Data — криптографическая контрольная сумма всего сообщения, начиная с фиксированного заголовка IKE и заканчивая полем Pad Length. Контрольная сумма должна рассчитываться для зашифрованного сообщения. Размер поля определяется согласованным алгоритмом защиты целостности.

3.15. Конфигурация

Элемент данных Configuration (CP) используется для обмена конфигурационными параметрами между партнерами IKE. Такой обмен включает запрос клиентом IRAC внутреннего адреса IP у сервера IRAS, а также обмен другими данными в процессе получения адреса по протоколу DHCP59, если клиент IRAC подключен непосредственно к ЛВС.

Элемент Configuration может принимать тип CFG_REQUEST/CFG_REPLY или CFG_SET/CFG_ACK (см. описание поля CFG Type ниже). Элементы CFG_REQUEST и CFG_SET могут добавляться к любому запросу IKE. отклик IKE должен включать соответствующий элемент CFG_REPLY, CFG_ACK или уведомление (элемент Notify) с кодом ошибки, показывающим причину невозможности выполненияя запроса. Исключением являются минимальные реализации, которые могут игнорировать все элементы CFG_REQUEST и CFG_SET, поэтому отклик без соответствующего элемента CFG_REPLY или CFG_ACK должен приниматься и трактоваться, как индикация того, что запрос не поддерживается.

CFG_REQUEST/CFG_REPLY позволяет конечной точке IKE запросить информацию у партнера. Если значение атрибута в элементе Configuration типа CFG_REQUEST отлично от 0, такой запрос воспринимается, как предложение для данного атрибута. Элемент Configuration типа CFG_REPLY может возвратить это значение или предложить другое. Он может также добавить новые атрибуты и не включать некоторые из запрошенных. Запрашивающая сторона должна игнорировать атрибуты, которые она не способна распознать.

Некоторые атрибуты могут быть многозначными — в этом случае может передаваться и/или возвращаться множество структур Configuration одного типа60. В общем случае при запросе атрибута возвращаются все значения. Для некоторых атрибутов (в данной версии спецификации, только для внутренних адресов) множественные запросы показывают, запрос на которому выделение множества значений. Для таких запросов не следует возвращать число значений, превышающее запрошенное количество.

Если тип данных, запрошенных в CFG_REQUEST, не распознан или не поддерживается, ответчику недопустимо возвращать ошибку — вместо этого он должен передать элемент CFG_REPLY, который может быть пустым, или вернуть отклик без CFG_REPLY. Возврат ошибки зарезервирован для случаев, когда запрос распознан, но не может быть выполнен должным образом, или запрос имеет некорректный формат.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!   CFG Type    !                     Резерв                    !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                   Configuration Attributes                    ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 22. Формат конфигурационных данных

CFG_SET/CFG_ACK позволяет конечной точке IKE «вытолкнуть» конфигурационные данные своему партнеру. В этом случае элемент Configuration типа CFG_SET содержит атрибуты, которые инициатор хочет изменить у своего партнера. Ответчик должен вернуть элемент Configuration, если он принимает какие-нибудь конфигурационные данные. Этот отклик должен содержать воспринятые ответчиком атрибуты без данных (данные нулевой длины). Непринятые атрибуты недопустимо включать в CFG_ACK Configuration. Если не был принят ни один из атрибутов, ответчик должен вернуть пустой элемент типа CFG_ACK или отклик без элемента CFG_ACK. В настоящее время использование обмена CFG_SET/CFG_ACK не определено, хотя такой обмен может применяться в соединениях с расширениями на базе Vendor ID. Минимальные реализации данной спецификации могут игнорировать элементы CFG_SET.

Расширения через элемент CP не следует использовать для управления общего типа. Основным назначением такого расширения является обеспечение механизма загрузки с обменом информацией IPsec между IRAS и IRAC. Хотя такой подход может применяться в качестве метода обмена информацией между защитными шлюзами (SGW61) или небольшими сетями, для управления крупными сетями и повторяющихся информационных обменов предпочтительно использовать существующие протоколы управления типа DHCP [DHCP], RADIUS [RADIUS], SNMP или LDAP [LDAP].

Рисунок 22 иллюстрирует формат элемента данных Configuration.

Идентификатор типа элемента Configuration имеет значение 47.

  • CFG Type

    Значение

    Резерв

    0

    CFG_REQUEST

    1

    CFG_REPLY

    2

    CFG_SET

    3

    CFG_ACK

    4

    CFG Type (1 октет) — тип обмена, представленного атрибутами элемента Configuration.

    Определенные значения типов показаны в таблице справа. Значения 5-127 зарезервированы IANA, значения 128-255 выделены для частного применения по согласованию сторон.

  • Резерв (3 октета) — должно устанавливаться в 0 при передаче и игнорироваться на приеме.

  • Configuration Attributes (переменные размер) — атрибуты конфигурации в формате «тип-размер-значение», описанные ниже. В элементе Configuration может содержаться множество (в том числе, пустое) атрибутов.

3.15.1. Атрибуты конфигурации

  •                      1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !R|         Attribute Type      !            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                             Value                             ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Рисунок 23. Формат атрибута конфигурации

    Резерв (1 бит) — должен устанавливаться в 0 при передаче и игнорироваться на приеме.

  • Attribute Type (15 битов) — уникальный идентификатор для каждого типа атрибутов конфигурации.

  • Length (2 октета) — размер поля Value в октетах.

  • Value (0 или более октетов) — поле переменного размера, содержащее значение атрибута конфигурации.

    Определенные в данное время типы атрибутов показаны в таблице справа. Значения типов 16 — 16383 зарезервированы IANA, диапазон значений 16384-32767 выделен для частного применения по согласованию сторон.

  • INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS — адрес внутренней сети, иногда называемый адресом красного узла (red node address) или приватным адресом, этот адрес может быть приватным с точки зрения сети Internet. Указанный в запросе адрес является запрашиваемым; если в запросе указан 0, это говорит о том, что адрес не запрашивается. Если запрошен конкретный адрес, это скорей всего говорит о том, что ранее существовало соединение с таким адресом и запрашивающий узел хочет снова использовать данный адрес. В IPv6 запрашивающий узел может указать младшие байты желаемого адреса. Можно запросить множество внутренних адресов, запрашивая множество атрибутов для внутреннего адреса. Ответчик может вернуть число адресов, не превышающее запрошенное количество. INTERNAL_IP6_ADDRESS может включать до двух полей, первое из которых содержит шестнадцатиоктетный адрес IPv6, а второе — однооктетный размер префикса, как определено в [ADDRIPV6].

    Запрашиваемый адрес остается корректным до окончания срока его действия, заданного атрибутом INTERNAL_ADDRESS EXPIRY, или до завершения всех IKE_SA между партнерами.

  • INTERNAL_IP4_NETMASK — маска внутренней сети. В запросах и откликах может содержаться только одна маска (например, 255.255.255.0) и она должна использоваться только с атрибутом INTERNAL_IP4_ADDRESS.

  • Тип атрибута

    Значение

    Многозначный

    Размер

    Резерв

    0

    INTERNAL_IP4_ADDRESS

    1

    Да*

    0 или 4 октета

    INTERNAL_IP4_NETMASK

    2

    Нет

    0 или 4 октета

    INTERNAL_IP4_DNS

    3

    Да

    0 или 4 октета

    INTERNAL_IP4_NBNS

    4

    Да

    0 или 4 октета

    INTERNAL_ADDRESS_EXPIRY

    5

    Нет

    0 или 4 октета

    INTERNAL_IP4_DHCP

    6

    Да

    0 или 4 октета

    APPLICATION_VERSION

    7

    Нет

    0 или более октетов

    INTERNAL_IP6_ADDRESS

    8

    Да*

    0 или 17 октетов

    Резерв

    9

    INTERNAL_IP6_DNS

    10

    Да

    0 или 16 октетов

    INTERNAL_IP6_NBNS

    11

    Да

    0 или 16 октетов

    INTERNAL_IP6_DHCP

    12

    Да

    0 или 16 октетов

    INTERNAL_IP4_SUBNET

    13

    Да

    0 или 8 октетов

    SUPPORTED_ATTRIBUTES

    14

    Нет

    кратно 2

    INTERNAL_IP6_SUBNET

    15

    Да

    17 октетов

    * Эти атрибуты возвращаются многозначными лишь в тех случаях, когда было запрошено множество значений.

    INTERNAL_IP4_DNS, INTERNAL_IP6_DNS — задает адрес сервера DNS внутри сети. Можно запрашивать адреса множества серверов DNS. Ответчик может возвращать 0 или более атрибутов серверов DNS.

  • INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS — задает адрес сервера имен NetBios (WINS) внутри сети. Можно запрашивать адреса множества серверов NBNS. Ответчик может возвращать 0 или более атрибутов серверов NBNS.

  • INTERNAL_ADDRESS_EXPIRY — задает время (в секундах), в течение которого хост может использовать внутренний адрес IP. Хост должен обновить IP-адрес до завершения срока его аренды. В отклике может присутствовать только один такой атрибут.

  • INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP — говорит хосту о необходимости отправки всех внутренних запросов DHCP по адресу, содержащемуся в этом атрибуте. Можно запрашивать адреса множества серверов DHCP. Ответчик может возвращать 0 или более атрибутов серверов DHCP.

  • APPLICATION_VERSION — версия или информация приложения хоста IPsec, заданная в форме строки печатаемых символов ASCII без null-символа завершения.

  • INTERNAL_IP4_SUBNET — защищаемые данным краевым устройством подсети. Атрибут может содержать до двух полей, первое из которых задает адрес IP, а второе — маску. Можно запрашивать множество подсетей. Ответчик может возвращать 0 или более атрибутов подсетей.

  • SUPPORTED_ATTRIBUTES — при использовании в запросе этот атрибут должен иметь нулевой размер и задает запрос ответчику на получение всех поддерживаемых им атрибутов. Отклик содержит атрибут, который включает набор идентификаторов атрибутов (по 2 октета в каждом). Размер данного атрибута, поделенный на 2 (октета) будет показывать число включенных в отклик поддерживаемых атрибутов.

  • INTERNAL_IP6_SUBNET — защищенная данным краевым устройством подсеть. Этот атрибут может содержать до двух полей, первое из которых задает шестнадцатиоктетный адрес IPv6, а второй однооктетный размер префикса, как определено в [ADDRIPV6]. Можно запрашивать множество подсетей. Ответчик может возвращать 0 или более атрибутов подсетей.

Отметим, что в этом документе не дается рекомендаций по выбору информации, которую реализация будет возвращать в откликах. В частности, мы не даем каких-либо конкретных рекомендаций в части определения сервером IRAS сервера DNS, адрес которого следует возвращать по запросам IRAC.

3.16. Элемент EAP

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       EAP Message                             ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 24. Формат EAP

Элемент Extensible Authentication Protocol62 (EAP) позволяет выполнять аутентификацию IKE_SA с использованием протокола, определенного в RFC 3748 [EAP] и его последующих расширений. Полный набор приемлемых значений выходит за пределы этой спецификации, однако краткий перечень значений из RFC 3748 включен в документ для использования в наиболее общих случаях.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!     Code      ! Identifier    !           Length              !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!     Type      ! Type_Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Рисунок 25. Формат сообщения EAP

Идентификатор типа для элемента данных EAP имеет значение 48.

  • Code (1 октет) показывает, является это сообщение запросом (Request — 1), откликом (Response — 2), успешным завершением (Success — 3) или отказом (Failure — 4).

  • Identifier (1 октет) используется в PPP, чтобы отличить повторное использование сообщений от повторной передачи. Поскольку в IKE протокол EAP работает на базе протокола с гарантированной доставкой, использование идентификатора смысла не имеет. В откликах этот октет должен устанавливаться равным значению идентификатора в соответствующем запросе. В остальных сообщениях это поле может принимать любое значение.

  • Length (2 октета) показывает размер сообщения EAP и должно быть на 4 меньше значения поля Payload Length инкапсулирующего элемента.

  • Type (1 октет) присутствует только в сообщениях с кодом Request (1) или Response (2). Для других кодов размер сообщения EAP должен составлять четыре октета, а поля Type и Type_Data должны отсутствовать. В запросах (1) поле Type показывает запрашиваемые данные, а в откликах (2) поле Type должно быть пустым или соответствовать типу запрошенных данных В RFC 3748 определены следующие типы:

1 Identity — тождественность.

2 Notification — уведомление.

3 Nak (только отклики)

4 MD5-Challenge

5 One-Time Password (OTP) — однократный пароль.

6 Generic Token Card — маркерная карта базового типа.

  • Type_Data (переменный размер) зависит от типа запроса и связанного с ним отклика. Дополнительная информация по методам EAP приведена в работе methods, see [EAP].

Поскольку IKE передает идентификацию инициатора в протокольном сообщении с номером 3, ответчику не следует передавать запросы EAP Identity. Инициатору следует, однако, отвечать на такие запросы при их получении.

4. Требования по соответствию

Для обеспечения взаимодействия всех реализаций IKEv2 вводятся специальные требования «необходимо поддерживать» (MUST support) в дополнение к другим требованиям. IKEv2 является протоколом защиты и одной из его основных функций является предоставление возможности организации SA только уполномоченным сторонам. Поэтому конкретная реализация может быть настроена с любыми ограничениями по части алгоритмов и удостоверяющих центров, что вступает в противоречие с всеобщей совместимостью.

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

  • возможность согласования SA через NAT и туннелирования полученной ESP SA с использованием UDP;

  • возможность запрашивать (и отдавать по запросу) временный адрес IP на удаленной стороне туннеля;

  • возможность поддерживать различные типы унаследованной аутентификации;

  • возможность поддерживать окна размером более 1;

  • возможность организации множества SA (ESP и/или AH) в одной IKE_SA;

  • возможность замены ключей SA.

Для обеспечения интероперабельности все реализации должны быть способны разбирать все типы элементов данных (или хотя бы пропускать их) и игнорировать непонятные элементы, если в их заголовках не установлен флаг критичности. При наличии флага критичности в заголовке непонятного элемента все реализации должны отвергать сообщения с такими элементами.

Каждая реализация должна быть способна выполнять обмен 4 сообщениями IKE_SA_INIT и IKE_AUTH, обеспечивающий организацию двух SA (одна для IKE, одна для ESP и/или AH). Реализации могут работать в режиме «только инициатор» или «только ответчик», если это подходит для используемой платформы. Каждая реализация должна быть способна отвечать на обмен INFORMATIONAL, но минимальные реализации могут отвечать на любое сообщение INFORMATIONAL пустым откликом INFORMATIONAL (отметим, что в контексте IKE_SA «пустое» сообщение состоит из заголовка IKE, за которым следует элемент Encrypted без вложенных в него элементов). Минимальная реализация может поддерживать обмен CREATE_CHILD_SA лишь для случаев, когда запрос распознан, и отвергать его с уведомлением типа NO_ADDITIONAL_SAS. От минимальных реализаций не требуется возможность инициирования обменов CREATE_CHILD_SA или INFORMATIONAL. Когда срок жизни SA истекает (по локальному значению времени жизни или числу переданных октетов), реализация может попытаться обновить связь с помощью обмена CREATE_CHILD_SA или удалить (закрыть) SA и создать новую. Если ответчик отвергает запрос CREATE_CHILD_SA с передачей уведомления NO_ADDITIONAL_SAS, реализация должна быть способна закрыть старую SA и создать новую.

Реализации не обязаны поддерживать возможность запроса временных адресов IP и отклики на такие запросы. Если реализация поддерживает создание таких запросов, она должна включать в сообщение 3 элемент данных CP, содержащий по крайней мере поле типа INTERNAL_IP4_ADDRESS или INTERNAL_IP6_ADDRESS. Все остальные поля являются необязательными. Если реализация поддерживает отклики на такие запросы, она должна разбирать элемент CP типа CFG_REQUEST в сообщении 3 и распознавать поля типа INTERNAL_IP4_ADDRESS или INTERNAL_IP6_ADDRESS. Если реализация поддерживает выдачу временных адресов запрошенного типа, она должна возвратить элемент CP типа CFG_REPLY, содержащий адрес запрошенного типа. Ответчику следует включать все остальные связанные с адресом атрибуты, если они имеются.

Минимальная реализация ответчика IPv4 будет игнорировать все содержимое элемента CP, кроме атрибута INTERNAL_IP4_ADDRESS, и будет отвечать на сообщение с включением адреса и других атрибутов, независимо от того, что запрашивал инициатор.

Минимальная реализация инициатора IPv4 будет генерировать элементы CP, содержащие только атрибут INTERNAL_IP4_ADDRESS и разбирать полученный отклик, игнорируя атрибуты, которые она не может использовать. Единственным атрибутом, который должна обрабатывать такая реализация, является атрибут INTERNAL_ADDRESS_EXPIRY63, ограничивающий время жизни SA, если она не будет обновлена до завершения срока жизни. От минимальной реализации инициатора не требуется поддержка запросов на обновление аренды адреса, а минимальные реализации ответчиков не поддерживают откликов на такие запросы.

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

  • сертификатов PKIX, содержащих ключи RSA размером 1024 или 2048 и подписанных с использованием таких ключей, когда передаваемый идентификатор является ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR или ID_DER_ASN1_DN;

  • аутентификации с общим ключом, когда передаваемый идентификатор является ID_KEY_ID, ID_FQDN или ID_RFC822_ADDR;

  • аутентификации ответчика с использованием сертификатов PKIX, а инициатора — с использованием общего ключа.

5. Вопросы безопасности

Хотя протокол разработан так, чтобы минимизировать раскрытие конфигурационной информации неуполномоченным партнерам, некоторое раскрытие все-таки неизбежно. Один из партнеров в любом случае должен сначала идентифицировать себя и подтвердить эту идентификацию. Для предотвращения зондирования к инициаторам обмена предъявляется требование идентифицировать себя первым и обычно требуется первым подтвердить свою подлинность. Однако инициатор может узнать, что ответчик поддерживает IKE и определить поддерживаемые им криптографические протоколы. Ответчик (или кто-нибудь, прикидывающийся таковым) может не только проверить идентификацию инициатора, но и с помощью элементов CERTREQ определить, какие сертификаты желает использовать инициатор.

Использование аутентификации EAP несколько меняет возможности зондирования. При использовании EAP ответчик подтверждает свою идентификацию раньше инициатора, поэтому любой инициатор, которому известно имя корректного инициатора, может зондировать ответчика для выяснения его имени и сертификатов.

Повторяющаяся замена ключей с использованием CREATE_CHILD_SA без дополнительных обменов Diffie-Hellman делает все SA уязвимыми для криптоанализа одного ключа или перегрузки (overrun) любой из конечных точек. Разработчикам следует отметить этот факт и установить предел для числа обменов CREATE_CHILD_SA между сторонами. В этом документе данный предел не задается.

Стойкость ключей, созданных в результате обмена Diffie-Hellman с использованием любой из определенных здесь групп, зависит от стойкости самой группы, размера используемого показателя и энтропии при генерации случайных значений. По причине большого числа влияющих на стойкость ключей факторов сложно определить стойкость ключа для любой из определенных групп. Группа Diffie-Hellman номер 2 при использовании с качественным генератором случайных чисел и показателем не менее 200 битов является общепринятой для 3DES. Группа 5 обеспечивает лучшую защиту по сравнению с группой 2. Группа 1 сохранена в качестве достояния истории и не обеспечивает достаточной защиты за исключением случаев применения с алгоритмом DES, который тоже стал уже достоянием истории. Разработчикам следует принимать во внимание эти оценки при выборе политики и согласовании параметров защиты.

Отметим, что отмеченные выше ограничения относятся к самим группам Diffie-Hellman. В IKE нет запретов на использование более сильных групп и ничто не снижает уровень стойкости, обеспечиваемый наиболее сильными группами (уровень стойкости ограничивается только выбранными при согласовании алгоритмами, включая функцию prf). Фактически, расширяемая схема IKE поощряет определение новых групп — применение групп эллиптических кривых может существенно повысить уровень стойкости при использовании значительно меньших чисел.

Предполагается, что все показатели Diffie-Hellman удаляются из памяти после использования. В частности, такие показатели недопустимо создавать на базе долгоживущих секретов типа «затравок» (seed) генератора случайных чисел, которые не уничтожаются после использования.

Стойкость всех ключей ограничивается размером результата согласованной функции prf. По этой причине функции prf, выходное значение которых имеет размер менее 128 битов (например, 3DES-CBC) недопустимо использовать с протоколом IKE.

Безопасность данного протокола критически зависит от уровня хаотичности случайно выбираемых параметров. Случайные значений должны создаваться качественным генератором случайных чисел или источником псевдослучайных чисел с подходящей «затравкой» (см. [RFC4086]). Разработчикам следует обеспечить гарантии того, что использование случайных чисел для создания ключей и значений nonce не может приводить к снижению уровня защиты ключей.

Для информации о причинах выбора многих криптографических параметров протокола рекомендуется обратиться к работам [SIGMA] и [SKEME]. Хотя защита согласованных CHILD_SA не зависит от стойкости алгоритмов шифрования и защиты целостности, выбранных для IKE_SA, реализациям недопустимо согласовывать использование NONE в качестве алгоритма защиты целостности IKE или ENCR_NULL в качестве алгоритма шифрования IKE.

При использовании заранее распространенных общих (pre-shared) ключей критически важным становится вопрос уровня хаотичности этих секретов. Жесткая практика требует обеспечения для этих ключей уровня хаотичности не меньше, чем у самого стойкого из согласуемых ключей. Создание общих ключей из паролей, имен или других источников с малой энтропией не обеспечивает нужной защиты. Такие источники не обеспечивают устойчивости к атакам по словарю и использованию методов социальной психологии, а также к другим атакам.

Уведомления NAT_DETECTION_*_IP содержат хэш адресов и портов для сокрытия внутренней структуры сети IP, расположенной за устройством NAT. Поскольку пространство адресов IPv4 включает лишь 32 бита и обычно очень разрежено, атакующий может найти внутренние адреса, скрытые NAT простым перебором всех возможных адресов IP и сравнением хэш-значений. Номера портов обычно содержат фиксированное значение 500, а значения SPI можно выделить из пакетов. Это снижает число попыток расчета хэш-значений до 232. Когда можно обоснованно предположить использование адресов из приватных блоков64, объем расчетов дополнительно сокращается во много раз. Разработчикам, в результате, не следует полагаться на то, что использование IKE гарантирует отсутствие утечки адресной информации.

При использовании методов аутентификации EAP без генерации общих ключей для защиты последующих элементов данных AUTH становятся возможными некоторые MITM-атаки и атаки с подставными серверами [EAPMITM]. Такие уязвимости возникают при использовании EAP с протоколами, которые не защищены безопасным туннелем. Поскольку EAP является протоколом аутентификации общего назначения, который часто используется в системах с единым входом65, развернутое решение IPsec, которое опирается на аутентификацию EAP без генерации общего ключа (этот метод также называют EAP без генерации ключей), может быть скомпрометировано в результате развертывания совершенно не связанных с ним приложений, использующих тот же метод EAP без генерации ключей, но не обеспечивающих должной защиты. Отметим, что эта уязвимость не связана только с EAP и может возникать также в других сценариях с повторным использованием инфраструктуры аутентификации. Например, если механизм EAP, используемый IKEv2, основан на маркерных идентификаторах, организатор MITM-атаки может использовать подставной web-сервер, перехватить аутентификационный обмен с использованием маркера и применить результат для организации соединения IKEv2. По этой причине следует избегать по возможности использования методов EAP без генерации ключей. При использовании таких методов крайне следует применять EAP только в защищенных туннелях, когда инициатор проверяет сертификат ответчика до начала обмена EAP. Разработчикам следует описывать уязвимость использования методов EAP без генерации ключей в своих реализациях так, чтобы администраторы при развертывании решений IPsec осознавали возможные риски.

Реализации, применяющие EAP, должны также использовать аутентификацию сервера клиенту на основе открытых ключей до начала обмена EAP даже в тех случаях, когда метод EAP предлагает взаимную аутентификацию сторон. Это позволяет избавиться от дополнительных вариаций протокола IKEv2 и защищает данные EAP от активных атак.

Если сообщения IKEv2 слишком велики и требуется фрагментация на уровне IP, атакующие могут заблокировать завершение обмена путем опустошения ресурсов (заполнения буферов) для сборки фрагментов. Вероятность такого исхода можно минимизировать за счет использования кодирования «Hash and URL» вместо передачи сертификатов (см. параграф 3.6). Дополнительные меры по снижению рисков обсуждаются в работе [KPS03].

6. Согласование с IANA

В этом документе определено множество новых типов и значений полей, для которых последующее распределение контролируется IANA.

Агентство IANA создало перечисленные ниже реестры.

IKEv2 Exchange Types (параграф 3.1)

IKEv2 Payload Types (параграф 3.2)

IKEv2 Transform Types66 (параграф 3.3.2)

IKEv2 Transform Attribute Types (параграф 3.3.2)

IKEv2 Encryption Transform IDs (параграф 3.3.2)

IKEv2 Pseudo-random Function Transform IDs (параграф 3.3.2)

IKEv2 Integrity Algorithm Transform IDs (параграф 3.3.2)

IKEv2 Diffie-Hellman Transform IDs (параграф 3.3.2)

IKEv2 Identification Payload ID Types (параграф 3.5)

IKEv2 Certificate Encodings (параграф 3.6)

IKEv2 Authentication Method (параграф 3.8)

IKEv2 Notify Message Types (параграф 3.10.1)

IKEv2 Notification IPCOMP Transform IDs (параграф 3.10.1)

IKEv2 Security Protocol Identifiers (параграф 3.3.1)

IKEv2 Traffic Selector Types (параграф 3.13.1)

IKEv2 Configuration Payload CFG Types (параграф 3.15)

IKEv2 Configuration Payload Attribute Types (параграф 3.15.1)

Изменения и дополнения перечисленных реестров осуществляются после экспертизы (процедура expert review).

7. Благодарности

Этот документ является результатом совместных усилий рабочей группы IPsec. Если бы не было ограничений на количество авторов RFC, следовало бы указать всех перечисленных ниже в алфавитном порядке людей — Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer Reingold и Michael Richardson. Множество других людей также внесло свой вклад. Это работы по развитию IKEv1, ISAKMP и IPsec DOI, каждая из которых имеет свой авторский коллектив. Hugh Daniel предложил включить нахождение инициатора (в сообщении 3), задал имя для ответчика и дал имя функции «You Tarzan, Me Jane». David Faucher и Valery Smyzlov помогли усовершенствовать процесс согласования селекторов трафика.

8. Литература

8.1. Нормативные документы

[ADDGROUP] Kivinen, T. and M. Kojo, «More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)», RFC 3526, May 2003.

[ADDRIPV6] Hinden, R. and S. Deering, «Internet Protocol Version 6 (IPv6) Addressing Architecture», RFC 351367, April 2003.

[Bra97] Bradner, S., «Key Words for use in RFCs to indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, «Extensible Authentication Protocol (EAP)», RFC 3748, June 2004.

[ESPCBC] Pereira, R. and R. Adams, «The ESP CBC-Mode Cipher Algorithms», RFC 2451, November 1998.

[Hutt05] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, «UDP Encapsulation of IPsec ESP Packets», RFC 3948, January 2005.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 3280, April 2002.

[RFC4301] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

8.2. Дополнительная литература

[DES] ANSI X3.106, «American National Standard for Information Systems-Data Link Encryption», American National Standards Institute, 1983.

[DH] Diffie, W., and Hellman M., «New Directions in Cryptography», IEEE Transactions on Information Theory68, V. IT-22, n. 6, June 1977.

[DHCP] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, March 1997.

[DSS] NIST, «Digital Signature Standard», FIPS 18669, National Institute of Standards and Technology, U.S. Department of Commerce, May, 1994.

[EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., «Man-in-the-Middle in Tunneled Authentication Protocols», http://eprint.iacr.org/2002/163, November 2002.

[HC98] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 240970, November 1998.

[IDEA] Lai, X., «On the Design and Security of Block Ciphers,» ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.

[IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, «IP Payload Compression Protocol (IPComp)», RFC 3173, September 2001.

[KPS03] Kaufman, C., Perlman, R., and Sommerfeld, B., «DoS protection for UDP-based protocols», ACM Conference on Computer and Communications Security, October 2003.

[KBC96] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

[LDAP] Wahl, M., Howes, T., and S Kille, «Lightweight Directory Access Protocol (v3)», RFC 2251, December 1997.

[MD5] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, April 1992.

[MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 240871, November 1998.

[Orm96] Orman, H., «The OAKLEY Key Determination Protocol», RFC 2412, November 1998.

[PFKEY] McDonald, D., Metz, C., and B. Phan, «PF_KEY Key Management API, Version 2», RFC 2367, July 1998.

[PKCS1] Jonsson, J. and B. Kaliski, «Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1», RFC 3447, February 2003.

[PK01] Perlman, R., and Kaufman, C., «Analysis of the IPsec key exchange Standard», WET-ICE Security Conference, MIT,2001, http://sec.femto.org/wetice-2001/papers/radia-paper.pdf.

[Pip98] Piper, D., «The Internet IP Security Domain Of Interpretation for ISAKMP», RFC 240772, November 1998.

[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, «Remote Authentication Dial In User Service (RADIUS)», RFC 2865, June 2000.

[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, June 2005.

[RFC1958] Carpenter, B., «Architectural Principles of the Internet», RFC 1958, June 1996.

[RFC2401] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 240173, November 1998.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, «An Architecture for Differentiated Service», RFC 2475, December 1998.

[RFC2522] Karn, P. and W. Simpson, «Photuris: Session-Key Management Protocol», RFC 2522, March 1999.

[RFC2775] Carpenter, B., «Internet Transparency», RFC 2775, February 2000.

[RFC2983] Black, D., «Differentiated Services and Tunnels», RFC 2983, October 2000.

[RFC3439] Bush, R. and D. Meyer, «Some Internet Architectural Guidelines and Philosophy», RFC 3439, December 2002.

[RFC3715] Aboba, B. and W. Dixon, «IPsec-Network Address Translation (NAT) Compatibility Requirements», RFC 3715, March 2004.

[RFC4302] Kent, S., «IP Authentication Header», RFC 4302, December 2005.

[RFC4303] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[RSA] Rivest, R., Shamir, A., and Adleman, L., «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems», Communications of the ACM74, v. 21, n. 2, February 1978.

[SHA] NIST, «Secure Hash Standard», FIPS 180-175, National Institute of Standards and Technology, U.S. Department of Commerce, May 1994.

[SIGMA] Krawczyk, H., «SIGMA: the `SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols», in Advances in Cryptography — CRYPTO 2003 Proceedings, LNCS 2729, Springer, 2003. Available at: http://www.informatik.uni-trier.de/~ley/db/conf/crypto/crypto2003.html.

[SKEME] Krawczyk, H., «SKEME: A Versatile Secure Key Exchange Mechanism for Internet», from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security76.

[X.501] ITU-T Recommendation X.501: Information Technology — Open Systems Interconnection — The Directory: Models, 1993.

[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology — Open Systems Interconnection — The Directory: Authentication Framework, June 1997.

Приложение A: Список отличий от IKEv1

Задачами этого пересмотра IKE явились:

  1. определение протокола IKE в едином документе, замена RFC 2407, 2408, 2409 и включение последующих изменений в части добавления работы через NAT, расширяемой аутентификации (EAP) и получения удаленных адресов;

  2. упрощение IKE за счет замены 8 разных начальных обменов одним обменом из 4 сообщений (с изменением механизмов аутентификации, воздействующих только на один элемент AUTH вместо реструктуризации всего обмена), см. [PK01];

  3. удаление полей области интерпретации (DOI), ситуации (SIT) и Labeled Domain Identifier, а также битов Commit и Authentication;

  4. снижение задержки IKE в общем случае за счет сведения изначального обмена к 2 периодам кругового обхода (4 сообщения) и разрешения организации CHILD_SA в этом обмене;

  5. замена криптографического синтаксиса для защиты самих сообщений IKE синтаксисом, близким к ESP, для упрощения реализации и анализа защиты;

  6. снижение числа возможных ошибочных состояний за счет обеспечения в протоколе гарантий доставки (все сообщения подтверждаются) и упорядочивания, позволивших сократить обмены CREATE_CHILD_SA с 3 сообщений до 2;

  7. повышение отказоустойчивости за счет предоставления ответчику возможности не выполнять существенной обработки до подтверждения инициатором возможности приема сообщений по заявленному им адресу IP и не менять состояния обмена, пока инициатор не будет криптографически аутентифицирован;

  8. устранение криптографических недостатков типа проблем с симметрией в хэш-значениях, используемых для аутентификации (отмечена Tero Kivinen);

  9. задание селекторов трафика в специальных элементах данных вместо перегрузки информацией элементов ID и более гибкое указание селекторов трафика;

  10. описание поведения при возникновении некоторых ошибок или получении непонятных данных для упрощения совместимости с будущими версиями без ухудшения совместимости с предшествующими;

  11. упрощение и прояснение поддержки общих состояний при возникновении ошибок в сети или DoS-атаках;

  12. поддержка существующего синтаксиса и «магических» значений для упрощения поддержки в реализациях IKEv1 расширения для работы с IKEv2 при минимальных затратах.

Приложение B: Группы Diffie-Hellman

Имеется две группы Diffie-Hellman, определенных здесь для использования в протоколе IKE. Эти группы создал Richard Schroeppel из Университета штата Аризона. Свойства этих простых чисел описаны в работе [Orm96].

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

Дополнительные группы Diffie-Hellman определены в работе [ADDGROUP].

B.1. Группа 1 — 768-битовая MODP

Этой группе присвоен идентификатор 1.

Простое число имеет значение 2768 — 2704 — 1 + 264 * { [2638 pi] + 149686 }, а его шестнадцатеричная форма имеет вид

        FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
        8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
        302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
        A63A3620 FFFFFFFF FFFFFFFF

Генератор имеет значение 2.

B.2. Группа 2 — 1024-битовая MODP

Этой группе присвоен идентификатор 2.

Простое число имеет значение 21024 — 2960 — 1 + 264 * { [2894 pi] + 129093 }, а его шестнадцатеричная форма имеет вид

        FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
        8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
        302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
        A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
        49286651 ECE65381 FFFFFFFF FFFFFFFF

Генератор имеет значение 2.

Адрес автора

Charlie Kaufman

Microsoft Corporation

1 Microsoft Way

Redmond, WA 98052

Phone: 1-425-707-3335

EMail: charliek@microsoft.com

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Internet Key Exchange.

2Security association.

3Internet Security Association and Key Management Protocol — протокол управления ключами и защищенными связями Internet.

4Domain of Interpretation — область интерпретации.

5Network Address Translation — трансляция сетевых адресов.

6IP Security.

7Encapsulating Security Payload — инкапсуляция защищенных данных.

8Authentication Header — аутентификационный заголовок.

9IP Compression.

10Security Parameter Index.

11Trust anchor.

12Central Processor Unit – центральный процессор. Прим. перев.

13Denial of service attack – атака на отказ службы.

14Хэш и указатель ресурса.

15На тот же запрос. Прим. перев.

16В оригинале это предложение содержит ошибку, см. https://www.rfc-editor.org/errata_search.php?eid=2190. Прим. перев.

17Или отказаться от обоих. Прим. перев.

18Quality of service.

19Security Policy Database — база данных о правилах защиты.

20Traffic Selector — селектор трафика.

21Traffic Selector-initiator — селектор трафика от инициатора.

22Traffic Selector-responder — селектор трафика отвечающей стороны.

23Блок адресов IP 192.0.2.* зарезервирован для использования в примерах для RFC и аналогичных документов. Поскольку в данном документе нужны два таких диапазона, используется также блок адресов 192.0.1.*. Не следует путать эти блоки с реальными адресами.

24Pseudo-random function — псевдослучайная функция — один из криптоалгоритмов, согласуемых в обмене IKE.

25В оригинале «perfect forward secrecy». Прим. перев.

26Brute force — подбор ключей методом «грубой силы».

27Hashed Message Authentication Code — код аутентификации хэшированных сообщений.

28Advanced Encryption Standard — улучшенный стандарт шифрования.

29В оригинале используется термин «ephemeral» (эфемерный). Прим. перев.

30Сначала старший байт. Такой порядок называют также сетевым (network byte order). Прим. перев.

31Message Authentication Code — код аутентификации сообщения. Прим. перев.

32Extensible Authentication Protocol — протокол расширяемой аутентификации.

33Man-in-the-middle — атака с прехватом данных, в котором участвует человек.

34IPsec Remote Access Client — клиент удаленного доступа IPsec.

35IPsec Remote Access Server — сервер удаленного доступа IPsec.

36Compression parameter index.

37В оригинале это предложение содержит ошибку, см. https://www.rfc-editor.org/errata_search.php?eid=1671. Прим. перев.

38Generic Payload Header.

39Security Association Payload.

40Пересечение или операция И (AND). Прим. перев.

41В https://www.rfc-editor.org/errata_search.php?eid=2192 была отмечена логическая ошибка в этом предложении, однако текст был сохранен и в последующих версиях документа — RFC 5996 и RFC 7296. Прим. перев.

42В оригинале ошибочно указано Transform Type 2 (см. типы преобразований ниже). В в последующих версиях документа — RFC 5996 и RFC 7296 тип преобразования был указан корректно. Прим. перев.

43В оригинале это предложение содержит ошибку, см. https://www.rfc-editor.org/errata_search.php?eid=1672. Прим. перев.

44В оригинале ошибочно указан RFC 1826, см. https://www.rfc-editor.org/errata_search.php?eid=2279. Прим. перев.

45Cipher Block Chaining — цепочки шифрованных блоков.

46Virtual Private Network — виртуальная частная сеть.

47Attribute Format.

48Type/Length/Value — тип/размер/значение.

49Type/Value — тип/значение.

50Элемент данных Key Exchange. Прим. перев.

51Distinguished Encoding Rules.

52Uniform Resource Locator – однотипный указатель ресурсов. Прим. перев.

53Certification Authority — удостоверяющий центр. Прим. перев.

54Например, с целью организации атак. Прим. перев.

55Без использования такого уведомления все CHILD_SA создаются для работы в туннельном режиме.

56Flow Confidentiality — конфиденциальность потока трафика. Прим. перев.

57В оригинале это предложение содержит ошибку, см. https://www.rfc-editor.org/errata_search.php?eid=2194. Прим. перев.

58Для строк равной длины дистанцией Хэмминга называют число позиций строк, в которых символы различаются. Прим. перев.

59Dynamic Host Configuration Protocol — протокол динамической настройки конфигурации хоста.

60В оригинале это предложение содержит ошибку, см. https://www.rfc-editor.org/errata_search.php?eid=2195. Прим. перев.

61Security Gateway.

62Расширяемый протокол аутентификации.

63В дополнение к поддержке атрибута INTERNAL_IP4_ADDRESS. Прим. перев.

64См. RFC 1918. Прим. перев.

65Single-signon facility.

66При создании нового типа преобразования для него должен создаваться новый реестр.

67Этот документ признан устаревшим и заменен RFC 4291. Прим. перев.

68Копия этой статьи доступна на сайте http://www.cs.berkeley.edu/~christos/classics/diffiehellman.pdf. Прим. перев.

69Копия этого стандарта доступна на сайте http://www.itl.nist.gov/fipspubs/fip186.htm. Прим. перев.

70Этот документ признан устаревшим и заменен RFC 4306. Прим. перев.

71Этот документ признан устаревшим и заменен RFC 4306. Прим. перев.

72Этот документ признан устаревшим и заменен RFC 4306. Прим. перев.

73Этот документ признан устаревшим и заменен RFC 4301. Прим. перев.

74Копия этой статьи доступна на сайте http://people.csail.mit.edu/rivest/Rsapaper.pdf. Прим. перев.

75Копия этого стандарта доступна на сайте http://www.itl.nist.gov/fipspubs/fip180-1.htm. Прим. перев.

76Копия этой статьи доступна на сайте http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.55.294&rep=rep1&type=pdf. Прим. перев.

 




RFC 4306 Internet Key Exchange (IKEv2) Protocol

Network Working Group                                C. Kaufman, Ed.
Request for Comments: 4306                                 Microsoft 
Obsoletes: 2407, 2408, 2409                            December 2005 
Category: Standards Track

Протокол обмена ключами в Internet (IKEv2)

Internet Key Exchange (IKEv2) Protocol

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2005).

Тезисы

В этом документе описана версия 2 протокола обмена ключами в Internet (IKE1). Протокол IKE является частью IPsec и служит для обоюдной аутентификации партнеров, организации и поддержки защищенных связей (SA2).

Эта версия спецификации IKE объединяет содержимое нескольких отдельных документов прежних версий, включая ISAKMP3 (RFC 2408), IKE (RFC 2409), DOI4 (RFC 2407), спецификация работы через NAT5, унаследованную аутентификацию и получение удаленного адреса.

Версия 2 протокола IKE не совместима с версией 1, но имеет достаточно много общего в формате заголовков и обе версии однозначно могут работать через один и тот же порт UDP.

Оглавление

Исключено в версии HTML.

1. Введение

Протоколы защиты IP (IPsec6) обеспечивает конфиденциальность, целостность данных, контроль доступа, а также аутентификацию источника данных для дейтаграмм IP. Эти услуги обеспечиваются за счет поддержки разделяемого состояния между источником и приемником дейтаграмм IP. Это состояние, наряду с другими аспектами, определяет услуги, предоставляемые дейтаграммам, используемые для этих услуг криптографические алгоритмы, а также ключи, используемые на входе криптоалгоритмов.

Организация этого состояния вручную не обеспечивает приемлемого масштабирования. Следовательно, требуется протокол для динамической организации этого состояния. В данном документе описан такой протокол — протокол обмена ключами Internet (IKE). Данное описание относится к версии 2 протокола IKE. Первая версия протокола IKE была определена в RFC 2407, 2408 и 2409 [Pip98, MSST98, HC98]. Данный документ заменяет три упомянутых RFC.

Определения основополагающих терминов, используемых в документе (таких, как защищенная связь или SA) можно найти в [RFC4301].

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [Bra97].

Термин Expert Review (экспертиза) интерпретируется в соответствии с определением [RFC2434].

IKE выполняет взаимную аутентификацию партнеров и организует защищенную связь IKE SA, включающую разделяемый секретный ключ, который может эффективно использоваться при организации SA для протоколов ESP7 [RFC4303] и/или AH8 [RFC4302], и набор криптографических алгоритмов, которые будут использоваться SA для защиты передаваемого трафика. В этом документе термины «набор» (suite) или «шифронабор» (cryptographic suite) обозначают все множество алгоритмов, используемых для защиты SA. Инициатор предлагает один или несколько наборов, перечисляя поддерживаемые им алгоритмы, которые могут быть объединены в наборы или использоваться «вперемешку». IKE может также согласовывать использование компрессии IP (IPComp9) [IPCOMP] совместно в ESP и/или AH SA. Для IKE SA будем использовать обозначение IKE_SA. SA для ESP и/или AH, проходящие через IKE_SA, будем обозначать CHILD_SA.

Весь обмен информацией IKE организован в форме парных сообщений запрос — отклик. Для пар используется термин «обмен» (exchange). Первые сообщения при организации IKE_SA включают обмен IKE_SA_INIT и IKE_AUTH, а за ними следуют обмены CREATE_CHILD_SA или INFORMATIONAL. В общем случае для организации IKE_SA и первой связи CHILD_SA используется один обмен IKE_SA_INIT и один обмен IKE_AUTH (всего 4 сообщения). В исключительных случаях оба обмена могут использоваться неоднократно. В любом случае все обмены IKE_SA_INIT должны быть завершены до начала обмена любого другого типа, после этого должны быть завершены все обмены IKE_AUTH и далее могут выполняться в любом порядке обмены CREATE_CHILD_SA и INFORMATIONAL. В некоторых сценариях между конечными точками IPsec требуется только один обмен CHILD_SA и, следовательно, не возникает дополнительных обменов. Последующие обмены могут использоваться для организации дополнительных CHILD_SA между теми же аутентифицированными парами конечных точек и для выполнения вспомогательных функций.

Поток сообщений IKE всегда состоит из запросов, за которыми следует соответствующий отклик. Ответственность за обеспечение надежности возлагается на запрашивающую сторону. Если отклик не получен в течение заданного времени ожидания, запрашивающая сторона должна повторить запрос (или прервать попытку соединения).

Первый запрос/отклик в сеансе IKE (IKE_SA_INIT) согласует параметры защиты для IKE_SA, передает специальные сигналы nonce и значения Diffie-Hellman.

Вторая пара запрос/отклик (IKE_AUTH) передает аутентификацию, обеспечивает информацию о секретах аутентифицированных сторон и организует защищенную связь для первой (зачастую, единственной) AH или ESP CHILD_SA.

Последующие обмены относятся к типу CREATE_CHILD_SA (создание CHILD_SA) и INFORMATIONAL (удаление SA, сообщения об ошибках и другие служебные функции). Каждый запрос требует отклика. Запросы типа INFORMATIONAL, не содержащие информации (кроме пустого поля Encrypted payload, требуемого синтаксисом) обычно используются для проверки сохранности соединения. Последующие обмены не могут осуществляться, пока не будут завершены начальные обмены. Далее в описании предполагается отсутствие ошибок. Изменения потока, связанные с ошибками, рассмотрены в параграфе 2.21.

1.1. Сценарии использования

Предполагается, что IKE будет использоваться при согласовании SA для протоколов ESP и/или AH SAs во множестве различных сценариев с отличающимися требованиями.

1.1.1. Туннель между защитными шлюзами

             +-+-+-+-+-+            +-+-+-+-+-+
             !Конечная ! Туннель    !Конечная !
Защищенная   !точка    ! IPsec      !точка    !     Защищенная
подсеть  <-->!туннеля  !<---------->!туннеля  !<--> подсеть
             !         !            !         !
             +-+-+-+-+-+            +-+-+-+-+-+

Рисунок 1. Туннель между защитными шлюзами

В этом сценарии ни одна из конечных точек соединений IP не поддерживает IPsec, но расположенные между конечными точками узлы сетей обеспечивают защиту трафика на пути передачи. Защита прозрачна для конечных точек и пакеты через обычную систему маршрутизации передаются в конечную точку туннеля для обработки. Каждая из конечных точек туннеля будет анонсировать множество расположенных за ней адресов и пакеты для этих адресов будут передаваться в туннель с адресом конечного получателя во внутреннем заголовке IP.

1.1.2. Туннель между конечными точками

+-+-+-+-+-+-+                                          +-+-+-+-+-+-+
!           !            Защищенная связь (SA)         !           !
!Защищенная !в туннельном или транспортном режиме IPsec!Защищенная !
!   точка   !<---------------------------------------->!   точка   !
!           !                                          !           !
+-+-+-+-+-+-+                                          +-+-+-+-+-+-+

Рисунок 2. Туннель между конечными точкам

В этом сценарии обе конечные точки соединения IP реализуют IPsec в соответствии с требованиями для хостов в [RFC4301]. Обычно используется транспортный режим без внутренних заголовков IP. Если внутренний заголовок используется, адрес IP в нем будет совпадать с адресом во внешнем заголовке. Для защиты с помощью данной SA согласуется одна пара адресов. Конечные точки могут реализовать средства контроля доступа на прикладных уровнях на основе IPsec-аутентификации участников соединения. Этот сценарий обеспечивает сквозную защиту, которая является одним из принципов работы Internet с момента разработки [RFC1958], [RFC2775] и метода ограничения унаследованных проблем, связанных со сложностью сетей, которые отмечены в [RFC3439]. Хотя этот сценарий не может полноценно применяться в Internet на базе IPv4, он может успешно использоваться внутри сетей intranet на базе IKEv1. Более широкому распространению этого сценария будет способствовать переход на IPv6 и адаптация IKEv2.

В таком сценарии одна или обе конечных точки могут находиться за системой трансляции сетевых адресов (NAT). В этом этом случае туннелируемые пакеты будут инкапсулироваться в UDP так, что номера портов в заголовках UDP можно будет использовать для аутентификации отдельных конечных точек, расположенных за NAT (см. параграф 2.23).

1.1.3. Туннель между конечной точкой и защитным шлюзом

+-+-+-+-+-+-+                          +-+-+-+-+-+
!           !        Туннель           !Конечная !     Защищенная
!Защищенная !         IPsec            !точка    !     подсеть
!точка      !<------------------------>!туннеля  !<--- и/или
!           !                          !         !     Internet
+-+-+-+-+-+-+                          +-+-+-+-+-+

Рисунок 3. Туннель между конечной точкой и защитным шлюзом

В этом сценарии защищенная конечная точка (обычно портативный компьютер) подключается к корпоративной сети с использованием защищенного туннеля IPsec. Туннель может использоваться только для доступа к информации, хранящейся в корпоративной сети, или служить для передачи всего трафика портативного компьютера через офисную сеть для обеспечения возможности использования корпоративного межсетевого экрана, защищающего компьютер от атак из сети Internet. В любом случае защищенной точке будет нужен IP-связанный с защитным шлюзом, чтобы адресованные этой точке пакеты попадали на защитный шлюз и передавались им через туннель на защищенную точку. Этот адрес может выделяться защитным шлюзом статически или динамически. Во втором случае IKEv2 включает механизм, с помощью которого инициатор соединения запрашивает адрес IP, принадлежащий шлюзу, для использования в течение срока действия SA.

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

В этом сценарии защищенная конечная точка может находиться за системой трансляции адресов (NAT). При этом адрес, который будет видеть защитный шлюз, отличается от IP-адреса защищенной конечной точки и пакеты будут инкапсулироваться в дейтаграммы UDP для обеспечения корректной маршрутизации.

1.1.4. Другие сценарии

Обозначение Данные

AUTH аутентификация

CERT сертификат

CERTREQ запрос сертификата

CP конфигурация

D удаление

E зашифровано

EAP расширенная аутентификация

HDR заголовок IKE

IDi идентификация — инициатор

IDr идентификация — отвечающая сторона

KE обмен ключами

Ni, Nr Nonce

N уведомление

SA защищенная связь

TSi селектор трафика — инициатор

TSr селектор трафика — отвечающая сторона

V идентификатор производителя

Возможны и другие сценарии, представляющие собой комбинации перечисленных выше вариантов. Один примечательный вариант объединяет в сете аспекты 1.1.1 и 1.1.3. Подсеть может организовать весь доступ наружу через удаленный защитный шлюз, используя туннель IPsec и тогда внешние сети (Internet) будут маршрутизировать пакеты для подсети защитному шлюзу. Например, некая домашняя сеть может виртуально представляться в сети Internet статическими адресами IP, несмотря на то, что эта сеть подключена через ISP, который выделяет один динамический адрес пользовательскому защитному шлюзу (видимый в Internet статический адрес IP и трансляция IPsec обеспечивается третьей стороной, расположенной в другом месте).

1.2. Начальные обмены

Коммуникации с использованием IKE всегда начинаются с обменов IKE_SA_INIT и IKE_AUTH (в IKEv1 — Фаза 1). Эти начальные обмены включают четыре сообщения, хотя в некоторых сценариях это число может расти. Все коммуникации с использованием IKE состоят из пар «запрос-отклик». Сначала будет описываться базовый обмен, а затем — возможные варианты. Первая пара сообщений (IKE_SA_INIT) согласует криптографические алгоритмы, осуществляет обмен сигналами nonce и обмен Diffie-Hellman [DH].

Вторая пара сообщений (IKE_AUTH) аутентифицирует предыдущие сообщения, обеспечивает обмен аутентификационной информацией и сертификатами, а также создает первую CHILD_SA. Компоненты этих сообщений шифруются и целостность их защищается с использованием ключей, организованных при обмене IKE_SA_INIT, поэтому аутентификационные данные недоступны для подслушивания, а все поля сообщений аутентифицируются.

На врезке справа приведен список обозначений и краткое описание данных, содержащихся в сообщениях.

Содержимое данных в сообщениях подробно рассматривается в разделе 3. Данные, которые являются необязательными, указываются в квадратных скобках — [CERTREQ] показывает возможность включения запроса сертификата.

Начальные обмены имеют вид:

       Инициатор                          Ответчик
      -----------                        ----------
       HDR, SAi1, KEi, Ni   -->

HDR содержит списки параметров защиты (SPI10), номера версий и различные флаги. SAi1 указывает поддерживаемые инициатором криптографические алгоритмы для IKE_SA. В KE передаются значения Diffie-Hellman от инициатора. Ni задает nonce от инициатора.

                            <--    HDR, SAr1, KEr, Nr, [CERTREQ]

Отвечающая сторона выбирает криптографический набор из числа предложенных инициатором и указывает свой выбор в SAr1, завершает обмен Diffie-Hellman в KEr и передает свой сигнал nonce в Nr.

На этом этапе согласования каждая из сторон может генерировать «затравку» SKEYSEED, на основе которой будут создаваться все ключи для данной IKE_SA. Все, кроме заголовков, во всех последующих сообщениях будет шифроваться с дополнительной защитой целостности. Ключи, используемые для шифрования и защиты целостности, создаются на основе SKEYSEED и обозначаются SK_e (encryption — шифрование) и SK_a (authentication — аутентификация для защиты целостности). Для каждого направления создаются отдельные ключи SK_e и SK_a. В дополнение к ключам SK_e и SK_a, создаваемым из значения DH для защиты IKE_SA, создается другая величина SK_d is, которая используется для создания последующего материала для защищенных связей CHILD_SA. Обозначения SK { … } показывают, что эти данные зашифрованы с защитой целостности на основе ключей SK_e и SK_a для соответствующего направления.

       HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                  AUTH, SAi2, TSi, TSr}     -->

Инициатор предъявляет свою идентификацию в IDi, доказывает свое знание ключа, соответствующего IDi и защищает целостность содержимого первого сообщения, используя AUTH (см. параграф 2.15). Он может также передать свой сертификат (сертификаты) в CERT и список своих доверенных привязок11 в CERTREQ. При включении CERT первый представляемый сертификат должен содержать открытый ключ, используемый для проверки поля AUTH. Необязательные данные IDr позволяют инициатору указать, какую идентификацию он хочет получить от отвечающей стороны. Это полезно в тех случаях, когда на машине, где работает отвечающая сторона, поддерживается множество вариантов идентификации для одного адреса IP. Инициатор начинает согласовывать CHILD_SA с использованием SAi2. Завершающие поля (начиная с SAi2) описаны при рассмотрении обмена CREATE_CHILD_SA.

                                   <--    HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

Отвечающая сторона представляет свою идентификацию в IDr, и может передавать один или множество сертификатов (как и у инициатора, сертификат, содержащий публичный ключ для проверки AUTH, должен указываться первым), подтверждает свою идентификацию, защищает целостность второго сообщения с помощью AUTH и завершает согласование CHILD_SA в дополнительных полях, описанных ниже для обмена CREATE_CHILD_SA.

Получателя сообщений 3 и 4 должны проверить корректность расчета всех сигнатур и MAC, а также соответствие имен в ID ключам, используемым для генерации AUTH.

1.3. Обмен CREATE_CHILD_SA

Этот обмен включает одну пару «запрос-отклик» и обозначается, как фаза 2 обмена в IKEv1. Обмен может инициироваться любой из сторон IKE_SA после завершения начальных обменов.

Все сообщения после первоначального обмена шифруются с использованием криптографического алгоритма и ключей, согласованных в первых двух сообщениях обмена IKE. Последующие сообщения используют синтаксис Encrypted Payload (зашифрованные данные), описанный в параграфе 3.14. Все последующие сообщения включаются в Encrypted Payload, даже если они указаны в тексте документа, как «пустые».

Любая из конечных точек может инициировать обмен CREATE_CHILD_SA, поэтому в данной секции термин «инициатор» означает конечную точку, начинающую этот обмен.

CHILD_SA создается путем передачи запроса CREATE_CHILD_SA. Этот запрос может содержать данные KE для дополнительного обмена Diffie-Hellman, позволяющего заблаговременно гарантировать более строгую защиту (секретность) для CHILD_SA. Ключевой материал для CHILD_SA является функцией SK_d, организованного при созданиии IKE_SA, обмена сигналами nonce в процессе обмена CREATE_CHILD_SA, и значения Diffie-Hellman (если данные KE включены в обмен CREATE_CHILD_SA).

В CHILD_SA, создаваемой, как часть начального обмена, недопустимо передавать второй KE и nonce. Сигналы nonce из начального обмена используются при расчете ключей для CHILD_SA.

Запрос CREATE_CHILD_SA включает:

       Инициатор                          Ответчик
      -----------                        ----------
       HDR, SK {[N], SA, Ni, [KEi],
           [TSi, TSr]}             -->

Инициатор передает предложение (предложения) SA в данных SA, nonce в Ni, может передать значение Diffie-Hellman в KEi, а также предложенные селекторы трафика в TSi и TSr. Если этот обмен CREATE_CHILD_SA служит для замены ключей существующей SA, отличной от IKE_SA, ведущие данные N типа REKEY_SA MUST аутентифицируют SA, для которой меняются ключи. Если этот обмен CREATE_CHILD_SA не является заменой ключей для существующей SA, данные N должны быть опущены. Если предложения SA включают различные группы Diffie-Hellman, данные KEi должны быть элементом группы, которую инициатор желает принять от отвечающей стороны. Если это предположение ошибочно, обмен CREATE_CHILD_SA завершится неудачей и будет повторяться с другим KEi.

Сообщение, следующее за заголовком, шифруется а для сообщения и заголовка обеспечивается защита целостности с использованием алгоритмов, согласованных для IKE_SA.

Отклик CREATE_CHILD_SA содержит:

                                  <--    HDR, SK {SA, Nr, [Ker], [TSi, TSr]}

Отвечающая сторона передает (используя то же значение Message ID) воспринятое предложение в данных SA, значение Diffie-Hellman в Ker, если в запрос были включены данные Kei, и выбранный криптографический набор, включающий данную группу. Если отвечающий выбирает криптографический набор с другой группой, он должен отвергнуть запрос. Инициатору следует повторить запрос с данными Kei из группы, выбранной отвечающим.

Селектор трафика для трафика, который будет передаваться в данной SA, указывается в данных TS, которые могут быть подмножеством предложенного инициатором CHILD_SA. Селекторы трафика опускаются, если данный запрос CREATE_CHILD_SA будет использоваться для смены ключа IKE_SA.

1.4. Обмен INFORMATIONAL

В различные моменты работы IKE_SA партнеры могут пожелать передать другой стороне управляющие сообщения, связанные с ошибками, или уведомления о некоторых событиях. Для обеспечения такой возможности в IKE определен информационный (INFORMATIONAL). Обмен INFORMATIONAL должен осуществляться только завершения начальных обменов и организации криптографической защиты с использованием согласованных ключей.

Управляющие сообщения, которые относятся к IKE_SA MUST, должны передаваться в данной IKE_SA. Управляющие сообщения, которые относятся к CHILD_SA должны передаваться под защитой IKE_SA, которая сгенерировала их (или ее наследник, если IKE_SA была заменена при смене ключей).

Сообщения информационного обмена содержат 0 или более элементов данных Notification, Delete и Configuration. Получатель запроса INFORMATIONAL должен передать некий отклик (иначе отправитель будет предполагать потерю сообщения в сети и повторять его). Отклик может быть сообщением без элементов данных. Запросное сообщение в информационном обмене также может не содержать элементов данных. Предполагается, что это может использоваться конечными точками для проверки того, что партнер «жив».

Защищенные связи ESP и AH всегда существуют в паре по одной SA для каждого направления. При закрытии SA должны быть закрыты оба члена пары. К тех случаях, когда SA являются вложенными, а также когда данные (и заголовки IP в туннельном режиме) сначала инкапсулируются с использованием IPComp, затем организовано ESP и, наконец, AH между одной парой конечных точек, все SA должны удаляться вместе. Каждая из конечных точек должна закрыть свои входящие SA и позволить другой точке закрыть соответствующую SA в каждой паре. Для удаления SA используется информационный обмен с передачей одного или множества элементов удаления (Delete Payload), перечисляющих SPI (которые ожидаются в заголовках входящих пакетов) удаляемых SA. Получатель должен закрыть означенные SA. Обычно отклик в информационном обмене будет содержать элементы удаления для парных SA обратного направления. Но существует одно исключение. Если обе стороны набора SA независимо решат закрыть их, каждая может передать элемент удаления и два запроса могут пересечься в сети. Если узел получает запрос удаления для SA, которые он уже указал в запросе удаления, он должен удалить исходящие SA в процессе обработки запроса и входящие SA при обработке отклика. В таких случаях в отклик недопустимо включать элементы удаления для удаленных SA, поскольку это будет приводить к дублированию удаления и может (теоретически) удалить ненужную SA.

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

Обмен INFORMATIONAL определяется следующим образом:

       Инициатор                          Ответчик
      -----------                        ----------
       HDR, SK {[N,] [D,] [CP,]...} -->
                                    <-- HDR, SK {[N,] [D,] [CP],...}

Обработка информационного обмена определяется включенными в него элементами данных.

1.5. Информационные сообщения вне IKE_SA

Если зашифрованный пакет IKE приходит в порт 500 или 4500 с нераспознанным SPI, причиной этого может быть недавний сбой принимающего узла и потеря информации о состоянии, тот или иной системный отказ или атака. Если принимающий узел имеет активную IKE_SA для IP-адреса, с которого пришел пакет, он может передать уведомление о странном пакете через IKE_SA, используя обмен INFORMATIONAL. Если узел не имеет такой IKE_SA, он может отправить информационное сообщение без криптографической защиты по адресу отправителя пакета. Такое сообщение не является частью информационного обмена и для принявшего это сообщение узла недопустимо отвечать на него. Такой ответ может привести к возникновению петли при обмене сообщениями.

2. Детали и вариации протокола IKE

IKE обычно слушает и передает дейтаграммы UDP через порт 500, хотя сообщения IKE принимаются также через порт UDP 4500 с использованием слегка отличающегося формата (см. параграф 2.23). Поскольку протокол UDP использует дейтаграммы (транспорт без гарантии доставки), IKE включает определение процедуры восстановления при ошибках передачи, включая потерю и повторное использование пакетов, а также прием поддельных пакетов. Протокол IKE рассчитан на работу в условиях, когда (1) по крайней мере один из серии переданных повторно пакетов достигает получателя до завершения времени ожидания и (2) канал не переполнен обманными и повторными пакетами так, что это ведет к нехватке ресурсов сети или производительности CPU12 на одной из конечных точек. Даже при невыполнении этих минимальных требований IKE будет прерывать работу «чисто» (как при обрыве сети).

Хотя сообщения IKEv2 должны быть короткими, они содержат структуры данных без жестко заданной верхней границы размера (в частности, сертификаты X.509), а сам протокол IKEv2 не включает механизма фрагментирования больших сообщений. Протокол IP определяет механизм фрагментирования слишком больших дейтаграмм UDP, но максимальный поддерживаемый размер может зависеть от реализации. Более того, использование фрагментации IP открывает реализации для атак на службы (DoS13) [KPS03]. Кроме того, некоторые реализации NAT и/или межсетевых экранов могут блокировать фрагменты IP.

Все реализации IKEv2 должны быть способны передавать, принимать и обрабатывать сообщения IKE размером до 1280 байтов и следует также обеспечивать возможность передачи, приема и обработки сообщений размеров до 3000 байтов. Реализациям IKEv2 следует принимать во внимание максимальный размер поддерживаемых сообщений UDP и можно укорачивать сообщения, убирая из них некоторые предлагаемые сертификаты и криптографические наборы, если это позволит сохранить размер сообщения ниже максимума. Использование форматов «Hash and URL14» там, где это возможно, позволит избежать большинства проблем. В реализациях и конфигурационных параметрах следует принимать во внимание, что в тех случаях, когда поиск URL становится возможным только после организации IPsec SA, проблемы рекурсии могут воспрепятствовать применению упомянутого метода.

2.1. Использование таймеров повтора передачи

Все сообщения в IKE существуют попарно — запрос и отклик. Организация IKE_SA обычно включает две пары запрос-отклик. После организации IKE_SA любая из сторон защищенной связи может в любой момент инициировать запрос и в каждый момент времени «налету» может находиться множество запросов и откликов. Но каждое сообщение помечается, как запрос или отклик и для каждой пары запрос-отклик одна из сторон является инициатором, а другая — ответчиком.

Для каждой пары сообщений IKE инициатор несет ответственность за повтор сообщения при тайм-аутах. Отвечающая сторона никогда не должна передавать отклик повторно без получения повторного запроса. В этом случае ответчик должен передать отклик на повторный запрос, не повторяя связанных с его обработкой действий. Отвечающий должен помнить каждый отклик до момента получения запроса порядковым номером, превышающим номер переданного запроса плюс размер окна (см. параграф 2.3).

IKE является протоколом с гарантированной доставкой в том смысле, что инициатор должен повторять передачу запроса, пока на него не будет получен отклик или не будет принято решение об отказе защищенной связи IKE с отбрасыванием всей информации о состояниях, связанной с данной IKE_SA и всеми CHILD_SA, согласованными в этой IKE_SA.

2.2. Использование порядковых номеров для Message ID

Каждое сообщение IKE содержит идентификатор Message ID, который является частью фиксированного заголовка. Этот идентификатор используется для поиска соответствия между запросами и откликами, а также для аутентификации повтора сообщений.

Message ID представляет собой 32-битовое число, которое принимает нулевое значение при передаче в IKE первого запроса в каждом направлении. Начальные сообщения при организации IKE_SA всегда будут иметь номера 0 и 1. Каждая конечная точка в IKE SA поддерживает два «текущих» значения Message ID — следующее, которое будет использоваться при инициировании запроса и следующее, которое она ожидает получить в запросе от другой стороны. Значения счетчиков инкрементируются при генерации и получении запросов, соответственно. Отклик всегда содержит значение Message ID из соответствующего запроса. Это означает, что после начального обмена каждое целое значение n может появляться в качестве идентификатора 4 разных сообщений — n-ого запроса от исходного инициатора IKE, соответствующего ему отклика, n-ого запроса от исходного ответчика IKE и соответствующего ему отклика. Если стороны делают разное число запросов, значения Message ID в разных направлениях могут существенно различаться. Однако здесь не возникает неоднозначности в сообщениях, поскольку биты инициатора (I) и ответчика (R) в заголовке сообщения показывают, которым из четырех возможных сообщений является данное.

Отметим, что значение Message ID шифруется и для него обеспечивается защита целостности для предотвращения повторного использования сообщений. В маловероятной ситуации, когда значение Message ID достигает предела 32-битового числа, требуется закрыть IKE_SA. Замена ключей IKE_SA ведет к сбросу значений идентификаторов.

2.3. Размер окна для перекрывающихся запросов

Для достижения максимальной производительности IKE конечная точка IKE может вводить множество запросов до получения ответа на кокой-либо из них, если другая точка указала свою способность обрабатывать множественные запросы. Для простоты реализация IKE может выбрать обработку запросов строго в порядке их подачи и/или подачу следующего запроса только после получения ответа на предыдущий. Необходимо ввести некоторые правила для обеспечения интероперабельности между реализациями, использующими разную стратегию.

После организации IKE_SA любая из сторон может инициировать один или множество запросов. Эти запросы могут могут проходить через сеть с изменением порядка следования. Конечная точка IKE должна быть готова к восприятию запроса в то время, когда еще не завершена обработка предыдущего запроса, чтобы избежать возникновения тупиковых ситуаций. Конечной точке IKE следует быть готовой к восприятию и обработке множества запросов при незавершенной обработке имеющихся запросов.

Конечная точка IKE должна ждать отклика на каждое из своих сообщений до передачи следующего сообщения, если она не получила от партнера уведомление SET_WINDOW_SIZE о готовности партнера поддерживать состояние для множества обрабатываемых запросов с целью повышения производительности.

Для конечной точки IKE недопустимо выходить за пределы заявленного партнером размера окна при передаче запросов IKE. Иными словами, если отвечающая сторона заявляет для своего окна размер N, инициатору для того, чтобы отправить запрос X, требуется необходимо дождаться откликов на все запросы, вплоть до X-N. Конечная точка IKE должна хранить копию (или обеспечивать точное воспроизведение) каждого переданного ею запроса, пока на этот запрос не был получен отклик. Конечная точка IKE должна хранить копию (или обеспечивать точное воспроизведение) предыдущих откликов в количестве, равном объявленному ею размеру окна, на случай потери отклика и получения от инициатора повторного запроса.

Конечной точке IKE, поддерживающей окно размером больше 1, следует обеспечивать возможность обработки входящих запросов, доставленных с нарушением порядка, для повышения пропускной способности в случаях разупорядочения пакетов или возникновения отказов в сети.

2.4. Синхронизация состояний и время ожидания для соединений

Конечным точкам IKE разрешается в любой момент забывать все свои состояния, связанные с IKE_SA и набором соответствующих CHILD_SA. Это сделано для обеспечения устойчивости к авариям и перезапускам конечных точек. Важно, чтобы при аварии или повторной инициализации состояния конечной точки другая сторона детектировала такие события и прекращала бы расход полосы сети на передачу пакетом через отброшенную SA, которые будут уходить в «черную дыру».

Поскольку протокол IKE был разработан с учетом возможности атак на отказ служб (DoS) из сети, для конечной точки недопустимо констатировать отказ другой конечной точки на основе какой-либо маршрутной информации (например, сообщений ICMP) или сообщений IKE, приходящих без криптографияеской защиты (например, сообщений Notify о неизвестных SPI). Конечная точка должна констатировать отказ другой конечной точки только в случаях повторяющихся в течение всего периода ожидания отказах (отсутствии ответов) при попытках контакта с этой точкой или при получении криптографически защищенного уведомления INITIAL_CONTACT для другой IKE_SA с такой же аутентификацией. Конечной точки на основании соответствующей маршрутной информации и инициировать запрос для проверки жизнеспособности другой точки. Для такой проверки в IKE предусмотрены пустые сообщения INFORMATIONAL, которые (подобно всем запросам IKE) требуют подтверждения (отметим, что в контексте IKE_SA «пустое» сообщение представляет собой заголовок, за которым следует поле Encrypted, не содержащее данных). Если от другой стороны недавно было получено криптографически защищенное соединение, незащищенные уведомления можно игнорировать. Реализации должны ограничивать частоту операций, выполняемых на основе незащищенных соединений.

Число попыток и продолжительность времени ожидания не задаются данной спецификацией, поскольку они не оказывают влияния на интероперабельность. Предлагается повторять передачу сообщения по крайней мере дюжину раз в течение периода по крайней мере в несколько минут прежде, чем отказаться от SA, однако в разных средах эти параметры могут различаться. Для предотвращения возможных перегрузок период повтора передачи сообщений должен возрастать экспоненциально. Если на всех SA, связанных с IKE_SA, присутствовал только исходящий трафик, важно убедиться в жизненности другой конечной точки для предотвращения «черных дыр». Если в течение некоторого времени не было получено криптографически защищенных сообщений в IKE_SA или любой из дочерних CHILD_SA, система должна проверить жизненность удаленной точки для предотвращения передачи сообщений «мертвому» партнеру. Получение свежего, криптографически защищенного сообщения в IKE_SA или любой из дочерних CHILD_SA гарантирует жизненность IKE_SA и всех дочерних CHILD_SA. Отметим, что это вносит требования к обработке отказов конечных точек IKE. Для реализации недопустимо продолжать передачу в любую SA, если тот или иной отказ не позволяет принимать сообщения на всех связанных SA. Если возможен отказ одной CHILD_SA независимо от других без возможности для IKE_SA передачи сообщения Delete, для таких SA должны согласовываться раздельные IKE_SA.

Существуют DoS-атаки на инициатора IKE_SA, которых можно избежать в случае применения инициатором соответствующих мер. Поскольку два первых сообщения при организации SA не защищаются криптографически, атакующий может ответить на сообщения инициатора раньше, чем вызываемая сторона, и сорвать организацию соединения. Для предотвращения этого инициатор может выбрать восприятие множества откликов на свое первое сообщение, трактуя их, как потенциально легитимные, а потом отбросить все некорректные полуоткрытые соединения, когда будет получен корректный, криптографически защищенный отклик на любой из его запросов. После получения криптографически корректного отклика все последующие отклики15 следует игнорировать, независимо от их криптографической корректности.

Отметим, что с приведенными правилами не возникает необходимости согласования срока жизни SA. Если IKE предполагает, что партнер не работает на основе повторяющегося отсутствия подтверждений для сообщения IKE, тогда IKE SA и все дочерние CHILD_SA, организованные в данной IKE_SA, удаляются.

Конечная точка IKE может в любой момент удалить неактивную CHILD_SA в целях освобождения ресурсов, используемых для поддержки состояния этих связей. Если конечная точка IKE принимает решение об удалении CHILD_SA, она должна передать другой стороне элемент Delete для уведомления об удалении. Это может быть похоже на тайм-аут для IKE_SA. Закрытие IKE_SA ведет к неявному закрытию всех связанных CHILD_SA. В этом случае конечной точке IKE следует передать элемент Delete, показывающий удаление IKE_SA.

2.5. Номера версий и совместимость

В этом документе описывается версия 2.0 протокола IKE — старшая часть версии имеет номер 2, а младшая — 0. Очевидно, что некоторые реализации захотят поддерживать версии 1.0 и 2.0, а в будущем и другие версии.

Старшую часть номера версии следует менять только в тех случаях, когда формат пакетов или требуемые действия меняются столь существенно, что узлы старой версии не смогут взаимодействовать напрямую с узлами более новой версии, если они будут просто игнорировать поля непонятные новой версии и выполнять действия, заданные в старой спецификации. Младшая часть номера версии показывает новые возможности и должна игнорироваться узлом с меньшим значением младшей части номера версии, но использоваться для информации с большим значением младшего номера версии. Например, младшая часть может показывать возможность обработки новых уведомляющих сообщений. Узел с большим значением младшей части номера будет просто отмечать неспособность своего корреспондента понимать такие сообщения и, следовательно, передавать их.

Если конечная точка получает сообщение с большим (чем у нее) значением старшей части номера версии, она должна отбросить такое сообщение; следует также передать в ответ неаутентифицированное уведомление, содержащее поддерживаемое значение старшей части номера версии. Если конечная точка поддерживает версию со старшей частью n и m, она должна также поддерживать все версии между n и m. Если такая точка получает сообщение поддерживаемой версии, она должна отвечать сообщением той же версии. Для предотвращения ситуаций, когда пара узлов использует старшую часть номера версии меньше максимально поддерживаемого обоими узлами номера, в IKE используется флаг, показывающий, что узел способен поддерживать больший номер версии.

Таким образом, старшая часть номера версии в заголовке IKE показывает номер версии для данного сообщения, а не номер версии, поддерживаемой отправителем. Если инициатор способен поддерживать версии n, n+1 и n+2, а отвечающая сторона поддерживает версии n и n+1, они согласуют использование версии n+1, а инициатор будет устанавливать флаг способности поддерживать более высокую версию. Если узлы по ошибке (или в результате активной атаки) согласуют использование версии n, тогда оба узла будут указывать поддержку более высокой версии. В этом случае они должны разорвать соединение и организовать его заново с использованием версии n+1.

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

Для обеспечения совместимости с более новыми версиями во всех резервных полях реализации версии 2.0 должны устанавливать значение 0, а при получении сообщений такие реализации должны игнорировать содержимое резервных полей (будьте консервативными при передаче и либеральными при приеме). В результате новые версии протокола смогут использовать резервные поля так, что их значения будут игнорироваться реализациями, не понимающими таких полей. Аналогично, типы данных, которые не определены, являются резервными16.

IKEv2 добавляет флаг «критичности» (critical) к каждому заголовку данных для более гибкой совместимости с грядущими версиями. Если флаг critical установлен, а тип данных нераспознан, сообщение должно быть отвергнуто, а отклик на запрос IKE, включающий эти данные, должен включать элемент Notify UNSUPPORTED_CRITICAL_PAYLOAD, показывающий прием нераспознанных критичных данных. Если флаг критичности не установлен, нераспознанный элемент должен игнорироваться.

Хотя в будущем могут добавляться новые элементы данных, которые будут появляться вперемешку с определенными в этой спецификации полями, реализации должны передавать определенные в этой спецификации элементы в том порядке, который показан на рисунках раздела 2 и реализациям следует отвергать некорректные сообщения с другим порядком элементов данных.

2.6. Cookie

Термин cookie, введенный Karn и Simpson [RFC2522] в Photuris — раннем варианте системы управления ключами IPsec, продолжает использоваться до настоящего времени. Фиксированный заголовок протокола управления ключами и защищенными связями Internet (ISAKMP) [MSST98] включает два восьмиоктетных поля cookies и этот синтаксис используется в IKEv1 и IKEv2, хотя в последнем эти поля обозначаются, как IKE SPI, и имеется новое отдельное поле в элементе Notify, которое сохраняет значение cookie.

Изначально два восьмиоктетных поля в заголовке использовались в качестве идентификаторов соединений в начальных пакетах IKE. Каждая из конечных точек выбирает одно или два значения SPI, которые следует выбирать так, чтобы они однозначно идентифицировали IKE_SA. Нулевое значение SPI является специальным и показывает, что удаленное значение SPI отправителю еще не известно.

В отличие от ESP и AH, где только значение SPI для получателя появляется в заголовке пакета, в IKE каждое сообщение содержит также SPI отправителя. Поскольку значение SPI, выбранное исходным инициатором IKE_SA, всегда передается первым, конечная точка со множеством открытых IKE_SA, которая хочет найти подходящую IKE_SA по выбранному для нее значению SPI, должна просматривать значение флага I (инициатор) в заголовке для определения где искать — в первой или второй группе из 8 октетов.

В первом сообщении начального обмена IKE инициатор не знает значение SPI отвечающей стороны и будет, следовательно, помещать в это поле нулевое значение.

Возможной атакой на IKE является истощение ресурсов на хранение состояний и ресурсов CPU, когда объект атаки в лавинном режиме получает запросы на организацию сессий с подставных адресов IP. Воздействие таких атак можно снизить, если реализация отвечающей стороны по минимуму использует CPU и не фиксирует состояния SA до того, как узнает, что инициатор может получать пакеты по адресу, указанному в запросе. Для решения этой задачи ответчику следует при обнаружении большого числа полуоткрытых IKE_SA отвергать стартовые сообщения IKE, если они не содержат элемента Notify типа COOKIE. Взамен ответчику следует передавать в качестве отклика незащищенное сообщение IKE и включать в него COOKIE Notify с данными cookie для возврата. Инициатор, получивший такой отклик, должен повторить IKE_SA_INIT с элементом Notify типа COOKIE, содержащим предложенные ответчиком данные cookie в качестве первого элемента, сохраняя остальные элементы данных. Начальный обмен в таком случае будет иметь вид:

       Инициатор                          Ответчик
      -----------                        ----------
       HDR(A,0), SAi1, KEi, Ni   -->
                                 <-- HDR(A,0), N(COOKIE)
       HDR(A,0), N(COOKIE), SAi1, KEi, Ni   -->
                                 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]
       HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
           AUTH, SAi2, TSi, TSr} -->
                                 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

Два первых сообщения не оказывают влияния на состояние инициатора и ответчика за исключением обмена cookie. В частности, порядковые номера в четырех первых сообщениях будут иметь нулевые значения, а в двух последних сообщениях приведенного примера номера будут иметь значение 1. «A» обозначает значение SPI, присвоенное инициатором, а «B» — значение, присвоенное ответчиком.

Реализации IKE следует поддерживать генерацию cookie ответчиком так, чтобы не требовалось сохранять какое-либо состояние для проверки корректности cookie при получении второго сообщения IKE_SA_INIT. Выбор алгоритма и используемый для cookie синтаксис не оказывают влияния на интероперабельность, поэтому не задаются данной спецификацией. Ниже приведен пример использования cookie конечной точкой для частичной защиты от DoSатак.

Хорошим способом реализации такой защиты является установка ответчиком cookie по следующему алгоритму:

      Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

где <secret> — случайное значение, известное только ответчику и периодически сменяемое, | указывает конкатенацию. Значение <VersionIDofSecret> следует менять всякий раз при смене <secret>. Значение cookie может быть рассчитано заново при получении IKE_SA_INIT второй раз и полученное значение сравнивается со значением cookie в принятом сообщении. Если значения совпадают, ответчик знает, что значение cookie было создано после замены <secret> и значение IPi должно совпадать с адресом отправителя, полученным в первом сообщении. Включение SPIi в расчет обеспечивает создание различных значений cookie для случаев, когда множество IKE_SA создается одновременно (предполагается, что инициаторы устанавливают уникальные значения SPIi). Включение в хэш значения Ni не позволяет атакующему, который увидел только сообщение 2, корректно подменить сообщение 3.

Если значение <secret> меняется в процессе инициализации соединения, сообщение IKE_SA_INIT может быть возвращено с отличным от текущего значением <VersionIDofSecret>. Ответчик в таком случае может отвергнуть сообщение, передавая другой отклик с новым значением cookie, или может сохранять старое значение <secret> на короткое время после его замены и принимать cookie, рассчитанные с использованием этого значения. Ответчику не следует воспринимать cookie неограниченно долго после смены <secret>, поскольку это будет нарушать часть защиты от DoS-атак. Ответчику следует менять значение <secret> достаточно часто, особенно во время атак.

2.7. Согласование криптоалгоритма

Элемент данных типа SA показывает предложения в части выбора протоколов IPsec (IKE, ESP и/или AH) для SA, а также криптографических алгоритмов, связанных с каждым протоколом.

Элемент данных SA включает одно или несколько предложений. Каждое из предложений включает один или несколько протоколов (обычно один). Каждый протокол включает одно или несколько преобразований, каждое из которых задает криптографический алгоритм. Каждое преобразование может включать атрибуты (атрибуты нужны лишь в тех случаях, когда идентификатор преобразования не задает криптографический алгоритм полностью).

Такая иерархическая структура была разработана для эффективного представления предложений по выбору криптографических наборов, когда число поддерживаемых наборов велико, поскольку множество значений приемлемо для множества платформ. Отвечающая сторона должна выбрать один набор, который может быть любым подмножеством предложения в SA, выбранным в соответствии с приведенными ниже правилами:

Каждое предложение включает, по крайней мере, один протокол. Если предложение принимается элемент SA в отклике должен содержать те же протоколы в том же порядке, как они были указаны в предложении. Ответчик должен принять одно из предложений или отвергнуть все предложения и возвратить сообщение об ошибке (Например, если предложение включает протоколы ESP и AH и это предложение принимается, оба протокола ESP и AH должны восприниматься. Если ESP и AH включены в разные предложения, ответчик должен принять только один из этих протоколов17).

Каждый предлагаемый протокол IPsec содержит, по крайней мере, одно преобразование. Каждое преобразование включает тип преобразования. Принимаемые криптографические наборы должны содержать в точности одно преобразование каждого типа, включенного в предложение. Например, если предложение ESP включает преобразования ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES с размером ключа 256, AUTH_HMAC_MD5 и AUTH_HMAC_SHA, принятый набор должен включать одно преобразование ENCR_ и одно преобразование AUTH_. Таким образом, возможно шесть комбинаций.

Поскольку инициатор передает свое значение Diffie-Hellman в сообщении IKE_SA_INIT, он должен угадать группу Diffie-Hellman, которую ответчик выберет из списка поддерживаемых групп. Если выбор инициатора окажется ошибочным, ответчик будет возвращать элемент данных Notify типа INVALID_KE_PAYLOAD, показывающий выбранную группу. В таком случае инициатор должен повторить запрос IKE_SA_INIT с указанием корректной группы Diffie-Hellman. Инициатор должен снова предложить полный набор допустимых криптографических наборов, поскольку сообщение с отказом было передано без аутентификации. Если этого не делать, активный атакующий сможет принудить конечные точки к выбору наиболее слабого криптографического набора из числа поддерживаемых обеими сторонами.

2.8. Смена ключей

Защищенные связи IKE, ESP и AH используют секретные ключи, которые следует применять в течение ограниченного периода времени для защиты ограниченного объема данных. Эти требования ограничивают срок существования защищенных связей. Когда время жизни защищенной связи заканчивается, дальнейшее использование такой связи недопустимо. При необходимости может быть организована новая защищенная связь. Повторная организация защищенной связи при завершении срока существования последней называется сменой ключей (rekeying).

Для того, чтобы сохранить возможность создания реализаций IPsec с минимальным набором возможностей, смена ключей SA без повторной организации IKE_SA целиком является необязательной. Реализация может отвергать все запросы CREATE_CHILD_SA в IKE_SA. Если срок жизни SA закончился или близок к завершению и попытки смены ключей с использованием описанных здесь механизмов не дали положительного результата, реализация должна закрыть IKE_SA и все дочерние CHILD_SA, а после этого может организовать новые связи. Реализациям следует поддерживать замену ключей для SA, поскольку это обеспечивает повышение производительности и снижение числа пакетов, теряемых в переходный период.

Для смены ключей CHILD_SA в существующей IKE_SA создается новая, эквивалентная SA (см. параграф 2.17 ниже) и после создания старая связь удаляется. Для смены ключей IKE_SA создается новая, эквивалентная IKE_SA (см. параграф 2.18 ниже) с партнером, который в старой IKE_SA совместно использовался в CREATE_CHILD_SA. Созданная таким путем IKE_SA наследует все CHILD_SA исходной in-place. Используется новая IKE_SA для всех управляющих сообщений, требуемых для поддержки CHILD_SA, созданных старой IKE_SA, после чего старая IKE_SA удаляется. Элемент данных Delete для удаления самой связи должен быть последним запросом, передаваемым через старую IKE_SA.

Ключи SA следует менять заранее, не дожидаясь, пока время жизни старых связей закончится и использовать их станет невозможно. Хотя между организацией новой SA и завершением срока жизни старой может остаться достаточно времени, трафик может быть переключен в новую SA.

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

Если политика обеих сторон в части времени жизни совпадает, они могут ввести запросы на смену ключей одновременно (это приведет к созданию избыточных SA). Для снижения вероятности такого события следует использовать вариации периода смены ключей (при получении уведомления о необходимости замены ключей вносится случайная задержка).

Такая форма смены ключей может приводить к временному существованию множества похожих SA между одной парой узлов. При наличии двух SA, подходящих для получения пакетов, узел должен воспринимать входящие пакеты из обеих SA. Если при таком конфликте создаются избыточные SA, связь, имеющую наименьшее из четырех использованных в этих двух обмена значений nonce, следует закрыть (конечной точке, которая создала эту связь).

Отметим, что существование параллельных SA с одинаковым трафиком между парой конечных точек разрешено в IKEv2 осознанно. Одной из причин этого является поддержка различий в качестве обслуживания трафика (QoS18) между SA (см. [RFC2474], [RFC2475] и параграф 4.1 в [RFC2983]). Следовательно, в отличие от IKEv1, комбинация конечных точек и селекторов трафика может не быть уникальным идентификатором SA между парой точек, поэтому принятое при смене ключей в IKEv1 эвристическое удаление SA на основе совпадения селекторов трафика не следует использовать.

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

Существуют интервалы времени (в частности, в присутствии потерь пакетов), когда конечные точки могут по разному трактовать состояние SA. Отвечающая на CREATE_CHILD_SA сторона должна быть готова к восприятию сообщений через SA до передачи своего отклика на запрос создания связи, поэтому здесь для инициатора не возникает неоднозначности. Инициатор может начать передачу в SA сразу после обработки отклика. Иницииатор, однако, не может принимать через новую SA до получения и обработки отклика на свой запрос CREATE_CHILD_SA. Как, в таком случае, ответчик может узнать о возможности начать передачу в новую SA?

С точки зрения технической корректности и интероперабельности ответчик может начать передачу через SA, как только он отправит свой отклик на запрос CREATE_CHILD_SA. Однако в некоторых случаях это может привести к неоправданному отбрасыванию пакетов, поэтому реализация может принять решение о задержке такой передачи.

Ответчик может быть уверен в том, что инициатор готов получать сообщения через SA, если (1) он получил криптографически корректное сообщение через новую SA или (2) новая SA создана при замене ключей для существующей SA и был получен запрос IKE на закрытие замененной SA. При смене ключей SA ответчику следует продолжать передачу сообщений через старую SA, пока не будет выполнено какое-либо из приведенных выше условий. При создании новой SA ответчик может отложить передачу сообщений через нее до получения сообщения через нее или завершения времени ожидания. Если инициатор получает сообщение в SA, для которой он еще не получил отклика на свой запрос CREATE_CHILD_SA, ему следует интерпретировать это событие, как потерю пакетов, и передать запрос CREATE_CHILD_SA повторно. Инициатор может передать бутафорское (dummy) сообщение через новую SA, если у него нет сообщений в очереди, чтобы уведомить ответчика о своей готовности к приему сообщений.

2.9. Согласование селекторов трафика

Когда полученный поддерживающей RFC4301 системой IPsec пакет IP соответствует «селектору защиты» в соответствии с SPD19, подсистема должна защитить пакет с использованием IPsec. Если SA еще не существует, ее создание является задачей IKE. Поддержка SPD в системе выходит за пределы IKE (см. [PFKEY] в качестве примера протокола), хотя некоторые реализации могут обновлять свои SPD в контакте с работающим IKE (см., для примера, сценарий 1.1.3).

Элементы данных TS20 позволяют конечным точкам обмениваться некой информацией из SPD со своими партнерами. Элементы TS задают критерии выбора пакетов, которые будут передаваться через вновь созданную SA. Это может служить проверкой согласованности в некоторых сценариях для контроля непротиворечивости SPD. В других случаях это ведет к динамическому обновлению SPD.

В каждом из сообщений обмена, создающего пару CHILD_SA, появляется два элемента TS. Каждый из TS содержит один или множество селекторов трафика. Каждый селектор состоит из диапазона адресов (IPv4 или IPv6), диапазона портов и идентификатора протокола IP. В поддержку сценария, описанного в параграфе 1.1.3, инициатор может запросить у отвечающей стороны выделение адреса IP с его кратким описанием (что это?).

IKEv2 позволяет ответчику выбрать подмножество селекторов трафика, предложенных инициатором. Это может происходить в тех случаях, когда конфигурация двух конечных точек была изменена, но только одна сторона получила новую информацию. Поскольку обе конечных точки могут настраиваться разными людьми, может возникать период несовместимости даже при отсутствии ошибок. Это также разрешает заведомо разные конфигурации, когда одна сторона настроена на туннелирование всех адресов и обновление списка зависит от другой стороны.

Первый из двух элементов TS называют TSi21, а второй — TSr22. TSi задает адрес отправителя трафика, пересылаемого от инициатора (или адрес получателя трафика, пересылаемого инициатору) пары CHILD_SA. TSr указывает адрес получателя трафика, пересылаемого ответчика (или адрес отправителя трафика, пересылаемого от ответчика) пары CHILD_SA. Например, если исходный инициатор запрашивает создание пары CHILD_SA и хочет туннелировать весь трафик из подсети 192.0.1.* на своей стороне в подсеть 192.0.2.*23 на стороне ответчика, инициатор будет включать один селектор трафика в каждый элемент TS. TSi будет задавать диапазон адресов 192.0.1.0 — 192.0.1.255, а TSr — диапазон 192.0.2.0 — 192.0.2.255. Предположим, что предложение будет принято ответчиком — тогда он будет передавать обратно идентичные элементы TS.

Ответчику разрешено сужать выбор путем выделения подмножества трафика (например, путем исключения или диапазона для одного или множества элементов набора дескрипторов трафика), но выбранное подмножество не должно быть пустым.

Политика отвечающей стороны может содержать множество меньших диапазонов, охватываемое предложенным инициатором селектором трафика, причем политика требует передачи трафика для этих диапазонов через разные SA. Продолжим использование приведенных выше для примера адресов. Ответчик может иметь политику, которая позволяет туннелировать эти адреса в направлении инициатора и от него, но может требовать, чтобы для каждой пары адресов независимо согласовывалась CHILD_SA. Если инициатор генерирует свой запрос в ответ на пакет с адреса 192.0.1.43, направленный по адресу 192.0.2.123, у ответчика не будет способа определить, какую пару адресов следует включить в этот туннель и он будет пытаться угадать или отбросить запрос со статусом SINGLE_PAIR_REQUIRED.

Чтобы позволить ответчику выбрать подходящий диапазон в том случае, когда инициатор запрашивает SA в результате получения пакета данных, инициатору следует включить в качестве первого селектора трафика в каждом элементе Tsi и TSr очень специфичный селектор трафика, включающий адреса в пакете, вызвавшем запрос. В нашем примере инициатор будет включать в TSi два селектора трафика — первый будет содержать диапазон адресов 192.0.1.43 — 192.0.1.43, а также порт отправителя и протокол IP из пакета, а второй — диапазон 192.0.1.0 — 192.0.1.255 со всеми портами и протоколами. Инициатор будет также включать два селектора трафика в TSr.

Если политика отвечающей стороны не позволяет принять весь набор селекторов трафика из запроса инициатора, но позволяет принять первый селектор TSi и TSr, ответчик должен сузить селекторы трафика до подмножества, включающего первый выбор инициатора. В приведенном примере ответчик может возвратить TSi 192.0.1.43 — 192.0.1.43 с поддержкой всех портов и протоколов IP.

Если инициатор создает CHILD_SA пару не в ответ на получение пакета, а, например, при старте, может не быть предпочтений в части адресов для начального туннеля. В таких случаях первые значения TSi и TSr могут задавать диапазоны, а не конкретные адреса и ответчик выбирает подходящее подмножество указанных инициатором TSi и TSr. Если ответчика устраивает несколько подмножеств, которые нельзя объединить, ответчик должен принять некое подмножество и может включить в сообщение элемент Notify типа ADDITIONAL_TS_POSSIBLE для индикации инициатору возможности повтора. Такая ситуация возникает только в тех случаях, когда конфигурации инициатора и ответчика различаются. Если инициатор и ответчик согласовали гранулярность туннелей, инициатор никогда не будет запрашивать более широкий туннель, нежели приемлет отвечающая сторона. Такие расхождения в конфигурационных параметрах следует заносить в системный журнал ошибок.

2.10. Элементы nonce

Каждое сообщение IKE_SA_INIT содержит nonce. Эти nonce используются в качестве входной информации для криптографических функций. Запросы CREATE_CHILD_SA и отклики CREATE_CHILD_SA также включают nonce. Эти nonce используются для повышения эффективности метода, используемого при получении ключей для CHILD_SA, обеспечения достаточно высокого уровня случайности для псевдослучайных битов, получаемых из ключа Diffie-Hellman. Элементы nonce, используемые в IKEv2, должны выбираться случайным образом, должны иметь размер не менее 128 битов и не менее половины размера ключа согласованной prf24. При использовании некого общего источника случайных чисел для ключей и nonce нужно быть осторожными, чтобы использование nonce не привело к компрометации ключей.

2.11. Использование адресов и портов

IKE работает по протоколу UDP через порты 500 и 4500, неявно устанавливая связи ESP и AH для тех же адресов IP. Адреса IP и номера портов во внешнем заголовке не защищаются криптографически и протокол IKE может работать даже через устройства трансляции адресов (NAT). Реализация должна воспринимать входящие запросы даже из портов с номерами, отличными от 500 или 4500 и должна отвечать на адрес и порт, с которых был получен запрос. Реализация должна указать в отклике адрес и порт, через которые был принят запрос, в качестве адреса и порта отправителя. Функции IKE идентичны для протоколов IPv4 и IPv6.

2.12. Многократное использование экспоненциалов Diffie-Hellman

Для обеспечения высокого уровня защиты25 IKE генерирует короткоживущие ключи с использованием обмена Diffie-Hellman. Это означает, что после закрытия соединения соответствующие ключи забываются. Если кто-либо смог записать всю переданную через соединение информацию и получил доступ к долгосрочным ключам обеих сторон соединения, он не сможет восстановить ключи, которые использовались для соединения без перебора26 всего пространства сеансовых ключей.

В соответствии с требованиями по обеспечению высокого уровня защиты каждая конечная точка при закрытии соединения должна забыть не только использованные в соединении ключи, но и любую информацию, которая применялась для расчета этих ключей. В частности необходимо забыть секреты, использованные в расчетах Diffie-Hellman и любые состояния, которые могли бы сохраниться в состоянии генератора псевдослучайных чисел, используемого для пересчета секретов Diffie-Hellman.

Поскольку расчет экспоненциалов Diffie-Hellman требует значительных вычислительных ресурсов, конечные точки могут получать преимущества в результате использования этих экспоненциалов для организации множества соединений. Существует несколько вариантов обоснованной стратегии многократного использования экспоненциалов. Конечная точка выбирает новый экспоненциал периодически, хотя это может приводить к снижению уровня защиты. Другим вариантом является сохранение информации об использованных для каждого соединения экспоненциалов и удалять связанную с экспоненциалом информацию только после закрытия соответствующего соединения. Это позволяет использовать экспоненциалы многократно без снижения уровня защиты, но за счет поддержки дополнительной информации о состоянии.

Решение вопроса о многократном использовании экспоненциалов Diffie-Hellman и способе такого использования является частным и не влияет на интероперабельность. Реализация, использующая экспоненциалы многократно, может принять решение о сохранении экспоненциалов, использованных другой точкой в предшествующих обменах, избегая второй половины расчетов при использовании этих экспоненциалов.

2.13. Материал для генерации ключей

В контексте IKE_SA согласуются четыре криптографических алгоритма — алгоритм шифрования, алгоритм защиты целостности, группа Diffie-Hellman и псевдослучайная функция (prf). Последняя используется при создании ключевого материала для всех криптографических алгоритмов, используемых как в IKE_SA, так и в дочерних CHILD_SA.

Мы полагаем, что каждый алгоритм шифрования и защиты целостности использует ключ фиксированного размера и случайно выбранное значение фиксированного размера может служить подходящим ключом. Для алгоритмов, которые воспринимают ключи переменного размера, должен указываться фиксированный размер ключа в процессе согласования криптографических преобразований. Для алгоритмов, в которых не все значения являются допустимыми ключами (например, DES или 3DES с четностью ключа) криптографическим преобразованием должен задаваться алгоритм создания ключей из произвольных значений. Для функций защиты целостности на основе кода HMAC27 фиксированным размером ключа является размер вывода нижележащей функции хэширования. Когда функций prf принимает ключ переменной длины и данные переменной длины, давая результат фиксированного размера (например, при использовании HMAC), применяются формулы из этого документа. Когда ключ для prf имеет фиксированный размер, представленные в качестве ключа данные усекаются или дополняются нулями, если приведенная ниже формула не задает специальной обработки.

Ключевой материал всегда производится, как выход согласованного алгоритма prf. Поскольку количество требуемого ключевого материала может быть больше, чем размер вывода алгоритма prf, мы будем использовать prf итеративно. Обозначим prf+ функцию, которая дает на выходе псевдослучайный поток на основе входной информации prf в соответствии с приведенными ниже правилами (| обозначает конкатенацию).

   prf+ (K,S) = T1 | T2 | T3 | T4 | ...

где:

   T1 = prf (K, S | 0x01)
   T2 = prf (K, T1 | S | 0x02)
   T3 = prf (K, T2 | S | 0x03)
   T4 = prf (K, T3 | S | 0x04)

и т. д., пока не будет достаточно материала для расчета всех требуемых ключей. Ключи берутся из выходной строки без учета границ (например, если нужен 256-битовый ключ AES28 и 160-битовый ключ HMAC, а функция prf дает на выходе 160 битов, ключ AES будет взят из T1 и начальной части T2, а ключ HMAC возьмет остаток T2 и начало T3).

Константа, добавляемая в конец каждой строки на входе prf, представляет собой один октет. Использование функции prf+ в данном документе не выходит за пределы 255-кратного увеличения размера результата prf.

2.14. Генерация ключевого материала для IKE_SA

Для расчета разделяемых ключей сначала вычисляется значение SKEYSEED на основе nonce из обмена IKE_SA_INIT и разделяемого секрета Diffie-Hellman созданного при этом обмене. Значение SKEYSEED используется для расчета семи других секретов — SK_d применяется при создании новых ключей для CHILD_SA, создаваемых в данной IKE_SA; SK_ai и SK_ar применяются в качестве ключа алгоритма защиты целостности для аутентификации компонент сообщений в последующих обменах; SK_ei и SK_er применяются для шифрования (и дешифровки) всех последующих обменов; SK_pi и SK_pr применяются при генерации элемента данных AUTH.

SKEYSEED и производные от него ключи рассчитываются следующим образом:

SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)

(левая часть второго уравнения показывает, что значения SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi и SK_pr берутся в указанном порядке из битов результата prf+). Параметр g^ir является разделяемым секретом из краткосрочного29 обмена Diffie-Hellman. Значение g^ir представляется строкой октетов в формате big endian30 с дополнением при необходимости нулями для выполнения требований по размеру модуля. Ni и Nr — значения элементов nonce, извлеченные из любых заголовков. Если согласованная функция prf принимает ключ фиксированного размера, а суммарная длина Ni и Nr превышает нужное значения, берется половина (первая) битов из Ni и половина (первая) битов из Nr.

Для двух направления потока трафика используются разные ключи. Ключи, служащие для защиты сообщений от исходного инициатора, обозначаются SK_ai и SK_ei. Ключи, служащие для защиты сообщений в другом направлении, обозначаются SK_ar и SK_er. Каждый алгоритм принимает фиксированное число битов ключевого материала, заданное как часть алгоритма. Для алгоритмов защиты целостности на основе хэш-функций размер ключа всегда равен размеры результата нижележащей хэш-функции.

2.15. Аутентификация IKE_SA

Если не используется расширяемая аутентификация (см. параграф 2.16), партнеры аутентифицируют себя посредством подписи (или MAC31 с использованием разделяемого секрета в качестве ключа) для блока данных. Для ответчика подписываемые данные начинаются с первого октета первого SPI в заголовке второго сообщения и заканчиваются последним октетом последнего элемента данных во втором сообщении. В конце к этому добавляется (с целью расчета подписи) значение nonce Ni от инициатора (просто значение, а не содержащий его элемент данных) и значение prf(SK_pr,IDr’), где IDr’ — элемент ID ответчика без фиксированного заголовка. Отметим, что ни одно из значений Ni и prf(SK_pr,IDr’) не передается. Подобно этому инициатор подписывает первое сообщение, начиная с первого октета первого SPI в заголовке и заканчивая последним октетом последнего элемента данных. В конце к этому добавляется (для расчета подписи) значение nonce Nr от ответчика и значение prf(SK_pi,IDi’). В приведенных выше расчетах IDi’ и IDr’ являются полными элементами данных ID без фиксированного заголовка. Для защиты обмена критично наличие подписи каждой стороны для nonce другой стороны.

Отметим, что подписываются все элементы данных, включая и те, которые не определены в этом документе. Если первое сообщение в обмене передается дважды (второй раз с cookie ответчика и/или другой группой Diffie-Hellman), подписывается вторая версия сообщения.

В дополнение к сказанному сообщения 3 и 4 могут включать сертификат или цепочку сертификатов, обеспечивающие очевидность того, что использованные для расчета цифровой подписи ключ относится к имени в элементе данных ID. Сигнатрура или MAC будет рассчитываться с использованием алгоритмов, диктуемых типом ключа, используемого подписывающим, и задается полем Auth Method в элементе данных Authentication. Здесь не задается использования одного криптографического алгоритма для инициатора и ответчика. Выбор криптографического алгоритма зависит от типа ключа, который имеет каждая из сторон. В частности, инициатор может использовать разделяемый ключ, а ответчик может иметь открытый ключ подписи и сертификат. Обычной (но не обязательной) практикой при наличии разделяемого ключа является использование этого ключа для аутентификации в обоих направлениях. Отметим, что общепринято, хотя и не обеспечивает достаточной защиты, использование разделяемого ключа, созданного исключитьельно на базе выбранного пользователем пароля без использования других источников случайных данных.

Такая защита недостаточна, поскольку пользовательские пароли с очевидностью не являются достаточно непредсказуемыми для устойчивости к атакам по словарю, следовательно данный метод от таких атак не защищает (приложениям, использующим аутентификацию по паролю на этапе загрузки и IKE_SA, следует применять метод аутентификации, описанный в параграфе 2.16, который предназначен для защиты от атак по словарю в режиме off-line). Разделяемый (pre-shared) ключ следует делать столь же непредсказуемым, как наиболее сильный из согласуемых ключей. В случае pre-shared-ключа значение AUTH вычисляется, как:

      AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)

где строка «Key Pad for IKEv2» представляет собой 17 символов ASCII без завершающего нуля. Разделяемый секрет (shared secret) может иметь переменный размер. Строка заполнения добавляется для того, чтобы при использовании разделяемого секрета на основе пароля реализации IKE не требовалось сохранять пароль в открытом виде, а можно было хранить его в форме prf(Shared Secret,»Key Pad for IKEv2″), которая не будет использоваться в качестве пароля для отличных от IKEv2 протоколов. Как отмечено выше, создание разделяемого ключа на основе пароля не обеспечивает должной защиты. Такая конструкция отмечена лишь потому, что многие люди ей пользуются до сих пор. Интерфейс управления, через который обеспечивается Shared Secret, должен принимать строки символов ASCII размером, по крайней мере, 64 октета; добавление завершающего нуля перед использованием строки в качестве разделяемого секрета недопустимо. Интерфейс управления должен также воспринимать разделяемый секрет в шестнадцатеричном (HEX) представлении. Интерфейс управления может воспринимать другие варианты кодировки строки, если указан алгоритм преобразования в двоичную строку. Если согласованная функция prf принимает ключ фиксированного размера, разделяемый секрет должен иметь такой же размер.

2.16. Методы EAP

В дополнение к аутентификации на основе подписей с открытыми ключами и разделяемыми секретами IKE поддерживает аутентификацию с использованием методов, определенных в RFC 3748 [EAP]. Обычно эти методы являются асимметричными (они разработаны для аутентификации пользователей на сервере) и могут не быть обоюдными. По это причине упомянутые протоколы обычно используются для аутентификации инициатора на отвечающей стороне и должны применяться в комбинации с аутентификацией ответчика инициатору по цифровой подписи на основе открытого ключа. Эти методы часто ассоциируются с механизмами, которые называют «унаследованной аутентификацией» (Legacy Authentication).

Хотя в этом документе [EAP] упоминается, прежде всего, в плане добавления в будущем новых методов без обновления данной спецификации, некоторые простые варианты описаны здесь и в параграфе 3.16. [EAP] определяет протокол аутентификации с переменным числом сообщений. Расширяемая аутентификация реализуется в IKE, как дополнительные обмены IKE_AUTH, которые должны быть выполнены для инициализации IKE_SA.

Инициатор показывает свое намерение использовать расширяемую аутентификацию, пропуская элемент AUTH в сообщении 3. За счет включения элемента IDi при отсутствии AUTH инициатор объявляет свою идентификацию, но не подтверждает ее. Если ответчик желает использовать расширяемую аутентификацию, он будет включать элемент EAP32 в сообщение 4 и откладывает передачу SAr2, TSi и Tsr, пока аутентификации инициатора не будет завершена в последующем обмене IKE_AUTH. В варианте минимально расширяемой аутентификации организация начальной SA будет иметь вид:

       Инициатор                          Ответчик
      -----------                        ----------
       HDR, SAi1, KEi, Ni         -->
                                  <--    HDR, SAr1, KEr, Nr, [CERTREQ]
       HDR, SK {IDi, [CERTREQ,] [IDr,]
                SAi2, TSi, TSr}   -->
                                  <--    HDR, SK {IDr, [CERT,] AUTH, EAP}
       HDR, SK {EAP}              -->
                                  <--    HDR, SK {EAP (success)}
       HDR, SK {AUTH}             -->
                                  <--    HDR, SK {AUTH, SAr2, TSi, TSr}

Для методов EAP, которые создают разделяемый ключ в качестве побочного продукта аутентификации, этот ключ должен использоваться инициатором и ответчиком для генерации элементов данных AUTH в сообщениях 7 и 8 с использованием синтаксиса для разделяемых секретов, описанного в параграфе 2.15. Разделяемый ключ от EAP в спецификации EAP называется полем MSK. Разделяемый ключ, созданный в процессе обмена IKE, недопустимо использовать для иных целей.

Методы EAP, не создающие разделяемого ключа, использовать не следует, поскольку они подвержены многочисленным атакам MITM33 [EAPMITM] при использовании в других протоколах, не применяющих аутентифицированные сервером туннели. Если используются методы EAP, не генерирующие разделяемого ключа, элементы данных AUTH в сообщениях 7 и 8 должны генерироваться с использованием SK_pi и SK_pr, соответственно.

Инициатору IKE_SA с использованием EAP следует поддерживать возможность расширения начального протокольного обмена по крайней мере до десяти обменов IKE_AUTH, если ответчик передает уведомления и/или повторяет приглашение к аутентификации. После успешного завершения протокольного обмена, определенного выбранным методом аутентификации EAP ответчик должен передать данные EAP, содержащие сообщение Success. Если при использовании выбранного метода аутентификации возник отказ, ответчик должен передать данные EAP, содержащие сообщение Failure. Ответчик может в любой момент прервать обмен IKE путем передачи данных EAP с сообщением Failure.

При таком расширенном обмене элементы данных EAP AUTH должны включаться в два сообщения, следующие за сообщением, содержащим EAP Success.

2.17. Материал для генерации ключей CHILD_SA

Одна связь CHILD_SA создается обменом IKE_AUTH, а дополнительные CHILD_SA могут создаваться в обменах CREATE_CHILD_SA. Ключевой материал для них создается следующим образом:

      KEYMAT = prf+(SK_d, Ni | Nr)

Здесь Ni и Nr — nonce из обмена IKE_SA_INIT, если данный запрос является первым созданием CHILD_SA, или обновленные Ni и Nr из обмена CREATE_CHILD_SA при создании дополнительных связей.

Для обменов CREATE_CHILD_SA, включающих дополнительный обмен Diffie-Hellman, ключевой материал определяется следующим образом:

      KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )

где g^ir (new) — разделяемый секрет из краткосрочного обмена Diffie-Hellman данного обмена CREATE_CHILD_SA (представляется, как строка октетов в формате big endian, дополненная нулями в старших битах при необходимости выравнивания размера по модулю).

Согласование одной CHILD_SA может приводить к созданию множества защищенных связей. Связи ESP и AH существуют попарно (по одной для каждого направления) и при использовании одновременно ESP и AH в одном согласовании CHILD_SA могут создаваться четыре SA.

Ключевой материал должен браться из KEYMAT в следующем порядке:

все ключи для SA, передающих данные от инициатора к ответчику, берутся до SA в обратном направлении;

если согласуется множество протоколов IPsec, ключевой материал для каждого из них берется в порядке появления протокольных заголовков в инкапсулированном пакете;

если один протокол имеет ключи для шифрования и аутентификации, ключ шифрования берется из первых октетов KEYMAT, а ключ аутентификации — из последующих.

Каждый криптографический алгоритм берет фиксированное число битов ключевого материала, задаваемое в спецификации алгоритма.

2.18. Смена ключей IKE_SA с использованием обмена CREATE_CHILD_SA

Обмен CREATE_CHILD_SA можно использовать для смены ключей существующей связи IKE_SA (см. 2.8). Новые SPI инициатора и ответчика передаются в полях SPI. Элементы данных TS опускаются при смене ключей IKE_SA. SKEYSEED для новой IKE_SA рассчитывается с использованием SK_d из существующей IKE_SA:

       SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)

где g^ir (new) — разделяемый секрет из краткосрочного обмена Diffie-Hellman данного обмена CREATE_CHILD_SA (представляется, как строка октетов в формате big endian, дополненная нулями в старших битах при необходимости выравнивания размера по модулю), а Ni и Nr — два значения nonce из любых заголовков.

Новая связь IKE_SA должна сбросить свои счетчики сообщений в 0.

SK_d, SK_ai, SK_ar, SK_ei и SK_er рассчитываются из SKEYSEED, как описано в параграфе 2.14.

2.19. Запрос внутреннего адреса удаленной сети

В наиболее распространенном сценарии с подключением конечной точки к защитному шлюзу конечной точке может потребоваться адрес IP из защищенной шлюзом сети; для такого адреса может также потребоваться динамическое выделение. Запрос на такой временный адрес может быть включен в любой запрос на создание CHILD_SA (включаяя неявный запрос в сообщении 3) с помощью элемента данных CP.

Эта функция обеспечивает выделение адреса для клиента IRAC34, пытающегося организовать туннель в сеть, защищенную сервером удаленного доступа IRAS35. Поскольку обмен IKE_AUTH создает связи IKE_SA и CHILD_SA, IRAC должен запрашивать контролируемый IRAS адрес (и, возможно, другую информацию о защищенной сети) в обмене IKE_AUTH. IRAS может предоставлять адрес для IRAC из любого числа источников адресов типа серверов DHCP/BOOTP или из собственного блока адресов.

       Инициатор                          Ответчик
      -----------                        ------------
       HDR, SK {IDi, [CERT,] [CERTREQ,]
        [IDr,] AUTH, CP(CFG_REQUEST),
        SAi2, TSi, TSr}              -->
                                     <--   HDR, SK {IDr, [CERT,] AUTH,
                                            CP(CFG_REPLY), Sar2, TSi, TSr}

Во всех случаях элемент данных CP должен помещаться перед элементом SA. В вариациях протокола с множеством обменов IKE_AUTH элементы CP должны помещаться в сообщения, содержащие элементы SA.

Элемент CP(CFG_REQUEST) должен содержать по крайней мере атрибут INTERNAL_ADDRESS attribute (IPv4 или IPv6), но может включать любое число дополнительных атрибутов, которые инициатор пожелал получить в отклике.

Ниже показан пример сообщения от инициатора к ответчику.

      CP(CFG_REQUEST)=
        INTERNAL_ADDRESS(0.0.0.0)
        INTERNAL_NETMASK(0.0.0.0)
        INTERNAL_DNS(0.0.0.0)
      TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
      TSr = (0, 0-65535,0.0.0.0-255.255.255.255)

Примечание. Селекторы трафика TS содержат (протокол, диапазон портов, диапазон адресов).

Сообщение инициатору от ответчика:

      CP(CFG_REPLY)=
        INTERNAL_ADDRESS(192.0.2.202)
        INTERNAL_NETMASK(255.255.255.0)
        INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
      TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
      TSr = (0, 0-65535,192.0.2.0-192.0.2.255)

Все возвращаемые значения зависят от реализации. Как можно видеть из приведенного выше примера, IRAS может также передавать другие атрибуты, которые не были включены в CP(CFG_REQUEST) и могут игнорировать необязательные атрибуты, которые они не поддерживают.

Для ответчика недопустимо передавать CFG_REPLY, если не был до этого принят запрос CP(CFG_REQUEST) от инициатора, поскольку мы не хотим, чтобы IRAS выполнял ненужные просмотры конфигурации, если IRAC не может обработать REPLY. В тех случаях, когда конфигурация IRAS требует, использования CP для данного IDi, но IRAC не удалось передать CP(CFG_REQUEST), сервер IRAS должен отвергнуть запрос и прервать обмен IKE с возвратом ошибки FAILED_CP_REQUIRED.

2.20. Запрос версии партнера

Узел IKE, желающий узнать номер версии программ своего партнера IKE, может воспользоваться описанным ниже методом. Это пример конфигурационного запроса в рамках обмена INFORMATIONAL после создания IKE_SA и первой дочерней CHILD_SA.

Реализация IKE может отвергать запросы на выдачу своего номера версии до завершения аутентификации партнера и даже после аутентификации в целях предотвращения возможности использования известных недостатков в части защиты. В таких случаях реализация должна возвращать пустую строку или пакет без данных CP, если CP не поддерживается.

       Инициатор                          Ответчик
      -----------                        ----------
      HDR, SK{CP(CFG_REQUEST)}      -->
                                    <--    HDR, SK{CP(CFG_REPLY)}
      CP(CFG_REQUEST)=APPLICATION_VERSION("")
      CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.")

2.21. Обработка ошибок

При обработке IKE может происходить множество разных ошибок. Если принятый запрос имеет некорректный формат или неприемлем по соображениям политики (например, не соответствуют криптографические алгоритмы), отклик должен содержать элемент Notify, показывающий ошибку. Если ошибка произошла за пределами контекста запроса IKE (например, узел получает сообщения ESP на несуществующий SPI), узлу следует инициировать обмен INFORMATIONAL с элементом данных Notify, описывающим проблему.

Ошибки, которые происходят до организации криптографически защищенной IKE_SA, должны обрабатываться с особой осторожностью. Существует компромисс между желанием оказать пользу в диагностике и решении проблем и желанием избежать возможности стать жертвой атаки на отказ служб в результате реакции на обманные сообщения.

Если узел получает сообщение в порт UDP с номером 500 или 4500 за пределами известного ему контекста IKE_SA (и это сообщение не является запросом на создание контекста), это может говорить о недавней аварии узла. Если сообщение отмечено, как отклик, узел может занести информацию о нем в журнал аудита, но отвечать на такое сообщение недопустимо. Если сообщение помечено, как запрос, отклик на него должен быть передан в адрес IP и порт, с которых запрос поступил, при этом значения IKE SPI и Message ID в отклике должны быть копиями этих полей из запроса. Недопустимо использовать для отклика криптографическую защиту и отклик должен содержать элемент Notify, показывающий INVALID_IKE_SPI.

Узлу, получившему такой незащищенный элемент Notify, недопустимо менять состояние существующих SA. Сообщение может быть обманным или может являться легитимного корреспондента, вовлеченного в передачу обманным путем. Узлу следует трактовать такое сообщение (а также сетевые сообщения типа ICMP destination unreachable), как намек о возможности проблем с SA для данного адреса IP, а также следует выполнить проверку жизненности для всех таких IKE_SA. Реализациям следует ограничивать частоту таких проверок для предотвращения возможности их использования для организации атак на службы.

Узел, получивший подозрительное сообщение с IP-адреса, с которым он имеет IKE_SA, может передать элемент данных IKE Notify в обмене IKE INFORMATIONAL через имеющуюся SA. Получателю недопустимо менять состояние каких-либо SA в результате приема такого сообщения, но следует записать событие в журнал аудита для упрощения диагностики. Узел должен ограничивать скорость передачи откликов на незащищенные сообщения.

2.22. Компрессия IPComp

Использование компрессии IP [IPCOMP] может быть согласовано на этапе создания CHILD_SA. Хотя сомпрессия IP включает дополнительный задоловок в каждом пакете и список параметров компрессии (CPI36), виртуальная «связь с компрессией» не существует за пределами содержащей ее ESP или AH SA. «Связи с компрессией» исчезают при удалении соответствующей ESP или AH SA. Эти связи не упоминаются явно в элементах данных DELETE.

Согласование компрессии IP отделено от согласования криптографических параметров, связанных с CHILD_SA. Узел, запрашивающий создание CHILD_SA, может анонсировать поддержку одного или множества алгоритмов компрессии путем передачи одного или множества элементов Notify типа IPCOMP_SUPPORTED. Отлик может показывать приемлемость одного алгоритма компрессии с помощью элемента Notify типа IPCOMP_SUPPORTED. Такие элементы недопустимо включать в сообщения, не содержащие элементов SA.

Хотя выше говорилось о допустимости использования множества алгоритмов компрессии и возможности использовать разные алгоритмы для двух направления CHILD_SA, данная спецификация запрещает реализациям принимать алгоритм IPComp, который не был предложен, а также запрещает использовать алгоритмы, кроме того, который был предложен и принят на этапе создания CHILD_SA.

Побочным эффектом раздельного согласования IPComp и криптографических параметров является невозможность предложить множество криптографических наборов и компрессию IP, которая будет использоваться с частью (но не со всеми) предложенных наборов.

2.23. Работа через NAT

Использование шлюзов с трансляцией сетевых адресов (NAT) является спорным вопросом. В этом параграфе кратко описаны такие шлюзы и их действия по отношению к трафику IKE. Многие враждебно относятся к NAT и считают, что не следует разрабатывать протоколы для улучшения работы через системы трансляции адресов. IKEv2 задает некоторые не вполне очевидные правила обработки для улучшения работы через NAT.

Основной причиной использования NAT является нехватка адресов IPv4. Узлы IP, находящиеся за шлюзами NAT используют адреса IP, которые не являются уникальными в глобальном масштабе и могут совпадать с адресами, которые применяются за другими шлюзами NAT. В общем случае узлы, расположенные за NAT, могут взаимодействовать с другими узлами за тем же шлюзом NAT и узлами с уникальными в глобальном масштабе адресами, не не с узлами, расположенными за другим шлюзом NAT. Из этого правила есть ряд исключений. Когда узлы, расположенные за NAT, соединяются с узлами в реальной сети Internet, шлюз NAT «преобразует» (транслирует) IP-адрес отправителя, меняя его на адрес, который будет маршрутизироваться обратно на этот шлюз. Полученные из Internet сообщения «транслируются» шлюзом с заменой адреса получателя на внутренний адрес соответствующего конечного узла.

Система NAT разрабатывалась с учетом обеспечения прозрачности для оконечных узлов. Ни программы находящегося за NAT узла, ни узлы Internet не требуется менять для работы через NAT. Обеспечение такой прозрачности для обних протоколов сложнее, чем для других. Протоколы, включающие IP-адреса конечных точек в данные (не только в заголовки), будут сталкиваться с проблемами, пока шлюз NAT не начнет понимать протокол и соответствующим образом изменять данные в пакетах. Такое решение является изначально ненадежным, нарушает целостность сетевого уровня и часто приводит к возникновению трудно обнаруживаемых проблем.

Организация соединений IPsec через NAT вызывает определенные проблемы. Если соединение работает в транспортном режиме, изменение адресов IP в пакетах будет приводить к изменению контрольных сумм, которые NAT не сможет скорректировать, поскольку они криптографически защищены. Даже в туннельном режиме вознкают проблемы с маршрутизацией, поскольку прозрачная трансляция адресов в пакетах AH и ESP требует реализации в NAT специальной логики, которая по своей природе эвристична и ненадежна. По этим причинам IKEv2 использует инкапсуляцию пакетов IKE и ESP в UDP. Такой вариант слегка снижает эффективность, но проще для обработки в NAT. Кроме того, межсетевые экраны могут быть настроены на передачу трафика IPsec, инкапсулированного в UDP, но при этом блокировать ESP/AH и наоборот.

NAT обычно используется для трансляции портов TCP и UDP, наряду с адресами, и использования номеров портов из входящих пакетов для принятия решения об адресе локального узла, которому адресован пакет. По этой причине, хотя пакеты IKE должны отправляться через порт UDP с номером 500, необходимо принимать пакеты, исходящие из любого порта и отклики должны направляться в порт, из которого был получен запрос. Эти требования обусловлены тем, что номера портов могут меняться при прохождении пакетов через NAT. Аналогично, адреса IP конечных точек IKE обычно не включаются в элементы данных IKE, поскольку данные криптографически защищены и не могут прозрачно изменяться устройствами NAT.

Порт 4500 зарезервирован для инкапсуляции ESP и IKE в UDP. При работе через NAT в общем случае лучше передавать пакеты IKE через порт 4500, поскольку некоторые старые реализации NAT обрабатывают трафик IKE через порт 500 некорректно, пытаясь организовать прозрачное соединение IPsec между между конечными точками, которые сами по себе не поддерживают работу через NAT. Такие реализации NAT могут конфликтовать с прямым прохождением через NAT, описанным в этом документе, поэтому конечная точка IPsec, которая обнаружит NAT между собой и своим корреспондентом, должна передавать весь последующий трафик через порт 4500, который NAT не следует обрабатывать специальным способом (как это может происходить для порта 500).

Ниже перечислены специфические требования для прохождения через NAT [RFC3715]. Поддержка работы через NAT является необязательной. Приведенные в этом параграфе требования типа «должно» относятся только к реализациям, поддерживающим работу через NAT.

IKE должен прослушивать порты 4500 и 500. IKE должен отвечать по адресам IP и портам, с которых были приняты пакеты.

Как инициатор, так и ответчик IKE должны включать в свои пакеты IKE_SA_INIT элементы данных Notify типа NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP. Эти элементы могут использоваться для детектирования наличия NAT между хостами и определения, какой из хостов находится за NAT. Эти элементы располагаются в пакетах IKE_SA_INIT после элементов Ni и Nr (перед необязательным элементом CERTREQ).

Если ни один из полученных элементов NAT_DETECTION_SOURCE_IP не соответствует хэшу IP-адреса и порта отправителя в заголовке IP содержащего элемент пакета, это означает, что другая сторона расположена за NAT (где-то на пути доставки адрес отправителя исходного пакета заменен на адрес устройства NAT). В таких случаях данной стороне следует разрешить динамическое обновление IP-адреса другой стороны, как описано ниже.

Если полученный элемент данных NAT_DETECTION_DESTINATION_IP не соответствует хэшу IP-адреса и номера порта получателя из заголовка IP пакета, содержащего элемент данных, это означает, что другая сторона расположена за NAT. В этом случае локальной стороне следует начать передачу пакетов keepalive, как описано в [Hutt05].

Инициатор IKE должен проверить наличие этих элементов данных и при несоответствии адресам во внешнем пакете должен туннелировать все будущие пакеты IKE и ESP, связанные с данной IKE_SA через порт UDP 4500.

При туннелировании пакетов IKE через порт UDP 4500 заголовок IKE имеет четыре октета нулей, следующих сразу после заголовка UDP. При туннелировании пакетов ESP через порт UDP 4500 заголовок ESP следует сразу после заголовка UDP. Поскольку первые четыре байта заголовка ESP содержат значение SPI, которое не может быть нулевым, это позволяет всегда легко различать сообщения ESP и IKE.

Исходные IP-адреса отправителя и получателя, которые нужны в транспортном режиме для расчета контрольной суммы пакетов TCP и UDP (см. [Hutt05]), извлекаются из селекторов трафика, связанных с этим обменом. При работе через NAT селекторы трафика должны содержать в точности один адрес IP, который используется в качестве исходного адреса IP.

В некоторых случаях устройство NAT может удалить отображения, которые продолжают использоваться (например, интервал keepalive слишком велик или устройство NAT перезагружено). Для восстановления в таких случаях хостам, которые не расположены за NAT, следует передавать все пакеты (включая повторные) в адрес IP и порт из последнего корректно аутентифицированного пакета от другой стороны (т. е., динамически обновлять адрес). Расположенному за NAT хосту не следует делать так, поскольку это будет открывать возможность организации DoS-атак. Любой аутентифицированный пакет IKE или ESP, инкапсулированный в UDP, можно использовать для детектирования смены IP-адреса и номера порта. Отметим, что похожие, но, возможно, не совсем идентичные, действия требуется выполнять при работе IKE через Mobile IP, но этот вопрос выходит за пределы данного документа.

2.24. Явные уведомления о перегрузке (ECN)

При развертывании туннелей IPsec в соответствии с исходной спецификацией [RFC2401], использование ECN во внешних заголовках IP было, по сути, невозможно, поскольку при декапсуляции туннеля индикаторы перегрузки ECN, появившиеся в сети, отбрасывались. Поддержка ECN для туннелей IPsec на базе IKEv1 требует множества режимов работы и согласований (см. [RFC3168]). IKEv2 упрощает ситуацию, вводя требование возможности использования ECN во внешних заголовках IP для всех IPsec SA в туннельном режиме, создаваемых IKEv2. В частности, точки инкапсуляции и декапсуляции туннельных SA, создаваемых IKEv2, должны поддерживать опцию полной функциональности ECN для туннелей, заданную в [RFC3168], а также должны реализовать инкапсуляцию и декапсуляцию в соответствии с [RFC4301] для предотвращения отбрасывания индикации перегрузки ECN.

 

Часть 2




RFC 4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

Network Working Group                                D. Eastlake 3rd
Request for Comments: 4305                     Motorola Laboratories
Obsoletes: 2404, 2406                                  December 2005
Category: Standards Track

Требования к реализациям криптографических алгоритмов для ESP и AH

Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

PDF

Статус документа

Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола1 можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Допускается свободное распространение документа.

Авторские права

Copyright (C) The Internet Society (2005).

Тезисы

В серии протоколов IPsec используются различные криптографические алгоритмы для защиты передаваемых через сеть данных. Протоколы ESP2 и AH3 обеспечивают два механизма защиты данных при передаче через защищенные связи IPsec SA4. Для обеспечения совместимости разнородных реализаций требуется задать набор обязательных для реализации алгоритмов, чтобы всем реализациям был доступен по крайней мере один алгоритм. В этом документе определен текущий вариант набора обязательных для реализаций ESP и AH алгоритмов, а также указаны алгоритмы, которые следует реализовать, поскольку они могут стать обязательными в будущем.

Оглавление

Исключено из версии HTML

1. Введение

Протоколы ESP и AH обеспечивают два механизма защиты данных при передаче через защищенные связи IPsec SA [IPsec, ESP, AH]. Для обеспечения совместимости разнородных реализаций требуется задать набор обязательных для реализации алгоритмов, чтобы всем реализациям был доступен по крайней мере один алгоритм. В этом документе определен текущий вариант набора обязательных для реализаций ESP и AH алгоритмов, а также указаны алгоритмы, которые следует реализовать, поскольку они могут стать обязательными в будущем.

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

Наконец, следует признать, что обязательные для реализации алгоритмы нужно менять время от времени с учетом происходящих в мире изменений. По этой причине выбор обязательных для реализации алгоритмов не включен в основные спецификации IPsec, ESP и AH. Вместо этого был создан настоящий документ. При смене алгоритмов достаточно будет обновить только один документ.

В идеальном случае алгоритмам, которые будут внесены в число обязательных для реализации завтра, уже следует присутствовать в большинстве реализаций IPsec на момент придания им статуса обязательных. Для облегчения этого мы будем пытаться идентифицировать такие алгоритмы (поскольку они уже известны) в данном документе. Не существует гарантий того, что указанные алгоритмы станут в будущем обязательными, но они могут ими стать. Все известные алгоритмы являются объектами атак и использование любого из них может быть прекращено в будущем.

2. Обозначения уровня требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

В этом документе определены также дополнительные уровни требований:

SHOULD+ Этот термин обозначает то же, что и SHOULD. Однако, алгоритм, помеченный как SHOULD+, в будущем перейдет в число обязательных (MUST).

SHOULD- Этот термин обозначает то же, что и SHOULD. Однако, алгоритм, помеченный как SHOULD-, может перейти на уровень разрешенных (MAY) в будущих версиях этого документа.

MUST- Этот термин обозначает то же, что и MUST. Однако мы предполагаем, что в какой-то момент этот алгоритм перестанет быть обязательным и может перейти на уровень SHOULD или SHOULD-.

3. Выбор алгоритма

Для обеспечения совместимости реализаций IPsec требуется поддержка по крайней мере одного общего алгоритма защиты. В этом разделе приведены требования по реализации алгоритмов защиты для соответствующих спецификации реализаций протоколов ESP и AH. Алгоритмы защиты, реально используемые любой конкретной защищенной связью ESP или AH, определяются механизмом согласования (таким, как IKE5 [RFC2409, IKEv2]) или задаются при организации соединения.

Естественно, допускается реализация дополнительных (стандартных или фирменных) алгоритмов, не упомянутых в этом документе.

3.1. Протокол ESP

Требования в поддержке алгоритмов защиты для соответствующих спецификации реализаций протокола ESP приведены ниже. Определения уровней требований содержатся в разделе 2.

3.1.1. Алгоритмы шифрования и аутентификации для ESP

В приведенных ниже таблицах указаны требования к алгоритмам шифрования и аутентификации для протокола IPsec ESP.

Требования Алгоритм шифрования
MUST — обязательно NULL6
MUST- — обязательно, но может утратить статус TripleDES-CBC [RFC2451]
SHOULD+ — следует, но может стать обязательным AES-CBC с ключами размером 128 битов [RFC3602]
SHOULD — следует AES-CTR [RFC3686]
SHOULD NOT — не следует DES-CBC [RFC2405]7
Требования Алгоритм аутентификации
MUST — обязательно HMAC-SHA1-96 [RFC2404]
MUST — обязательно NULL2
SHOULD+ — следует, но может стать обязательным AES-XCBC-MAC-96 [RFC3566]
MAY — возможно HMAC-MD5-96 [RFC2403]8

3.1.2. Комбинированные алгоритмы для ESP

Как указано в [ESP], протокол поддерживает использование комбинированных алгоритмов, которые обеспечивают услуги конфиденциальности и аутентификации. Поддержка таких алгоритмов требует соответствующего структурирования реализации ESP. Во многих ситуациях комбинированные алгоритмы обеспечивают значительные преимущества в части эффективности и пропускной способности. Хотя в настоящее время не указывается предлагаемых или обязательных к реализации комбинированных алгоритмов, предполагается, что в ближайшем будущем представит интерес алгоритм AES-CCM [CCM], адаптированный в качестве предпочтительного для IEEE 802.11 [802.11i].

3.2. Протокол AH

Ниже приведены требования к реализации алгоритмов защиты в соответствующих спецификации реализациях протокола AH. Определения уровней требований приведены в разделе 2. Как вы понимаете, все перечисленные алгоритмы относятся к числу алгоритмов аутентификации.

Требования Алгоритм аутентификации
MUST — обязательно HMAC-SHA1-96 [RFC2404]
SHOULD+ — следует, но может стать обязательным AES-XCBC-MAC-96 [RFC3566]
MAY — возможно HMAC-MD5-96 [RFC2403]9

4. Вопросы безопасности

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

Этот документ посвящен выбору криптографических алгоритмов для использования с протоколами ESP и AH и, в частности, обязательных для реализации алгоритмов. Алгоритмы, которые в соответствии с этой спецификацией требуется (MUST) или следует (SHOULD) реализовать, не имеют в данный момент известных фактов взлома и выполненные криптографические исследования позволяют надеяться, что эти алгоритмы останутся безопасными в обозримом будущем. Однако, такое положение дел не обязательно сохранится. Мы, следовательно, предполагаем появление новых версий этого документа, отражающих накопленный в сфере защиты опыт.

5. Благодарности

Значительная часть приведенного здесь текста была заимствована из RFC 4307, Cryptographic Algorithms for Use in the Internet Key Exchange Version 2, автором которого является Jeffrey I. Schiller.

6. Отличия от RFC 2402 и 2406

[RFC2402] и [RFC2406] определяли протоколы IPsec AH и IPsec ESP. Каждый из этих документов содержал требования к криптографическим алгоритмам для соответствующего протокола. В настоящее время эти спецификации заменены документами [AH] и [ESP], которые не содержат требований к реализации криптографических алгоритмов. В данном документе указаны такие требования для обоих протоколов — [AH] и [ESP].

Сравнение требований приведено ниже.

Старое требование Старый RFC Новое требование Алгоритм
MUST — требуется 2406 SHOULD NOT — не следует DES-CBC [RFC2405]10
MUST — требуется 2402, 2406 MAY — возможно HMAC-MD5-96 [RFC2403]
MUST — требуется 2402, 2406 MUST — требуется HMAC-SHA1-96 [RFC2404]

7. Нормативные документы

[AH] Kent, S., «IP Authentication Header», RFC 4302, December 2005.

[ESP] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[IPsec] Kent, S., «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2403] Madson, C. and R. Glenn, «The Use of HMAC-MD5-96 within ESP and AH», RFC 2403, November 1998.

[RFC2404] Madson, C. and R. Glenn, «The Use of HMAC-SHA-1-96 within ESP and AH», RFC 2404, November 1998.

[RFC2405] Madson, C. and N. Doraswamy, «The ESP DES-CBC Cipher Algorithm With Explicit IV», RFC 2405, November 1998.

[RFC3566] Frankel, S. and H. Herbert, «The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec», RFC 3566, September 2003.

[RFC3602] Frankel, S., Glenn, R., and S. Kelly, «The AES-CBC Cipher Algorithm and Its Use with IPsec», RFC 3602, September 2003.

[RFC3686] Housley, R., «Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)», RFC 3686, January 2004.

8. Дополнительная литература

[802.11i] LAN/MAN Specific Requirements Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Medium Access Control (MAC) Security Enhancements, IEEE Std 802.11i, June 2004.

[JIS] Schiller, J., «Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)», RFC 4307, December 2005.

[CCM] Housley, R., «Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)», RFC 3686, January 2004.

[IKEv2] Kaufman, C., Ed., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC2402] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 2402, November 1998.

[RFC2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 2406, November 1998.

[RFC2407] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 2407, November 1998.

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, November 1998.

Адрес автора

Donald E. Eastlake 3rd

Motorola Laboratories

155 Beaver Street

Milford, MA 01757 USA

Phone: +1-508-786-7554 (w)

+1-508-634-2066 (h)

EMail: Donald.Eastlake@Motorola.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1В настоящее время этот документ заменен RFC 4835, перевод которого доступен на сайте www.protocols.ru. Прим. перев.

2Encapsulating Security Payload — инкапсуляция защищенных данных.

3Authentication Header — заголовок аутентификации.

4Security Association — защищенная связь.

5Internet Key Exchange — обмен ключами в Internet.

6Поскольку шифрование и аутентификация в ESP являются необязательными, поддержка двух «пустых» алгоритмов NULL обязательна для обеспечения совместимости со способом согласования используемых услуг. Отметим, что алгоритмы шифрования и аутентификации по отдельности могут принимать значения NULL, но недопустимо, чтобы значение NULL имели оба алгоритма сразу.

7Алгоритм DES с его малым размером ключей и публично показанной открытой аппаратурой для взлома, является сомнительным средством защиты общего пользования.

8Алгоритм MD5 достаточно слаб, однако эта слабость не проявляется при использовании MD5 с HMAC.

9Алгоритм MD5 достаточно слаб, однако эта слабость не проявляется при использовании MD5 с HMAC.

10IETF запрещает самостоятельное использование DES уже много лет и не включает этот алгоритм в новые стандарты в течение достаточного времени (см. комментарий IESG на первой странице [RFC2407]). Но этот документ является первым проектом стандарта, в котором указано, что реализациям не следует использовать алгоритм DES самостоятельно (не в комбинации с другими, прим. перев.). Институт стандартов и технологий США (NIST) формально признал слабость DES при самостоятельном использовании в документе, опубликованном 26 июля 2004 в Федеральном правительственном реестре США (Docket No. 040602169-4169-01), призывая прекратить использование этого алгоритма в качестве Государственного стандарта США. Алгоритм Triple DES по прежнему признается как IETF, так и NIST.

13Этот документ признан устаревшим и заменен RFC 5996, а затем RFC 7296. Прим. перев.




RFC 4304 Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)

Network Working Group                                        S. Kent
Request for Comments: 4304                          BBN Technologies
Category: Standards Track                              December 2005

Добавление расширенных порядковых номеров (ESN) в области интерпретации IPsec (DOI) для протокола управления защитными связями и ключами (ISAKMP)

Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)

PDF

Статус документа

Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Допускается свободное распространение документа.

Авторские права

Copyright (C) The Internet Society (2005).

Тезисы

Протоколы AH1 и ESP2 используют порядковые номера для детектирования попыток повторного использования пакетов. В этом документе описано расширение области интерпретации (DOI3) для протокола управления защищенными связями и ключами (ISAKMP4). Это расширение поддерживает согласование использования традиционных 32-битовых порядковых номеров или расширенных (64 бита) порядковых номеров (ESN5) для конкретной защищенной связи AH или ESP.

1. Введение

Спецификации протоколов AH [AH] и ESP [ESP] описывают опцию использования расширенных (64 бита) порядковых номеров. Эта опция обеспечивает возможность передачи очень больших объемов данных с высокмими скоростями через защищенные связи (SA) без сменя ключей, связанной с исчерпанием пространства порядковых номеров. В этом документе описано дополнение к IPsec DOI для ISAKMP [DOI], которое требуется для поддержки согласования опции ESN.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [Bra97].

2. Атрибут SA

Описанный здесь атрибут SA используется во второй фазе (Phase II) согласования протокола IKE6. Атрибут относится к базовому типу — Basic (B). Кодирование этого атрибута определено в базовой спецификации ISAKMP [ISAKMP]. Атрибуты, описанные в качестве базовых, недопустимо кодировать, как переменные. Более подробное описание кодирования атрибута в IPsec DOI приведено в документе [IKE]. Все ограничения, перечисленные в [IKE], применимы к IPsec DOI и настоящему дополнению.

Тип атрибута

Класс Значение Тип
Extended (64-bit) Sequence Number 11 B

Значения класса

Этот класс показывает, что защищенная связь SA будет использовать 64-битовые порядковые номера (описание расширенных порядковых номеров содержится в документах [AH] и [ESP]).

Резерв 0

64-битовый порядковый номер 1

3. Согласование атрибута

Если реализация получает определенный атрибут IPsec DOI (или значение атрибута), который не поддерживается, следует передать сигнал ATTRIBUTES-NOT-SUPPORT, а организация защищенной связи должна быть прервана.

Если реализация получает любое значение атрибута, отличное от значений для 64-битовой нумерации, организация защищенной связи должна быть прервана.

4. Вопросы безопасности

Этот документ связан с протоколом обмена ключами [IKE], который объединяет ISAKMP [ISAKMP] и Окли [OAKLEY] для распространения криптографических ключей с обеспечением защиты и идентификации сторон. Обсуждение различных протоколов защиты и преобразований, описанных в этом документе, можно найти в упомянутых ниже базовых документах и документах по шифрованию.

Добавление атрибута ESN не меняет параметров безопасности IKE. При использовании ESN с протоколом ESP важно выбрать режим шифрования, который обеспечит достаточную защиту при шифровании очень большого объема данных с использованием одного ключа. В этом смысле такие алгоритмы, как DES7 в режиме CBC8 не подходит для использования с ESN, поскольку с использованием одного ключа DES не следует шифровать более 232 блоков в таком режиме. Аналогично, с протоколами ESP и AH следует использовать алгоритмы контроля целостности, обеспечивающие должную защиту при больших объемах передаваемой информации. Во избежание возможных проблем с защитой, порождаемых ограничениями алгоритмов, время жизни SA можно ограничивать по объему информации, защищаемой с использованием одного ключа, до того, как будет достигнут предел ESN в 264 пакетов.

5. Согласование с IANA

В этом документе задано «магическое» число, поддерживаемое IANA. Для этого атрибута не выделяется дополнительных значений. Агентство IANA выделило значение IPsec Security Attribute для Attribute Type (тип атрибута). Это значение указано в колонке «Значение» таблицы раздела 2.

Благодарности

Автор благодарит членов рабочей группы IPsec. Автор также признателен Karen Seo за помощь при редактировании этой спецификации.

Нормативные документы

[Bra97] Bradner, S., «Key words for use in RFCs to Indicate Requirement Level», BCP 14, RFC 2119, March 1997.

[AH] Kent, S., «IP Authentication Header», RFC 4302, December 2005.

[DOI] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 240710, November 1998.

[ESP] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[IKE] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 24094, November 1998.

[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 24084, November 1998.

Дополнительная литература

[OAKLEY] Orman, H., «The OAKLEY Key Determination Protocol», RFC 2412, November 1998.

Адрес автора

Stephen Kent

BBN Technologies

10 Moulton Street

Cambridge, MA 02138

USA

Phone: +1 (617) 873-3988

EMail: kent@bbn.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Authentication Header — заголовок идентификации.

2Encapsulating Security Payload — инкапсуляция защищенных данных.

3Internet IP Security Domain of Interpretation — область интерпретации защиты IP.

4Internet Security Association and Key Management Protocol — протокол управления защищенными связями и ключами в Internet.

5Extended Sequence Number.

6Internet Key Exchange — протокол обмена ключами.

7Data Encryption Standard — стандарт шифрования данных.

8Cipher Block Chaining — сцепка шифрованных блоков.

10В настоящее время этот документ утратил силу и заменен RFC 4306. Прим. перев.




RFC 4303 IP Encapsulating Security Payload (ESP)

Network Working Group                                        S. Kent
Request for Comments: 4303                          BBN Technologies
Obsoletes: 2406                                        December 2005
Category: Standards Track

Инкапсуляция защищенных данных IP (ESP)

IP Encapsulating Security Payload (ESP)

PDF

Статус документа

Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Допускается свободное распространение документа.

Авторские права

Copyright (C) The Internet Society (2005).

Тезисы

Этот документ описывает обновленную версию протокола ESP1, разработанного для обеспечения различных услуг защиты в среде IPv4 и IPv6. Протокол ESP используется для обеспечения конфиденциальности, идентификации источника данных, контроля целостности без организации специальных соединений, предотвращения повторного использования пакетов (форма контроля порядковых номеров) и ограниченной конфиденциальности потоков трафика. Данный документ отменяет действие RFC 2406 (ноябрь 1998).

Оглавление

Исключено из версии HTML

1. Введение

В документе предполагается, что читатель достаточно знаком с терминами и концепциями, изложенными в документе «Архитектура защиты для протокола IP» [Ken-Arch], далее называемом для карткости описанием архитектуры. В частности, читателю следует понимать определения услуг по защите, обеспечиваемых ESP2 [Ken-ESP] и AH, концепцию защищенных связей, способы использования ESP вместе с идентификационным заголовком AH, а также различные опции управления ключами, поддерживаемые для ESP и AH.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [Bra97].

Заголовок ESP разработан для обеспечения смешанных услуг по защите информации в среде IPv4 и IPv6 [DH98]. ESP может использоваться автономно, в комбинации с AH [Ken-AH] или в режиме вложенности (см. документ по архитектуре защиты [Ken-Arch]). Услуги по защите могут обеспечиваться между парой взаимодействующих хостов, парой защитных шлюзов, а также между защитным шлюзом и хостом. Более детальная информация об использовании ESP и AH в различных сетевых средах приведена в документе по архитектуре защиты [Ken-Arch].

Заголовок ESP помещается после заголовка IP и перед заголовком протокола следующего уровня (транспортный режим) или перед инкапсулированным заголовком IP (туннельный режим). Детальное описание обоих режимов приведено ниже.

Протокол ESP может использоваться для обеспечения конфиденциальности, идентификации источника данных, контроля целостности без организации специальных соединений, предотвращения повторного использования пакетов (форма контроля порядковых номеров) и (ограниченной) конфиденциальности потоков трафика. Набор предоставляемых услуг зависит от опций, выбранных в момент организации защищенной связи (SA3), и местоположения реализации протокола в сетевой топологии.

В ESP допускается использование только функций шифрования для обеспечения конфиденциальности. Однако следует отметить, что в общем случае шифрование будет обеспечивать лишь защиту от пассивных атак. Использование шифрования без строгого контроля целостности (в ESP или с помощью AH) может сделать шифрованные услуги уязвимыми для некоторых форм активных атак [Bel96, Kra01]. Более того, нижележащие службы контроля целостности (такие, как AH), использованные до шифрования, не обеспечивают достаточной защиты конфиденциальных данных от активных атак при использовании только шифрования [Kra01]. ESP позволяет использовать SA только с шифрованием, поскольку в этом случае обеспечивается более высокая производительность в сочетании с адекватной защитой (например, при независимой реализации услуг проверки идентификации и целостности данных). Однако стандарт не требует от реализаций ESP предлагать лишь услуги шифрования.

Идентификация источника данных и контроль целостности без организации специальных соединений являются связанными услугами и совместно называются услугами по обеспечению целостности (integrity4). ESP с обеспечением только услуг целостности должны предлагаться как опция выбора услуг (например, это должно согласовываться в протоколах управления SA и должно быть настраиваемым с использованием интерфейса управления). ESP с поддержкой лишь целостности являются привлекательной альтернативой AH в различных контекстах (например, по причине более высокой производительности или большей пригодности для канализации во многих приложениях).

Хотя конфиденциальность и целостность могут обеспечиваться независимо, ESP обычно поддерживает оба типа услуг (т. е., пакеты будут защищаться как в части конфиденциальности, так и в части целостности). Таким образом, существует три варианта услуг ESP:

  • только конфиденциальность (может поддерживаться);
  • только целостность (должна поддерживаться);
  • конфиденциальность и целостность (должна поддерживаться)

Поддержка предотвращения повторного использования пакетов может быть выбрана для SA только вместе с поддержкой функций целостности для этой SA. Выбор этой услуги полностью отдается на откуп получателю и не требует согласования. Однако для использования расширенных порядковых номеров (ESN) требуется согласование этой опции — ESP требует от протоколов управления SA поддержки возможности такого согласования (см. параграф 2.2.1).

Услуги по обеспечению конфиденциальности потоков трафика (TFC5) в общем случае эффективны только при таком развертывании ESP, когда обеспечивается сокрытие адресов исходных отправителей и получателей (например, в туннеле между защитными шлюзами) и только при потоке трафика между партнерами IPsec (естественного или генерируемого в целях маскировки), достаточном для сокрытия конкретного потока индивидуальных абонентов6. Новые функции TFC, включенные в ESP, облегчают генерацию и отбрасывание маскирующего трафика и обеспечивают более эффективное заполнение для реального трафика. При этом обеспечивается совместимость с более ранними версиями.

В разделе 7 кратко перечислены отличия данной спецификации от RFC 2406.

2. Формат пакетов ESP

В заголовок (внешний) протокола (IPv4, IPv6, Extension), непосредственно предшествующий заголовку ESP, следует включать значение 507 в поле Protocol (IPv4) или Next Header (IPv6, Extension). Рисунок 1 показывает верхний уровень формата пакетов ESP. Пакет начинается с двух 4-байтовых полей (SPI 8 и Sequence Number9). Вслед за ними размещается поле данных Payload Data, структура которого зависит от выбора алгоритма шифрования и режима, а также заполнения TFC, детально описанного ниже. Вслед за полем Payload Data размещается поле заполнения (Padding), поле размера заполнения (Pad Length) и поле Next Header (следующий заголовок). Дополнительно в конце пакета может помещаться значение ICV10.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
|               Security Parameters Index (SPI)                 | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|                      Sequence Number                          | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
|                    Payload Data* (перемен.)                   | |   ^
~                                                               ~ |   |
|                                                               | |Conf.
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|               |     Padding (0-255 байтов)                    | |ered*
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
|                               |  Pad Length   | Next Header   | v   v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|         Integrity Check Value-ICV   (перемен.)                |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

* При наличии в поле Payload данных криптографической синхронизации (например, вектора инициализации — IV, описанного в параграфе 2.3) эти данные обычно не шифруются, хотя о них зачастую говорят, как о части шифрованных данных.

Рисунок 1: Формат пакета ESP на верхнем уровне

Трейлер (передаваемый) ESP содержит поля Padding, Pad Length и Next Header. В дополнение к этим полям включаются неявные данные трейлера ESP (не передаются), используемые для контроля целостности, как описано ниже.

При выборе контроля целостности контрольная сумма дополняет поля SPI, Sequence Number, Payload Data и трейлер ESP (явный и неявный).

При выборе услуг конфиденциальности шифруется поле Payload Data (за исключением данных криптографической синхронизации, которые могут быть включены, но не шифруются) и (явный) трейлер ESP.

Как отмечено выше, поле Payload Data может иметь дополнительную структуру. Алгоритмы шифрования, которым требуется явный вектор инициализации IV11 (например, CBC12), часто используют эти данные в качестве префикса защищаемых данных (Payload Data). Некоторые алгоритмы объединяют шифрование и контроль целостности в одну операцию — здесь такие алгоритмы будут называться комбинированными. Приспособление таких алгоритмов требует от алгоритма явного описания структуры Payload Data, используемой для передачи данных контроля целостности.

Некоторые комбинированные алгоритмы обеспечивают целостность только для шифрованных данных, тогда как другие могут обеспечивать целостность неких дополнительных данных, которые не шифруются для передачи. Поскольку поля SPI и Sequence требуют контроля целостности и не шифруются, необходимо обеспечить их целостность, независимо от выбранных услуг и стиля работы комбинированного алгоритма.

При использовании комбинированного алгоритма предполагается, что этот алгоритм сам по себе будет возвращать шифрованные данные и результат проверки целостности. Для комбинированных алгоритмов значение ICVЭ обычно находящее в конце пакета ESP (когда выбран контроль целостности), можно опустить. Когда выбран контроль целостности и ICV опускается, ответственность за кодирование эквивалента ICV в поле Payload Data и проверку целостности пакета ложится на комбинированный алгоритм.

Если комбинированный алгоритм обеспечивает только целостность данных, которые уже зашифрованы, необходимо реплицировать значения полей SPI и Sequence Number, как часть Payload Data.

В заключение добавляются байты заполнения для сохранения конфиденциальности потоков трафика после поля Payload Data и перед трейлером ESP. Рисунок 2 показывает структуру поля Payload Data для таких случаев13.

При использовании комбинированного алгоритма явное поле ICV, показанное на рисунках 1 и 2, может отсутствовать (см. параграф 3.3.2.2). Поскольку алгоритмы и режимы задаются при организации SA, формат пакетов ESP для данной SA (включая структуру Payload Data) фиксирован для всего трафика данной SA.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Security Parameters Index (SPI)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
   |                    IV (optional)                              | ^ p
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
   |                    Rest of Payload Data  (перемен.)           | | y
   ~                                                               ~ | l
   |                                                               | | o
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
   |               |         TFC Padding * (необязат., перемен.)   | v d
   +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
   |                         |        Padding (0-255 bytes)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |  Pad Length   | Next Header   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Integrity Check Value-ICV   (перемен.)                |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

* При использовании туннельного режима реализация IPsec может добавлять заполнение TFC (см. параграф 2.4) после поля Payload Data и перед полем Padding.

Рисунок 2: Субструктура данных (Payload Data)

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

Таблица 1:Раздельные алгоритмы шифрования и контроля целостности

Число байтов

Требуется14

Шифруется Учитывается в ICV Передается
SPI

4

M

+

Без шифрования
Seq# (младшие биты)

4

M

+

Без шифрования
IV

переменное

O

+

cipher15

Payload

IP datagram16

переменное

M или D

+

+

cipher5
TFC padding

переменное

O

+

+

cipher5
Padding

0 — 255

M

+

+

cipher5
Pad Length

1

M

+

+

cipher5
Next Header

1

M

+

+

cipher5
Seq# (старшие биты)

4

При ESN17

+

Не передается
ICV Padding

переменное

Если используется

+

Не передается
ICV

переменное

M18

Без шифрования

Таблица 2: Комбинированные алгоритмы шифрования и контроля целостности

Число байтов

Требуется19

Шифруется Учитывается в ICV Передается
SPI

4

M

+

Без шифрования
Seq# (младшие биты)

4

M

+

Без шифрования
IV

переменное

O

+

cipher

Payload

IP datagram20

переменное

M или D

+

+

cipher
TFC padding21

переменное

O

+

+

cipher
Padding

0 — 255

M

+

+

cipher
Pad Length

1

M

+

+

cipher
Next Header

1

M

+

+

cipher
Seq# (старшие биты)

4

При ESN22

+

23
ICV Padding

переменное

Если используется

+

5
ICV

переменное

O24

Без шифрования

В последующих параграфах рассматриваются поля заголовка. Необязательные поля могут быть опущены (т. е., отсутствуют как при передаче, так и при расчете ICV — см. параграф 2.7), если соответствующая опция не выбрана. Обязательные поля присутствуют в пакетах ESP всегда для каждой SA. Формат пакетов ESP для данной SA фиксирован на протяжении всего срока существования данной SA.

Примечание. Все криптографические алгоритмы, используемые в IPsec, предполагают на входе канонический сетевой порядок байтов (см. Приложение к RFC 791 [Pos81]) и генерируют результаты с использованием этого же порядка.

ESP не включает номера версии, следовательно при возникновении вопросов о совместимости с предыдущими версиями, эти вопросы должны решаться с использованием механизмов сигнализации (например, IKEv2) [Kau05] или настройка конфигурации по отдельному каналу) между партнерами IPsec, обеспечивающих совместимость версий ESP.

2.1. Security Parameters Index (SPI) — список параметров защиты

SPI представляет собой произвольное 32-битовое значение, используемое получателем для идентификации SA, с которой связан входящий пакет. Поле SPI является обязательным.

Для индивидуальных SA, значение SPI может само по себе идентифицировать SA или использоваться в комбинации с типом протокола IPsec (в данном случае ESP). Поскольку для индивидуальных SA значение SPI генерируется получателем, решение вопроса о достаточности этого значения для идентификации SA или необходимости использования в комбинации с типом протокола IPsec определяется локальными условиями. Этот механизм отображения входящего трафика на индивидуальные SA должен поддерживаться всеми реализациями ESP.

В реализациях IPsec, поддерживающих групповую адресацию, должны поддерживаться групповые SA с использованием описанного ниже алгоритма отображения входящих дейтаграмм IPsec на SA. Разработчикам, поддерживающим только индивидуальный трафик, не обязательно реализовать механизм демультиплексирования.

Во многих защищенных multicast-архитектурах (например, [RFC3740]) центральный контроллер группы/сервер ключей сам выделяет для группы значение SPI. Выделение SPI не согласуется и не координируется с подсистемами управления ключами (например, IKE) на конечных узлах группы. Следовательно, возникает возможность совпадения значений SPI для групповой и индивидуальной SA. Поддерживающие групповую адресацию реализации IPsec должны корректно демультиплексировать входящий трафик даже в случаях совпадения значений SPI.

Каждая запись в базе данных защищенных связей (SAD25) [Ken-Arch] должна указывать, по каким критериям в дополнение к SPI отыскивается SA – получатель, получатель и отправитель. Для групповых SA поле протокола не используется при поиске SA. Для каждого входящего пакета с защитой IPsec реализация должна произвести поиск в SAD и найти запись, наиболее точно соответствующую идентификатору SA. Если обнаруживается более одной записи SAD, соответствующей значению SPI, выбирается запись по наиболее точному соответствию получателя или получателя и отправителя (как указано в записи SAD). Таким образом, логический порядок поиска в SAD имеет вид:

  1. Поиск в базе SAD соответствия {SPI, адрес получателя, адрес отправителя}. Если запись SAD найдена, входящий пакет AH обрабатывается с найденной записью SAD. В противном случае выполняется п. 2.
  2. Поиск в базе SAD соответствия {SPI, адрес получателя}. Если запись SAD найдена, входящий пакет AH обрабатывается с найденной записью SAD. В противном случае выполняется п. 3.
  3. Поиск в базе SAD соответствия {SPI}, если получатель выбрал поддержку одного пространства SPI для AH и ESP, или {SPI, протокол} в противном случае. Если запись SAD найдена, входящий пакет AH обрабатывается с найденной записью SAD. В противном случае пакет отбрасывается с записью в журнал аудита.

На практике реализация может выбрать любой метод ускорения поиска, но наблюдаемое извне поведение должно соответствовать описанному выше поиску в SAD. Например, программные реализации могут индексировать хэш-таблицу SPI. Записи SAD в хэш-таблице сортируются в связный список, в котором записи для SA с большим соответствием располагаются ближе к началу, а с меньшим соответствием — ближе к концу списка. В аппаратных реализациях поиск максимального соответствия может ускоряться встроенными средствами с использованием общедоступной технологии TCAM26.

Индикация использования адресов отправителя и получателя при поиске соответствия для отображения входящего трафика IPsec на SA должна выполняться при настройке конфигурации SA вручную или путем согласования параметров с использованием протокола управления SA (например, IKE или GDOI27 [RFC3547]). Обычно группы SSM28 [HC03] используют трехкомпонентный идентификатор SA, включающий SPI, групповой адрес получателей и адрес отправителя. SA группы Any-Source Multicast требует в качестве идентификатора только SPI и групповой адрес получателей.

Значения SPI в диапазоне от 1 до 255 зарезервированы IANA для использования в будущем. Эти значения не будут распределяться агентством IANA, пока их использование не будет оговорено в специальном RFC. Значение SPI = 0 зарезервировано для локального, связанного с реализацией, применения и его недопустимо передавать в сеть. Например, реализация управления ключами может использовать SPI=0 для идентификации отсутствия защищенных связей29 в период, когда реализация IPsec запрашивает новую SA для объекта управления ключами, но данная SA еще не организована.

2.2. Sequence Number — порядковый номер

Это 32-битовое поле, трактуемое, как целое число без знака, содержит значение счетчика пакетов, которое увеличивается на 1 для каждого переданного пакета (счетчик пакетов для SA). Для индивидуальных SA и групповых SA с одним отправителем, последний должен инкрементировать данное поле для каждого переданного пакета. Использование одной SA множеством отправителей допустимо, хотя в общем случае не рекомендуется. ESP не предоставляет возможностей синхронизации порядковых номеров между множеством отправителей или осмысленного счетчика пакетов на стороне получателя и не обеспечивает окна в контексте множества отправителей. Таким образом, для SA с множеством отправителей функции предотвращения повторного использования пакетов ESP становятся недоступными (см. параграфы 3.3.2 и 3.4.3).

Это поле является обязательным и должно присутствовать даже в тех случаях, когда получатель не пользуется услугами по предотвращению повторного использования пакетов для конкретной SA. Обработка поля Sequence Number осуществляется по усмотрению получателя, но все реализации ESP должны обеспечивать возможность обработки, описанной в параграфах 3.3.3. Генерация порядковых номеров и 3.4.3. Проверка порядковых номеров. Таким образом, отправитель должен передавать это поле, но получатель не обязан принимать его во внимание (см. обсуждение проверки порядковых номеров в параграфе 3.4.3. Проверка порядковых номеров.

Счетчики на стороне отправителя и получателя инициализируются нулевым значением при создании SA (первый пакет, переданный с использованием данной SA будет иметь порядковый номер 1; генерация порядковых номеров более подробно описана в параграфе 3.3.3). Если предотвращение повторного использования пакетов включено (используется по умолчанию), передаваемые порядковые номера никогда не должны повторяться. Таким образом, счетчики пакетов на стороне отправителя и получателя должны сбрасываться (путем создания новой SA и нового ключа) до передачи пакета с порядковым номером 2^32 в каждой SA.

2.2.1. Extended Sequence Number — расширенный порядковый номер (64 бита)

В высокоскоростных реализациях IPsec следует предлагать новую опцию для расширения 32-битового поля порядкового номера. Использование поля ESN30 должно согласовываться протоколом управления SA. Отметим, что в IKEv2 это согласование происходит неявно — использование ESN включено по умолчанию, пока явно не выбраны 32-битовые порядковые номера. Поддержка ESN возможна как для индивидуальных, так и для групповых SA.

ESN позволяет использовать для SA 64-битовые порядковые номера (см. Приложение A: Расширенные порядковые номера (64 бита) ). В заголовке ESP каждого пакета для минимизации издержек передаются только младшие 32 бита расширенного порядкового номера, а старшие 32 бита учитываются, как часть порядкового номера, отправителем и получателем и включаются в расчет ICV (если контроль целостности используется). Если реализован отдельный алгоритм контроля целостности, старшие биты включаются в неявный трейлер ESP, но не передаются по аналогии с битами заполнения алгоритма контроля четности. При использовании комбинированного алгоритма, последний определяет судьбу старших битов ESN — передавать или неявно включать в расчет. Детали обработки рассматриваются в параграфе 3.3.2.2.

2.3. Payload Data — данные

Поле переменного размера Payload Data содержит данные (из исходного пакета IP), указываемые полем Next Header. Поле Payload Data является обязательным и размер его составляет целое число байтов. Если алгоритм, используемый для шифрования данных, требует данных криптографической синхронизации (например, вектор инициализации — IV), эти данные явно передаются в поле Payload, но не рассматриваются в качестве отдельного поля в ESP (т. е., передача явного IV невидима для ESP — см. Рисунок 2). Любой алгоритм шифрования, требующий таких явных данных синхронизации для каждого пакета, должен указывать размер и структуру таких данных, а также их местоположение в RFC, содержащем спецификацию использования алгоритма с ESP. Обычно IV помещается непосредственно перед зашифрованным текстом (см. Рисунок 2). Если данные синхронизации передаются неявно, алгоритм их выделения должен быть описан в RFC с определением алгоритма шифрования. Если неявные данные криптографической синхронизации (например, вектор инициализации — IV) включаются в поле Payload, обычно эти данные не шифруются (см. таблицы 1 и 2), хотя в некоторых случаях о них говорят, как о части шифрованных данных.

Отметим, что начало заголовка протокола следующего уровня должно быть выровнено относительно заголовка ESP — для IPv4 выравнивание выполняется по 4-байтовой границе, для IPv6 — по 8-байтовой.

В части выравнивания (действительно) зашифрованных данных при наличии IV отметим следующее:

  • Для некоторых режимов работы на базе IV получатель трактует IV, как начало шифрованных данных, передавая вектор инициализации в алгоритм напрямую. В таких случаях идентификация начала (действительно) шифрованных данных не вызывает проблем на приемной стороне.
  • В некоторых случаях получатель считывает IV независимо от шифрованных данных. В таких случаях алгоритм должен указывать способ идентификации начала (действительно) шифрованных данных.

2.4. Padding — заполнение (для шифрования)

Использование поля Padding обусловлено двумя основными факторами:

  • Если алгоритм шифрования требует, чтобы размер шифруемых данных был кратен некоторому целому числу байтов (например, размер блока при блочном шифровании), поле Padding используется для требуемого алгоритмом выравнивания нешифрованных данных (поля Payload Data, Padding, Pad Length и Next Header) до требуемого алгоритмом размера.
  • Заполнение может потребоваться и без связи с алгоритмом шифрования для обеспечения выравнивания зашифрованных данных по 4-байтовой границе. В частности, поля Pad Length и Next Header должны быть выравниваться по 4-байтовой границе, как показано выше на рисунке, описывающем формат пакетов ESP, для обеспечения выравнивания поля ICV (если оно используется) по 4-байтовой границе.

Независимо от приведенных выше требований заполнение может служить для сокрытия действительного размера зашифрованных данных с целью поддержки конфиденциальности потока трафика (TFC). Однако описываемое здесь поле Padding слишком мало для эффективной реализации TFC, поэтому его не следует использовать с такой целью. Для обеспечения конфиденциальности потока следет использовать специальный механизм, описанный ниже (см. параграф 2.7).

Отправитель может добавлять в поле заполнения от 0 до 255 байтов. Включение поля Padding в пакет ESP является необязательным (в соответствии с приведенными выше требованиями), но каждая реализация должна поддерживать генерацию и восприятие поля заполнения.

  • При использовании заполнения для выравнивания размера шифрованных данных в соответствии с требованиями алгоритма к размеру блока (первое требование выше) при расчете заполнения принимается во внимание поле Payload Data без IV, но со включением всех трейлерных полей ESP. Если комбинированный алгоритм требует передачи SPI и Sequence Number для контроля целостности (например, репликации SPI и Sequence Number в поле Payload Data), тогда реплицированные версии этих полей, а также все связанные данные эквивалента ICV включаются в расчет размера заполнения. Если выбрана опция ESN, старшие 32 бита ESN также учитываются при расчете заполнения, если комбинированный алгоритм требует их передачи для контроля целостности.
  • Для выравнивания поля ICV по 4-байтовой границе (второе требование выше) при расчете заполнения учитывается поле Payload Data, включая IV, Pad Length и Next Header. При использовании комбинированного алгоритма все реплицируемые данные и эквивалент ICV учитываются в Payload Data для расчета заполнения.

Если поле Padding требуется, но алгоритм шифрования не задает содержимого заполнения, должна использоваться описанная ниже обработка, принятая по умолчанию. Байты Padding инициализируются последовательностями целочисленных значений (1 байт, без знака). Первый байт заполнения, добавляемый в конце шифрованных данных, имеет номер 1, а номера последующих байтов монотонно возрастают на единицу, образуя последовательность 1, 2, 3, …. При использовании такой схемы заполнения получателю следует проверять поле Padding (эта схема была выбрана за ее относительную простоту, возможность аппаратной реализации и наличие некоторой защиты от ряда форм атак «cut and paste» в отсутствии механизмов контроля целостности, если получатель проверяет заполнение до расшифровки).

Если алгоритм шифрования или комбинированный алгоритм вносят ограничения в выбор значений байтов заполнения, эти ограничения должны быть указаны в RFC, определяющем использование алгоритма с ESP. Если алгоритм требует проверки значений байтов заполнения, это требование также должно быть включено в упомянутый документ RFC.

2.5. Pad Length — размер заполнения

Поле Pad Length показывает число байтов заполнения, непосредственно предшествующих данному полю в поле Padding. Значение поля лежит в диапазоне от 0 до 255, где нулевое значение говорит об отсутствии байтов заполнения. Как было отмечено выше, в этом поле не учитываются байты заполнения TFC. Поле Pad Length является обязательным.

2.6. Next Header — следующий заголовок

Восьмибитовое обязательное поле Next Header показывает тип данных, содержащихся в поле Payload Data (например, пакет IPv4 или IPv6, заголовок и данные следующего уровня). Значения этого поля выбираются из списка номеров протоколов IP31, представленного на сайте IANA32. Например, значение 4 показывает протокол IPv4, значение 41 — IPv6, а 6 — протокол TCP.

Для упрощения быстрой генерации и отбрасывания трафика заполнения, используемого для обеспечения конфиденциальности потока (см. параграф 2.4), в «бутафорских» пакетах должен указываться идентификатор протокола 59 (нет следующего заголовка). Передающая сторона должна обеспечивать возможность генерации «бутафорских» пакетов с указанным значением поля, а получатель должен быть готов к отбрасыванию таких пакетов, без индикации ошибки. Все остальные заголовки и трейлерные поля ESP (SPI, Sequence Number, Padding, Pad Length, Next Header, ICV) должны присутствовать в «бутафорских» пакетах, но нешифрованную часть данных (кроме поля Next Header), следует делать бессмысленной (например, включать в эту часть поля Payload Data случайные байты). «Бутафорские» пакеты отбрасываются без какого-либо ущерба.

Реализациям следует обеспечивать локальные средства управления использованием «бутафорских» пакетов на уровне SA. Средствам управления следует давать пользователю возможность включения и выключения этой функции, а также управления параметрами (например, средства управления могут позволять администратору выбирать случайный или фиксированный размер «бутафорских» пакетов).

Обсуждение. «бутафорские» пакеты могут помещаться в поток со случайными интервалами для маскировки отсутствия реального трафика. Они могут также «формовать» реальный трафик в соответствии с некоторым распределением. Наибольший уровень защиты потоков трафика (TFS33) будет обеспечивать генерация «бутафорских» пакетов со скоростью, обеспечивающей постоянную скорость передачи данных для SA. Если все пакеты имеют одинаковый размер, SA показывает постоянную скорость потока данных, аналогично средствам шифрования каналов на уровне 1 или 2. Однако, неочевидно, что такой подход будет подходить во всех случаях (например, при наличии множества активных SA такое решение будет приводить к неоправданному расходу полосы, сводящему на нет преимущества использования коммутации пакетов вместо коммутации каналов). Разработчикам следует обеспечивать средства управления, позволяющие локальному администратору управлять генерацией «бутафорских» пакетов для целей TFC.

2.7.Заполнение TFC

Как было отмечено выше, размер поля Padding ограничен 255 байтами. В общем случае этого не достаточно для адекватного сокрытия характеристик трафика с целью обеспечения конфиденциальности. Для решения задач обеспечения конфиденциальности потоков (TFC34) используется специальное необязательное поле.

Реализациям IPsec следует обеспечивать возможность заполнения трафика путем добавления байтов после поля Payload Data, но до начала поля Padding. Однако такое заполнение (его часто называют заполнением TFC) может добавляться только в тех случаях, когда поле Payload Data содержит размер дейтаграммы IP. Это требование всегда выполняется в туннельном режиме и может выполняться в транспортном, если протокол следующего уровня (например, IP, UDP, ICMP) содержит точное значение размера. Информация о размере позволяет получателю пакета отбросить заполнение TFC, поскольку известен истинный размер поля Payload Data (поля трейлера ESP находятся путем отсчета от конца пакета ESP). Соответственно, при добавлении заполнения TFC значение поля, содержащего размер дейтаграммы IP недопустимо менять с учетом этого заполнения. Данный стандарт не включает требований к содержимому заполнения.

В принципе, существующие реализации IPsec могли использовать такую возможность и ранее с сохранением прозрачности. Однако по причине того, что получатели не были готовы к работе с таким заполнением, протокол управления SA должен был согласовывать такую возможность до того, как отправитель начнет ее применять, поскольку нужно было обеспечить совместимость с более ранними реализациями. В комбинации с описанным в параграфе 2.6 соглашением об использовании ID 59 реализация ESP может генерировать «пустышки» (dummy) и реальные пакеты с большее широкими пределами изменения размеров в целях поддержки TFC.

Реализациям следует поддерживать локальные средства управления для включения этой функции на уровне SA. Эти средства должны позволять пользователю управлять применением данной функции, а также обеспечивать параметрический контроль параметров.

2.8. ICV — контроль целостности

Поле переменного размера ICV35 вычисляется для заголовка ESP, поля Payload и трейлерных полей ESP. Неявные поля трейлера ESP (заполнение и старшие биты ESN) принимаются во внимание при расчете ICV. Поле ICV является необязательным. Оно присутствует лишь в тех случаях, когда контроль целостности включен и обеспечивается с использованием отдельного алгоритма или комбинированного алгоритма с поддержкой ICV. Размер поля определяется выбранным алгоритмом контроля целостности и связывается с SA. Спецификация алгоритма контроля целостности должна задавать размер ICV, а также правила сравнения и порядок проверки корректности значений.

3. Обработка ESP

3.1. Расположение заголовка ESP

ESP может работать в двух режимах — транспортном и туннельном.

3.1.1. Транспортный режим

В транспортном режиме36 ESP помещается после заголовка IP и перед заголовком следующего уровня (например, TCP, UDP, ICMP и т. п.). В контексте IPv4 это означает размещениеESP после заголовка IP (и всех опций), но перед протоколом следующего уровня (если для пакета используется также AH, заголовок идентификации применяется к заголовку ESP, полю Payload, трейлеру ESP и ICV). На рисунке показано расположение ESP в типичном заголовке IPv4 (на этом и следующих рисунках данного параграфа показано поле ICV, реальное наличие которого связано с функциями защиты и выбранными алгоритмом и режимом).

            До применения ESP
      -------------------------------
IPv4  |исх. загол. IP|     |        |
      | (любые опции)| TCP | Данные |
      -------------------------------

           После применения ESP
      -----------------------------------------------------
IPv4  |исх. загол. IP| заг. |     |        | Трейлер | ESP|
      | (любые опции)| ESP  | TCP | Данные |   ESP   | ICV|
      -----------------------------------------------------
                              |<---- шифрование ---->|
                        |<------- целостность ------>|

В контексте IPv6 заголовок ESP представляется как передаваемые «насквозь» данные и ему, таким образом, следует размещаться после заголовков расширения hop-by-hop, routing и fragmentation. Заголовки расширения опций адресата могут размещаться до, после и по обе стороны от заголовка ESP, в зависимости от требуемой семантики. Однако, поскольку ESP защищает только поля, расположенные после заголовка ESP, в общем случае желательно помещать опции адресата после заголовка ESP. На рисунке справа показан заголовок ESP для типичного пакета IPv6 при использовании транспортного режима.

               До применения ESP
      ---------------------------------------
IPv6  | Исходный    |расш. заг.|     |      |
      | заголовок IP|если есть | TCP |Данные|
      ---------------------------------------

               После применения ESP
      -----------------------------------------------------------
IPv6  | исход|hop-by-hop,dest*,|   |dest|   |      |Трейлер| ESP|
      |заг IP|routing,fragment.|ESP|opt*|TCP|Данные|  ESP  | ICV|
      -----------------------------------------------------------
                                   |<---- шифрование ----->|
                               |<------ целостность ------>|

* — при наличии может размещаться до или после ESP или в обоих местах.

Отметим, что в транспортном режиме для реализаций bump-in-the-stack и bump-in-the-wire, как указано в описании архитектуры защиты, входящие и исходящие фрагменты IP могут требовать от реализации IPsec выполнения дополнительных операций сборки/фрагментации в соответствии с данной спецификацией и для обеспечения прозрачной поддержки IPsec. При выполнении таких операций требуются особые меры осторожности в тех случаях, когда используется множество интерфейсов.

3.1.2. Туннельный режим

В туннельном режиме «внутренний» заголовок IP указывает исходные (IP) адреса отправителя и получателя, а «внешний» заголовок IP содержит адреса «партнеров» IPsec (защитных шлюзов). Допускается различие версий внутреннего и внешнего заголовков IP (т. е., возможна передача IPv6 по протоколу IPv4 и IPv4 по IPv6). В туннельном режиме ESP защищает вложенный пакет IP целиком, включая внутренний заголовок IP. Положение ESP в туннельном режиме относительно внешнего заголовка IP совпадает с положением ESP в транспортном режиме. На рисунке показано положение ESP для туннельного режима в заголовках типичных пакетов IPv4 и IPv6.

           До применения ESP
      ----------------------------
IPv4  |Исходный     |     |      |
      |заголовок IP | TCP |Данные|
      ----------------------------

           После применения ESP
      -------------------------------------------------------------
IPv4  | Новый       |     | Исходный      |   |      |Трейлер| ESP|
      |заголовок IP*| ESP | заголовок IP  |TCP|Данные| ESP   | ICV|
      -------------------------------------------------------------
                          |<---------- Шифрование ---------->|
                    |<------------- Целостность ------------>|
                До применения ESP
      ---------------------------------------
IPv6  | Исходный    |расш загол|     |      |
      | заголовок IP|если есть | TCP |Данные|
      ---------------------------------------

               После применения ESP
      ---------------------------------------------------------------
IPv6  |новый*|нов загол|   |исход*|исх загол|   |      |Трейлер| ESP|
      |заг IP|расшир*  |ESP|заг IP| расшир* |TCP|Данные|ESP    | ICV|
      ---------------------------------------------------------------
                           |<---------- Шифрование ----------->|
                       |<------------ Целостность ------------>|

*Конструкция внешнего заголовка/расширения и изменение внутреннего обсуждаются в документе по архитектуре защиты. Эти элементы не обязательны.

3.2. Алгоритмы

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

3.2.1. Алгоритмы шифрования

Алгоритм шифрования, используемый для защиты пакета ESP задается на уровне SA в которой пакет передается/принимается. Поскольку пакеты IP могут доставляться с нарушением порядка и потерей части пакетов, в каждом пакете должны содержаться все данные, требуемые получателю для выполнения криптографической синхронизации при расшифровке. Эти данные могут передаваться явно в поле payload (например, как описанный выше вектор инициализации IV ) или выделяться из незашифрованной части37 заголовка пакета (внешнего заголовка IP или заголовка ESP). Поскольку ESP использует заполнение незашифрованной части, используемый ESP алгоритм шифрования может демонстрировать характеристики блочного или потокового режима. Поскольку шифрование (конфиденциальность) может быть опциональной услугой (например, в ESP с обеспечением только контроля целостности), этот алгоритм может быть пустым (NULL) [Ken-Arch].

Чтобы позволить реализации ESP рассчитывать заполнение для шифрования, требуемое блочными алгоритмами, и определять влияние алгоритма на MTU, в RFC для каждого алгоритма, используемого с ESP, должен задаваться модуль заполнения.

3.2.2. Алгоритмы контроля целостности

Алгоритм контроля целостности, применяемый для расчета ICV, задается в SA, используемой для передачи/приема пакетов. Как и алгоритм шифрования, алгоритм контроля целостности, используемый с ESP, должен обеспечивать обработку пакетов, доставленных с нарушением порядка, и быть устойчивым к потере пакетов. Приведенные выше замечания по поводу использования незашифрованных данных для синхронизации получателя применимы и к алгоритму контроля целостности. По причине необязательности использования алгоритма, для него может быть установлено значение NULL.

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

3.2.3. Комбинированные алгоритмы

При использовании комбинированного алгоритма предоставляются услуги обеспечения конфиденциальности и целостности. Как и алгоритм шифрования, комбинированный алгоритм должен обеспечивать обработку пакетов, доставленных с нарушением порядка, и быть устойчивым к потере пакетов. Способы обеспечения комбинированным алгоритмом целостности данных, а также полей SPI и (Extended) Sequence Number, могут меняться в зависимости от алгоритма. Для обеспечения однородного и независимого от алгоритма решения по использованию комбинированных алгоритмов, дополнительная структура полей данных не определяется. Например, поля SPI и Sequence Number могут реплицироваться в шифрованый «конверт», ICV может добавляться после трейлера ESP. Эти детали не видны снаружи.

Чтобы позволить ESP определять влияние комбинированного алгоритма на MTU, RFC для каждого алгоритма, используемого с ESP, должен указывать (простую) формулу, которая определяет размер шифрованных данных, как функцию размеров шифруемой информации и порядковых номеров.

3.3. Обработка исходящих пакетов

В транспортном режиме отправитель инкапсулирует информацию протокола следующего уровня между заголовком ESP и трейлером ESP, а также сохраняет указанный заголовок IP (и все расширенные заголовки IP в контексте IPv6). В туннельном режиме внешний и внутренний заголовки/расширения IP могут располагаться в различных вариантах. Создание внешнего заголовка/расширений IP на этапе инкапсуляции описано в документе по архитектуре защиты.

3.3.1. Нахождение SA

ESP применяется к исходящему пакету только после того, как реализация IPsec определяет, что пакет связан с SA, вызвавшей обработку ESP. Процесс определения применимой к исходящему трафику обработки IPsec описан в документе по архитектуре защиты.

3.3.2. Шифрование пакетов и расчет ICV

В этом параграфе мы говорим, что шифрование используется всегда, поскольку оно оказывает влияние на форматирование. Следует понимать, что возможна работа «без шифрования» при использовании пустого (NULL) алгоритма шифрования (RFC 2410). Существует несколько вариантов алгоритмов.

3.3.2.1. Раздельные алгоритмы конфиденциальности и целостности

При использовании раздельных алгоритмов шифрования и контроля целостности отправитель выполняет перечисленные ниже операции.

  • Инкапсуляция (в поле ESP Payload Data):
  • для транспортного режима — исходная информация протокола следующего уровня;
  • для туннельного режима — исходная дейтаграмма IP.
  • Добавление требуемого заполнения — необязательное заполнение TFC и заполнение для шифрования.
  • Шифрование результата с использованием ключа, алгоритма и режима, заданных для SA, и требуемых для криптографической синхронизации данных.
  • Если указаны явные данные криптографической синхронизации (например, IV), они являются входной информацией для алгоритма шифрования в соответствии с его спецификацией и помещаются в поле Payload.
  • Если используются неявные данные криптографической синхронизации, эти данные создаются и передаются на вход алгоритма шифрования в соответствии с его спецификацией.
  • Если выбран контроль целостности, сначала выполняется шифрование, которое не затрагивает поля ICV. Такой порядок обработки упрощает быстрое обнаружение и отбрасывание повторно используемых или фиктивных пакетов до их расшифровки, потенциально снижая влияние атак на службы (DoS). Это также обеспечивает возможность параллельной обработки пакетов на принимающей стороне (т. е., дешифровка может выполняться одновременно с контролем целостности). Отметим, что результатом отсутствия защиты поля ICV с помощью шифрования, является необходимость использования для расчета ICV алгоритма контроля целостности с поддержкой ключей.
  • Расчет ICV для пакета ESP без учета самого поля ICV. Таким образом, при вычислении ICV принимаются во внимание поля SPI, Sequence Number, Payload Data, Padding (если используется), Pad Length и Next Header38. Если для SA выбрана опция ESN, старшие 32 бита порядкового номера добавляются при расчете после поля Next Header, но не передаются в пакете.

Для некоторых алгоритмов контроля целостности строка, для которой выполняется расчет ICV, должна иметь размер, кратный значению, задаваемому алгоритмом. Если размер пакета ESP (перечисленные выше поля) не соответствует размеру блока, в конце пакета ESP должно добавляться неявное заполнение (после поля Next Header или после старших 32 битов порядкового номера, если используется ESN). Размер блока и, следовательно, величина заполнения задается спецификацией алгоритма контроля целостности. Заполнение не передается в пакете. Для определения необходимости использования неявного заполнения требуется обращаться к документу, определяющему алгоритм контроля целостности. Если этот документ не дает ответа на вопрос, по умолчанию используется неявное заполнение в соответствии с принятым для алгоритма размером блока (размер пакета делается кратным размеру блока). Если заполнение требуется, но алгоритм не задает его содержимого, для заполнения должны использоваться октеты заполнения с нулевым значением.

3.3.2.2. Комбинированные алгоритмы конфиденциальности и целостности

При использовании комбинированных алгоритмов шифрования/контроля целостности отправитель выполняет перечисленные ниже операции.

  • Инкапсуляция (в поле ESP Payload Data):
  • для транспортного режима — исходная информация протокола следующего уровня;
  • для туннельного режима — исходная дейтаграмма IP.
  • Добавление требуемого заполнения, включая необязательное заполнение TFC и заполнение для шифрования.
  • Шифрование и защита целостности полученного результата с использованием ключа и комбинированного алгоритма, заданных для SA, а также требуемых данных криптографической синхронизации.
  • Если указаны явные данные криптографической синхронизации (например, IV), они являются входной информацией для комбинированного алгоритма в соответствии с его спецификацией и помещаются в поле Payload.
  • Если используются неявные данные криптографической синхронизации, эти данные создаются и передаются на вход алгоритма шифрования в соответствии с его спецификацией.
  • Поля Sequence Number (или Extended Sequence Number) и SPI являются входной информацией для алгоритма, поскольку эти поля используются для контроля целостности. Это означает, что способ включения этих полей зависит от используемого комбинированного алгоритма и не включается в данный стандарт.
  • Явное поле ICV может быть частью пакета ESP при использовании комбинированных алгоритмов. Если оно не используется, обычно в шифрованных данных имеется аналогичное поле. Расположение полей контроля целостности и способ включения полей Sequence Number и SPI в расчет контрольной суммы должны определяться в RFC, содержащих спецификацию комбинированных алгоритмов, используемых с ESP.

3.3.3. Генерация порядковых номеров

Счетчик отправителя инициализуируется нулевым значением при организации SA. Отправитель инкрементирует счетчик порядковых номеров (или ESN) для данной SA и помещает младшие 32 бита номера в поле Sequence Number. Таким образом, первый пакет для данной SA получает порядковый номер 1.

Если включена функция предотвращения повторного использования пакетов (включена по умолчанию), отправитель проверяет, не повторяется ли порядковый номер перед вставкой значения в поле Sequence Number. Иными словами, для отправителя недопустимо передавать пакет в SA, если эта передача будет приводить к повторному использованию порядкового номера. Попытка передачи пакета, которая будет вызывать переполнение (переход на новый цикл отсчета) счетчика порядковых номеров приводит к внесению записи в журнал аудита. В эту запись следует включать значение SPI, текущую дату и время, адреса отправителя и получателя, а для IPv6 еще и нешифрованное представление Flow ID.

Отправитель предполагает, что предотвращение повторного использования включено по умолчанию, пока получатель однозначно не укажет обратное (см. параграф 3.4.3) или эта функция была отключена вручную при выборе конфигурации SA. Таким образом, в типичном случае реализация ESP говорит отправителю о необходимости организации новой SA, когда значение Sequence Number (или ESN) достигает максимума и должно вернуться к нулю.

Если ключи, используемые для расчета ICV, распространяются вручную, приложениям не следует использовать услуги по предотвращению повтора пакетов. Если пользователь выбрал поддержку предотвращения повторного использования, счетчик порядковых номеров на стороне отправителя должен обеспечивать корректность значений при локальных перезагрузках и т. п., пока ключ не будет сменен (см. раздел 5).

Если функция предотвращения повторов отключена (как описано выше) отправителю не нужно заботиться о мониторинге переполнения (сброса в 0) счетчика порядковых номеров. Однако отправитель будет по-прежнему инкрементировать значение счетчика и после максимального значения счетчик будет сброшен в 0. Такой вариант поведения рекомендуется для групповых SA со множеством отправителей, если между отправителями и получателями не согласовано использование механизма предотвращения повторов (выходящего за рамки данного стандарта).

Если выбрано использование ESN (см. Приложение), в поле Sequence Number передаются только 32 младших бита расширенного порядкового номера, хотя отправитель и получатель поддерживают полные 64-битовые счетчики ESN. При этом старшие 32 бита порядкового номера учитываются алгоритмом контроля четности (например, эти 32 бита могут добавляться при расчете контрольной суммы после поля Next Header, если реализован отдельный алгоритм контроля целостности).

Примечание. Если отправитель отказался от использования функции предотвращения повторов для SA, ему не следует согласовывать использование ESN в протоколе управления SA. Использование ESN вызывает у получателя необходимость поддержки окна anti-replay (для определения корректного значения старших битов ESN, которые используются при расчете ICV), что вступает в противоречие с отказом от предотвращения повторов для SA.

3.3.4. Фрагментация

Если требуется фрагментация IP, она выполняется после обработки ESP в реализации IPsec. Таким образом, в транспортном режиме ESP применяется только к целым дейтаграммам IP39 (не фрагментам). Пакет IPv4, к которому применили ESP, может быть фрагментирован маршрутизаторами на пути и в таком случае фрагменты должны быть собраны до обработки ESP на приемной стороне (этого не возникает для IPv6, где фрагментация по инициативе маршрутизаторов невозможна). В туннельном режиме ESP применяется к пакетам IP, содержимое которых может представлять собой фрагменты пакетов IP. Например, шлюз или реализация IPsec bump-in-the-stack или bump-in-the-wire (см. документ по архитектуре защиты) может использовать ESP для таких фрагментов в туннельном режиме.

Фрагментация, выполняемая реализацией IPsec или маршрутаторами на пути доставки между партнерами IPsec, существенно снижает производительность. Более того, необходимость сборки фрагментов на приемной стороне до выполнения операций ESP, порождает возможность организации атак на отказ служб. Таким образом, реализация ESP может выбрать отказ от поддержки фрагментации и маркировать передаваемые пакеты флагом DF40 для облегчения определения PMTU41. В любом случае, реализация ESP должна поддерживать генерацию сообщений ICMP PMTU (или использование эквивалентной внутренней сигнализации) для минимизации издержек на фрагментирование. Детали требований, связанных с фрагментацией рассматриваются в документе по архитектуре защиты.

3.4. Обработка входящих пакетов

3.4.1. Сборка фрагментов

Если нужна сборка фрагментов42, она выполняется до обработки AH. Если переданный на обработку AH пакет оказывается фрагментом IP (т. е., поле Offset имеет ненулевое значение или установлен флаг More Fragments), получатель должен отбрасывать такой пакет и делать запись в журнале аудита. В запись следует включать значение SPI, дату и время, адреса отправителя и получателя, а также Flow ID для IPv6.

3.4.2. Нахождение SA

При получении пакета, содержащего заголовок ESP, получатель определяет подходящую (одностороннюю) SA путем просмотра SAD. Для индивидуальных SA определение основано на значении SPI, в дополнение к которому может использоваться поле протокола, как описано в параграфе 2.1. Если реализация поддерживает групповой трафик, при определении SA используется также адрес получателя (в дополнение к SPI) и может применяться адрес отправителя, как описано в параграфе 2.1 (более подробно этот процесс описан в документе по архитектуре защиты). Запись SAD для SA показывает также использование поля Sequence Number и его размер (32 или 64 бита) для данной SA. Кроме того, запись SAD для SA задает алгоритм(ы), используемый для расчета ICV и показывает, нужно ли проверять значения ICV.

Если для пакета не найдено защищенной связи, получатель должен отбросить пакет с записью в журнал аудита. В запись следует включать значение SPI, дату и время, адреса отправителя и получателя, а также Flow ID для IPv6.

Отметим, что трафик управления SA (такой, как пакеты IKE) не требуется обрабатывать на базе SPI, т. е., этот трафик может демультиплексироваться отдельно (например, на основе полей Next Protocol и Port).

3.4.3. Проверка порядковых номеров

Все реализации ESP должны поддерживать предотвращение повторного использования пакетов43, хотя использование этой функции может быть включено или отключено получателем на уровне SA. Этот сервис недопустимо включать, пока не включены услуги контроля целостности ESP для данной SA, поскольку без этого не обеспечивается защита целостности поля Sequence Number. Функции предотвращения повторного использования применимы как к индивидуальным, так и к групповым SA. Однако данный стандарт не задает механизмов защиты от повторного использования пакетов для SA со множеством отправителей (групповых или индивидуальных). При отсутствии согласования (или настройки вручную) механизма предотвращения повторного использования для таких SA отправителю и получателю рекомендуется проверить запрет использования поля Sequence Number для таких SA (запрет организуется путем согласования или вручную), как описано ниже.

Если получатель не включил предотвращение повторного использования для SA, на входе не проверяются значения поля Sequence Number. Однако с точки зрения отправителя предотвращение повторного использования по умолчанию включено. Чтобы избавить отправителя от ненужной передачи и мониторинга порядковых номеров (см. параграф 3.3.3), получателю следует уведомить отправителя об отказе от поддержки предотвращения повторного использования на этапе организации SA, если применяется протокол организации SA.

Если получатель включил предотвращение повторного использования для SA, он должен установить значение счетчика пакетов для данной SA нулевым на момент организации SA. Для каждого принятого пакета получатель должен проверять, что поле Sequence Number в пакете не совпадает с порядковым номером ни одного из пакетов, полученных в данной SA. Эту проверку следует проводить до выполнения каких-либо операций ESP по отношению к данному пакету сразу после проверки принадлежности пакета к SA для ускорения отбрасывания дубликатов.

ESP позволяет двухэтапную проверку порядковых номеров в пакетах. Такая возможность важна для реализаций ESP (обычно для их шифровальной части), не способных выполнять расшифровку и/или проверку целостности пакетов со скоростью интерфейса подключения к незащищенной сети. Если реализация может работать со скоростью интерфейса, выполнение описанной ниже предварительной проверки становится ненужным.

Предварительная проверка поля Sequence Number обусловлена использованием порядкового номера в заголовке ESP и выполняется до проверки целостности и расшифровки пакета. Если предварительная проверка дала отрицательный результат, пакет отбрасывается, что позволяет избавиться от ненужных криптографических операций на приемной стороне. При положительном результате проверки получатель еще не может менять свой локальный счетчик, поскольку целостность порядкового номера пока не подтверждена.

Дубликаты отбрасываются с помощью «скользящего» окна приема. Реализация такого окна осуществляется локально, но описанная ниже функциональность должна поддерживаться всем реализациями.

«Правый» край окна представляет наибольшее проверенное значение поля Sequence Number для данной SA. Пакеты с номерами, выходящими за «левый» край окна, отбрасываются. Попадающие в окно пакеты проверяются на предмет совпадения порядковых номеров с номерами принятых пакетов для окна. При использовании опции ESN для SA явно передаются только младшие 32 бита расширенного порядкового номера, но получатель использует и старшие 32 бита номера для SA (от локального счетчика) при проверке порядковых номеров. При восстановлении полного порядкового номера, если значение младших 32 битов порядкового номера из принятого пакета меньше младших 32 битов значения счетчика порядковых номеров на стороне получателя, последний предполагает, что значение старших 32 битов номера было инкрементировано, т. е., перемещает номер в новое «подпространство». Этот алгоритм допускает интервал приема для отдельной SA до 232-1 пакетов. Если интервал становится больше, могут использоваться эвристические проверки для ресинхронизации порядковых номеров на приемной стороне, как описано в Приложении).

Если полученный пакет попадает в окно и не является дубликатом или пакет относится к правому краю окна и применяется отдельный алгоритм контроля целостности, получатель выполняет проверку целостности. Если используется комбинированный алгоритм, проверка целостности выполняется вместе с дешифрованием. При отрицательном результате проверки целостности получатель должен отбросить полученную дейтаграмму IP, как некорректную, с записью в журнал аудита. В запись следует включать значение SPI, дату и время, адреса отправителя и получателя, а также Flow ID для IPv6. Окно приема обновляется только при положительном результате проверки целостности (при использовании комбинированного алгоритма защищенное значение поля Sequence Number должно также совпадать с порядковым номером защиты от повторного использования пакетов).

Должны поддерживаться окна минимального размера в 32 пакета, но по умолчанию следует поддерживать окна размером 64 пакета. Получатель может выбирать другие размеры окна (больше минимального). Получатель не информирует отправителя о выбранном размере окна. Для высокоскоростных сред размер окна приема следует увеличивать. Минимальные и рекомендуемые размеры окна для высокоскоростных (например, мультимегабитных) устройств данный стандарт не задает.

3.4.4. Проверка ICV

Как и при обработке исходящих пакетов, имеется несколько вариантов, зависящих от используемого алгоритма.

3.4.4.1. Раздельные алгоритмы конфиденциальности и целостности

При использовании раздельных алгоритмов конфиденциальности и целостности выполняются перечисленные ниже операции.

  1. Если выбрана функция контроля целостности, получатель рассчитывает значение ICV для пакета ESP без самого поля ICV, используя заданный алгоритм контроля целостности и сравнивает полученное значение со значением поля ICV а пакете. Подробное описание расчета приведено ниже.Если рассчитанное значение ICV совпадает с полученным в пакете, это говорит о корректности дейтагараммы и она принимается. При отрицательном результате проверки получатель должен отбросить полученную дейтаграмму IP, как некорректную, и внести запись в журнал аудита. В запись следует включать значение SPI, дату и время получения пакета, адреса получателя и отправителя, порядковый номер и незашифрованное значение Flow ID (для IPv6).

Примечание для разработчиков.

Разработчики могут использовать любую последовательность действий, которая дает такой же результат, как перечисленные здесь операции. Сначала значение ICV из принятого пакета сохраняется и заменяется нулем. После этого проверяется общий размер пакета ESP без учета ICV. Если требуется неявное заполнение по размеру блока алгоритма контроля целостности, добавляются нулевые44 байты в конце пакета ESP сразу же вслед за полем Next Header или после старших 32 битов порядкового номера в случае использования ESN. Выполняется расчет ICV и полученный результат сравнивается с сохраненным значением. Правила сравнения задаются спецификацией алгоритма контроля целостности.

  1. Получатель дешифрует в пакете ESP поля Payload Data, Padding, Pad Length и Next Header, используя ключ, алгоритм, режим и данные криптографической синхронизации (если они нужны) в соответствии с SA. Как и в параграфе 3.3.2, мы говорим о том, что шифрование применяется всегда, поскольку оно влияет на формат. При этом предполагается, что может использоваться режим «без шифрования» с пустым (NULL) алгоритмом шифрования (RFC 2410).
    • Если явно указаны данные криптографической синхронизации (например, IV), эти данные берутся из поля Payload и передаются на вход алгоритма дешифровки в соответствии со спецификацией алгоритма.
    • Если указаны неявные данные криптографической синхронизации, создается локальная версия IV и передается на вход алгоритма дешифровки в соответствии со спецификацией алгоритма.
  1. Получатель обрабатывает поля заполнения (Padding) в соответствии со спецификацией алгоритма шифрования. Если используется принятая по умолчанию схема заполнения (смю параграф 2.4, получателю следует проверить поле Padding до удаления заполнения перед передачей расшифрованных данных на следующий уровень.
  2. Получатель проверяет поле Next Header. Если значение поля расно 59 (нет следующего заголовка), (фиктивный) пакет отбрасывается без дальнейшей обработки.
  3. Получатель восстанавливает исходную дейтаграмму IP:
    • для транспортного режима — внешний заголовок IP плюс исходная информация протокола следующего уровня в поле ESP Payload;
    • для туннельного режима — вся дейтаграмма IP в поле ESP Payload.

Конкретные действия по восстановлению исходной дейтаграммы зависят от режима (транспортный или туннельный) и описаны в документе по архитектуре защиты. По минимуму в контексте IPv6 получателю следует обеспечить для расшифрованных данных выравнивание по 8-байтовой границе для упрощения обработки протокола, указанного в поле Next Header. При этой обработке «отбрасывается» все (необязательное) заполнение TFC45, которое было добавлено для обеспечения конфиденциальности потока трафика.

Если проверка целостности выполняется параллельно с дешифровкой46, контроль целостности должен быть завершен до передачи расшифрованного пакета на дальнейшую обработку. Такой порядок упрощает быстрое детектирование и отбрасывание повторных или обманных пакетов до их дешифровки, что потенциально может снижать воздействие атак на службы.

3.4.4.2. Комбинированные алгоритмы конфиденциальности и целостности

При использовании комбинированного алгоритма защиты конфиденциальности и целостности получатель выполняет перечисленные ниже операции.

  1. Дешифровка и проверка целостности полей ESP Payload Data, Padding, Pad Length, Next Header с использованием ключа, алгоритма, режима и данных криптографической синхронизации (если они нужны), указанных SA. Значение SPI из заголовка ESP и значения счетчика пакетов на стороне получателя (преобразованное в соответствии с требованиями параграфа 3.4.3) являются входными данными для этого алгоритма, поскольку нужны для проверки целостности.
    • Если явно указаны данные криптографической синхронизации (например, IV), эти данные берутся из поля Payload и передаются на вход алгоритма дешифровки в соответствии со спецификацией алгоритма.
    • Если указаны неявные данные криптографической синхронизации, создается локальная версия IV и передается на вход алгоритма дешифровки в соответствии со спецификацией алгоритма.
  1. При отрицательном результате проверки целостности, проведенной комбинированным алгоритмом получатель должен отбросить полученную дейтаграмму IP, как некорректную, внеся запись в журнал аудита. В журнальную запись следует включать значение SPI, дату и время приема дейтаграммы, адреса отправителя и получателя, порядковый номер, а также нешифрованное значение Flow ID для IPv6.
  2. Обработка поля заполнения (Padding) в соответствии со спецификацией алгоритма шифрования, если алгоритм уже не выполнил эту операцию.
  3. Проверка поля Next Header. Если значение поля расно 59 (нет следующего заголовка), (фиктивный) пакет отбрасывается без дальнейшей обработки.
  4. Восстановление исходной дейтаграммы IP (туннельный режим) или кадра транспортного уровня (транспортный режим) из поля ESP Payload Data. При этой операции неявно отбрасывается любое (необязательное1) заполнение, используемое для защиты конфиденциальности потока трафика.

4. Аудит

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

  • Для сессии нет корректной защищенной связи (SA). В журнал аудита следует включать значение SPI, дату и время приема дейтаграммы, адреса отправителя и получателя, порядковый номер, а также нешифрованное значение Flow ID для IPv6.
  • Пакет, предложенный для обработки ESP, представляется фрагментом IP (отличное от нуля значение поля OFFSET или установлен флаг MORE FRAGMENTS). В журнал аудита следует включать значение SPI, дату и время приема дейтаграммы, адреса отправителя и получателя, порядковый номер, а также нешифрованное значение Flow ID для IPv6.
  • Попытка передачи пакета, ведущая к переполнению счетчика порядковых номеров. that would result in Sequence Number overflow. В журнал аудита следует включать значение SPI, дату и время приема дейтаграммы, адреса отправителя и получателя, порядковый номер, а также нешифрованное значение Flow ID для IPv6.
  • Полученный пакет не прошел проверки на повторное использование. В журнал аудита следует включать значение SPI, дату и время приема дейтаграммы, адреса отправителя и получателя, порядковый номер, а также нешифрованное значение Flow ID для IPv6.
  • Не прошла проверка целостности. В журнал аудита следует включать значение SPI, дату и время приема дейтаграммы, адреса отправителя и получателя, порядковый номер, а также нешифрованное значение Flow ID для IPv6.

В записи можно также включать дополнительную информацию и можно указывать в журнале информацию о других событиях, которые явно не упомянуты в данной спецификации. Получатель не обязан уведомлять отправителя о внесении записей в журнал аудита, поскольку такое требование создавало бы возможность организации атак на отказ служб.

5. Соответствие требованиям

Реализации, которые заявляют о своем соответствии или совместимости с данной спецификацией, должны полностью реализовать синтаксис и обработку ESP, описанные здесь, для индивидуального трафика, а также должны полностью выполнять все требования документа по архитектуре защиты [Ken-Arch]. В дополнение к этому, реализации, заявляющие поддержку группового трафика, должны соответствовать всем дополнительным требованиям, заданным для такого трафика. При ручном распределении ключей, используемых для расчета ICV, корректная работа системы предотвращения повторного использования пакетов требует аккуратной поддержки состояния счетчика на передающей стороне при замене ключа, поскольку в этом случае невозможно восстановить работу после переполнения счетчика. Таким образом, совместимым со спецификацией реализациям не следует предоставлять такой сервис для SA с распространением ключей вручную.

Обязательные для реализации алгоритмы, используемые с ESP, описаны в отдельном документе [Eas04], для обеспечения возможности обновления алгоритмов независимо от протокола. Кроме обязательных для ESP алгоритмов могут поддерживаться дополнительные алгоритмы.

Поскольку шифрование в ESP не является обязательным, требуется поддержка «пустого» (NULL) алгоритма шифрования для обеспечения совместимости способов согласования сервиса ESP. Поддержка только услуг защиты конфиденциальности является опциональной. Если реализация предлагает такой сервис, она должна поддерживать использование пустого (NULL) алгоритма контроля целостности. Отметим, что хотя услуги защиты целостности и конфиденциальности сами по себе могут использовать алгоритм NULL при указанных выше условиях, недопустимо выбирать NULL для обоих услуг сразу.

6. Вопросы безопасности

Безопасность является основным аспектом данного протокола и вопросы безопасности рассматриваются во всем документе. Дополнительные аспекты использования протокола IPsec, связанные с обеспечением безопасности, рассматриваются в документе по архитектуре защиты.

7. Отличия от RFC 2406

Этот документ имеет несколько существенных отличий от RFC 2406.

  • Предоставление только услуг защиты конфиденциальности — в данном документе возможно, а не обязательно.
  • Изменено определение SPI для обеспечения возможности однотипного поиска в SAD для индивидуальных и групповых SA, совместимого со многими технологиями групповой передачи. Для выбора индивидуальных SA значение SPI может использоваться само по себе или в комбинации с протоколом по усмотрению получателя. Для выбора групповых SA значение SPI объединяется с адресом отправителя (и, опционально, с адресом получателя).
  • Добавлены расширенные порядковые номера (ESN) для обеспечения 64-битовой нумерации на высокоскоростных соединениях. Разъяснены требования к отправителю и получателю для групповых SA и защищенных связей с множеством отправителей.
  • Поле Payload — расширена модель для использования комбинированных алгоритмов.
  • Заполнение для повышения конфиденциальности потока трафика — добавлено требование обеспечения возможности добавления байтов после завершения данных IP Payload и до начала поля Padding.
  • Next Header – добавлено требование по обеспечению возможности генерации и отбрасывания фиктивных пакетов заполнения (Next Header = 59).
  • ICV — расширена модель с учетом использования комбинированных алгоритмов.
  • Алгоритмы — добавлена поддержка комбинированных алгоритмов защиты конфиденциальности.
  • Ссылки на обязательные алгоритмы вынесены в отдельный документ.
  • Обработки исходящих и входящих пакетов — сейчас существуют два варианта: (1) с раздельными алгоритмами защиты конфиденциальности и целостности и (2) с комбинированным алгоритмом. Добавление комбинированных алгоритмов привело к созданию разделов шифрования/дешифровки и контроля целостности для обработки как входящих, так и исходящих пакетов.

8. Совместимость с ранними версиями

В ESP нет номера версии и механизмов, позволяющих партнерам IPsec определять и согласовывать используемые версии ESP. В этом параграфе рассмотрены вопросы совместимости с более ранними версиями.

Во-первых, если не реализовано ни одной из новых возможностей ESP v3, формат пакетов ESP будет идентичен для ESP v2 и ESP v3. При использовании комбинированного алгоритма (поддерживается только в ESP v3) формат пакетов может отличаться от формата пакетов ESP v2. Однако партнер, поддерживающий только ESP v2 не будет согласовывать алгоритм, поскольку он определен только для использования в контексте ESP v3.

Согласование расширенных порядковых номеров (ESN) поддерживается IKE v2 and и может быть решено для IKE v1 за счет добавления ESN Addendum к IKE v1 DOI47.

В новом ESP (v3) появились два новых метода повышения уровня конфиденциальности потоков трафика (TFC):

  • произвольное заполнение после окончания пакета IP;
  • условное отбрасывание с использованием Next Header = 59.

Первая возможность относится к тем, которые могут вызывать проблемы на приемной стороне, поскольку поле общего размера пакета IP будет говорить о завершении пакета. Таким образом, все байты заполнения TFC после завершения пакета следует удалять в той же точке при обработке пакета IP после выполнения операций ESP, даже если программы IPsec не удалили это заполнение. Таким образом, эту возможность ESP v3 отправитель может применять независисимо от того, использует получатель ESP v2 или ESP v3.

Вторая возможность позволяет отправителю передавать в данных произвольные строки байтов, которые не обязаны быть корректно сформированными пакетами IP (внутри туннеля для целей TFC). Возникает вопрос, что будет делать получатель ESP v2, когда поле Next Header в заголовке пакета ESP будет иметь значение 59. Он может отбросить пакет, обнаружив некорректный заголовок IP, и внести запись в журнал аудита и может продолжить нормальную работу, поскольку иное поведение создавало бы уязвимость к DoS-атакам с использованием трафика от идентифицированных узлов. Таким образом, эта возможность является оптимизацией, которую отправитель ESP v3 может использовать независимо от того, какая версия реализована на приемной стороне — ESP v2 или ESP v3.

9. Благодарности

Автор благодарит Ran Atkinson, чей вклад был очень важен на начальных этапах разработки IPsec, а также разработчиков первой серии стандартов IPsec RFC 1825 — 1827. Karen Seo заслуживает особой благодарности за помощь при редактировании этой и предыдущей версии спецификации. Автор также благодарит членов рабочих групп IPSEC и MSEC, которые внесли свой вклад в развитие спецификации протокола.

10. Литература

10.1. Нормативные документы

[Bra97] Bradner, S., «Key words for use in RFCs to Indicate Requirement Level», BCP 14, RFC 2119, March 1997.

[DH98] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[Eas04] 3rd Eastlake, D., «Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)», RFC 4305, December 2005.

[Ken-Arch] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

[Pos81] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

10.2. Дополнительная литература

[Bel96] Steven M. Bellovin, «Problem Areas for the IP Security Protocols», Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996.

[HC03] Holbrook, H. and B. Cain, «Source-Specific Multicast for IP», Work in Progress49, November 3, 2002.

[Kau05] Kaufman, C., Ed., «The Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[Ken-AH] Kent, S., «IP Authentication Header», RFC 4302, December 2005.

[Kra01] Krawczyk, H., «The Order of Encryption and Authentication for Protecting Communications (Or: How Secure Is SSL?)», CRYPTO’ 2001.

[NIST01] Federal Information Processing Standards Publication 140-2 (FIPS PUB 140-2), «Security Requirements for Cryptographic Modules», Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.

[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, «The Group Domain of Interpretation», RFC 3547, July 2003.

[RFC3740] Hardjono, T. and B. Weis, «The Multicast Group Security Architecture», RFC 3740, March 2004.

[Syverson] P. Syverson, D. Goldschlag, and M. Reed, «Anonymous Connections and Onion Routing», Proceedings of the Symposium on Security and Privacy, Oakland, CA, May 1997, pages 44-54.

Приложение A: Расширенные порядковые номера (64 бита)

A1. Обзор

В этом приложении описана схема расширенной порядковой нумерации (ESN) для IPsec (ESP и AH), где используются 64-битовые порядковые номера, но в каждом пакете передаются только младшие 32 бита номера. Описана схема окна, используемого для обнаружения повтрно используемых пакетов, а также механизм определения старших битов порядкового номера, используемых для отбрасывания пакетов и расчета ICV. Описан также механизм обработки случаев потери синхронизации для старших (не передаваемых в пакетах) битов порядкового номера.

A2. Окно Anti-Replay

Получатель будет поддерживать окно предотвращения повторного использования пакетов размером W51. Это окно будет ограничивать степень разупорядочивания пакетов при доставке без потери идентификации. Все 232 порядковых номера, связанных с любым фиксированным значением старших 32 битов (Seqh) будем называть подпространством порядковых номеров. В приведенной ниже таблице перечислены используемые переменные и даны их определения.

Имя Размер в битах Значение
W 32 Размер окна
T 64

Наибольший порядковый номер, идентифицированный до настоящего времени — верхняя граница окна

Tl 32 32 младших бита T
Th 32 32 старших бита T
B 64 Нижняя граница окна
Bl 32 32 младших бита B
Bh 32 32 старших бита B
Seq 64 Порядковый номер полученного пакета
Seql 32 32 младших бита Seq
Seqh 32 32 старших бита Seq

При выполнении проверки на предмет повторного использования пакетов или определении старших битов номера для идентификации входящего пакета возможны два случая:

  • Случай A: Tl >= (W — 1) все окно находится в одном подпространстве порядковых номеров (Рисунок 3)
  • Случай B: Tl < (W — 1) окно захватывает части двух смежных подпространств порядковых номеров (Рисунок 4).

На рисунках нижняя линия —- показывает смежные подпространства порядковых номеров, а 0 указывает начало каждого подпространства. Короткая двойная линия === показывает применимые старшие биты, а ==== представляет окно. Звездочки **** обозначают грядущие номера, т. е., номера номера, превышающие максимальный идентифицируемый в данный момент номер (ThTl).

        Th+1                         *********

        Th               =======*****

              --0--------+-----+-----0--------+-----------0--
                         Bl    Tl            Bl
                                        (Bl+2^32) mod 2^32
Рисунок 3: Случай A
        Th                           ====**************

        Th-1                      ===

              --0-----------------+--0--+--------------+--0--
                                  Bl    Tl            Bl
                                                 (Bl+2^32) mod 2^32
Рисунок 4: Случай B

A2.1. Использование окна Anti-Replay и управление им

Окно предотвращения повторов можно рассматривать как строку битов размером W (W = T — B + 1 и не может превышать 232 — 1). Младший бит строки соответствует B, а старший — T и каждый порядковый номер от Bl до Tl представлен соответствующим битом. Значение бита показывает, был ли пакет с соответствующим номером принят и идентифицирован, что позволяет обнаружить и отбросить повторные пакеты.

При получении и проверке корректности пакета с 64-битовым порядковым номером (Seq), превышающим T:

  • B увеличивается на (Seq — T);
  • отбрасываются (Seq — T) битов в левой части окна;
  • добавляются (Seq — T) битов в правой части окна;
  • устанавливается «верхний» бит для индикации приема и идентификации пакета с данным порядковым номером;
  • сбрасываются новые биты между T и «верхним» битом для индикации отсутствия принятых пакетов с соответствующими порядковыми номерами;
  • для T устанавливается значение нового порядкового нгомера.

Проверка пакетов на предмет повторного использования:

  • Случай A: Если Seql >= Bl (где Bl = Tl — W + 1) И Seql <= Tl, проверяется соответствующий бит окна. Если пакет с номером Seql уже был принят (бит окна установлен), он отбрасывается. В противном случае проверяется целостность пакета. Проверка старших битов номера (Seqh) описана в параграфе A2.2.

Случай B: Если Seql >= Bl ( где Bl = Tl — W + 1) ИЛИ Seql <= Tl, проверяется соответствую щий бит окна. Если пакет с номером Seql уже был принят (бит окна установлен), он отбрасывается. В противном случае проверяется целостность пакета. Проверка старших битов номера (Seqh) описана в параграфе A2.2.

A2.2. Определение старших битов (Seqh) порядкового номера

Поскольку в пакетах передается только значение Seql, получатель должен отслеживать подпространство порядковых номеров для каждого пакета (т. е., определять значение Seqh). Приведенные справа уравнения определяют выбор Seqh в «нормальных» условиях. В параграфе B3 рассматривается определение старших битов номера в условиях экстремальных потерь пакетов.

+ Для случая A (Рисунок 3):
  Если Seql >= Bl (где Bl = Tl - W + 1), то Seqh = Th
  Если Seql <  Bl ( где Bl = Tl - W + 1), то Seqh = Th + 1

+ Для случая B (Рисунок 4):
  Если Seql >= Bl ( где Bl = Tl - W + 1), то Seqh = Th - 1
  Если Seql <  Bl ( где Bl = Tl - W + 1), то Seqh = Th

A2.3. Пример псевдокода

Приведенный ниже псевдокод иллюстрирует описанные выше алгоритмы предотвращения повторного использования и контроля целостности пакетов. Значения Seql, Tl, Th и W являются 32-битовыми целыми числами без знака. Используется арифметика по модулю 232.

        Если (Tl >= W - 1)                        Случай A
            Если (Seql >= Tl - W + 1)
                Seqh = Th
                Если (Seql <= Tl)
                    Если (проверка на предмет повтора прошла)
                        Если (проверка целостности прошла)
                            Установить бит, соответствующий Seql
                            Принять пакет
                        Иначе отбросить пакет
                    Иначе отбросить пакет
                Иначе
                    Если (проверка целостности прошла)
                        Tl = Seql (shift bits)
                        Установить бит, соответствующий Seql
                        Принять пакет
                    Иначе отбросить пакет
            Иначе
                Seqh = Th + 1
                Если (проверка целостности прошла)
                    Tl = Seql (shift bits)
                    Th = Th + 1
                    Установить бит, соответствующий Seql
                    Принять пакет
                Иначе отбросить пакет
        Иначе                                    Случай B
            Если (Seql >= Tl - W + 1)
                Seqh = Th - 1
                Если (проверка на предмет повтора прошла)
                    Если (pass integrity check)
                        Установить бит, соответствующий Seql
                        Принять пакет
                    Иначе отбросить пакет
                Иначе отбросить пакет
            Иначе
                Seqh = Th
                Если (Seql <= Tl)
                    Если (проверка на предмет повтора прошла)
                        Если (проверка целостности прошла)
                            Установить бит, соответствующий Seql
                            Принять пакет
                        Иначе отбросить пакет
                    Иначе отбросить пакет
                Иначе
                    Если (проверка целостности прошла)
                        Tl = Seql (shift bits)
                        Установить бит, соответствующий Seql
                        Принять пакет
                    Иначе отбросить пакет

A3. Обработка потери синхронизации в результате больших потерь пакетов

При потере 232 или более пакетов подряд для одной SA отправитель и получатель теряют синхронизацию старших битов порядкового номера, т. е., уравнения параграфа B2.2 не будут давать корректного значения. Пока эта проблема не будет обнаружена и разрешена, последующие пакеты для данной SA не могут быть идентифицированы и будут отбрасываться. Описанную ниже процедуру восстановления синхронизации следует поддерживать во всех реализациях IPsec (ESP или AH), которые работают с ESN.

Отметим, что описанный вариант экстремальных потерь представляется маловероятным для SA, использующих протокол TCP, поскольку отправитель, не получающий пакетов ACK в ответ на переданные пакеты, будет останавливать передачу до того, как будут потеряны 232. И другие приложения с двухсторонним обменом данными (даже работающие по протоколу UDP) при таких экстремальных потерях будут включать тот или иной тайм-аут. Однако приложения с односторонним потоком трафика, работающие по протоколу UDP, могут не поддерживать средств автоматического детектирования экстремальных потерь пакетов и, следовательно, требуется обеспечить метод восстановления для таких ситуаций.

Предлагаемое решение призвано:

  • минимизировать влияние на обработку нормального трафика;
  • предотвратить создание новой возможности организации атак на отказ служб за счет неоправданной затраты ресурсов на ресинхронизацию;
  • реализовать механизм восстановления только на принимающей стороне, поскольку отправитель обычно не знает, для каких порядковых номеров получателю требуется восстановление синхронизации; реализация механизмов восстановления на приемной стороне является предпочтительной; кроме того, такое решение обеспечивает совместимость с ранними версиями.

A3.1. Включение ресинхронизации

Для каждой SA получатель запоминает число последовательных пакетов, для которых не прошла идентификация. Это значение используется для включения процесса ресинхронизации, который следует выполнять в фоновом режиме или на отдельном процессоре. Прием корректного пакета для данной SA ведет к сбросу счетчика некорректных пакетов в 0. Значение, при котором включается ресинхронизация, является локальным параметром. Не требуется поддерживать независимые значения порога ресинхронизации для каждой SA, но реализация вправе поддерживать их.

A3.2. Процесс ресинхронизации

Когда значение счетчика некорректных пакетов достигает заданного порога, выбирается «плохой» пакет, для которого процедура идентификации повторяется с использованием следующего большего значения для старшей части расширенного порядкового номера (Seqh). Значение старшей части номера увеличивается на 1 при каждой проверке. Число попыток проверки следует ограничивать на случай того, что выбранный для проверки пакет оказался «из прошлого» или является поддельным. Максимальное число попыток задается локальным параметром. Поскольку значение Seqh неявно помещается после данных AH (или ESP), может оказаться возможной оптимизация процедуры восстановления за счет выполнения процедуры контроля целостности пакета с использованием нарастающих значений Seqh для расчета ICV. При успешной идентификации пакета с помощью описанной процедуры значение счетчика некорректных пакетов сбрасывается и устанавливается значение T, определенное по прошедшему проверку пакету.

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

Адрес автора

Stephen Kent

BBN Technologies

10 Moulton Street

Cambridge, MA 02138

USA

Phone: +1 (617) 873-3988

EMail: kent@bbn.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Encapsulating Security Payload — инкапсуляция защищенных данных.

2Encapsulating Security Payload — инкапсулированные защищенные данные.

3Security Association.

4Этот термин используется потому, что (на базе пакетов) выполняемые расчеты будут обеспечивать контроль целостности напрямую без организации специальных соединений. Идентификация источника данных выполняется опосредованно в результате привязывания ключа, используемого для контроля целостности к партнеру IPsec. Обычно такая привязка обеспечивается за счет использования разделяемого симметричного ключа.

5Traffic flow confidentiality

6Система ESP может быть развернута, как часть системы TFC более высокого уровня (например, Onion Routing [Syverson]), но такие системы выходят за пределы настоящего стандарта.

7Значения идентификаторов протоколов приведены на странице http://www.iana.org/assignments/protocol-numbers.

8Security Parameters Index — список параметров защиты.

9Sequence Number — порядковый номер.

10Integrity Check Value — контрольная сумма для проверки целостности.

11Initialization Vector.

12Cipher Block Chaining — сцепка шифрованных блоков.

13На рисунке показаны «биты в среде передачи» — даже при использовании расширенных порядковых номеров передаваемые пакеты включают только младшие 32 бита порядкового номера (см. параграф 2.2.1).

14M = обязательно; O = опция; D = фикция.

15Ciphertext, если выбрано шифрование.

16В туннельном режиме дейтаграмма IP, в транспортном — следующий заголовок и данные.

17См. параграф 2.1.1

18Обязательно при использовании отдельного механизма контроля целостности.

19M = обязательно; O = опция; D = фикция

20В туннельном режиме дейтаграмма IP, в транспортном — следующий заголовок и данные.

21Может использоваться только при указании реального размера данных (payload).

22См. параграф 2.1.1

23Передача этого поля определяется алгоритмом, но в любом случае поле является «невидимым» для ESP.

24Присутствие этого поля определяется спецификацией алгоритма.

25Security Association Database.

26Ternary Content-Addressable Memory — ассоциативная память.

27Group Domain of Interpretation.

28Source-Specific Multicast.

29No Security Association Exists.

30Extended Sequence Number — расширенный порядковый номер.

31Реестр «IP Protocol Numbers».

32В настоящее время этот список доступен по ссылке http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml. Прим. перев.

33Traffic Flow Security — защита потока трафика.

34Traffic Flow Confidentiality — конфиденциальность потока трафика.

35Integrity Check Value — значение контроля целостности.

36Отметим, что транспортный режим не следует ограничивать только его использованием для транспортных протоколов TCP и UDP.

37Отметим, что при использовании незашифрованной части заголовка для создания IV, эта информация может стать критичной для защиты и, таким образом, граница защиты, связанная с процессом шифрования, может расширяться. Например, при использовании ESP Sequence Number для определения IV логика генерации значения Sequence Number (программная или аппаратная) будет оцениваться, как часть реализации алгоритма. В случае FIPS 140-2 [NIST01] это будет существенно расширять границы оценки криптографического модуля.

38Отметим, что 4 последних поля будут зашифрованы, поскольку шифрование выполянется до расчета ICV.

39Как отмечено в конце параграфа 3.1.1, реализации bump-in-the-stack и bump-in-the-wire могут сначала выполнять сборку фрагментов, созданных локальным уровнем IP, потом выполнять обработку IPsec и снова фрагментировать полученный в результате пакет.

В случае IPv6 реализации bump-in-the-stack и bump-in-the-wire должны проверять все расширенные заголовки, а также значения флага More и поля Fragment Offset для обнаружения фрагментирования. Если фрагментирование используется, пакеты должны быть собраны до выполнения операций IPsec.

40Не фрагментировать. Прим. перев.

41Path MTU — размер максимального передаваемого блока для пути.

42При сборке пакетов текущая спецификация IPv4 не требует обнуления поля Offset и сброса флага More Fragments. Для корректной обработки собранных из фрагментов пакетов IPsec (вместо отбрасывания, принятого для фрагментов) реализация IP должна выполнять обе указанные операции после сборки пакета из фрагментов.

43Anti-replay service.

44Значения байтов должны устанавливаться в соответствии со спецификацией алгоритма контроля целостности, т. е., не обязаны быть нулевыми во всех случаях. Прим. перев.

45Если это заполнение используется, оно размещено после дейтаграммы IP (или кадра транспортного уровня) и перед полем Padding (см. параграф 2.4).

46При параллельной дешифровке и проверке целостности необходимо принимать меры по предотвращению «гонки» в части доступа к пакету и преобразования дешифрованного пакета.

47Domain of Interpretation — область интерпретации.

49Работа завершена и опубликована в RFC 4607. Прим. перев.

51Для окна при расширенной нумерации не вводится дополнительных требований по поддержке минимального или рекомендуемого размера окна, сверх тех требований (32 и 64 пакета, соответственно), которые уже заданы для окна при 32-битовой нумерации. Однако разработчикам предлагается масштабировать размер окна в соответствии со скоростью интерфейсов, поддерживаемых реализацией, использующей опцию ESN. Описанный ниже механизм предполагает, что размер окна не превышает 231 пакета.

Рисунок 3: Случай A




RFC 4302 IP Authentication Header

Network Working Group                                        S. Kent
Request for Comments: 4302                          BBN Technologies
Obsoletes: 2402                                        December 2005
Category: Standards Track

Идентификационный заголовок IP

IP Authentication Header

PDF

Статус документа

Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Допускается свободное распространение документа.

Авторские права

Copyright (C) The Internet Society (2005).

Тезисы

В этом документе описана обновленная версия идентификационного заголовка IP (AH1), который разработан для обеспечения услуг проверки тождественности (идентификации) в IPv4 и IPv6. Этот документ отменяет действие RFC 2402 (ноябрь 1998).

Оглавление

Исключено из версии HTML

1. Введение

В документе предполагается, что читатель достаточно знаком с терминами и концепциями, изложенными в документе «Архитектура защиты для протокола IP» [Ken-Arch], далее называемом для краткости описанием архитектуры. В частности, читателю следует понимать определения услуг по защите, обеспечиваемых ESP2 [Ken-ESP] и AH, концепцию защищенных связей, способы использования ESP вместе с идентификационным заголовком AH, а также различные опции управления ключами, поддерживаемые для ESP и AH.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [Bra97].

Идентификационный заголовок IP (AH) используется для обеспечения целостности и идентификации источника данных для дейтаграмм IP (далее для краткости будет использоваться термин «целостность») без организации специальных соединений и защиты против повторного использования пакетов. Второй, необязательный, сервис может выбираться получателем при создании защищенной связи (SA3). Протокол по умолчанию требует от отправителя увеличивать порядковые номера для предотвращения повторного использования пакетов, но этот механизм работает только при проверке порядковых номеров на приемной стороне. Для использования расширенных возможностей порядковой нумерации AH вносит требование к протоколу управления SA по обеспечению возможности согласования этой новой функции (см. параграф 2.5.1).

AH обеспечивает идентификацию для всех возможных частей заголовка, а также для данных протокола следующего уровня. Однако некоторые поля заголовка IP могут изменяться на пути передачи и значения этих полей при получении пакета могут быть непредсказуемыми для отправителя. Такие поля нельзя защитить с помощью AH. Таким образом, защита заголовка IP с помощью AH является неполной (см. Приложение A.).

AH может использоваться в комбинации с ESP [Ken-ESP] или путем вложения [Ken-Arch]. Услуги по защите могут обеспечиваться между парой взаимодействующих хостов, парой защитных шлюзов, а также между защитным шлюзом и хостом. ESP может использоваться для обеспечения такой же защиты от повторного использования пакетов и аналогичной защиты целостности, а также обеспечивает дополнительную защиту конфиденциальности (шифрование). Основным различием между защитой целостности, обеспечиваемой ESP и AH является расширение покрытия. В частности, ESP не защищает никаких полей заголовка IP, пока эти поля не инкапсулируются ESP (например, за счет использования туннеля). Более детальное описание использования AH и ESP в разных сетевых средах приводится в документе, посвященном архитектуре защиты [Ken-Arch].

В разделе 7 кратко рассмотрены отличия этого документа от RFC 2402 [RFC2402].

2. Формат заголовка идентификации

 В протокольный заголовок (IPv4, IPv6 или расширение IPv6), непосредственно предшествующий заголовку AH, следует помещать значение 51 в поле Protocol (IPv4) или Next Header (IPv6, включая расширение) [DH98]. Рисунок 1 показывает формат заголовка AH.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Header   |  Payload Len  |          RESERVED             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Security Parameters Index (SPI)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Sequence Number Field                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                Integrity Check Value-ICV (перемен.)           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1: Формат заголовка AH

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

Число битов

Когда требуется4

Покрывается

Передается

IP Header

переменное

M

5

да

Next Header

1

M

да

да

Payload Len

1

M

да

да

RESERVED

2

M

да

да

SPI

4

M

да

да

Seq# (младшие 32 бита)

4

M

да

да

ICV

переменное

M

да6

да

IP datagram7

переменное

M

да

да

Seq# (старшие 32 бита)

4

При поддержке ESN8

да

нет

ICV Padding

переменное

Если нужно

нет

Описание полей заголовка AH приводится в последующих параграфах. Все описанные здесь поля являются обязательными, т. е., всегда должны присутствовать в заголовке AH и учитываются при расчете значения для контроля целостности (ICV9) (см. параграфы 2.6 и 3.3.3).

Примечание. Предполагается, что все криптографические алгоритмы IPsec используют на входе канонический сетевой порядок байтов (см. Приложение к RFC 791 [RFC791]) и на выходе дают результат также в каноническом сетевом порядке байтов.

При передаче пакетов IP также используется сетевой порядок байтов.

AH не содержит номера версии, следовательно для обеспечения совместимости со старыми версиями информация о версии идентификационного заголовка должна передаваться с помощью механизмов сигнализации между партнерами IPsec (например, IKE [IKEv2] или настройка по отдельному каналу).

2.1. Next Header — следующий заголовок

Восьмибитовое поле Next Header показывает тип информации, расположенной после идентификационного заголовка AH. Значения этого поля выбираются из списка номеров протоколов IP10, представленного на сайте IANA11. Например, значение 4 показывает протокол IPv4, значение 41 — IPv6, а 6 — протокол TCP.

2.2. Payload Length — размер данных

Это 8-битовое поле указывает размер заголовка AH в 32-битовых словах (4-байтовых блоках) минус 2. Например, если алгоритм проверки целостности использует 96-битовое идентификационное значение, поле длины будет иметь значение 4 (3 слова полей фиксированной длины и 3 слова для ICV минус 2). Для IPv6 общий размер заголовка должен быть кратным 8 октетам (отметим, что хотя IPv6 [DH98] характеризует AH как внешний заголовок, его размер измеряется в 32-битовых словах, а не 64-битовых, как в заголовках расширения IPv6). Комментарии по учету байтов заполнения приведены в параграфах 2.6 и 3.3.3.2.1.

2.3. Reserved — резерв

Это 16-битовое поле зарезервировано для использования в будущем. Отправитель должен устанавливать для этого поля нулевое значение, а получателю следует игнорировать значение этого поля. Отметим, что значение этого поля (0) учитывается при вычислении ICV, но игнорируется получателем.

2.4. Security Parameters Index (SPI) — список параметров защиты

SPI представляет собой произвольное 32-битовое значение, используемое получателем для идентификации SA, с которой связан входящий пакет. Для индивидуальных SA, значение SPI может само по себе идентифицировать SA или использоваться в комбинации с типом протокола IPsec (в данном случае AH). Поскольку для индивидуальных SA значение SPI генерируется получателем, решение вопроса о достаточности этого значения для идентификации SA или необходимости использования в комбинации с типом протокола IPsec определяется локальными условиями. Поле SPI является обязательным и упомянутый выше механизм отображения входящего трафика на индивидуальные SA должен поддерживаться всеми реализациями AH.

В реализациях IPsec, поддерживающих групповую адресацию, должны поддерживаться групповые SA с использованием описанного ниже алгоритма отображения входящих дейтаграмм IPsec на SA. Разработчикам, поддерживающим только индивидуальный трафик, не обязательно реализовать механизм демультиплексирования.

Во многих защищенных multicast-архитектурах (например, [RFC3740]) центральный контроллер группы/сервер ключей сам выделяет для группы значение SPI. Выделение SPI не согласуется и не координируется с подсистемами управления ключами (например, IKE) на конечных узлах группы. Следовательно, возникает возможность совпадения значений SPI для групповой и индивидуальной SA. Поддерживающие групповую адресацию реализации IPsec должны корректно демультиплексировать входящий трафик даже в случаях совпадения значений SPI.

Каждая запись в базе данных защищенных связей (SAD12) [Ken-Arch] должна указывать, по каким критериям в дополнение к SPI отыскивается SA – получатель, получатель и отправитель. Для групповых SA поле протокола не используется при поиске SA. Для каждого входящего пакета с защитой IPsec реализация должна произвести поиск в SAD и найти запись, наиболее точно соответствующую идентификатору SA. Если обнаруживается более одной записи SAD, соответствующей значению SPI, выбирается запись по наиболее точному соответствию получателя или получателя и отправителя (как указано в записи SAD). Таким образом, логический порядок поиска в SAD имеет вид:

  1. Поиск в базе SAD соответствия {SPI, адрес получателя, адрес отправителя}. Если запись SAD найдена, входящий пакет AH обрабатывается с найденной записью SAD. В противном случае выполняется п. 2.
  2. Поиск в базе SAD соответствия {SPI, адрес получателя}. Если запись SAD найдена, входящий пакет AH обрабатывается с найденной записью SAD. В противном случае выполняется п. 3.
  3. Поиск в базе SAD соответствия {SPI}, если получатель выбрал поддержку одного пространства SPI для AH и ESP, или {SPI, протокол} в противном случае. Если запись SAD найдена, входящий пакет AH обрабатывается с найденной записью SAD. В противном случае пакет отбрасывается с записью в журнал аудита.

На практике реализация может выбрать любой метод ускорения поиска, но наблюдаемое извне поведение должно соответствовать описанному выше поиску в SAD. Например, программные реализации могут индексировать хэш-таблицу SPI. Записи SAD в хэш-таблице сортируются в связный список, в котором записи для SA с большим соответствием располагаются ближе к началу, а с меньшим соответствием — ближе к концу списка. В аппаратных реализациях поиск максимального соответствия может ускоряться встроенными средствами с использованием общедоступной технологии TCAM13.

Индикация использования адресов отправителя и получателя при поиске соответствия для отображения входящего трафика IPsec на SA должна выполняться при настройке конфигурации SA вручную или путем согласования параметров с использованием протокола управления SA (например, IKE или GDOI14 [RFC3547]). Обычно группы SSM15 [HC03] используют трехкомпонентный идентификатор SA, включающий SPI, групповой адрес получателей и адрес отправителя. SA группы Any-Source Multicast требует в качестве идентификатора только SPI и групповой адрес получателей.

Значения SPI в диапазоне от 1 до 255 зерезервированы IANA для использования в будущем. Эти значения не будут распределяться агентством IANA, пока их использование не будет оговорено в специальном RFC. Значение SPI = 0 зарезервировано для локального, связанного с реализацией, применения и его недопустимо передавать в сеть. Например, реализация управления ключами может использовать SPI=0 для идентификации отсутствия защищенных связей16 в период, когда реализация IPsec запрашивает новую SA для объекта управления ключами, но данная SA еще не организована.

2.5. Sequence Number — порядковый номер

Это 32-битовое поле, трактуемое, как целое число без знака, содержит значение счетчика пакетов, которое увеличивается на 1 для каждого переданного пакета (счетчик пакетов для SA). Для индивидуальных SA и групповых SA с одним отправителем, последний должен инкрементировать данное поле для каждого переданного пакета. Использование одной SA множеством отправителей допустимо, хотя в общем случае не рекомендуется. AH не предоставляет возможностей синхронизации порядковых номеров между множеством отправителей или осмысленного счетчика пакетов на стороне получателя и не обеспечивает окна в контексте множества отправителей. Таким образом, для SA с множеством отправителей функции предотвращения повторного использования пакетов AH становятся недоступными (см. параграфы 3.3.2 и 3.4.3).

Это поле является обязательным и должно присутствовать даже в тех случаях, когда получатель не пользуется услугами по предотвращению повторного использования пакетов для конкретной SA. Обработка поля Sequence Number осуществляется по усмотрению получателя, но все реализации AH должны обеспечивать возможность обработки, описанной в параграфах 3.3.2. Генерация порядковых номеров и 3.4.3. Проверка порядковых номеров. Таким образом, отправитель должен передавать это поле, но получатель не обязан принимать его во внимание.

Счетчики на стороне отправителя и получателя инициализируются нулевым значением при создании SA (первый пакет, переданный с использованием данной SA будет иметь порядковый номер 1; генерация порядковых номеров более подробно описана в параграфе 3.3.2). Если предотвращение повторного использования пакетов включено (используется по умолчанию), передаваемые порядковые номера никогда не должны повторяться. Таким образом, счетчики пакетов на стороне отправителя и получателя должны сбрасываться (путем создания новой SA и нового ключа) до передачи пакета с порядковым номером 2^32 в каждой SA.

2.5.1. Extended Sequence Number — расширенный порядковый номер (64 бита)

В высокоскоростных реализациях IPsec следует предлагать новую опцию для расширения 32-битового поля порядкового номера. Использование поля ESN17 должно согласовываться протоколом управления SA. Отметим, что в IKEv2 это согласование происходит неявно — использование ESN включено по умолчанию, пока явно не выбраны 32-битовые порядковые номера. Поддержка ESN возможна как для индивидуальных, так и для групповых SA.

ESN позволяет использовать для SA 64-битовые порядковые номера (см. Приложение B: Расширенные порядковые номера (64 бита) ). В заголовке AH каждого пакета передаются только младшие 32 бита расширенного порядкового номера, а старшие 32 бита учитываются, как часть порядкового номера, отправителем и получателем и включаются в расчет ICV, но не передаются.

2.6. Integrity Check Value (ICV) — контроль целостности

Это поле переменной длины содержит значение контрольной суммы ICV18 для данного пакета. Размер поля должен быть кратным 32 битам как для IPv4, так и для IPv6. Обработка ICV рассматривается в параграфах 3.3.3. Расчет ICV и 3.4.4. Проверка ICV. Это поле может включать явное заполнение для обеспечения кратности размера заголовка AH в целом 32 (IPv4) или 64 (IPv6) битам. Заполнение должны поддерживать все реализации и размер заполнения должен быть минимально достаточным для выравнивания заголовков в соответствии с требованиями IPv4/IPv6. Подробное описание расчета размера области заполнения приведено в параграфе 3.3.3.2. Заполнение и расширенные порядковые номера. Спецификация алгоритма контроля целостности должна включать размер ICV, а также правила сравнения и этапы обработки при проверке целостности.

3. Обработка идентификационного заголовка AH

3.1. Местоположение AH

AH может работать в двух режимах — транспортном и туннельном. Более подробное описание этих режимов и рекомендации по выбору приводится в документе, посвященном архитектуре защиты.

3.1.1. Транспортный режим

В транспортном режиме19 AH помещается между заголовком IP и заголовком протокола следующего уровня (например, TCP, UDP, ICMP и т. п.) или перед другими заголовками IPsec, если они имеются. В контексте IPv4 это говорит о размещении AH после заголовка IP (и всех опций этого заголовка), но перед заголовком протокола следующего уровня. На рисунке справа показан заголовок типичного пакета IPv4 до защиты и положение заголовка AH при работе в транспортном режиме.

            До применения AH
      ----------------------------
IPv4  |Исх. заг. IP |     |      |
      |   (опции)   | TCP | Data |
      ----------------------------

             После применения AH
      -------------------------------------------------------
IPv4  |Исходный заголовок IP (опции) | AH | TCP |    Data   |
      -------------------------------------------------------
      |<- Обраб. переменного поля  ->|<-  неизменые поля  ->|
      |<----- идентифицировано кроме перемен. полей   ----->|

В контексте IPv6 заголовок AH представляется, как передаваемые «насквозь» данные и, следовательно, ему надлежит размещаться после заголовков расширения (hop-by-hop, routing, fragmentation). Опции получателя в расширенном заголовке могут располагаться перед заголовком AH, после него или по обе стороны, в зависимости от желаемой семантики. На приведенном ниже рисунке показано размещение AH для транспортного режима в типичном пакете IPv6.

                 До применения AH
      -----------------------------------------
IPv6  |             | расш. заг|     |        |
      | Исх. заг. IP|если есть | TCP | Данные |
      -----------------------------------------

                 После применения AH
      ------------------------------------------------------------
IPv6  |             |hop-by-hop, dest*, |    | dest |     |      |
      | Исх. заг. IP|routing, fragment. | AH | opt* | TCP | Data |
      ------------------------------------------------------------
      |<--- Обраб. переменного поля  -->|<--  неизменые поля  -->|
      |<---- идентифицировано кроме перемен. полей   ----------->|

* при наличии может располагаться перед AH, после AH или в обоих местах

ESP и AH могут использоваться совместно в разных режимах. В документе, описывающем архитектуру IPsec, кратко рассматриваются методы настройки защищенных связей при использовании обоих протоколов.

Отметим, что в транспортном режиме для реализаций bump-in-the-stack и bump-in-the-wire, как определено в архитектуре защиты, входящие и исходящие фрагменты IP могут потребовать от реализации IPsec выполнения дополнительных операций фрагментации/сборки дейтаграмм IP для выполнения требования данной спецификации и обеспечения прозрачной поддержки IPsec. Особое внимание следует обращать на выполнение таких операций при использовании множества интерфейсов.

3.1.2. Туннельный режим

В туннельном режиме «внутренний» заголовок IP содержит исходные адреса получателя и отправителя, а «внешний» заголовок IP — адреса «партнеров IPsec (например, защитных шлюзов). Во внутреннем и внешнем заголовках могут использоваться разные версии IP (например, IPv6 через туннель IPv4 или IPv4 через туннель IPv6). В туннельном режиме заголовок AH защищает внутренний пакет целиком (включая его заголовок). Положение AH в туннельном режиме относительно внешнего заголовка IP совпадает с положением AH в транспортном режиме. На рисунке справа показано размещение AH в типичных пакетах IPv4 и IPv6 для туннельного режима.

     ----------------------------------------------------------------
IPv4 |                              |    | Исх. заг. IP* |   |      |
     |Новый заголовок IP*  (опции)  | AH |    (опции)    |TCP| Data |
     ----------------------------------------------------------------
     |<-  обработка измен. полей  ->|<------ неизменные поля  ----->|
     |<-  идентифицировано кроме изменяемых полей в новом загол.  ->|

     --------------------------------------------------------------
IPv6 |           |расширен. |    |            |расширен. |   |    |
     |Нов. загол*|заголовки*| AH |Исх. заг.IP*|заголовки*|TCP|Data|
     --------------------------------------------------------------
     |<-- Обр перем поля -->|<---------  неизменые поля  -------->|
     |<-- идентифицировано кроме изменяемых полей в новом загол.->|

* при использовании создается внешний заголовок IP и меняется внутренний, как описано в документе, посвященном архитектуре защиты. Расширенные заголовки могут отсутствовать.

3.2. Контроль целостности

Алгоритм контроля целостности, используемый для расчета ICV, задается SA. Для связи «точка-точка» к числу подходящих алгоритмов контроля целостности относится MAC20 с использованием симметричных алгоритмов шифрования (например, AES [AES]) или необратимые хэш-функции типа MD5, SHA-1, SHA-256 и т. п.). Для групповых приложений разработан большой набор криптографических стратегий и продолжаются исследования в этой области.

3.3. Обработка исходящих пакетов

В транспортном режиме отправитель помещает заголовок AH после заголовка IP и перед заголовком протокола следующего уровня, как описано выше. В туннельном режиме внешний и внутренний заголовок IP и расширения могут взаимодействовать различными способами. Создание внешнего заголовка IP в процессе инкапсуляции описан в документе, посвященном архитектуре защиты.

3.3.1. Нахождение SA

AH применяется к исходящим пакетам только после того, как реализация IPsec определит, что пакет связан с SA, которая вызывается для обработки AH. Процесс определения необходимости обработки IPsec для исходящего трафика описан в документе по архитектуре защиты.

3.3.2. Генерация порядковых номеров

Счетчик отправителя инициализуируется нулевым значением при организации SA. Отправитель инкрементирует счетчик порядковых номеров (или ESN) для данной SA и помещает младшие 32 бита номера в поле Sequence Number. Таким образом, первый пакет для данной SA получает порядковый номер 1.

Если включена функция предотвращения повторного использования пакетов (включена по умолчанию), отправитель проверяет, не повторяется ли порядковый номер перед вставкой значения в поле Sequence Number. Иными словами, для отправителя недопустимо передавать пакет в SA, если эта передача будет приводить к повторному использованию порядкового номера. Попытка передачи пакета, которая будет вызывать переполнение (переход на новый цикл отсчета) счетчика порядковых номеров приводит к внесению записи в журнал аудита. В эту запись следует включать значение SPI, текущую дату и время, адреса отправителя и получателя, а для IPv6 еще и нешифрованное представление Flow ID.

Отправитель предполагает, что предотвращение повторного использования включено по умолчанию, пока получатель однозначно не укажет обратное (см. параграф 3.4.3) или эта функция была отключена вручную при выборе конфигурации SA. Таким образом, в типичном случае реализация AH говорит отправителю о необходимости организации новой SA, когда значение Sequence Number (или ESN) достигает максимума и должно вернуться к нулю.

Если функция предотвращения повторов отключена (как описано выше) отправителю не нужно заботиться о мониторинге переполнения (сброса в 0) счетчика порядковых номеров (например, в случае управления ключами вручную, как описано в разделе 5). Однако отправитель будет по-прежнему инкрементировать значение счетчика и после максимального значения счетчик будет сброшен в 0. Такой вариант поведения рекомендуется для групповых SA со множеством отправителей, если между отправителями и получателями не согласовано использование механизма предотвращения повторов (выходящего за рамки данного стандарта).

Если выбрано использование ESN (см. Приложение B), в поле Sequence Number передаются только 32 младших бита расширенного порядкового номера, хотя отправитель и получатель поддерживают полные 64-битовые счетчики ESN. При этом старшие 32 бита порядкового номера учитываются в контрольной сумме ICV.

Примечание. Если отправитель отказался от использования функции предотвращения повторов для SA, ему не следует согласовывать использование ESN в протоколе управления SA. Использование ESN вызывает у получателя необходимость поддержки окна anti-replay (для определения корректного значения старших битов ESN, которые используются при расчете ICV), что вступает в противоречие с отказом от предотвращения повторов для SA.

3.3.3. Расчет ICV

При расчете ICV в AH учитываются следующие поля:

  • Поля заголовка IP или расширения перед заголовком AH, которые не изменяются при передаче или предсказуемы на момент прибытия в конечную точку SA;
  • заголовок AH (поля Next Header, Payload Len, Reserved, SPI, Sequence Number — младшие 32 бита), поле ICV, значение которого на момент расчета принимается нулевым, и явные байты заполнения (если они есть);
  • все данные после заголовка AH предполагаются неизменными при передаче и учитываются в расчете;
  • старшие биты ESN (если расширенная нумерация используется) и все байты неявного заполнения, требуемые алгоритмом контроля целостности.
3.3.3.1. Обработка изменяемых полей

Если поле меняется в процессе передачи, при расчете ICV значение этого поля принимается нулевым. Если поле изменчиво, но его значение на уровне получателя IPsec предсказуемо, это значение может использоваться при расчете ICV. Значение поля Integrity Check Value при расчете также принимается нулевым. Отметим, что использование нулевого значения поля вместо пропуска этого поля при расчете сохраняет выравнивание для расчета ICV. Кроме того, заполнение неучитываемых полей нулями предотвращает их изменение в процессе передачи, хотя содержимое этих полей и не покрывается явно ICV.

При создании нового расширения заголовка или опции IPv4 они определяются в соответствующем RFC и в сецификацию (раздел «Вопросы безопасности») следует включать инструкции по учету полей при расчете ICV для AH. Если реализация IP (v4 или v6) встречается с нераспознанным расширением заголовка, она должна отбросить такой пакет и передать отправителю сообщение ICMP. IPsec просто не увидит такого пакета. Если реализация IPsec сталкивается с нераспознанной опцией IPv4, эту опцию следует целиком обнулить, используя второй байт опции в качестве ее размера. Опции IPv6 (в заголовках Destination Extension или заголовке Hop-by-Hop Extension) содержат флаг изменчивости, который определяет порядок обработки такой опции.

3.3.3.1.1. Расчет ICV для IPv4

3.3.3.1.1.1. Поля основного заголовка

Базовые поля заголовка IPv4 характеризуются следующим образом:

Неизменные

Version

Internet Header Length

Total Length

Identification

Protocol (здесь должно быть значение для AH)

Source Address

Destination Address (без строгой или нестрогой маршрутизации, заданной отправителем)

Предсказуемо изменяемые

Destination Address (со строгой или нестрогой маршрутизацией, заданной отправителем)

Изменяемые (0 перед расчетом ICV)

Differentiated Services Code Point (DSCP) (6 битов, см. RFC 2474 [NBBB98])

Explicit Congestion Notification (ECN) (2 бита, см. RFC 3168 [RFB01])

Flags

Fragment Offset

Time to Live (TTL)

Header Checksum

DSCP — маршрутизаторы могут менять значение поля DS для обеспечения желаемого сервиса (локального или сквозного), поэтому значение поля в момент получения пакета отправителю предсказать невозможно.

ECN — это поле будет меняться, если на пути встретится перегруженный маршрутизатор, следовательно значение поля в момент получения пакета не может быть определено отправителем.

Flags — это поле исключается из расчетов, поскольку промежуточные маршрутизаторы могут устанавливать флаг DF, даже в тех случаях, когда отправитель не установил его.

Fragment Offset — поскольку AH применяется только к нефрагментированным пакетам IP, значение этого поля всегда должно быть нулевым, поэтому оно исключено из расчета (несмотря на предсказуемость).

TTL — это значение маршрутизаторы меняют в процессе штатной обработки пакетов, поэтому отправитель не может предсказать значение поля в момент приема пакета.

Header Checksum — это поле меняется при изменении любого флага, поэтому отправитель не может предсказать значение поля на момент доставки пакета.

3.3.3.1.1.2. Опции

Для IPv4 (в отличие от IPv6) не существует механизма маркировки опций, изменяющихся при передаче. По этой причине опции IPv4 перечислены в Приложении A и явно классифицированы, как неизменные, изменяющиеся предсказуемо и переменчивые. Для IPv4 опция рассматривается как неделимый объект, поэтому, несмотря на неизменность типа и размера некоторых опций при передаче, изменение значения опции делает все поле данной опции изменяемым и опция целиком учитывается как нулевые значения при расчете ICV.

3.3.3.1.2. Расчет ICV для IPv6

3.3.3.1.2.1. Поля основного заголовка

Поля заголовков IPv6 классифицируются следующим образом:

Неизменные

Version

Payload Length

Next Header

Source Address

Destination Address (без заголовка Routing Extension)

Предсказуемо изменяемые

Destination Address (с заголовком Routing Extension)

Изменяемые (0 перед расчетом ICV)

DSCP (6 битов, см. RFC2474 [NBBB98])

ECN (2 бита, см. RFC3168 [RFB01])

Flow Label21

Hop Limit

3.3.3.1.2.2. Расширенные заголовки с опциями

Опции IPv6 в расширенных заголовках Hop-by-Hop и Destination содержат бит, указывающий, что опция может измениться (непредсказуемо) в процессе передачи. Для любой опции, которая может измениться на маршруте, все поле Option Data должно трактоваться как нулевые октеты при вычислении и проверке ICV. Поля Option Type и Opt Data Len включаются в расчет ICV. Все опции, для которых упомянутый бит показывает неизменность, включаются в расчет ICV. Дополнительную информацию о заголовках IPv6 можно найти в спецификации протокола [DH98].

3.3.3.1.2.3. Расширенные заголовки без опций

Расширенные заголовки IPv6, не содержащие опций, явно перечислены в Приложении A и классифицированы, как неизменные, изменяемые предсказуемо или изменяемые.

3.3.3.2. Заполнение и расширенные порядковые номера
3.3.3.2.1. Заполнение ICV

Как указано в параграфе 2.6, поле ICV может включать явное заполнение, если это требуется для выравнивания заголовка AH по границе 32 (IPv4) или 64 (IPv6) бита. Если заполнение требуется, его размер определяют два фактора:

  • размер ICV;
  • версия протокола IP (v4 или v6)

Например, если выбранный алгоритм дает 96 контрольную сумму, заполнения не требуется для обеих версий IP. Однако, если другой алгоритм расчета ICV дает сумму иного размера, может потребоваться заполнение в зависимости от размера результата и версии протокола IP. Содержимое поля заполнения выбирается по усмотрению отправителя (заполнение произвольно, но использования случайных значений в целях защиты не требуется). Эти байты заполнения включаются в расчет ICV, учитываются, как часть Payload Length, и передаются в конце поля ICV, чтобы позволить получателю повторно выполнить расчет ICV для проверки. Заполнение, превышающее по размеру количество, требуемое для выравнивания заголовков Ipv4/IPv6, не допускается.

3.3.3.2.2. Неявное заполнение и ESN

Если для SA выбрано использование ESN, старшие 32 бита расширенного порядкового номера должны включаться в расчет ICV. При расчете эти биты (неявно) добавляются непосредественно после данных и перед любым неявным заполнением в пакете.

Для некоторых алгоритмов контроля целостности строка байтов, по отношению к которой выполняются операции расчета ICV, должна иметь размер, кратный заданному алгоритмом размеру блока. Если размера пакета IP (включая AH и 32 старших бита ESN при использовании расширенной нумерации) не соответствует этим требованиям, в конец пакета перед расчетом ICV должны добавляться байты неявного заполнения. Октеты заполнения должны иметь нулевое значение. Для решения вопроса об использовании такого неявного заполнения необходимо обратиться к документу, определяющему алгоритм контроля целостности. Если в документе нет ответа на данный вопрос, по умолчанию предполагается необходимость использования неявного заполнения (для выравнивания размера пакета в соответствии с размером блока, требуемого алгоритмом). Если байты заполнения требуются, но алгоритм не задает значения этих байтов, должны использоваться нулевые значения байтов заполнения.

3.3.4. Фрагментация

Если требуется фрагментация IP, она выполняется после обработки AH в реализации IPsec. Таким образом, в транспортном режиме AH применяется только к целым дейтаграммам IP22 (не фрагментам). Пакет IPv4, к которому применили AH, может быть фрагментирован маршрутизаторами на пути и в таком случае фрагменты должны быть собраны до обработки AH на приемной стороне (этого не возникает для IPv6, где фрагментация по инициативе маршрутизаторов невозможна). В туннельном режиме AH применяется к пакетам IP, содержимое которых может представлять собой фрагменты пакетов IP. Например, шлюз или реализация IPsec bump-in-the-stack или bump-in-the-wire (см. документ по архитектуре защиты) может использовать AH для таких фрагментов в туннельном режиме.

Фрагментация, выполняемая реализацией IPsec или маршрутаторами на пути доставки между партнерами IPsec, существенно снижает производительность. Более того, необходимость сборки фрагментов на приемной стороне до выполнения операций AH, порождает возможность организации атак на отказ служб. Таким образом, реализация AH может выбрать отказ от поддержки фрагментации и маркировать передаваемые пакеты флагом DF23 для облегчения определения PMTU24. В любом случае, реализация AH должна поддерживать генерацию сообщений ICMP PMTU (или использование эквивалентной внутренней сигнализации) для минимизации издержек на фрагментирование. Детали требований, связанных с фрагментацией рассматриваются в документе по архитектуре защиты.

3.4. Обработка входящих пакетов

При наличии нескольких заголовков/расширений IPsec при обработке каждого из них остальные игнорируются (не обнуляются и не используются).

3.4.1. Сборка фрагментов

Если нужна сборка фрагментов25, она выполняется до обработки AH. Если переданный на обработку AH пакет оказывается фрагментом IP (т. е., поле Offset имеет ненулевое значение или установлен флаг More Fragments), получатель должен отбрасывать такой пакет и делать запись в журнале аудита. В запись следует включать значение SPI, дату и время, адреса отправителя и получателя, а также Flow ID для IPv6.

3.4.2. Нахождение SA

При получении пакета, содержащего идентификационный заголовок IP (AH), получатель определяет подходящую (одностороннюю) SA путем просмотра SAD. Для индивидуальных SA определение основано на значении SPI, в дополнение к которому может использоваться поле протокола, как описано в параграфе 2.4. Если реализация поддерживает групповой трафик, при определении SA используется также адрес получателя (в дополнение к SPI) и может применяться адрес отправителя, как описано в параграфе 2.4 (более подробно этот процесс описан в документе по архитектуре защиты). Запись SAD для SA показывает также использование поля Sequence Number и его размер (32 или 64 бита) для данной SA. Кроме того, запись SAD для SA задает алгоритм(ы), используемый для расчета ICV и показывает, нужно ли проверять значения ICV.

Если для пакета не найдено защищенной связи, получатель должен отбросить пакет с записью в журнал аудита. В запись следует включать значение SPI, дату и время, адреса отправителя и получателя, а также Flow ID для IPv6.

Отметим, что трафик управления SA (такой, как пакеты IKE) не требуется обрабатывать на базе SPI, т. е., этот трафик может демультиплексироваться отдельно (например, на основе полей Next Protocol и Port).

3.4.3. Проверка порядковых номеров

Все реализации AH должны поддерживать предотвращение повторного использования пакетов26, хотя использование этой функции может быть включено или отключено получателем на уровне SA. Функции предотвращения повторного использования применимы как к индивидуальным, так и к групповым SA. Однако данный стандарт не задает механизмов защиты от повторного использования пакетов для SA со множеством отправителей (групповых или индивидуальных). При отсутствии согласования (или настройки вручную) механизма предотвращения повторного использования для таких SA отправителю и получателю рекомендуется проверить запрет использования поля Sequence Number для таких SA (запрет организуется путем согласования или вручную), как описано ниже.

Если получатель не включил предотвращение повторного использования для SA, на входе не проверяются значения поля Sequence Number. Однако с точки зрения отправителя предотвращение повторного использования по умолчанию включено. Чтобы избавить отправителя от ненужной передачи и мониторинга порядковых номеров (см. параграф 3.3.2. Генерация порядковых номеров), получателю следует уведомить отправителя об отказе от поддержки предотвращения повторного использования на этапе организации SA с помощью протокола организации SA (например, IKE).

Если получатель включил предотвращение повторного использования для SA, он должен установить значение счетчика пакетов для данной SA нулевым на момент организации SA. Для каждого принятого пакета получатель должен проверять, что поле Sequence Number в пакете не совпадает с порядковым номером ни одного из пакетов, полученных в данной SA. Эту проверку следует проводить до выполнения каких-либо операций AH по отношению к данному пакету сразу после проверки принадлежности пакета к SA для ускорения отбрасывания дубликатов.

Дубликаты отбрасываются с помощью «скользящего» окна приема. Реализация такого окна осуществляется локально, но описанная ниже функциональность должна поддерживаться всем реализациями.

«Правый» край окна представляет наибольшее проверенное значение поля Sequence Number для данной SA. Пакеты с номерами, выходящими за «левый» край окна, отбрасываются. Попадающие в окно пакеты проверяются на предмет совпадения порядковых номеров с номерами принятых пакетов для окна.

При использовании опции ESN для SA явно передаются только младшие 32 бита расширенного порядкового номера, но получатель использует и старшие 32 бита номера для SA (от локального счетчика) при проверке порядковых номеров. При восстановлении полного порядкового номера, если значение младших 32 битов порядкового номера из принятого пакета меньше младших 32 битов значения счетчика порядковых номеров на стороне получателя, последний предполагает, что значение старших 32 битов номера было инкрементировано, т. е., перемещает номер в новое «подпространство». Этот алгоритм допускает интервал приема для отдельной SA до 232-1 пакетов. Если интервал становится больше, могут использоваться эвристические проверки для ресинхронизации порядковых номеров на приемной стороне, как описано в Приложении B.

Если полученный пакет попадает в окно и не является дубликатом, получатель выполняет проверку ICV. При отрицательном результате проверки ICV получатель должен отбросить полученную дейтаграмму IP, как некорректную, с записью в журнал аудита. В запись следует включать значение SPI, дату и время, адреса отправителя и получателя, а также Flow ID для IPv6. Окно приема обновляется только при положительном результате проверки ICV.

Должны поддерживаться окна минимального размера в 32 пакета, но по умолчанию следует поддерживать окна размером 64 пакета. Получатель может выбирать другие размеры окна (больше минимального). Получатель не информирует отправителя о выбранном размере окна. Для высоскоскоростных сред размер окна приема следует увеличивать. Минимальные и рекомендуемые размеры окна для высокоскоростных (например, мультимегабитных) устройств данный стандарт не задает.

3.4.4. Проверка ICV

Получатель рассчитывает ICV для соответствующих полей пакета, используя заданный алгоритм контроля целостности и сравнивает полученный результат со значением поля ICV в принятом пакете. Детальное описание расчета приведено ниже.

Если рассчитанное значение ICV совпадает с полученным в пакете, дейтаграмма считается корректной. Если значения не совпадают, получатель должен отбросить полученную дейтаграмму IP, как некорректную с записью информации об этом факте в журнал аудита. В запись следует включать значение SPI, дату и время, адреса отправителя и получателя, а также Flow ID для IPv6.

Примечание для разработчиков.

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

Сначала значение ICV из принятого пакета сохраняется и заменяется нулем. Значения поля заполнения ICV при этом не изменяются. Далее обнуляются все остальные поля, которые могли измениться в процессе передачи пакета (поля, которые следует обнулять при расчете ICV, перечислены в параграфе 3.3.3.1. Обработка изменяемых полей). Если для данной SA выбрано использование ESN, добавляются старшие 32 бита ESN в конце пакета. Проверяется общий размер пакета (как описано выше) и при необходимости в конец пакета (после старших битов ESN, если они используются) добавляются нулевые байты неявного заполнения с учетом требований алгоритма контроля целостности.

Здесь описан лишь общий ход проверки, который на практике может быть существенно другим. Например, при использовании цифровой подписи или однонаправленной хэш-функции для расчета ICV соответствующий процесс может быть более сложным.

4. Аудит

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

5. Соответствие требованиям

Реализации, которые заявляют о своем соответствии или совместимости с данной спецификацией, должны полностью реализовать синтаксис и обработку AH, описанные здесь, для индивидуального трафика, а также должны полностью выполнять все требования документа по архитектуре защиты [Ken-Arch]. В дополнение к этому, реализации, заявляющие поддержку группового трафика, должны соответствовать всем дополнительным требованиям, заданным для такого трафика. При ручном распределении ключей, используемых для расчета ICV, корректная работа системы предотвращения повторного использования пакетов требует аккуратной поддержки состояния счетчика на передающей стороне при замене ключа, поскольку в этом случае невозможно восстановить работу после переполнения счетчика. Таким образом, совместимым со спецификацией реализациям не следует предоставлять такой сервис для SA с распространением ключей вручную.

Обязательные для реализации алгоритмы, используемые с AH, описаны в отдельном RFC [Eas04], для обеспечения возможности обновления алгоритмов независимо от протокола. Кроме обязательных для AH алгоритмов могут поддерживаться дополнительные алгоритмы.

6. Вопросы безопасности

Безопасность является основным аспектом данного протокола и вопросы безопасности рассматриваются во всем документе. Дополнительные аспекты использования протокола IPsec, связанные с обеспечением безопасности, рассматриваются в документе по архитектуре защиты.

7. Отличия от RFC 2402

В этом документе имеется ряд перечисленных ниже отличий от RFC 2402 [RFC2402].

  • Изменено определение SPI для обеспечения возможности однотипного поиска в SAD для индивидуальных и групповых SA, совместимого со многими технологиями групповой передачи. Для выбора индивидуальных SA значение SPI может использоваться само по себе или в комбинации с протоколом по усмотрению получателя. Для выбора групповых SA значение SPI объединяется с адресом отправителя (и, опционально, с адресом получателя).
  • Добавлены расширенные порядковые номера (ESN) для обеспечения 64-битовой нумерации на высокоскоростных соединениях. Разъяснены требования к отправителю и получателю для групповых SA и защищенных связей с множеством отправителей.
  • Спецификации обязательных алгоритмов вынесены в отдельный документ [Eas04].

8. Благодарности

Автор выражает свою благодарность Ran Atkinson, за его критически важную роль на начальном этапе создания IPsec и всем авторам первой серии стандартов IPsec — RFC 1825-1827. Отдельная благодарность Karen Seo за помощь в редактировании этой и предыдущей версии данной спецификации. Автор также благодарит членов рабочих групп IPsec и MSEC, которые внесли свой вклад в разработку спецификации протокола.

9. Литература

9.1. Нормативные документы

[Bra97] Bradner, S., «Key words for use in RFCs to Indicate Requirement Level», BCP 14, RFC 2119, March 1997.

[DH98] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[Eas04] 3rd Eastlake, D., «Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)», RFC 4305, December 2005.

[Ken-Arch] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC1108] Kent, S., «U.S. Department of Defense Security Options for the Internet Protocol», RFC 1108, November 1991.

9.2. Дополнительная литература

[AES] Advanced Encryption Standard (AES), Federal Information Processing Standard 197, National Institutes of Standards and Technology, November 26, 2001.

[HC03] Holbrook, H. and B. Cain, «Source Specific Multicast for IP», Work in Progress28, November 3, 2002.

[IKEv2] Kaufman, C., Ed., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[Ken-ESP] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[NBBB98] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[RFB01] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, «IP MTU discovery options», RFC 1063, July 1988.

[RFC1122] Braden, R., «Requirements for Internet Hosts-Communication Layers», STD 3, RFC 1122, October 1989.

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, November 1990.

[RFC1385] Wang, Z., «EIP: The Extended Internet Protocol», RFC 1385, November 1992.

[RFC1393] Malkin, G., «Traceroute Using an IP Option», RFC 1393, January 1993.

[RFC1770] Graff, C., «IPv4 Option for Sender Directed Multi-Destination Delivery», RFC 1770, March 1995.

[RFC2113] Katz, D., «IP Router Alert Option», RFC 2113, February 1997.

[RFC2402] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 2402, November 1998.

[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, «The Group Domain of Interpretation», RFC 3547, July 2003.

[RFC3740] Hardjono, T. and B. Weis, «The Multicast Group Security Architecture», RFC 3740, March 2004.

Приложение A: Изменяемые опции и расширения заголовков IP

A1. Опции IPv4

В таблице показаны опции IPv4 с классификацией их по «изменяемости». Если в колонке «Документ» указаны две ссылки, второй документ имеет более высокий приоритет. Таблица основана на информации, представленной в RFC 1700, «ASSIGNED NUMBERS»29, (октябрь 1994).

Копия

Класс

Номер опции

Имя

Документ

Неизменные — учитываются в ICV

0

0

0

End of Options List30 – конец списка опций

[RFC791]

0

0

1

No Operation — нет операции

[RFC791]

1

0

2

Security31 — защита

[RFC1108]32

1

0

5

Extended Security1 — расширенная защита

[RFC1108]2

1

0

6

Commercial Security1 — коммерческая защита

[RFC2113]

1

0

20

Router Alert — сигнал маршрутизатора

[RFC1770]

1

0

21

Sender Directed Multi-Destination Delivery — направленная отправителем доставка по множеству адресов

Изменяемые — должны иметь нулевое значение

1

0

3

Loose Source Route — нежестко заданный отправителем маршрут

[RFC791]

0

2

4

Time Stamp — временная метка

[RFC791]

0

0

7

Record Route33 — запись маршрута

[RFC791]

1

0

9

Strict Source Route — жестко заданный отправителем маршрут

[RFC791]

0

2

18

Traceroute — трассировка пути

[RFC1393]

Экспериментальные и переопределенные — должны иметь нулевое значение

1

0

8

Stream ID — идентификатор потока

[RFC791], [RFC1122]

0

0

11

MTU Probe – проба MTU

[RFC1063], [RFC1191]

0

0

12

MTU Reply – отклик MTU

[RFC1063], [RFC1191]

1

0

17

Extended Internet Protocol — расширенный протокол IP

[RFC1385], [DH98]

0

0

10

Experimental Measurement – экспериментальные измерения

1

2

13

Experimental Flow Control — экспериментальное управление потоком данных

1

0

14

Experimental Access Ctl — экспериментальный контроль доступа

0

0

15

???

1

0

16

IMI Traffic Descriptor — дескриптор трафика IMI

1

0

19

Address Extension — расширение адреса

A2. Заголовки расширения IPv6

В таблице показаны расширения заголовков IPv6 и дана их классификация в плане «изменчивости».

Название опции или расширения Ссылка
Предсказуемо изменяемые – включаются в расчет ICV
Routing (Type 0) [DH98]

Биты, показывающие изменяется ли опция (изменения при передаче непредсказуемы)

Опция Hop-by-Hop [DH98]
Опция Destination [DH98]
Неприменимо
Fragmentation [DH98]

Опции IPv6 в расширенных заголовках Hop-by-Hop и Destination содержат бит, который показывает возможность (непредсказуемого) изменения опции в процессе доставки пакета. Для лобой опции, содержимое которое может меняться на пути, все поле Option Data должно трактоваться, как нулевые октеты при расчете и проверке ICV. Поля Option Type и Opt Data Len включаются в расчет ICV. Все опции, для которых флаг показывает неизменность, включаются в расчет ICV. Дополнительная информация по опциям IPv6 приведена в [DH98].

Routing (Type 0) — этот заголовок IPv6 будет приводить к реорганизации адресных полей в пакете на пути доставки. Однако содержимое пакета на момент доставки известно отправителю и всем промежуточным узлам. Следовательно, это поле включается в расчет ICV, поскольку его изменения предсказуемы. Отправитель должен перед расчетом ICV включить в это поле то значение, которое увидит получатель.

Fragmentation — фрагментация происходит после выходной обработки IPsec (параграф 3.3), а сборка — перед входной обработкой IPsec (параграф 3.4). По этой причине расширенный заголовок Fragmentation (если он имеется) не виден для IPsec.

Отметим, что на приемной стороне реализация IP может сохранить расширенный заголовок Fragmentation после сборки фрагментов. В таком случае реализация AH при получении пакета должна «удалить» (или пропустить) этот заголовок до обработки ICV и заменить значение предыдущего поля Next Header на значение Next Header из заголовка Fragmentation.

Отметим, что на стороне отправителя реализация IP может передавать IPsec пакет с расширенным заголовком Fragmentation, где Offset = 0 (первый фрагмент) и флаг More Fragments = 0 (последний фрагмент). В таких случаях до обработки ICV реализация AH должна «удалить» (или пропустить) этот заголовок и заменить значение предыдущего Next Header на значение Next Header из заголовка Fragmentation.

Приложение B: Расширенные порядковые номера (64 бита)

B1. Обзор

В этом приложении описана схема расширенной порядковой нумерации (ESN) для IPsec (ESP и AH), где используются 64-битовые порядковые номера, но в каждом пакете передаются только младшие 32 бита номера. Описана схема окна, используемого для обнаружения повтрно используемых пакетов, а также механизм определения старших битов порядкового номера, используемых для отбрасывания пакетов и расчета ICV. Описан также механизм обработки случаев потери синхронизации для старших (не передаваемых в пакетах) битов порядкового номера.

B2. Окно Anti-Replay

Получатель будет поддерживать окно предотвращения повторного использования пакетов размером W34. Это окно будет ограничивать степень разупорядочивания пакетов при доставке без потери идентификации. Все 232 порядковых номера, связанных с любым фиксированным значением старших 32 битов (Seqh) будем называть подпространством порядковых номеров. В приведенной ниже таблице перечислены используемые переменные и даны их определения.

Имя Размер в битах Значение
W 32 Размер окна
T 64

Наибольший порядковый номер, идентифицированный до настоящего времени — верхняя граница окна

Tl 32 32 младших бита T
Th 32 32 старших бита T
B 64 Нижняя граница окна
Bl 32 32 младших бита B
Bh 32 32 старших бита B
Seq 64 Порядковый номер полученного пакета
Seql 32 32 младших бита Seq
Seqh 32 32 старших бита Seq

При выполнении проверки на предмет повторного использования пакетов или определении старших битов номера для идентификации входящего пакета возможны два случая:

  • Случай A: Tl >= (W — 1) все окно находится в одном подпространстве порядковых номеров (Рисунок 2)
  • Случай B: Tl < (W — 1) окно захватывает части двух смежных подпространств порядковых номеров (Рисунок 3).

На рисунках нижняя линия —- показывает смежные подпространства порядковых номеров, а 0 указывает начало каждого подпространства. Короткая двойная линия === показывает применимые старшие биты, а ==== представляет окно. Звездочки **** обозначают грядущие номера, т. е., номера номера, превышающие максимальный идентифицируемый в данный момент номер (ThTl).

        Th+1                         *********

        Th               =======*****

              --0--------+-----+-----0--------+-----------0--
                         Bl    Tl            Bl
                                        (Bl+2^32) mod 2^32

Рисунок 2: Случай A

        Th                           ====**************

        Th-1                      ===

              --0-----------------+--0--+--------------+--0--
                                  Bl    Tl            Bl
                                                 (Bl+2^32) mod 2^32

Рисунок 3: Случай B

B2.1. Использование окна Anti-Replay и управление им

Окно предотвращения повторов можно рассматривать как строку битов размером W (W = T — B + 1 и не может превышать 232 — 1). Младший бит строки соответствует B, а старший — T и каждый порядковый номер от Bl до Tl представлен соответствующим битом. Значение бита показывает, был ли пакет с соответствующим номером принят и идентифицирован, что позволяет обнаружить и отбросить повторные пакеты.

При получении и проверке корректности пакета с 64-битовым порядковым номером (Seq), превышающим T:

  • B увеличивается на (Seq — T);
  • отбрасываются (Seq — T) битов в левой части окна;
  • добавляются (Seq — T) битов в правой части окна;
  • устанавливается «верхний» бит для индикации приема и идентификации пакета с данным порядковым номером;
  • сбрасываются новые биты между T и «верхним» битом для индикации отсутствия принятых пакетов с соответствующими порядковыми номерами;
  • для T устанавливается значение нового порядкового нгомера.

Проверка пакетов на предмет повторного использования:

  • Случай A: Если Seql >= Bl (где Bl = Tl — W + 1) И Seql <= Tl, проверяется соответствующий бит окна. Если пакет с номером Seql уже был принят (бит окна установлен), он отбрасывается. В противном случае проверяется целостность пакета. Проверка старших битов номера (Seqh) описана в параграфе B2.2.
  • Случай B: Если Seql >= Bl ( где Bl = Tl — W + 1) ИЛИ Seql <= Tl, проверяется соответствую щий бит окна. Если пакет с номером Seql уже был принят (бит окна установлен), он отбрасывается. В противном случае проверяется целостность пакета. Проверка старших битов номера (Seqh) описана в параграфе B2.2.

B2.2. Определение старших битов (Seqh) порядкового номера

Поскольку в пакетах передается только значение Seql, получатель должен отслеживать подпространство порядковых номеров для каждого пакета (т. е., определять значение Seqh). Приведенные справа уравнения определяют выбор Seqh в «нормальных» условиях. В параграфе B3 рассматривается определение старших битов номера в условиях экстремальных потерь пакетов.

+ Для случая A (Рисунок 2):
  Если Seql >= Bl (где Bl = Tl - W + 1), то Seqh = Th
  Если Seql <  Bl ( где Bl = Tl - W + 1), то Seqh = Th + 1

+ Для случая B (Рисунок 3):
  Если Seql >= Bl ( где Bl = Tl - W + 1), то Seqh = Th - 1
  Если Seql <  Bl ( где Bl = Tl - W + 1), то Seqh = Th

B2.3. Пример псевдокода

Приведенный ниже псевдокод иллюстрирует описанные выше алгоритмы предотвращения повторного использования и контроля целостности пакетов. Значения Seql, Tl, Th и W являются 32-битовыми целыми числами без знака. Используется арифметика по модулю 232.

        Если (Tl >= W - 1)                        Случай A
            Если (Seql >= Tl - W + 1)
                Seqh = Th
                Если (Seql <= Tl)
                    Если (проверка на предмет повтора прошла)
                        Если (проверка целостности прошла)
                            Установить бит, соответствующий Seql
                            Принять пакет
                        Иначе отбросить пакет
                    Иначе отбросить пакет
                Иначе
                    Если (проверка целостности прошла)
                        Tl = Seql (shift bits)
                        Установить бит, соответствующий Seql
                        Принять пакет
                    Иначе отбросить пакет
            Иначе
                Seqh = Th + 1
                Если (проверка целостности прошла)
                    Tl = Seql (shift bits)
                    Th = Th + 1
                    Установить бит, соответствующий Seql
                    Принять пакет
                Иначе отбросить пакет
        Иначе                                    Случай B
            Если (Seql >= Tl - W + 1)
                Seqh = Th - 1
                Если (проверка на предмет повтора прошла)
                    Если (pass integrity check)
                        Установить бит, соответствующий Seql
                        Принять пакет
                    Иначе отбросить пакет
                Иначе отбросить пакет
            Иначе
                Seqh = Th
                Если (Seql <= Tl)
                    Если (проверка на предмет повтора прошла)
                        Если (проверка целостности прошла)
                            Установить бит, соответствующий Seql
                            Принять пакет
                        Иначе отбросить пакет
                    Иначе отбросить пакет
                Иначе
                    Если (проверка целостности прошла)
                        Tl = Seql (shift bits)
                        Установить бит, соответствующий Seql
                        Принять пакет
                    Иначе отбросить пакет

B3. Обработка потери синхронизации в результате больших потерь пакетов

При потере 232 или более пакетов подряд для одной SA отправитель и получатель теряют синхронизацию старших битов порядкового номера, т. е., уравнения параграфа B2.2 не будут давать корректного значения. Пока эта проблема не будет обнаружена и разрешена, последующие пакеты для данной SA не могут быть идентифицированы и будут отбрасываться. Описанную ниже процедуру восстановления синхронизации следует поддерживать во всех реализациях IPsec (ESP или AH), которые работают с ESN.

Отметим, что описанный вариант экстремальных потерь представляется маловероятным для SA, использующих протокол TCP, поскольку отправитель, не получающий пакетов ACK в ответ на переданные пакеты, будет останавливать передачу до того, как будут потеряны 232. И другие приложения с двухсторонним обменом данными (даже работающие по протоколу UDP) при таких экстремальных потерях будут включать тот или иной тайм-аут. Однако приложения с односторонним потоком трафика, работающие по протоколу UDP, могут не поддерживать средств автоматического детектирования экстремальных потерь пакетов и, следовательно, требуется обеспечить метод восстановления для таких ситуаций.

Предлагаемое решение призвано:

  • минимизировать влияние на обработку нормального трафика;
  • предотвратить создание новой возможности организации атак на отказ служб за счет неоправданной затраты ресурсов на ресинхронизацию;
  • реализовать механизм восстановления только на принимающей стороне, поскольку отправитель обычно не знает, для каких порядковых номеров получателю требуется восстановление синхронизации; реализация механизмов восстановления на приемной стороне является предпочтительной; кроме того, такое решение обеспечивает совместимость с ранними версиями.

B3.1. Включение ресинхронизации

Для каждой SA получатель запоминает число последовательных пакетов, для которых не прошла идентификация. Это значение используется для включения процесса ресинхронизации, который следует выполнять в фоновом режиме или на отдельном процессоре. Прием корректного пакета для данной SA ведет к сбросу счетчика некорректных пакетов в 0. Значение, при котором включается ресинхронизация, является локальным параметром. Не требуется поддерживать независимые значения порога ресинхронизации для каждой SA, но реализация вправе поддерживать их.

B3.2. Процесс ресинхронизации

Когда значение счетчика некорректных пакетов достигает заданного порога, выбирается «плохой» пакет, для которого процедура идентификации повторяется с использованием следующего большего значения для старшей части расширенного порядкового номера (Seqh). Значение старшей части номера увеличивается на 1 при каждой проверке. Число попыток проверки следует ограничивать на случай того, что выбранный для проверки пакет оказался «из прошлого» или является поддельным. Максимальное число попыток задается локальным параметром. Поскольку значение Seqh неявно помещается после данных AH (или ESP), может оказаться возможной оптимизация процедуры восстановления за счет выполнения процедуры контроля целостности пакета с использованием нарастающих значений Seqh для расчета ICV. При успешной идентификации пакета с помощью описанной процедуры значение счетчика некорректных пакетов сбрасывается и устанавливается значение T, определенное по прошедшему проверку пакету.

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

Адрес автора

Stephen Kent

BBN Technologies

10 Moulton Street

Cambridge, MA 02138

USA

Phone: +1 (617) 873-3988

EMail: kent@bbn.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1IP Authentication Header — идентификационный заголовок IP.

2Encapsulating Security Payload — инкапсуляция защищенных данных.

3Security Association.

4M = mandatory — обязательно.

5Информация о покрываемых полях заголовка IP приведена в параграфе 3.3.3.

6Обнуляется перед расчетом ICV и результат расчета помещается в это поле.

7В туннельном режиме — дейтаграмма IP, в транспортном — следующий заголовок и данные.

8Extended Sequence Number — расширенный порядковый номер.

9Integrity Check Value — значение проверки целостности.

10Реестр IP Protocol Numbers.

11В настоящее время этот список доступен по ссылке http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml. Прим. перев.

12Security Association Database.

13Ternary Content-Addressable Memory — ассоциативная память.

14Group Domain of Interpretation.

15Source-Specific Multicast.

16No Security Association Exists.

17Extended Sequence Number — расширенный порядковый номер.

18Integrity Check Value — значение для проверки целостности.

19 Отметим, что термин транспортный не следует трактовать как на ограничесние использования протоколов только транспортными протоколами TCP и UDP.

20Message Authentication Code — код идентификации сообщения.

21Метки потока, описанные в Ahv1, были изменяемыми и в RFC 2460 [DH98] сохранили потенциальную изменчивость. Для совместимости с существующими реализациями AH метки потоков не вкалючаются в расчет ICV для AHv2.

22Как отмечено в конце параграфа 3.1.1, реализации bump-in-the-stack и bump-in-the-wire могут сначала выполнять сборку фрагментов, созданных локальным уровнем IP, потом выполнять обработку IPsec и снова фрагментировать полученный в результате пакет.

В случае IPv6 реализации bump-in-the-stack и bump-in-the-wire должны проверять все расширенные заголовки, а также значения флага More и поля Fragment Offset для обнаружения фрагментирования. Если фрагментирование используется, пакеты должны быть собраны до выполнения операций IPsec.

23Не фрагментировать. Прим. перев.

24Path MTU — размер максимального передаваемого блока для пути.

25При сборке пакетов текущая спецификация IPv4 не требует обнуления поля Offset и сброса флага More Fragments. Для корректной обработки собранных из фрагментов пакетов IPsec (вместо отбрасывания, принятого для фрагментов) реализация IP должна выполнять обе указанные операции после сборки пакета из фрагментов.

26Anti-replay service.

28В настоящее время работа завершена и опубликована в RFC 4607. Прим. перев.

29В настоящее время документ «Assigned Numbers» утратил силу. Реестры выделенных значений публикуются на сайте http://www.iana.org/numbers/. Прим. перев.

30Опции End of Options List следует повторять при необходимости для выравнивания заголовка IP по 4-байтовой границе, чтобы предотвратить появление байтов, которые могли бы использоваться для организации скрытых каналов.

31Добавление или удаление защитных меток (например, Basic Security Option — BSO, Extended Security Option — ESO или Commercial Internet Protocol Security Option -CIPSO) системами на пути доставки пакета вступает в конфликт с данной классификацией, считающей эти опции IP неизменными, и, следовательно, несовместимо с использованием IPsec.

32Устарел, но продолжает использоваться.

33Использование опции Router Alert потенциально несовместимо с IPsec. Хотя эта опция является неизменной, ее использование ведет к тому, что все маршрутизаторы на пути будут «обрабатывать» пакет и, следовательно, могут менять его. Это может происходить поэтапно на пути от одного маршрутизатора к другому. До обработки приложениями, которым эта опция адресуется (например, протокол RSVP или IGMP) пакет следует подвергнуть обработке AH. Однако эта обработка требует, чтобы каждый маршрутизатор на пути был членом групповой SA, определяемой SPI. Это может вызывать проблемы с нестрого заданной отправителем маршрутизацией и требует методов поддержки группового трафика, которые в настоящее время недоступны.

34Для окна при расширенной нумерации не вводится дополнительных требований по поддержке минимального или рекомендуемого размера окна, сверх тех требований (32 и 64 пакета, соответственно), которые уже заданы для окна при 32-битовой нумерации. Однако разработчикам предлагается масштабировать размер окна в соответствии со скоростью интерфейсов, поддерживаемых реализацией, использующей опцию ESN. Описанный ниже механизм предполагает, что размер окна не превышает 231 пакета.




RFC 4301 Часть 2

Часть 1

5. Обработка трафика IP

Как отмечено в параграфе 4.4.1. База правил защиты (SPD), необходимо обращаться к SPD (или кэшированным данным) до начала обработки любого трафика, пересекающего границу защиты IPsec, включая управляющий трафик IPsec. Если в SPD не найдено правила, которому соответствует пакет (входящий или исходящий), пакет должен отбрасываться. Для упрощения обработки и ускорения поиска SA (для SG/BITS/BITW) в этом документе вводится понятие кэша SPD для всего исходящего трафика (SPD-O плюс SPD-S) и кэша для входящего трафика без защиты IPsec65 (SPD-I). Номинально существует один кэш на SPD. Для целей данной спецификации предполагается, что каждая кэшированная запись будет отображать единственную SA. Отметим, однако, что возникают исключения, когда используется множество SA для передачи трафика с различными приоритетами (например, заданными разными значениями DSCP) но одинаковыми селекторами. Отметим также, что существуют ситуации, когда SAD может иметь записи для SA, у которых нет соответствующих записей в SPD. Поскольку этот документ не требует селективной очистки SAD при изменении SPD, записи SAD могут сохраняться, хотя создавшие их записи SPD изменены или удалены. Также при создании SA с заданием ключей вручную могут существовать записи SAD для SA, не имеющих записей в SPD.

Поскольку записи SPD могут перекрываться, в общем случае кэширование таких записей не вполне безопасно. Простое кэширование может приводить к соответствию кэшированной записи, тогда как упорядоченный поиск в SPD может показывать соответствие другой записи. Если записи SPD сначала декоррелируются, результаты такой операции можно кэшировать без опаски. Каждая кэшированная запись будет показывать, что соответствующий ей трафик следует передать в обход или отбросить66. Если явно не указано иное, ниже все упоминания «SPD», «кэша SPD» или «кэша» относятся к декоррелированной SPD (SPD-I, SPD-O, SPD-S) или кэшу SPD, содержащему записи из декоррелированной SPD.

Примечание. В реализации хоста IPsec на основе сокетов, обращение к SPD будет происходить при каждом создании сокета для определения будет ли применяться (и какая) обработка IPsec к потоку трафика через этот сокет. Это обеспечивает механизм неявного кэширования и предшествующее обсуждение вопросов кэширования для таких реализаций можно игнорировать.

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

Для входящего трафика IPsec запись SAD, выбранная SPI, служит в качестве кэша для проверки селекторов прибывающих пакетов IPsec, после чего выполняется обработка AH или ESP.

5.1. Обработка исходящего трафика IP67

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

                    Незащищенный интерфейс
                               ^
                               |
        (вложенные SA)     +---------+
       --------------------|Пересылка|<-----+
       |                   +---------+      |
       |                        ^           |
       |                        | BYPASS    |
       V                     +-----+        |
   +-------+                 | Кэш |     +---------+
...| SPD-I |.................| SPD |.....|Обработка|...Граница
   |  (*)  |                 | (*) |---->|(AH/ESP) |   IPsec
   +-------+                 +-----+     +---------+
       |    +-----------+     /  ^
       |    |Отбрасывние| <--/   |
       |    +-----------+        |
       |                         |
       |                 +-------------+
       |---------------->|  Выбор SPD  |
                         +-------------+
                                ^
                                |     +------+
                                |  -->| ICMP |
                                | /   +------+
                                |/
                                |
                                |
                       Защищенный интерфейс

(*) На рисунке показан кэш SPD. При отсутствии этого кэша проверяется непосредственно SPD. Реализация не обязаны буферизовать пакет при отсутствии кэша.

Рисунок 2: Модель обработки исходящего трафика

Реализация IPsec должна выполнять следующие действия при обработке исходящих пакетов.

  1. Когда пакет приходит с абонентского (защищенного) интерфейса, вызывается функция выбора SPD для получения SPD-ID, нужного при выборе подходящей SPD (если используется только одна SPD, этот этап становится пустым — no-op).
  2. Заголовки пакета сравниваются с кэшем для SPD, заданной SPD-ID на этапе 1. Отметим, что этот кэш содержит записи из SPD-O и SPD-S.
  3. a. При совпадении пакет обрабатывается, как задано соответствующей записью (т. е., BYPASS, DISCARD или PROTECT с использованием AH или ESP). Если обработка IPsec выполнена, имеется связь между кэш-записью SPD и соответствующей записью SAD (задает режим, криптографические алгоритмы, ключи, SPI, PMTU и пр.). Обработка IPsec определяется ранее для туннельного или транспортного режима и протокола AH или ESP, как задано в соответствующих RFC [Ken05b, Ken05a]. Отметим, что значение SA PMTU вкупе со значением флага проверки фрагментов с учетом состояния (а также бита DF в заголовке IP исходящего пакета) определяют возможность (необходимость) фрагментирования пакета до обработки IPsec или его отбрасывания с передачей сообщения ICMP PMTU.b. Если в кэше не найдено соответствия, осуществляется поиск в SPD (части SPD-S и SPD-O), заданной SPD-ID. Если запись SPD задает BYPASS или DISCARD, создается одна или несколько новых исходящих кэш-записей SPD, а для BYPASS создается одна или несколько входящих кэш-записей SPD. Множество записей может создаваться в результате того, что декоррелированная запись SPD может быть связана с другими такими же записями (побочный эффект процесса декорреляции). Если запись SPD задает PROTECT (т. е., создание новой SA), вызывается механизм управления ключами (например, IKEv2) для создания SA. При успешном создании SA создается новая исходящая (SPD-S) кэш-запись вместе с входящей и исходящей записью SAD. В противном случае пакет отбрасывается (пакет, вызвавший просмотр SPD, может быть отброшен реализацией или обработан в соответствии с вновь созданной кэш-записью). Поскольку SA создаются попарно, создается также запись SAD для соответствующей входящей SA, содержащая значения селекторов, определенные из записи SPD (и пакета, если установлен флаг PFP), использованной для создания входящей SA. Эта запись служит для проверки трафика, входящего через SA.
  4. Пакет передается выходной функции пересылки (за пределы реализации IPsec) для выбора интерфейса, через который следует передать пакет. Эта функция может вернуть пакет через границу IPsec для дополнительной обработки IPsec (например, при поддержке вложенных SA). В таких случаях должна присутствовать дополнительная запись в базе SPD-I, которая разрешает такой обход, поскольку в противном случае пакет будет отброшен. При необходимости (т. е., при наличии множества SPD-I) завернутый назад трафик может быть помечен, как исходящий с внутреннего интерфейса. Это позволяет при необходимости использовать разные SPD-I для действительно внешнего трафика и «завернутого назад» трафика.

Примечание. За исключением транспортного режима IPv4 и IPv6, реализации SG, BITS или BITW могут фрагментировать пакеты до выполнения функций IPsec68. Устройству следует иметь конфигурационные параметры для запрета такого фрагментирования. Фрагменты обычным способом сравниваются с SPD. Таким образом фрагменты без номеров портов (сообщения ICMP без типа и кода или Mobility Header без типа) будут соответствовать лишь правилам, в которых селекторы для порта (типа и кода ICMP или типа MH) имеют значение OPAQUE или ANY (см. раздел 7).

Примечание. В части определения и реализации PMTU для SA системы IPsec должны следовать действиям, описанным в параграфе 8.2.

5.1.1. Обработка исходящих пакетов, которые должны быть отброшены

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

a. Селекторы в пакете соответствуют записи SPD, требующей отбрасывания пакета.

IPv4 Type = 3 (адресат недоступен) Code = 13 (связь запрещена административно)

IPv6 Type = 1 (адресат недоступен) Code = 1 (связь с адресатом запрещена административно)

b1. Для системы IPsec удаленный партнер доступен, но с ним не удается согласовать SA, требуемую запись SPD, которой соответствует пакет (например, удаленному партнеру административно запрещена связь с инициатором, инициатор не может идентифицировать себя удаленному партнеру или SPD на удаленной стооне не имеет подходящей записи).

IPv4 Type = 3 (адресат недоступен) Code = 13 (связь запрещена административно)

IPv6 Type = 1 (адресат недоступен) Code = 1 (связь с адресатом запрещена административно)

b2. Система IPsec не способна организовать SA, требуемую запись SPD, которой соответствует пакет, поскольку не удалось связаться с партнером IPsec на другой стороне.

IPv4 Type = 3 (адресат недоступен) Code = 1 (хост недоступен)

IPv6 Type = 1 (адресат недоступен) Code = 3 (адрес недоступен)

Отметим, что атакующий за защитным шлюзом может передавать пакеты с обманным адресом отправителя W.X.Y.Z объекту IPsec, заставляя того передавать сообщения ICMP по адресу W.X.Y.Z. Это открывает возможность организации атак на службы (DoS69) хостов, находящихся за защитным шлюзом. Для устранения такой возможности в защитные шлюзы следует включать средства управления, позволяющие администратору включать или отключать для реализации IPsec передачу сообщений ICMP в таких обстоятельствах и при включенной передаче сообщений ICMP ограничивать скорость такой передачи.

5.1.2. Создание заголовка для туннельного режима

В этом параграфе описывается обработка внутренних и внешних заголовков IP, расширений заголовков, а также опций туннелей AH и ESP для исходящего трафика. Обсуждается создание инкапсулирующего (внешнего) заголовка IP, обработка полей внутреннего заголовка и другие операции, которые следует применять к исходящему трафику в туннельном режиме. Обработка, описанная здесь, основана на модели RFC 2003, «Инкапсуляция IP в IP» [Per96]:

  • Поля Source Address и Destination Address внешнего заголовка IP идентифицируют «конечные точки» туннеля (инкапсулятор и декапсулятор). Эти же поля внутреннего заголовка идентифицируют исходного отправителя и конечного получателя дейтаграмм (с точки зрения данного туннеля), соответственно (см. примечание 3 к таблице в параграфе 5.1.2.1 с комментариями по поводу инкапсуляции адреса отправителя).
  • Внутренний заголовок IP не меняется за исключением поля TTL (или Hop Limit) и полей DS/ECN. В процессе доставки пакета к выходной точке туннеля внутренний заголовок сохраняется неизменным.
  • Опции IP и расширения для внутреннего заголовка не меняются в процессе доставки инкапсулированной дейтаграммы через туннель.

Туннелирование IPsec имеет некоторые отличия от туннелирования IP-in-IP (RFC 2003 [Per96]):

  • IPsec поддерживает средства, позволяющие администратору управлять скрытыми каналами (которые обычно не туннелируются) и обеспечить проверку получателем полученных пакетов в плане контроля доступа. Реализация IPsec может быть настраиваемой в плане обработки внешнего поля DS при передаче пакетов в туннельном режиме. Для исходящего трафика одна конфигурационная установка для внешнего поля DS будет действовать, как описано ниже, на обработку заголовков IPv4 и IPv6 для туннелей IPsec. Другая будет позволять отображение внешнего поля DS на фиксированное значение, которое может быть настраиваемым на уровне SA70. Эти конфигурационные опции позволяют локальному администратору решить, будет ли скрытый канал, обеспечиваемый копированием этих битов, перевешивать преимущества копирования.
  • IPsec описывает обработку ECN и DS, а также обеспечивает возможность контроля за распространением изменений этих полей между защищенными и открытыми доменами. В общем случае распространение из защищенной области в открытую представляет собой скрытый канал и для полосы этого канала поддерживаются средства управления. Распространение значений ECN в другом направлении контролируется так, что передаются только легитимные изменения ECN (показывающие насыщение между конечными точками туннеля). По умолчанию распространение DS из защищенной области в открытую запрещено. Однако, если отправитель и получатель не используют единое пространство кодов DS и получатель не может узнать способ отображения одного пространства на другое, распространение может быть разрешено. В частности, реализации IPsec могут настраиваться в части обработки внешнего поля DS для принятых пакетов (в туннельном режиме). Они могут быть настроены на отбрасывание внешнего значения DS (по умолчанию) или переписывание значения внутреннего поля DS в соответствии со значением внешнего. Выбор отбрасывания или изменения DS может быть задан на уровне SA. Эта опция позволяет локальному администратору самому выбрать между возникновением уязвимости при копировании поля DS и обеспечиваемыми таким копированием преимуществами. Описание каждого из этих вариантов дано в [RFC2983] вместе с описанием кондиционирования трафика до или после обработки IPsec (включая декапсуляцию).
  • IPsec позволяет использовать разные версии протокола IP во внутреннем и внешнем заголовке.

Приведенные ниже таблицы описывают обработку полей заголовка и опций (термин «создается» означает, что значение поля во внешнем заголовке задается независимо от значения во внутреннем заголовке).

5.1.2.1. IPv4: создание заголовка для туннельного режима

<— Связь внешнего заголовка с внутренним —>

Поля заголовка IPv4 Внешний заголовок на инкапсуляторе Внутренний заголовок на декапсуляторе
Version 4 (1) без изменения
Header length создается без изменения
DS копируется из внутреннего заголовка (5) без изменения
ECN копируется из внутреннего заголовка создается (6)
Total length создается без изменения
ID создается без изменения
Flags (DF, MF) создается, DF (4) без изменения
Fragment offset создается без изменения
TTL создается (2) уменьшается на 1 (2)
Protocol AH, ESP без изменения
Checksum создается создается (2)(6)
Src address создается (3) без изменения
Dest address создается (3) без изменения
Options никогда не копируются без изменения

Примечания:

  1. Версия IP в инкапсулирующем заголовке может отличаться от версии протокола во внутреннем заголовке.
  2. Значение TTL декрементируется инкапсулятором перед пересылкой пакета и декапсулятором — при пересылке71 (контрольная сумма заголовка IPv4 меняется при изменении TTL).
  3. Локальные и удаленные адреса зависят от SA, которая служит для определения удаленного адреса, а тот, в свою очередь, определяет локальный адрес (сетевой интерфейс), используемый для пересылки пакета72.
  4. Для поля DS копирование из внутреннего заголовка (IPv4), сброс или создание определяется настройкой.
  5. Если пакет будет непосредственно попадать в ломен, где значение DSCP во внешнем заголовке неприемлемо, значение должно быть отображено на приемлемое для домена [NiBlBaBL98] (см. RFC 2475 [BBCDWW98]).
  6. Если поле ECN внутреннего заголовка имеет значение ECT(0)73 или ECT(1) и внешнее поле ECN включает флаг CE (перегрузка), в поле ECN внутреннего заголовка устанавливается флаг CE; в остальных случаях значение внутреннего поля ECN не меняется (при изменении ECN меняется контрольная сумма заголовка IPv4).

Примечание. IPsec не копирует опции из внутреннего заголовка во внешний и не создает опций для внешнего заголовка. Однако после IPsec опции внешнего заголовка могут добавляться и изменяться.

5.1.2.2. IPv6: создание заголовка для туннельного режима

<— Связь внешнего заголовка с внутренним —>

Поля заголовка IPv6 Внешний заголовок на инкапсуляторе Внутренний заголовок на декапсуляторе
Version 6 (1) без изменения
DS копируется из внутреннего заголовка (5) без изменения (9)
ECN копируется из внутреннего заголовка создается (6)
Flow label копируется или настраивается (8) без изменения
Payload length создается без изменения
Next header AH, ESP, routing hdr без изменения
Hop limit создается (2) уменьшается на 1 (2)
Src address создается (3) без изменения
Dest address создается (3) без изменения
Extension headers никогда не копируется (7) без изменения

Примечания:

  1. — (3), (5), (6) см. параграф 5.1.2.1.
  1. IPsec не копирует расширения заголовка из внутреннего пакета во внешний и не создает расширений во внешнем заголовке. Однако после IPsec возможна вставка и создание расширений для внешнего заголовка.
  2. См. [RaCoCaDe04]. Копирование допустимо только для конечных систем, но не для защитных шлюзов. Если шлюз копирует метки защиты из внутреннего заголовка во внешний, могут возникать конфликты.
  3. Реализация может выбрать способ передачи значения DS из внешнего заголовка во внутренний на уровне SA для принятых в туннельном режиме пакетов. Мотивацией для такого решения служит приспособление к ситуациям, когда пространство кодов DS на приемной стороне отличается от пространства кодов передающей стороны и нет информации о способе трансляции из пространства отправителя. Копирование значения DS из внешнего заголовка во внутренний представляет опасность, поскольку у атакующего появляется возможность влияния на трафик за счет изменения значений DSCP во внешнем заголовке. Следовательно, по умолчанию реализации IPsec не разрешают такое копирование.

5.2. Обработка входящего трафика IP74

Обработка входящего трафика несколько отличается от обработки исходящего, по причине использования SPI для отображения трафика IPsec на SA. Входной кэш SPD (SPD-I) применяется только для передаваемого в обход или отбрасываемого трафика. Если прибывающий с незащищенного интерфейса пакет выглядит, как фрагмент IPsec, сборка осуществляется до выполнения обработки IPsec. Смысл каждого кэша SPD заключается в том, что пакет, не соответствующий ни одной записи в кэше, относится к соответствующей SPD. Каждой SPD следует иметь номинальную, завершающую запись, которая «захватывает» все, что не соответствует другим записям и отбрасывает пакеты. Это обеспечивает отбрасывание всех входящих пакетов, которые не защищены IPsec и не соответствуют ни одной записи SPD-I.

                   Незащищенный интерфейс
                              |
                              V
                   +---------------------+ Защита IPsec
       ----------->|Демультиплексирование|-----------+
       |           +---------------------+           |
       |                      |                      |
       |             Не IPsec |                      |
       |                      |                      |
       |                      V                      |
       |   +---------+    +---------+                |
       |   |Отбросить|<---|SPD-I (*)|                |
       |   +---------+    +---------+                |
       |                   |                         |
       |                   |-----+                   |
       |                   |     |                   |
       |                   |     V                   |
       |                   |  +------+               |
       |                   |  | ICMP |               |
       |                   |  +------+               |
       |                   |                         V
    +---------+            |               +---------------+
....|SPD-O (*)|............|...............|Обработать (**)|...Граница
    +---------+            |               |   (AH/ESP)    |   IPsec
       ^                   |               +---------------+
       |                   |       +---+             |
       |            Обход  |   +-->|IKE|             |
       |                   |   |   +---+             |
       |                   V   |                     V
       |               +---------+           +---------+   +----+
       |--------<------|Пересылка|<----------|SAD Check|-->|ICMP|
         вложенные SA  +---------+           | (***)   |   +----+
                             |               +---------+
                             V
                    Защищенный интерфейс

(*) = На рисунке показаны кэшированные записи. Если кэш отсутствует, проверяется SPD. Требования буферизации пакета при отсутствии кэша не предъявляется к реализациям.

(**) = Эта обработка включает использование SPI и других параметров пакета для поиска SA в SAD, которая формирует кэш SPD для входящих пакетов (за исключением случаев, отмеченных в параграфах 4.4.2 и 5). См. п. 3a ниже.

(***) = Эта проверка SAD выполняется на этапе 4 (см. ниже).

Рисунок 3: Модель обработки входящего трафика

До обработки AH или ESP все фрагменты IP, приходящие через незащищенный интерфейс собираются (средствами IP). Каждая входящая дейтаграмма IP, к которой будет применяться обработка IPsec, идентифи-цируется наличием значений AH или ESP в поле IP Next Protocol (или AH/ESP в качестве протокола следующего уровня в контексте IPv6).

IPsec необходимо выполнить следующие действия:

  1. Прибывающий пакет может быть помечен идентификатором интерфейса (физического или логического), через который пакет был принят, если это требуется для поддержки множества SPD и связанных с ними кэшей SPD-I (идентификатор интерфейса отображается на соответствующий SPD-ID).
  2. Пакет проверяется и демультиплексируется в одну из двух категорий:
  • Если пакет представляется защищенным с помощью IPsec и адресован данному устройству, предпринимается попытка отобразить этот пакет на активную SA через SAD. Отметим, что устройство может иметь множество адресов IP, которые могут служить для поиска в SAD (например, в случае использования протоколов типа SCTP).
  • Трафик не адресованный данному устройству или адресованный устройству, но не относящийся к AH или ESP, направляется на просмотр SPD-I (это означает, что для трафик IKE в SPD должна присутствовать явная запись BYPASS). При наличии множества SPD для выбора SPD-I (и кэша) используется присвоенный на этапе 1 тег. Поиск в SPD-I определяет для пакета действие DISCARD (отбросить) или BYPASS (передать в обход IPsec).
  1. a. Если пакет адресован устройству IPsec и в качестве протокола указан AH или ESP, выполняется поиск в SAD. Для индивидуального трафика используется только SPI (или SPI и протокол). Для группового трафика используется SPI в комбинации с адресом получателя или адресами отправителя и получателя, как указано в параграфе 4.1. В любом случае (групповой или индивидуальный трафик) при отсутствии соответствия пакеты отбрасываются с внесением записи в журнал аудита. В запись следует включать текущую дату и время, SPI, отправителя и получателя пакета, протокол IPsec и все прочие доступные из пакета селекторы. Если пакет найден в SAD, выполняется п. 4.b. Если пакет не адресован устройству или не относится к AH или ESP, просматривается соответствующий кэш SPD-I. Если соответствие найдено и пакет следует отбросить или передать в обход, выполняется нужная операция. Если в кэше не обнаружено соответствия, просматривается подходящая SPD-I и создается запись в кэше (не создается SA в ответ на получение пакета, требующего защиты IPsec; таким путем в кэше могут создаваться только записи BYPASS или DISCARD). Если соответствия не найдено, трафик отбрасывается с внесением записи в журнал аудита. В запись следует включать текущую дату и время, SPI, отправителя и получателя пакета, протокол IPsec и все прочие доступные из пакета селекторы.c. Предполагается, что обработка сообщений ICMP выполняется на незащищенной стороне границы IPsec. Незащищенные сообщения ICMP проверяются и к ним применяется локальная политика для определения дальнейших действий (принять или отбросить), а также действий при восприятии сообщения. Например, при получении сообщения ICMP unreachable реализация должна решить, что делать — отбросить сообщение или обработать его с учетом ограничений (см. раздел 6).
  2. Выполняется обработка AH или ESP с использованием записи SAD, выбранной на этапе 3a. Затем проверяется соответствие пакета входным селекторам, определяемым записью SAD, чтобы убедиться в принадлежности пакета SA, через которую он был получен.
  3. Если реализация IPsec получает пакет через SA и поля в заголовке пакета не согласуются с селекторами для SA, пакет должен отбрасываться с записью в журнал аудита. В запись следует включать текущую дату и время, SPI, отправителя и получателя пакета, протокол IPsec и все прочие доступные из пакета селекторы, а также значение селекторов для соответствующей записи SAD. Системе следует также поддерживать возможность генерации и передачи отправителю (партнеру IPsec) уведомления IKE INVALID_SELECTORS, показывающего, что принятый пакет был отброшен в результате несоответствия при проверке селекторов.

Для минимизации влияния DoS-атак и некорректно настроенных партнеров системам IPsec следует включать средства управления, позволяющие администратору настроить для реализации IPsec режим уведомлений IKE (передавать или не передавать) и ограничение частоты передачи таких уведомлений.

После того, как трафик передан в обход или обработан IPsec, он передается входной функции пересылки для его дальнейшей передачи. Эта функция может вызывать передачу пакета через границу IPsec (исходящий трафик) для дополнительной входной обработки IPsec (например, при использовании вложенных SA). В таких случаях, как для всего исходящего трафика, передаваемого в обход, должно проверяться соответствие пакета записи в SPD-O. В конечном итоге пакет следует переслать хосту-адресату или обработать пересылки дальше.

6. Обработка ICMP

В этом разделе описана обработка в IPsec трафика ICMP, который делится на две категории — сообщения об ошибках (например, type = destination unreachable) и прочие сообщения (например, type = echo). Данный раздел посвящен исключительно сообщениям об ошибках. Обработка остальных сообщений ICMP, которые не адресованы самой реализации IPsec, должна явно учитываться в плане использования записей SPD.

Обсуждение в этом разделе применимо как к ICMPv6, так и к ICMPv4. Следует также обеспечивать механизм, который позволит администратору протоколировать сообщения ICMP об ошибках (выбранные, все или никаких) для диагностики.

6.1. Обработка сообщений ICMP об ошибках, направленных реалиации IPsec

6.1.1. Сообщения ICMP об ошибках на незащищенной стороне границы

Рисунок 3 в параграфе 5.2 показывает отдельный обработки ICMP на незащищенной стороне границы IPsec, предназначенный для обработки сообщений ICMP (ошибки и другие сообщения), адресованных устройству IPsec и не защищенных AH или ESP. Сообщения ICMP этого сорта являются неидентифицированными и их обработка может приводить к отказу или снижению производительности сервиса. По этой причине в общем случае желательно игнорировать такие сообщения. Однако хосты и защитные шлюзы получают много сообщений ICMP из неидентифицированных источников (например, маршрутизаторов в открытой сети Internet. Игнорирование этих сообщений сообщений PMTU или перенаправлений). Таким образом, нужна мотивация для восприятия и выполняемых действий в случаях получения неидентифицированных сообщений ICMP.

Для учета всех особенностей, связанных с обработкой сообщений ICMP соответствующая спецификации реализация IPsec должна позволять локальному администратору возможность настройки восприятия или отбрасывания неидентифицированного трафика ICMP. Эти средства должны обеспечивать гранулярность по типу ICMP и могут обеспечивать гранулярность по типу и коду. В дополнение к этому реализации следует поддерживать механизмы и параметры для работы с таким трафиком. Например, может обеспечиваться возможность поддержки минимального PMTU для трафика (по адресатам), чтобы предотвратить установку слишком малых значение PMTU в результате обработки неидентифицированных сообщений ICMP.

Если сообщение ICMP PMTU проходит указанную выше проверку и система настроена на восприятие такого сообщения, возникают две возможности. Если реализация использует фрагментацию на шифрованной стороне границы, принятая информация PMTU передается модулю пересылки (не относится к реализации IPsec), который использует ее при фрагментации исходящих пакетов. Если реализация настроена на фрагментацию нешифрованного трафика, информация PMTU передается на защищенную (нешифрованную) сторону и обрабатывается, как описано в параграфе 8.2.

6.1.2. Сообщения ICMP об ошибках, принимаемые на защищенной стороне

Эти сообщения ICMP не идентифицированы, но они приходят с защищенной стороны границы IPsec. Таким образом, эти сообщения в общем случае рассматриваются, как более «доверенные» по сравнению с описанными выше сообщениями с незащищенной стороны. Основная проблема безопасности для таких сообщений связана с тем, что скомпрометированный хост или маршрутизатор может генерировать не соответствующие действительности сообщения ICMP об ошибках, которые могут снижать производительность сервиса для других устройств, находящихся «за шлюзом», и даже приводить к нарушению конфиденциальности. Например, если ложные сообщения ICMP redirect будут восприниматься защитным шлюзом, это может приводить к изменению таблицы пересылки на защищенной стороне, в результате чего трафик будет попадать неприемлемому получателю «за шлюзом». Таким образом, реализации должны обеспечивать средства контроля, позволяющие локальному администратору ограничить обработку сообщений ICMP об ошибках, полученных с защищенной стороны границы и направленных реализации IPsec. Эти средства контроля имеют тот же тип, который описан для незащищенной стороны в параграфе 6.1.1.

6.2. Обработка защищенных транзитных сообщений ICMP об ошибках

Когда сообщение ICMP об ошибке передается через SA устройству, находящемуся за реализацией IPsec, требуется проверять заголовок и содержимое сообщения ICMP с точки зрения контроля доступа. Если одно из таких сообщений пересылается хосту за защитным шлюзом, реализация принимающего хоста будет принимать решение на основе содержимого сообщения (т. е., заголовка пакета, вызвавшего передачу сообщения об ошибке). Таким образом, реализация IPsec должна обеспечивать возможность настройки на проверку соответствия этого заголовка SA, через которую был получен пакет (это означает, что заголовок с обращенными адресами о номерами портов отправителя и получателя должен соответствовать селекторам трафика для SA). Если такую проверку не проводить, тогда любой, с кем принимающая система IPsec (A) имеет активную SA, сможет передать сообщение ICMP Destination Unreachable, указывающее на недоступность хоста/сети, с которым A взаимодействует, что создает возможность организации очень эффективных DoS-атак на соединения. Обычный получатель IPsec, обрабатывающий трафик, недостаточно защищен от таких атак. Однако упомянутая выше проверка требуется не в каждом контексте, поэтому необходимо предоставить лакальному администратору возможность отказа от такой проверки.

Для обеспечения обеих возможностей принимается описанное далее соглашение. Если администратор разрешит передачу сообщений ICMP об ошибках через SA без проверки содержимого, создается запись SPD, которая явно позволяет передавать такой трафик. Если администратор решит проверять содержимое сообщений ICMP об ошибках на предмет соответствия SA, записи SPD для восприятия такого трафика на основе заголовка пакета ICMP не создается. Это соглашение служит мотивацией для описанной далее обработки.

Отправители и получатели IPsec должны поддерживать описанную ниже обработку сообщений ICMP об ошибках, передаваемых и принимаемых через SA.

Если существует SA, которая принимает исходящее сообщении ICMP об ошибке, сообщение отображается на эту SA и при получении проверяются только заголовки IP и ICMP, как для других типов трафика. Если не существует SA, соответствующей селекторам трафика, связанным с сообщением ICMP об ошибке, просматривается SPD для определения возможности создания такой SA. При положительном результате создается SA и сообщение ICMP передается через нее. При получении к такому сообщению применяется обычная проверка селекторов. Такая обработка ничем не отличается от обработки обычного трафика и не включает каких-либо специальных действий применительно к обработке сообщений ICMP об ошибках.

Если нет SA, которая будет использоваться для передачи исходящих сообщений ICMP, о которых идет речь, и нет записи SPD, которая позволяет передавать исходящие сообщения ICMP об ошибках, реализация IPsec должна отобразить сообщение на SA, которая будет передавать трафик, связанных с пакетом, вызвавшим сообщение ICMP об ошибке. Это требует от реализации IPsec детектировать исходящие сообщения ICMP об ошибках, которые отображаются на несуществующую SA или запись SPD и специальным образом обрабатывать их в плане поиска и создания SA. Реализация просматривает заголовок пакета для определения информации о пакете, вызвавшем ошибку (из поля данных сообщения ICMP), меняет местами адреса отправителя и получателя, выделяет поле протокола и меняет местами номера портов отправителя и получателя (если они доступны). Полученная информация служит для определения подходящей активной исходящей SA и передачи сообщения об ошибке через эту SA. Если SA не существует, новая SA не создается и в журнал аудита вносится запись об этом факте.

Если реализация IPsec получает входящее сообщение ICMP об ошибке на SA, f заголовки IP и ICMP в этом сообщении не соответствуют селекторам трафика для SA, получатель должен обрабатывать полученное сообщение особо. В частности, получатель должен выделить заголовок вызвавшего ошибку пакета из сообщения ICMP и выполнить обращение полей, как описано выше, для определения соответствия пакета SA, через которую было получено сообщение ICMP. При несоответствии реализации IPsec недопустимо пересылать сообщение ICMP об ошибке указанному в нем адресату. Информация о таких событиях заносится в журнал аудита.

7. Обработка фрагментов на защищенной стороне границы IPsec

В предыдущих разделах документа описаны механизмы для (a) фрагментации исходящих пакетов после обработки IPsec и сборки фрагментов на приемной стороне до обработки IPsec и (b) механизмы обработки входящих фрагментов, полученных с незащищенной стороны границы IPsec. В этом разделе рассматривается, как реализации следует выполнять обработку исходящих незашифрованных фрагментов на защищенной стороне границы IPsec (см. Приложение D: Обоснование обработки фрагментов) В частности, здесь рассматривается:

  • отображение исходящих фрагментов, не являющихся первыми на корректную SA (или поиск записи SPD);
  • проверка полномомочности передачи фрагмента, отличного от первого, через SA, в которой он был получен;
  • отображение исходящих и входящих фрагментов, не являющихся первыми, на корректную запись SPD-O/SPD-I или подходящую запись в кэше для трафика BYPASS/DISCARD.

Примечание. В параграфе 4.1 SA транспортного режима определены, как не передающие фрагменты (IPv4 или IPv6). Отметим также, что в параграфе 4.4.1, были определены два специальных случая селекторов — ANY и OPAQUE, причем ANY включает в себя OPAQUE. Для селекторов, отличных от OPAQUE и ANY используется термин «нетривиальный».

Примечание. Термин «фрагмент, отличный от первого» используется для индикации фрагментов, не содержащих значения всех селекторов, которые могут потребоваться для контроля доступа. Как отмечено в параграфе 4.4.1, в зависимости от значения Next Layer Protocol, кроме номеров порта в таких фрагментах может отсутсттвовать тип/код ICMP или тип Mobility Header. Для IPv6 даже первый фрагмент может не включать значений Next Layer Protocol или Port (тип/код ICMP или тип Mobility Header) в зависимости от числа и типа имеющихся расширений заголовка. Если отличный от первого фрагмент содержит Port (тип и код ICMP или тип Mobility Header), но не включает Next Layer Protocol, тогда при отсутствии записи SPD для подходящих адресов Local/Remote с ANY в полях Next Layer Protocol и Port (тип и код ICMP или тип Mobility Header) фрагмент не будет включать полного набора информации, требуемой для контроля доступа.

Для решения этих вопросов определены три модели:

  • SA туннельного режима, передающие отличные от первых фрагменты (параграф 7.1.);
  • отдельные SA туннельного режима для фрагментов, отличных от первых (параграф 7.2.);
  • контроль фрагментов с учетом состояний ( параграф 7.3.).

7.1. SA туннельного режима, передающие любые фрагменты

Все реализации должны поддерживать SA туннельного режима, которые настраиваются на передачу трафика вне зависимости от номера порта (типа/кода ICMP или типа Mobility Header type). Если SA будет передавать трафик для заданных протоколов, набор селекторов для SA должен задавать поля портов (типа/кода ICMP или типа Mobility Header), как ANY. Определенные таким способом SA будут передавать весь трафик, включая первые и последующие фрагменты для указанных адресов Local/Remote и заданного протокола (протоколов) следующего уровня. Если SA будет передавать трафик независимо от протокола (т. е, Next Layer = ANY), значения портов не определены и должны быть указаны, как ANY (как отмечено в параграфе 4.4.1, значение ANY включает OPAQUE и все конкретные номера).

7.2. Отдельные туннельные SA для фрагментов, отличных от первых

Реализация может поддерживать SA туннельного режима, через которые будут передаваться только нефрагментированные пакеты и первые фрагменты. Для задания поля порта (типа/кода ICMP или типа Mobility Header) селекторов таких SA будет использоваться значение OPAQUE. Получатели должны проверять минимальное смещение в (отличных от первого) фрагментах IPv4 для защиты от атак с перекрывающимися фрагментами, когда используются SA такого типа. Поскольку такие проверки не могут осуществляться для (отличных от первого) фрагментов IPv6, пользователям и администраторам следует принимать во внимание опасность, связанную с передачей таких фрагментов и реализации могут отказываться от поддержки таких SA для трафика IPv6. SA этого типа также будут передавать все отличные от первых фрагменты, которые соответствуют заданной паре адресов Local/Remote и значению протокола (т. е., фрагменты, передаваемые в таких SA, относятся к пакетам, которые не будучи фрагментированными, могли бы передаваться через другие SA с иной защитой). Следовательно, пользователям и администраторам нужно защищать такой трафик с использованием ESP (с защитой целостности) и «самыми строгими» алгоритмами шифрования и защиты целостности для данной пары партнеров (определение «самого строгого» алгоритма требует упорядочивания доступных алгоритмов со стороны инициатора данной SA).

Значения селекторов порта (типа/кода ICMP или типа Mobility Header) будут использоваться для определения SA, передающих нефрагментированные пакеты и первые фрагменты. Такая модель может использоваться, если пользователь или администратор хочет создать одну или более SA туннельного режима между одной парой адресов Local/Remote и эти связи разделяются по полям портов (типов/кодов ICMP или типов Mobility Header). Эти SA должны иметь нетривиальные значения селекторов протокола, иначе должен использоваться описанный выше вариант #1.

Примечание. В общем случае для описанной здесь модели требуется только одна SA между двумя реализациями для передачи фрагментов, отличных от первого. Однако, если выбрано использование множества SA между парой реализаций для дифференциации QoS, может возникнуть желание создать множество SA для передачи «фрагментов без номера порта», каждая из которых поддерживает класс QoS. Поскольку поддержка QoS через разные SA задается на локальном уровне и не определяется данным документом, выбор использования множества SA для передачи фрагментов, отличных от первого, также решается на локальном уровне.

7.3. Проверка фрагментов с учетом состояния

Реализация может поддерживать ту или иную форму проверки фрагментов с учетом состояния для SA туннельного режима с нетривиальным (отличным от ANY и OPAQUE) значением поля порта (типа/кода ICMP или типа MH). Реализации, которые будут передавать отличные от первых фрагменты в SA туннельного режима, использующие нетривиальные селекторы порта (типа/кода ICMP или типа MH), должны уведомлять партнера с помощью элемента данных IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO.

Партнер должен отвергать такие предложения, если он не будет принимать отличные от начального фрагменты в таком контексте. Если реализация не согласовала передачу фрагментов, отличных от первого, для такой SA, ей недопустимо передавать эти фрагменты через SA. Этот стандарт не задает для партнеров способа обработки фрагментов (например, сборки или иные операции на стороне отправителя или получателя). Однако получатель должен отбрасывать отличные от первого фрагменты, которые приходят через SA с нетривиальным селектором порта (типа/кода ICMP или типа MH), если прием таких фрагментов не был согласован. Получатель также должен отбрасывать отличные от первого фрагменты, которые не соответствуют политике защиты для полного пакета. Записи о таких событиях заносятся в журнал аудита. Отметим, что в сетевых конфигурациях, где фрагменты пакетов могут передаваться и приниматься через разные защитные шлюзы или реализации BITW75, стратегии отслеживания состояния фрагментации могут давать отказы.

7.4. Операции BYPASS/DISCARD для трафика

Все реализации должны поддерживать отбрасывание фрагментов с использованием нормальных механизмов классификации SPD. Все реализации должны поддерживать проверку фрагментов с учетом состояния, чтобы принимать передаваемый в обход (BYPASS) трафик, для которого задан нетривиальный диапазон портов. Дело в том, что передаваемый в обход трафик представляет собой нешифрованные фрагменты, отличные от первого и прибывающие в реализацию IPsec, могут подрывать защиту, обеспечиваемую для трафика IPsec, направленного тому же получателю. Рассмотрим в качестве примера реализацию IPsec с записью SPD, которая обеспечивает защиту трафика между парой адресов (отправитель-получатель) для заданного протокола и порта получателя (например, трафик TCP в порт 23 — Telnet). Предположим, что реализация также разрешает передавать в обход трафик между той же парой хостов для того же протокола, но с другим номером порта (например, порт 119 — NNTP). Атакующий может передать отличный от первого фрагмент (с обманным адресом отправителя), который при передаче в обход может перекрываться с трафиком IPsec с того же адреса и, таким образом, нарушать целостность трафика IPsec. Требование проверки с учетом состояния для отличных от первого фрагментов с нетривиальными значениями портов, направляемых в обход, позволяет предотвратить такие атаки. Как отмечено выше, в сетях, где фрагменты могут передаваться и приниматься через разные защитные шлюзы или реализации BITW, могут возникать проблемы с проверкой фрагментов с учетом состояния.

8. Обработка Path MTU и DF

Операции AH и ESP, применяемые к исходящим пакетам, увеличивают размер пакетов и могут в результате приводить к тому, что размер пакета превысит значение PMTU для SA, через которую пакет будет передаваться. Реализация IPsec может также получить незащищенное сообщение ICMP PMTU, реакция на которое будет воздействовать на обработку исходящего трафика. В этом разделе описаны операции, которые реализация IPsec должна выполнять в упомянутых ситуациях.

8.1. Бит DF

Все реализации IPsec должны поддерживать опцию копирования флага DF из заголовка исходящего пакета в заголовок создаваемого пакета туннельного режима при передаче трафика через туннельную SA. Это означает необходимость настройки для реализации трактовки флага DF (установить, сбросить, копировать из внутреннего заголовка) применительно к каждой SA (в том случае, когда внешний и внутренний заголовок относятся к IPv4).

8.2. Определение PMTU

В этом параграфе рассматривается обработка IPsec для незащищенных сообщений Path MTU Discovery. Обозначение ICMP PMTU76 используется здесь для сообщений ICMP в:

IPv4 (RFC 792 [Pos81b]):

  • Type = 3 (Адресат недоступен)
  • Code = 4 (Нужна фрагментация, но установлен флаг DF)
  • Next-Hop MTU в младших 16 второго слова заголовка ICMP (указаны в RFC 792, как неиспользуемые) с нулевым значением старших 16 битов.

IPv6 (RFC 2463 [CD98]):

  • Type = 2 (Пакет слишком велик)
  • Code = 0 (Нужна фрагментация)
  • Next-Hop MTU в 32-битовом поле MTU сообщения ICMP6.

8.2.1. Распространение PMTU

Когда реализация IPsec получает неидентифицированное сообщение PMTU, будучи настроенной на обработку (вместо игнорирования) таких сообщений, она отображает это сообщение на SA, которой оно соответствует. Отображение осуществляется с использованием информации из заголовка в поле данных сообщения PMTU по процедуре, описанной в параграфе 5.2. Определяемое таким сообщением значение PMTU используется для обновления поля SAD PMTU с учетом размера заголовка AH или ESP, который будет использован, всех данных криптографической синхронизации, а также издержек, связанных с дополнительным заголовком IP для туннельных SA.

В естественной реализации хоста возможно поддерживать данные PMTU с такой же гранулярностью, как для незащищенных коммуникаций, т. е., без потери функциональности. Сигнализация для данных PMTU является внутренним делом хоста. Для остальных реализаций IPsec данные PMTU должны распространяться с использованием синтезированного сообщения ICMP PMTU. В таких случаях реализации IPsec следует дождаться отображения исходящего трафика на запись SAD. При поступлении такого трафика с превосходящим PMTU размером пакетов должна выполняться следующая обработка:

Случай 1 — исходный (нешифрованный) пакет относится к IPv4 и имеет флаг DF. Реализации следует отбросить пакет и передать сообщение PMTU ICMP.

Случай 2 — исходный (нешифрованный) пакет относится к IPv4 и не имеет флага DF. Реализации следует фрагментировать пакет (до шифрования или после него в зависимости от настроек) и переслать фрагменты. Сообщение PMTU ICMP передавать не следует.

Случай 3 — исходный (нешифрованный) пакет относится к IPv6. Реализации следует отбросить пакет и передать сообщение PMTU ICMP.

8.2.2. Старение PMTU

Во всех реализациях IPsec значение PMTU, связанное с SA должно «стареть» с использованием того или иного механизма для своевременного обновления PMTU, особенно с целью проверки того, что найденное значение PMTU не меньше требуемого текущими условиями в сети. Данное значение PMTU сохраняется достаточно долго, чтобы доставить пакет от источника SA до партнера и передать сообщение ICMP, если текущее значение PMTU слишком велико.

Реализациям следует использовать модель, описанную с документе Path MTU Discovery (RFC 1191 [MD90], параграф 6.3), которая предлагает периодически сбрасывать PMTU для значения MTU канала данных на первом интервале, а потом обновлять его при необходимости с помощью обычного процесса PMTU Discovery. Период следует делать настраиваемым.

9. Проведение проверок

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

10. Соответствие требованиям

Все реализации IPv4 IPsec должны удовлетворять всем требованиям, приведенным в данном документе. Все реализации IPv6 IPsec должны удовлетворять всем требованиям, приведенным в данном документе.

11. Вопросы безопасности

Основной темой этого документа является защита — следовательно, вопросы безопасности являются неотъемлемой частью данной спецификации.

IPsec вносит строгие ограничения на обход данных в заголовках IP для обоих направления прохождения через границу IPsec, в частности, при использовании SA туннельного режима. Некоторые ограничения являются абсолютными, иные находятся в ведении локального администратора (зачастую, на уровне SA). Для исходящего трафика ограничения направлены на сужение полосы скрытых каналов. Для входящего трафика целью ограничений является предотвращение враждебного воздействия на другие потоки данных (на защищенной стороне IPsec) со стороны тех злоумышленников, которые могут перехватывать поток данных (на незащищенной стороне IPsec). Иллюстрацией может служить приведенное в разделе 5 обсуждение обработки значений DSCP для SA туннельного режима.

Если реализация IPsec настроена на пропускание сообщений ICMP об ошибках через SA по значениям заголовков ICMP без проверки данных из заголовков, содержащихся в поле данных ICMP, может возникнуть серьезная уязвимость. Рассмотрим сценарий с несколькими сайтами (A, B, C), соединенными между собой туннелями ESP ((A-B, A-C, B-C). Предположим также, что селекторы трафика для каждого туннеля содержат значение ANY в полях протокола и порта, а адреса IP для отправителя и получателя содержат диапазоны, охватывающие блоки адресов, находящиеся за защитными шлюзами каждого из сайтов. Это позволяет хосту сайта B передавать любому хосту сайта A сообщения ICMP Destination Unreachable, которые говорят о недоступности всех хостов сети на сайте C. В результате возникает возможность организации очень эффективной DoS-атаки, которая могла бы быть предотвращена, если бы в сообщениях ICMP не только проверялись заголовки, но и выполнялись бы другие проверки, обеспечиваемые IPsec (если SPD подобающим образом настроена, как описано в параграфе 6.2).

12. Согласование с IANA

Агентство IANA выделило значение (3) для реестра asn1-modules и идентификатор объекта 1.3.6.1.5.5.8.3.177 для модуля SPD (см. Приложение C, «ASN.1 для записи SPD»).

13. Отличия от RFC 2401

Этот документ, посвященный архитектуре защиты, существенно отличается от RFC 2401 [RFC2401] в деталях и организации самого документа, но основы архитектуры остались неизменными.

  • Модель обработки была пересмотрена для реализации новых сценариев IPsec, повышения производительности и упрощения реализации. Изменения включают разделение пересылки (маршрутизации) и выбора SPD, раздельное изменение SPD, добавление исходящего кэша SPD и входящего кэша SPD для передаваемого в обход и отбрасываемого трафика. Добавлена также база данных идентификации партнеров (PAD78). Это обеспечило связь между протоколом управления SA (таким, как IKE) и SPD.
  • Снято требование поддержки вложенных SA или «связок SA79». Соответствующая функциональность может быть достигнута за счет SPD и таблицы пересылки. Пример конфигурации приведен в Приложении E.
  • Переопределены записи SPD для повышения уровня гибкости. Каждая запись SPD сейчас включает от 1 до N наборов селекторов, каждый из которых содержит один протокол, а список диапазонов может включать адреса Local IP, Remote IP и другие поля (если они есть), связанные с протоколом следующего уровня (локальный порт, удаленный порт, тип и код сообщения ICMP, тип Mobility Header). Отдельные значения представляются тривиальным (вырожденным) диапазоном, а значение ANY представляется диапазоном, который включает все значения селектора. Пример описания ASN.1 включен в Приложение C.
  • TOS (IPv4) и Traffic Class (IPv6) были заменены на DSCP и ECN. Обновлен раздел, посвященный туннелям, в плане обработки битов DSCP и ECN.
  • Для SA туннельного режима реализациям SG, BITS и BITW сейчас разрешено фрагментировать пакеты до обработки IPsec. Это относится только к IPv4, а пакеты IPv6 разрешается фрагментировать только их источнику.
  • Кода требуется защита между двумя промежуточными точками пути или между промежуточной и конечной точками, можно использовать транспортный режим между защитными шлюзами или между хостом и защитным шлюзом.
  • В этом документе уточнено, что для всего трафика, проходящего через границу IPsec (включая трафик управления IPsec), должна запрашиваться SPD или связанные с ней кэшированные записи.
  • В этом документе описана обработка ситуаций, когда на защтном шлюзе с множеством абонентов требуется организация раздельных контекстов IPsec.
  • Добавлено определение резервных SPI.
  • Расширено объяснение необходимости проверки всех пакетов IP — IPsec включает минимальную функциональность межсетевого экрана для контроля доступа на уровне IP.
  • В разделе, посвященном туннелям, разъяснена обработка поля опций IP и расширенных заголовков IPv6 при создании внешнего заголовка.
  • Обновлено отображение SA для входящего трафика с целью обеспечения согласованности с изменениями, внесенными в AH и ESP для поддержки индивидуальных и групповых SA.
  • Добавлено руководство, касающееся работы со скрытыми каналами, создаваемыми в туннельном режиме при копировании значения DSCP во внешний заголовок.
  • Отменено требование поддержки AH для IPv4 и IPv6 одновременно.
  • Обновлена обработка PMTU. Приложение, посвященное обработке PMTU/DF/Fragmentation удалено.
  • Добавлены три модели обработки нешифрованных фрагментов на защищенной стороне границы IPsec. В Приложении D приведено обоснование работы с фрагментами.
  • Добавлено описание процесса создания значений серекторов для SA из записей SPD, полей пакета и т. п.
  • Добавлена таблица, описывающая связи между значениями селекторов в записи SPD, флагом PFP и получаемыми в результате значениями селекторов соответствующей записи SAD.
  • Добавлено Приложение B, описывающее декорреляцию.
  • Добавлен текст, описывающий обработку исходящих пакетов, которые должны быть отброшены.
  • Добавлен текст, описывающий обработку отбрасываемых входящих пакетов (т. е., пакетов, не соответствующих SA, через которую они были приняты).
  • Добавлен заголовок IPv6 Mobility Header в качестве возможного значения Next Layer Protocol. Тип IPv6 Mobility Header добавлен в качестве селектора.
  • Тип и код сообщения ICMP добавлены в качестве селектора.
  • В целях упрощения удален селектор «data sensitivity level».
  • Обновлен текст, описывающий обработку сообщений ICMP об ошибках. Приложение «Categorization of ICMP Messages» было удалено.
  • Обновлен и прояснен текст для имен селекторов.
  • Приведены дополнительные разъяснения для Next Layer Protocol (проткол следующего уровня) и добавлен принятый по умолчанию список протоколов, пропускаемых при поиске протокола следующего уровня.
  • Обновлен текст, в котором сказано, что данный документ предполагает использование протокола IKEv2 или протокола управления SA, обеспечивающего сравнимые возможности.
  • Добавлен текст, разъясняющий алгоритм отображения входящих дейтаграмм IPsec на SA в присутствии групповых SA.
  • Удалено приложение Sequence Space Window Code Example.
  • Применительно к адресам IP и портам в правилах политики используются термины «локальный» и «удаленный» (взамен отправителя и получателя). Локальный относится к объекту, защищенному реализацией IPsec (т. е., отправителю исходящих пакетов или получателю входящих), а удаленный — к его партнеру. Термины «отправитель» и «получатель» по-прежнему используются применительно к полям заголовков.

14. Благодарности

Авторы отмечают значительный вклад Ran Atkinson в работы на начальном этапе IPsec и подготовку первых вариантов стандарта IPsec — RFC 1825-1827, а также существенный вклад Charlie Lynn в подготовку второй версии стандарта IPsec — RFC 2401, 2402, 2406 и текущей версии (в части IPv6). Авторы также благодарят членов рабочих групп IPsec и MSEC, внесших важный вклад в разработку спецификации протокола.

Приложение A: Глоссарий

В этом разделе даны определения ключевых терминов, используемых в этом документе. Дополнительные определения и базовая информация содержатся также в ряде дополнительных документов, посвященных этой технологии (например, [Shi00], [VK83], [HA94]). В этот глоссарий включены базовые термины, связанные с вопросами защиты, и термины IPsec.

Access Control — контроль доступа

Услуга защиты, предотвращающая несанкционированное использование ресурсов, включая использование ресурсов сверх имеющихся полномочий. В контексте IPsec к контролируемым ресурсам относятся:

  • вычислительные ресурсы и данные на хостах;
  • защищаемые шлюзами сети и полоса сетевых соединений.

Anti-replay — предотвращение повторного использования пакетов

См. Integrity ниже.

Authentication — идентификация

Неформально используется для обозначения комбинации двух номинально разных услуг защиты — идентификации источника данных и защиты целостности соединений (см. приведенные ниже определения этих терминов).

Availability — доступность

В контексте защиты — решение проблем, вызываемых атаками на сети, связанными со снижением производительности или нарушением работы служб. Например, в контексте IPsec доступность обеспечивается механизмами предотвращения повторного использования пакетов в протоколах AH и ESP.

Confidentiality — конфиденциальность

Услуга защиты, обеспечивающая предотвращение раскрытия информации. Основной проблемой конфиденциальности в большинстве случаев является несанкционированное раскрытие данных прикладного уровня, однако раскрытие коммуникационных параметров также может нарушать конфиденциальность при определенных обстоятельствах. Конфиденциальность потока трафика представляет собой услугу по сокрытию адресов отправителей и получателей, размера сообщений, интенсивности обмена информацией. В контексте IPsec использование ESP в туннельном режиме (особенно на защитных шлюзах) может обеспечивать некоторый уровень конфиденциальности потока трафика (см. также Traffic Analysis).

Data Origin Authentication — идентификация источника данных

Услуга защиты, обеспечивающая проверку идентичности заявленного источника данных. Эта услуга обычно объединяется с защитой целостности (без привязки к соединению).

Encryption — шифрование

Механизм защиты, используемый для преобразования данных из понятной формы (нешифрованной) в совершенно непонятную (шифрованную) для обеспечения конфденциальности информации. Обратное преобразование называется расшифровкой или дешифровкой. Зачастую термин «шифрование» используется для обозначения обоих процессов вместе.

Integrity — целостность

Услуга защиты, обеспечивающая детектирование внесенных в данные изменений. Защита целостности может обеспечиваться в различных формах в зависимости от потребностей приложений. IPsec поддерживает две формы защиты целостности — не связанную с соединениями (connectionless) и частичную защиту порядка (partial sequence integrity). Защита целостности, не связанная с соединениями, представляет собой услугу по обнаружению изменения отдельных дейтаграмм IP без связи с порядком их следования в потоке трафика. Частичная защита порядка, предлагаемая в IPsec, называется также предотвращением повторного использования пакетов, и обеспечивает детектирование дубликатов дейтаграмм IP (в пределах ограниченного окна). Этим она отличается от защиты целостности соединений, которая обеспечивает более жесткий контроль упорядоченности трафика (например, может детектировать потерю или нарушение порядка доставки сообщений). Хотя услуги идентификации и защиты целостности часто рассматривают отдельно, на практике они обычно тесно связаны и почти всегда предоставляются в тандеме.

Protected vs. Unprotected — защищенный и незащищенный

«Защищенной» называют систему или интерфейс, находящиеся внутри защитной границы IPsec, а «незащищенной» — систему или интерфейс, находящиеся за пределами защитной границы. IPsec обеспечивает границу, через которую проходит трафик. На границе имеется асимметрия, которая отражена в модели обработки. Исходящие данные, если они не передаются в обход и не отбрасываются, будут защищены с использованием AH или ESP и добавлением соответствующих заголовков. Входящие данные, если они не передаются в обход и не отбрасываются, будут обрабатываться путем удаления заголовков AH или ESP. В этом документе входящим считается трафик, который приходит реализации IPsec от «незащищенного» интерфейса. Исходящий трафик поступает с «защищенного» интерфейса или генерируется самой реализацией на «защищенной» стороне границы и направляется в сторону «незащищенного» интерфейса. Реализация IPsec может поддерживать более одного интерфейса с каждой стороны границы. Защищенный интерфейс может быть внутренним (например, для реализации IPsec на хосте). Защищенный интерфейс может быть связан с интерфейсом уровня сокета, обеспечиваемым операционной системой (OS).

Security Association (SA) — защищенная связь

Симплексное (одностороннее) логическое соединение, создаваемое в целях защиты. Для всего трафика, проходящего через SA обеспечивается одинаковая защитная обработка. В IPsec защищенная связь (SA) представляет собой абстракцию уровня Internet, реализуемую за счет использования AH или ESP. Данные о состоянии, связанные с SA представляются в базе данных SA (SAD).

Security Gateway (SG) — защитный шлюз

Промежуточная система, выполняющая функции коммуникационного интерфейса между двумя сетями. Хосты (сети), расположенные с внешней стороны защитного шлюза, называют незащищенными (они в любом случае менее защищены, чем те, которые находятся «за шлюзом»), а сети и хосты с внутренней стороны шлюза называют защищенными. Внутренние подсети и хосты, обслуживамые защитным шлюзом, будут доверенными в силу использования общего, локального администрирования защиты. В контексте IPsec защитный шлюз является точкой, в которой реализуются AH и/или ESP для обслуживания внутренних хостов с целью предоставления им услуг защиты при обмене информацией с внешними хостами, которые также используют IPsec (непосредственно или через другой защитный шлюз).

Security Parameters Index (SPI) — список параметров защиты

Произвольное 32-битовое значение, используемое получателем для идентификации SA, с которой следует связать входящий поток. Для индивидуальных SA значение SPI можно использовать для указания SA само по себе или в комбинации с типом протокола IPsec. Для идентификации групповых SA дополнительно используются адреса IP. Значения SPI передаются в протоколах AH и ESP для того, чтобы принимающая система могла выбрать SA, в которой будут обрабатываться принимаемые пакеты. SPI имеет только локальную значимость, как определяется создателем SA (обычно, получатель пакета, содержащего SPI), поэтому в общем случае SPI представляется неформатированной строкой битов. Однако создатель SA может выбрать интерпретацию битов SPI для упрощения локальной обработки.

Traffic Analysis — анализ трафика

Анализ потока сетевого трафика с целью обнаружения информации, которая может быть полезна противнику. Примерами такой информации могут служить интенсивность обмена данными, идентификация сторон, размеры пакетов, идентификаторы потоков [Sch94].

Приложение B: Декорреляция

Это приложение основано на работах по кэшированию правил, выполненных Luis Sanchez, Matt Condell и John Zao в рамках рабочей группы IP Security Policy.

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

B.1. Алгоритм декорреляции

Базовый алгоритм декорреляции принимает каждую запись в коррелирующих SPD и делит ее на множество записей, используя древовидную структуру. Узлы дерева являются селекторами, которые могут перекрываться между правилами. На каждом узле алгоритм создает ветвь для каждого значения селектора. Создается также одна ветвь для дополнения к объединению значений всех селекторов. Правила формируются путем прохождения по дереву от корня до каждого листа. Правила на листьях сравниваются с набором ранее декоррелированных правил. Каждое правило на каждом листе или полностью перекрывается набором уже декоррелированных правил и отбрасывается, или никак не коррелирует с набором ранее декоррелированных правил и добавляется к нему.

Базовый алгоритм не гарантирует создания оптимального набора декоррелированных записей. Т. е., записи могут представлять собой набор, который меньше необходимого, хотя они по-прежнему будут содержать всю требуемую информацию о правилах. Некоторые расширения базового алгоритма, описанные ниже, позволяют преодолеть этот недостаток и повышают производительность алгоритма.

C набор упорядоченных, коррелирующих записей (коррелирующая SPD).

Ci i-ая запись в C.

U набор декоррелированных записей, созданный из C.

Ui i-ая запись в U.

Sik k-ый выбор для правила Ci.

Ai действие для правила Ci.

Правило (запись SPD) P можно выразить, как последовательность значений селекторов и действие(BYPASS — обход, DISCARD — отбрасывание, PROTECT — защита):

Ci = Si1 x Si2 x ... x Sik -> Ai
  1. Поместим C1 в набор U, как U1Для каждого правила Cj (j > 1) в наборе C
  2. Если Cj декоррелирована с каждой записью в U, Cj добавляется в U.
  3. Если Cj коррелирует с одной или множеством записей в U, создается дерево с корнем у Cj, которое делит Cj на множество декоррелированных записей. Алгоритм начинает работу с корневого узла, где еще не были выбраны селекторы.
    1. Выбирается селектор Sjn в Cj, который еще не был выбран при прохождении от корня дерева к данному узлу. Если ни одного селектора еще не было использовано, продолжается работа со следующей незавершенной ветвью, пока все ветви не будут завершены. При завершении дерева переход к п. D.T представляет собой набор записей в U, коррелирующих с записью для данного узла.Запись у этого узла представляет собой запись, формируемую значениями селекторов каждой из ветвей между корнем и данным узлом. Любые значения селекторов, которые еще не представлены ветвями, предполагаются соответствующими значению селектора в Cj, поскольку значения в Cj представляют максимальное значение для каждого селектора.
    2. К дереву добавляется ветвь для каждого значения селектора Sjn, которое появляется в любой из записей в T (если значение представляет собой надмножество значения Sjn в Cj, используется значение в Cj, поскольку это значение представляет универсальный набор). Добавляется также ветвь для дополнения к объединению значений селектора Sjn в T. При создании дополнения следует помнить, что универсальный набор является значением Sjn в Cj. Для пустых наборов ветви не создаются.
    3. П. A и B повторяются до завершения дерева.
    4. Запись для каждого листа сейчас представляет запись, являющуюся подмножеством Cj. Записи у листьев полностью делят Cj так, что каждая запись полностью перекрывается записью в U или декоррелирована со всеми записями U.

Все декоррелированные записи у листьев дерева добавляются к U.

4. Переход к следующей Cj и п. 2.

5. При завершении обработки всех записей C набор U будет представлять собойдекоррелированную версию C.

Этот алгоритм можно оптимизировать и некоторые из вариантов оптимизации представлены ниже.

Можно оптимизировать число ветвлений за счет аккуратного выбора селекторов, используемых для следующей ветви. Например, если селектор Sjn был выбран так, что все значения для этого селектора в T совпадают или являются надмножеством значений Sjn в Cj, нужно будет создавать только одну ветвь (поскольку дополнение будет пустым).

Ветви дерева не требуется обрабатывать с использованием полного алгоритма декорреляции. Например, если узел представляет запись, которая декоррелирована со всеми записями в U, нет причин продолжать декорреляцию этой ветви. Точно так же, если ветвь полностью перекрывается записью в U, эту ветвь больше не нужно декоррелировать.

Дополнительная оптимизация обеспечивается проверкой перекрытия ветви одной из коррелированных записей в наборе C, которые уже были декоррелированы. Т. е., если ветвь является частью декоррелированной Cj, проверяется перекрытие этой ветви записью Cm (m < j). Такая проверка корректна, поскольку все записи Cm уже выражены в U.

Вместе с проверкой того, что запись уже была декоррелирована на этапе 2, проверяется перекрытие Cj любой записью в U. Если такое перекрытие присутствует, запись пропускается, поскольку она не имеет отношения к делу. Запись x перекрывается другой записью y, если селектор в x совпадает с соответствующим селектором в y или является его подмножеством.

Приложение C: ASN.1 для записи SPD

Это приложение включено в качестве дополнительного способа описания записей SPD, определенных в параграфе 4.4.1. Здесь используется синтаксис ASN.1, который был успешно скомпилирован. Синтаксис служит исключительно для иллюстрации и его не требуется воплощать в реализациях для обеспечения совместимости. Описание SPD в параграфе 4.4.1 является нормативным.

SPDModule
    {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5)
     ipsec (8) asn1-modules (3) spd-module (1) }

       DEFINITIONS IMPLICIT TAGS ::=

       BEGIN

       IMPORTS
           RDNSequence FROM PKIX1Explicit88
             { iso(1) identified-organization(3)
               dod(6) internet(1) security(5) mechanisms(5) pkix(7)
               id-mod(0) id-pkix1-explicit(18) } ;

       -- SPD представляет собой список правил в порядке убывания предпочтений
       SPD ::= SEQUENCE OF SPDEntry

       SPDEntry ::= CHOICE {
           iPsecEntry       IPsecEntry,                -- PROTECT (защита трафика)
           bypassOrDiscard  [0] BypassOrDiscardEntry } -- DISCARD/BYPASS (обход/отбрасывание)

       IPsecEntry ::= SEQUENCE {       -- Каждая запись включает
           name        NameSets OPTIONAL,
           pFPs        PacketFlags,    -- Заполняется в соответствии с флагами в пакете
                              -- Применяется ко всем соответствующим селекторам трафика
                              -- из SelectorLists
           condition   SelectorLists,  -- Правило "condition" - условие
           processing  Processing      -- Правило "action" - действие
           }

       BypassOrDiscardEntry ::= SEQUENCE {
           bypass      BOOLEAN,        -- TRUE BYPASS (обход), FALSE DISCARD (отбрасывание)
           condition   InOutBound }

       InOutBound ::= CHOICE {
           outbound    [0] SelectorLists,
           inbound     [1] SelectorLists,
           bothways    [2] BothWays }

       BothWays ::= SEQUENCE {
           inbound     SelectorLists,
           outbound    SelectorLists }

       NameSets ::= SEQUENCE {
           passed      SET OF Names-R,  -- Соответствует IKE ID
           local       SET OF Names-I } -- Используется инициатором IKE

       Names-R ::= CHOICE {                   -- IKEv2 IDs
           dName       RDNSequence,           -- ID_DER_ASN1_DN
           fqdn        FQDN,                  -- ID_FQDN
           rfc822      [0] RFC822Name,        -- ID_RFC822_ADDR
           keyID       OCTET STRING }         -- KEY_ID

       Names-I ::= OCTET STRING       -- Используется инициатором IKE

       FQDN ::= IA5String

       RFC822Name ::= IA5String

       PacketFlags ::= BIT STRING {
                   -- при установленном флаге берется значение селектора из пакета, 
                   -- создающего SA, иначе используется значение из записи SPD
           localAddr  (0),
           remoteAddr (1),
           protocol   (2),
           localPort  (3),
           remotePort (4)  }

       SelectorLists ::= SET OF SelectorList

       SelectorList ::= SEQUENCE {
           localAddr   AddrList,