4. Аудит
Не все системы, поддерживающие AH, реализуют аудит. Однако, если AH встраивается в систему, поддерживающую аудит, реализация AH должна поддерживать аудит и также должна позволять администратору системы включать и отключать аудит для AH. В большинстве случаев гранулярность аудита определяется локально. Однако некоторые события, заносимые в журнал аудита, задаются данной спецификацией и для каждого из этих событий указывается минимальный набор информации, которую следует включать в журнал аудита. В записи можно также включать дополнительную информацию и можно указывать в журнале информацию о других событиях, которые явно не упомянуты в данной спецификации. Получатель не обязан уведомлять отправителя о внесении записей в журнал аудита, поскольку такое требование создавало бы возможность организации атак на отказ служб.
5. Соответствие требованиям
Реализации, которые заявляют о своем соответствии или совместимости с данной спецификацией, должны полностью реализовать синтаксис и обработку AH, описанные здесь, для индивидуального трафика, а также должны полностью выполнять все требования документа по архитектуре защиты [Ken-Arch]. В дополнение к этому, реализации, заявляющие поддержку группового трафика, должны соответствовать всем дополнительным требованиям, заданным для такого трафика. При ручном распределении ключей, используемых для расчета ICV, корректная работа системы предотвращения повторного использования пакетов требует аккуратной поддержки состояния счетчика на передающей стороне при замене ключа, поскольку в этом случае невозможно восстановить работу после переполнения счетчика. Таким образом, совместимым со спецификацией реализациям не следует предоставлять такой сервис для SA с распространением ключей вручную.
Обязательные для реализации алгоритмы, используемые с AH, описаны в отдельном RFC [Eas04], для обеспечения возможности обновления алгоритмов независимо от протокола. Кроме обязательных для AH алгоритмов могут поддерживаться дополнительные алгоритмы.