RFC 8586 | Обнаружение петель в сетях доставки контента (CDN)

RFC 8586 | Обнаружение петель в сетях доставки контента (CDN)

Аннотация

Этот документ определяет поле заголовка запроса CDN-Loop для HTTP. Цикл CDN удовлетворяет оперативную потребность, которая возникает, когда HTTP-запрос преднамеренно пересылается между сетями доставки контента (CDN), но затем случайно или злонамеренно перенаправляется обратно в исходный CDN, вызывая бесконечный цикл. Новое поле заголовка может использоваться для идентификации ошибки и завершения цикла.

Скачать оригинальный документ на английском языке RFC 8586 PDF

 

Оглавление

1. Введение
1.1. Отношение к Via
1.2. Условные обозначения и определения
2. Поле заголовка запроса CDN-петли
3. Вопросы безопасности
4. Соображения IANA
5. Ссылки
5.1. Нормативные ссылки
5.2. Информационные ссылки
Адреса авторов

 

1. Введение

В современных развертываниях HTTP-серверов обычно размещают сети доставки контента (CDN) перед исходными серверами, чтобы повысить задержку, воспринимаемую конечными пользователями, снизить эксплуатационные расходы и улучшить масштабируемость и надежность услуг.

Часто более одного CDN используется данным источником. Это происходит по ряду причин, таких как экономия затрат, организация аварийного переключения в случае возникновения проблем в одном CDN или прямое сравнение услуг CDN.

В результате возможно перенаправление CDN, которые могут быть сконфигурированы в «петле» случайно; потому что маршрутизация достигается за счет комбинации правил DNS и пересылки, а конфигурации сайта иногда бывают сложными и управляются несколькими сторонами.

Когда это происходит, это трудно отладить. Кроме того, иногда это не случайно; Циклы между несколькими CDN могут использоваться в качестве вектора атаки (например, см. [loop-attack]), особенно если один CDN непреднамеренно удаляет заголовки обнаружения цикла другого.

Эта спецификация определяет поле заголовка HTTP-запроса CDN-Loop, чтобы помочь обнаруживать такие атаки и аварии среди пересылающих CDN, которые его реализовали; поле заголовка не может быть изменено их клиентами.

 

1.1. Отношение к Via

HTTP определяет поле заголовка Via в Разделе 5.7.1 [RFC7230] для «отслеживания пересылки сообщений, предотвращения циклов запросов и определения возможностей протокола отправителей в цепочке запросов / ответов».

Теоретически, Via может использоваться для идентификации этих петель. Однако на практике это не используется таким образом, потому что некоторые HTTP-серверы используют Via для других целей — в частности, некоторые реализации отключают некоторые функции HTTP / 1.1 при наличии заголовка Via.

 

1.2. Условные обозначения и определения

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119] [RFC8174].

В этой спецификации используется нотация расширенной формы Бэкуса-Наура (ABNF) в [RFC5234] с расширением списка, определенным в разделе 7 [RFC7230], который позволяет компактно определять списки, разделенные запятыми, используя оператор «#» (аналогично как оператор ‘*’ указывает на повторение). Кроме того, он использует правила токена (OWS), uri-host и port из [RFC7230] и правила параметра rule из [RFC7231].

 

2. Поле заголовка запроса CDN-петли

Поле заголовка запроса CDN-Loop предназначено для того, чтобы помочь сети доставки контента определить, когда входящий запрос уже прошел через серверы этой CDN для обнаружения петель.

CDN-Loop = #cdn-info
cdn-info = cdn-id *( OWS «;» OWS parameter )
cdn-id = ( uri-host [ «:» port ] ) / pseudonym
pseudonym = token

Идентификатор cdn идентифицирует CDN, используя имя хоста под своим контролем или псевдоним. Имена хостов являются предпочтительными, чтобы избежать случайных столкновений. Если используется псевдоним, непреднамеренные коллизии более вероятны, и поэтому следует тщательно выбирать значения, чтобы предотвратить их; например, используя общеизвестное значение (такое как распознанное имя рассматриваемого CDN) или сгенерированное значение с достаточной энтропией, чтобы сделать коллизии маловероятными (например, UUID [RFC4122]).

