Сервисный центр по ремонту телевизоров в Санкт-Петербурге - вызов мастера на дом.. Почему просто перестал включаться телевизор. Я не поняла почему, отдала на ремонт к вам по квитанции 7932. Мастер после ремонта попросил оставить отзыв, о том устроила ли меня его проделанная работа. прошло две недели, телевизор работает исправно.
RFC: 4302
Оригинал: IP Authentication Header
Предыдущие версии: RFC 1826, RFC 2402
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

Страница 1 из 28

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

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

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

Copyright (C) The Internet Society (2005).

Тезисы

В этом документе описана обновленная версия идентификационного заголовка IP (AH — Authentication Header), который разработан для обеспечения услуг проверки тождественности (идентификации) в IPv4 и IPv6. Этот документ отменяет действие RFC 2402 (ноябрь 1998).

Оглавление

1. Введение

В документе предполагается, что читатель достаточно знаком с терминами и концепциями, изложенными в документе «Архитектура защиты для протокола IP» [Ken-Arch], далее называемом для карткости описанием архитектуры. В частности, читателю следует понимать определения услуг по защите, обеспечиваемых ESP (Encapsulating Security Payload — инкапсуляция защищенных данных) [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 (далее для краткости будет использоваться термин «целостность») без организации специальных соединений и защиты против повторного использования пакетов. Второй, необязательный, сервис может выбираться получателем при создании защищенной связи (SA — Security Association). Протокол по умолчанию требует от отправителя увеличивать порядковые номера для предотвращения повторного использования пакетов, но этот механизм работает только при проверке порядковых номеров на приемной стороне. Для использования расширенных возможностей порядковой нумерации 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].

Страница 1 из 28

2007 - 2022 © Русские переводы RFC, IETF, ISOC.