RFC: 2475
Оригинал: An Architecture for Differentiated Services
Категория: Информационный
Дата публикации:
Авторы: , , , , ,
Перевод: Николай Малых

RFC 2475, Страница 21 из 22

6.2 Взаимодействие с IPsec и туннелями

Протокол IPsec, как указано в [RFC4303] и [RFC4302], не включает операций с полем DS заголовков IP в криптографические преобразования (в туннельном режиме поле DS внешнего заголовка IP IP IP не шифруется). Следовательно, изменение поля DS в сети не оказывает влияния на сквозную защиту IPsec, поскольку такое изменение не способно дать отрицательный результат при проверке целостности IPsec. В результате IPsec не обеспечивает какой-либо защиты от злонамеренного изменения поля DS (т. е., перехвата и изменения с участием человека — MITM), поскольку такое иземенение не оказывает влияния на уровень сквозной защиты IPsec. В некоторых средах возможность изменения поля DS без влияния на целостность данных IPsec может позволить создание скрытого канала; если требуется предотвратить создание таких каналов или снизить их полосу, домены DS следует настраивать так, чтобы требуемая обработка (например, установка одного значения для всех полей DS в чувствительном трафике) могла выполняться на выходных узлах DS, где трафик выходит из защищенных доменов.

Туннельный режим IPsec обеспечивает защиту для полей DS инкапсулированных заголовков IP. Пакет IPsec в туннельном режиме включает два заголовка IP — внешний заголовок, подставляемый на входе туннеля, и внутренний (инкапсулированный) заголовок от инициатора пакета. Когда туннель IPsec проходит (полностью или частично) через сети с дифференциацией услуг, промежуточные узлы оперируют с полем DS внешнего заголовка. На выходе из туннеля IPsec внешние заголовки удаляются и пакет пересылается (если нужно) с использованием внутреннего заголовка. Если внутренний заголовок IP не обрабатывается входным узлом DS при выходе из туннеля в домен DS, выходной узел туннеля является входным узлом DS для выходящего из туннеля трафика и, следовательно, для него должно осуществляться соответствующее кондиционирование (см. параграф 6.1). Если обработка IPsec включает достаточно строгую криптографическую проверку целостности инкапсулированного пакета (достаточность определяется локальной политикой безопасности), выходной узел туннеля может без опасений предполагать, что поле DS во внутреннем заголовке не изменилось по сравнению со значением на входе в туннель. Это позволяет выходному узлу туннеля, находящемуся в одном домене DS со входным узлом туннеля, без опасений относиться к пакетам, прошедшим такую проверку целостности, как к пакетам, полученным от узла в том же домене DS, избавляя входной узел домена DS от необходимости кондиционирования трафика, которое требуется в противном случае. Важным следствием этого является то, что незащищенные каналы, являющиеся внутренними по отношению к домену DS, могут быть защищены с помощью достаточно надежного туннеля IPsec.

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

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

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

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

Страница 21 из 22

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