Опционально, cdn-info может иметь разделенные точкой с запятой параметры ключа / значения для размещения дополнительной информации для использования CDN.

Соответствующие сети доставки контента ДОЛЖНЫ добавлять cdn-info в это поле заголовка во все запросы, которые они генерируют или пересылают (создавая поле заголовка при необходимости).

Как и во всех полях заголовка HTTP, определенных с использованием правила «#», поле заголовка CDN-Loop может быть добавлено с помощью значений, разделенных запятыми, или путем создания нового поля заголовка с требуемым значением.

Например:

GET /image.jpg HTTP/1.1
Host: cdn-customer.example
User-Agent: ExampleBrowser/5
CDN-Loop: foo123.foocdn.example, barcdn.example; trace=»abcdef»
CDN-Loop: AnotherCDN; abc=123; def=»456″

Обратите внимание, что синтаксис псевдонима не допускает пробелы, DQUOTE или любые символы «(), / :; <=>? @ [] {}». См. Раздел 3.2.6 [RFC7230]. Также обратите внимание на правила, когда значения параметров должны быть указаны в Разделе 3.1.1 [RFC7231].

Эффективность этого механизма основана на том, что все посредники сохраняют поле заголовка, поскольку удаление (или разрешение его удалить, например, по конфигурации клиента) не позволит использовать его в нисходящих CDN для обнаружения зацикливания. Как правило, неизвестные поля заголовка не удаляются посредниками, но может возникнуть необходимость добавить CDN-Loop в список полей заголовка реализации, которые нельзя удалять ни при каких обстоятельствах. Поле заголовка НЕ ДОЛЖНО использоваться для других целей.

 

3. Вопросы безопасности

Модель угрозы, к которой обращается поле заголовка CDN-Loop, — это клиент, который нападает на поставщика услуг, настраивая цикл пересылки случайно или со злым умыслом. Для его функционирования CDN не могут позволить клиентам изменить или удалить его в своей конфигурации (см. Раздел 2).

Обратите внимание, что CDN, который позволяет клиентам удалять или изменять поле заголовка CDN-Loop (то есть они не реализуют эту спецификацию), остается вектором атаки как на внедряющие, так и не реализующие CDN.

Использование CDN поля заголовка CDN-Loop может раскрыть его присутствие. Например, если CDN A сконфигурирован для пересылки своих запросов в CDN B для данного источника, присутствие CDN B может быть обнаружено, если оно ведет себя по-разному на основании наличия поля заголовка CDN-Loop.

Поле заголовка CDN-Loop может быть сгенерировано любым клиентом, и поэтому его содержимому нельзя доверять. CDN, которые изменяют свое поведение на основе его содержимого, должны гарантировать, что это не станет вектором атаки (например, для отказа в обслуживании).

Можно подписать содержимое поля заголовка (либо поместив подпись непосредственно в содержимое поля, либо используя другое поле заголовка), но такое использование не определено (или не требуется) в данной спецификации.

В зависимости от того, как он используется, CDN-Loop может предоставлять информацию о внутренней конфигурации CDN; например, количество прыжков внутри CDN и имена хостов узлов.

 

4. Соображения IANA

Этот документ регистрирует поле заголовка «CDN-Loop» в реестре «Имена полей заголовка постоянного сообщения».

  • Имя поля заголовка: CDN-Loop
  • Протокол: http
  • Статус: стандартный
  • Ссылка: RFC 8586

5. Ссылки

5.1. Нормативные ссылки

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

5.2. Информационные ссылки

[loop-attack] Chen, J., Jiang, J., Zheng, X., Duan, H., Liang, J., Li, K., Wan, T., and V. Paxson, «Forwarding-Loop Attacks in Content Delivery Networks», February 2016, <http://www.icir.org/vern/papers/cdn-loops.NDSS16.pdf>.

[RFC4122] Leach, P., Mealling, M., and R. Salz, «A Universally Unique IDentifier (UUID) URN Namespace», RFC 4122, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>.

Адреса авторов

Stephen Ludin
Akamai Technologies
Email: sludin@akamai.com

Mark Nottingham
Fastly
Email: mnot@fastly.com

Nick Sullivan
Cloudflare
Email: nick@cloudflare.com