9.2.2. Изменения поля ECN в туннелях IPsec
Если поле ECN неподобающим образом меняется в туннеле IPsec и эти изменения детектируются на выходе туннеля, получение пакета, не удовлетворяющего условиям для данной SA протоколируется системой аудита. Реализация может создавать записи аудита с учетом некорректных пакетов для каждой SA в течение определенного периода вместо создания отдельной записи для каждого некорректного пакета. Во все записи аудита следует включать заголовки по крайней мере из одного некорректного пакета, но не требуется включать заголовки всех пакетов, представленных в записи.
9.2.3. Комментарии к поддержке IPsec
Приведенные здесь комментарии к двум частям этого документа были получены при просмотре документа членами рабочей группы IPsec. В этом параграффе рассматриваются полученные комментарии и даются объяснения причин того, что предложенные изменения не были включены в документ.
В первом комментарии отмечалось, что настройка конфигурации на уровне узла проще в реализации, нежели настройка на уровне SA. После серьезного обдумывания и дискуссий исходное предложение о настройке конфигурации на уровне узла перестало казаться хорошей идеей. Причина заключается в том, что осведомленность о ECN становится все шире в IPsec — многие знающие о ECN реализации IPsec осознают, что они взаимодействуют как с поддерживающими ECN конечными точками туннелей IPsec, так и с точками, не понимающими ESNESNESN. В такой среде при настройке конфигурации на уровне узла остается лишь запретить использование ECN для всех туннелей IPsec, которые не являются нужным выходом.
Во втором комментарии ряд обозревателей отметил, что согласование SA является достаточно сложным и его добавление — нетривиальная задача. Другие предлагали в качестве альтернативы использование ICMP после огранизации туннеля. Поддержка согласования SA в этом документе указана, как опциональная и останется таковой — разработчики сами принимают решение о реализации этой опции. Авторы надеются, что приведенные здесь аргументы будут полезны в разных ситуациях. Если эти рекомендации не будут использованы на практике, они могут быть удалены на последующих этапах процесса стандартизации. Использование ICMP для согласования ECN после организации туннеля более сложно, нежели расширения согласования атрибутов SA. Некоторые туннели не принимают трафик, адресованный узлу выходной точки туннеля, следовательно, пакеты ICMP нужно будет направлять в какой-то иной адрес — они будут «сканироваться» на выходе туннеля и отбрасываться здесь или у конечного их получателя. Кроме того, ICMP не обеспечивает гарантированной доставки и, следовательно, существует возможность отбрасывания пакетов ICMP, для учета которой потребуется создать дополнительных механизм подтверждений и повторов передачи. Опциональное расширение существующего механизма согласования SA представляется более эффективным решением.
9.3. Пакеты IP, инкапсулированные в пакеты других протоколов
При инкапсуляции пакетов IP в пакеты других протоколов возникают другие вопросы, связанные с ECN. Такие ситуации возникают для MPLS [MPLS], GRE [GRE], L2TP [L2TP] и PPTP [PPTP]. Для этих протоколов не возникает конфликта с ECN — дело в том, что ECN просто не может использоваться внутри туннеля, пока код ECN не может быть включен в заголовок инкапсулирующего протокола. Выполнены начальные разработки по встраиванию ECN в MPLS, а предложения по встраиванию ECN в GRE, L2TP или PPTP будут рассматриваться по мере их появления.