Статус документа
Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа "Internet Official Protocol Standards" (STD 1). Допускается свободное распространение документа.
Тезисы
Протоколы AH и ESP используют порядковые номера для детектирования попыток повторного использования пакетов. В этом документе описано расширение области интерпретации (DOI) для протокола управления защищенными связями и ключами (ISAKMP). Это расширение поддерживает согласование использования традиционных 32-битовых порядковых номеров или расширенных (64 бита) порядковых номеров (ESN) для конкретной защищенной связи AH или ESP.
- AH (Authentication Header) — заголовок идентификации.
- ESP (Encapsulating Security Payload) — инкапсуляция защищенных данных.
- DOI (Internet IP Security Domain of Interpretation) — область интерпретации защиты IP.
- ISAKMP (Internet Security Association and Key Management Protocol) — протокол управления защищенными связями и ключами в Internet.
- ESN (Extended Sequence Number)
- IKE (Internet Key Exchange) - протокол обмена ключами.
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 важно выбрать режим шифрования, который обеспечит достаточную защиту при шифровании обчень большого объема данных с использованием одного ключа. В этом смысле такие алгоритмы, как DES в режиме CBC не подходит для использования с ESN, поскольку с использованием одного ключа DES не следует шифровать более 2^32 блоков в таком режиме. Аналогично, с протоколами ESP и AH следует использовать алгоритмы контроля целостности, обеспечивающие должную защиту при больших объемах передаваемой информации. Во избежание возможных проблем с защитой, порождаемых ограничениями алгоритмов, время жизни SA можно ограничивать по объему информации, защищаемой с использованием одного ключа, до того, как будет достигнут предел ESN в 2^64 пакетов.
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, Март 1997. |
| [AH] | Kent, S., «Идентификационный заголовок IP», RFC 4302, Декабрь 2005 |
| [DOI] | Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 2407, Ноябрь 1998. |
| [ESP] | Kent, S., «Инкапсуляция защищенных данных IP (ESP)», RFC 4303, Декабрь 2005. |
| [IKE] | Harkins, D. и D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, Ноябрь 1998. |
| [ISAKMP] | Maughan, D., Schertler, M., Schneider, M., and J. Turner, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 2408, Ноябрь 1998. |
Дополнительная литература
| [OAKLEY] | Orman, H., «The OAKLEY Key Determination Protocol», RFC 2412, Ноябрь 1998. |
Адрес автора
Stephen Kent
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
USA
Phone: +1 (617) 873-3988
EMail: moc.nbb@tnek