Соображения безопасности
Протокол COPS предоставляет объект Integrity, который может обеспечить аутентификацию, целостность сообщения, и предотвратить подмену с использованием записи предыдущих сообщений. Все реализации COPS должны поддерживать работу с объектом COPS Integrity. Чтобы гарантировать, что клиент (PEP) обменивается с корректным сервером политики (PDP), необходима аутентификация PEP и PDP, с использованием общего ключа (secret), и согласованная проверка того, что соединение является корректным. Ключ используется в сочетании с содержимым сообщения COPS, чтобы вычислить дайджест сообщения, который является частью объекта Integrity. Объект Integrity затем используется для проверки всех сообщений COPS, посланных через TCP-соединение между PEP и PDP.
Объект COPS Integrity предоставляет также порядковый номер, чтобы исключить атаки откликов. PDP выбирает начальный порядковый номер для PEP, а PEP выбирает начальный порядковый номер для PDP. Эти начальные номера затем инкрементируются каждым последующим сообщением, пересланным через данное соединение в соответствующем направлении. Исходный порядковый номер должен быть выбран так, чтобы для заданного ключа в процессе монотонного приращения не получалось идентичных номеров.
Безопасность обмена между клиентом (PEP) и сервером (PDP) может быть обеспечена за счет IP Security [IPSEC]. В этом случае, заголовок аутентификации IPSEC (AH) должен использоваться для проверки правильности соединения; кроме того, безопасное поле данных IPSEC ESP (Encapsulation Security Payload) может использоваться для реализации, как безопасности, так и конфиденциальности.
TLS [Transport Layer Security] может использоваться, как для обеспечения соединения, так и для гарантии конфиденциальности.
Тип клиента идентифицирует Client-type приложения, к которому относится сообщение. Значения типа клиента в диапазоне 0x0001-0x3FFF зарезервированы для статуса необходимой спецификации (Specification Required), как это определено [IANA-CONSIDERATIONS]. Эти значения должны быть зарегистрированы IANA и их поведение и применимость должны быть описана в документе расширения COPS.
Значения типа клиента (Client-type) в диапазоне 0x4000 - 0x7FFF зарезервированы для частного использования, как это определено в [IANA-CONSIDERATIONS].
Значения типа клиента в диапазоне 0x8000 - 0xFFFF относятся к типу "первым пришел - первым обслужен", как это определено в [IANA-CONSIDERATIONS].
Некоторые маршрутизаторы могут реализовать безопасные процедуры, которые зависят от заголовка сетевого уровня, положение которого фиксировано по отношению к заголовку канального уровня. Базовая инкапсуляция MPLS подразумевает введение прослойки между заголовком канального и сетевого уровня. Это может вызвать отказ в работе некоторых процедур безопасности. Метка MPLS имеет свое значение благодаря соглашению между LSR, который записывает метку в стек (источник метки), и LSR, который интерпретирует метку (получатель метки). Если помеченный пакет получен от непроверенного отправителя, или если некоторая метка получена от LSR, которому она не посылалась, тогда пакеты могут маршрутизоваться некорректным образом.
В этом разделе идентифицируются угрозы, к которым LDP может быть чувствителен и обсуждаются средства, которые могут уменьшить эти угрозы.
На практике эти расширения RSVP не предлагают никакой безопасности в дополнение к RFC 2205 [1]. Однако имеется небольшое изменение в доверительной модели. Трафик обычной RSVP сессии может быть отфильтрован по адресам отправителя и получателя, а также по номерам портов. В этой спецификации, отбор происходит только на основе входных меток. По этой причине администрация может пожелать ограничить область, где могут прокладываться LSP-туннели. Это может быть выполнено путем фильтрации по разным портам, чтобы препятствовать воздействию на сообщение RSVP path со стороны объекта SESSION типа LSP_TUNNEL_IPv4 (7) или LSP_TUNNEL_IPv6 (8).
В данном документе не вводится никаких дополнительных мер безопасности за исключением рассмотренных в [RFC3212] или [RFC3209]. Соображения безопасности, упомянутые в [RFC3212] или [RFC3209], относятся к специфическим протокольным формам GMPLS, смотри [RFC3473] и [RFC3472].
Безопасность сообщения RSVP описана в [RFC2747] и обеспечивает целостность сообщения и аутентификацию узла. Для сообщений, передаваемых шаг-за-шагом, в данном документе не предлагается новых возможностей.
В данном документе вводится возможность посылки сообщения уведомления (Notify) вне схемы шаг-за-шагом. Это мешает реализовать модель целостности и аутентификации RSVP. В случае, когда RSVP генерирует сообщения из-конца-в-конец и желательна безопасность, предоставляемая [RFC2747], можно использовать стандарт IPSEC. При использовании IPSEC для обеспечения аутентификации сообщений применяется следующее:
Селекторы
Селектор идентифицирован RSVP сообщениями, которыми обмениваются узлы, не являющиеся смежными. Узлы идентифицируются IP-адресами отправителя и получателя, используемыми в сообщениях Notify.
Режим
Передаваемая информация, как правило, не является конфиденциальной, поэтому шифрование необязательно. Можно использовать AH [RFC2402] или ESP [RFC2406]. Если используется ESP, IP-адрес отправителя должен быть сравнен с адресом, используемым при управлении ключевым обменом.
Управление ключами
Чтобы разрешить детектирование откликов, должна использоваться автоматическая система управления ключами, такая как IKE [RFC2409]. Могут использоваться конфигурируемые ключи.
Политика безопасности
Сообщения не должны восприниматься, если они посланы неизвестными узлами.
Идентификация
Механизмы общих ключей должны быть адекватны исходным установкам для небольших сетей. Для крупномасштабных систем следует применять IKE, базирующуюся на сертификатах. Какая бы система не использовалась, она должна каким-то образом быть привязана к IP-адресу отправителя.
Доступность
Многие маршрутизаторы и переключатели поддерживают IPSEC. Для случаев, когда IPSEC недоступна, а безопасность необходима, следует посылать сообщения Notify по схеме шаг-за-шагом.
