О документе
Global Routing Operations D. Plonka
Network Working Group University of Wisconsin
Request for Comments: 4085 June 2005
BCP: 105
Category: Best Current Practice
Встраивание глобально маршрутизируемых интернет-адресов считается вредным
1. Введение
Некоторые производители бытовой электроники и сетевого оборудования,
к сожалению, решили встраивать или «жёстко кодировать» глобально
маршрутизируемые адреса Internet Protocol в микропрограммное обеспечение
своих продуктов. Эти встроенные IP-адреса обычно являются отдельными
IP-адресами серверов или префиксами IP-подсетей. Поэтому они иногда
используются как идентификаторы служб, на которые направляются
незапрошенные запросы, или как идентификаторы подсетей, задающие
множества интернет-адресов, которые данный продукт каким-либо образом
обрабатывает специально.
Одним из недавних примеров было встраивание глобально маршрутизируемого
IP-адреса сервера Network Time Protocol в микропрограммное обеспечение
сотен тысяч интернет-хостов, которые в настоящее время эксплуатируются
по всему миру. Эти хосты преимущественно, но не обязательно, ограничены
недорогими маршрутизаторами и промежуточными устройствами для личного
или домашнего использования. В другом случае префиксы IP-адресов,
которые ранее были зарезервированы Internet Assigned Numbers Authority
(IANA), были встроены в маршрутизаторный продукт, чтобы он мог
автоматически отбрасывать пакеты, у которых, по-видимому, недействительные
исходные IP-адреса.
Такое «жёсткое кодирование» глобально маршрутизируемых IP-адресов как
идентификаторов в микропрограммном обеспечении хоста создаёт существенные
проблемы для функционирования Интернета и управления его адресным
пространством.
По всей видимости, такая практика возникла как попытка упростить
конфигурирование IP-хостов посредством предварительной загрузки в хосты
IP-адресов. Продукты, опирающиеся на такие встроенные IP-адреса, поначалу
могут казаться удобными для разработчика продукта и его оператора или
пользователя, но это сомнительное преимущество достигается за счёт
других участников интернет-сообщества.
Этот документ осуждает практику встраивания ссылок на уникальные,
глобально маршрутизируемые IP-адреса в интернет-хосты, описывает
некоторые возникающие вследствие этого проблемы и рассматривает
выбранные альтернативы. Он также напоминает интернет-сообществу о
эфемерной природе уникальных, глобально маршрутизируемых IP-адресов;
назначение и использование IP-адресов в качестве идентификаторов носит
временный характер и поэтому не следует использовать в фиксированных
конфигурациях.
2. Проблемы
Встраивание IP-адресов в продукты привело к тому, что всё большее число
интернет-хостов стало зависеть от единственной центральной интернет-службы.
Это может привести к отказу службы, когда совокупная нагрузка превышает
возможности этой службы. Когда фиксированные адреса встраиваются
во всё большее количество клиентских IP-хостов, эта практика прямо
противоречит замыслу иерархически развёртываемых служб, которые в ином
случае были бы устойчивыми решениями.
Надёжность, масштабируемость и производительность многих интернет-служб
требуют, чтобы совокупность пользователей не обращалась к службе
непосредственно по её IP-адресу. Вместо этого они обычно полагаются на
уровень косвенного обращения, предоставляемый Domain Name System, RFC
2219 [6]. При надлежащем использовании DNS позволяет оператору службы
переконфигурировать ресурсы для обслуживания и выполнять балансировку
нагрузки без участия пользователей и без необходимости изменения
конфигурации в клиентских хостах. Например, один распространённый метод
балансировки нагрузки использует несколько DNS-записей с одним и тем же
именем; набор возвращаемых ответов циклически чередуется при
последовательных запросах. Получив такой ответ на запрос, резолверы
обычно пробуют ответы по порядку, пока один из них не завершится успехом,
что позволяет оператору распределять нагрузку пользовательских запросов
между набором серверов с отдельными IP-адресами, которые, как правило,
остаются неизвестными пользователю.
Встраивание глобально уникальных IP-адресов обременяет блоки IP-адресов,
в которых они находятся, уменьшая полезность и мобильность этих блоков
IP-адресов и увеличивая стоимость эксплуатации. Незапрошенный трафик
может продолжать доставляться на встроенный адрес ещё долго после того,
как IP-адрес или блок был переназначен и более не размещает службу, для
которой предназначался этот трафик. Примерно в 1997 году авторы RFC 2101
[7] сделали следующее наблюдение:
Из-за динамического выделения адресов и всё более частой перенумерации
сетей временная уникальность адресов IPv4 более не гарантируется
глобально, что ставит под серьёзное сомнение их использование в
качестве идентификаторов.
Когда IP-адреса встраиваются в конфигурацию множества интернет-хостов,
блоки IP-адресов оказываются обременены историей их использования. Это
может препятствовать возможности Internet Assigned Numbers Authority
(IANA) и иерархии Internet Registry (IR) полезно перераспределять блоки
IP-адресов. Аналогично, чтобы облегчить повторное использование IP-адресов,
RFC 2050 [1] рекомендует поставщикам интернет-услуг (ISPs) рассматривать
назначения адресов как «займы».
Поскольку потребители не обязательно имеют опыт эксплуатации
интернет-хостов, нельзя полагаться на то, что они исправят проблемы,
если и когда те возникнут. Поэтому значительная ответственность лежит на
изготовителе или поставщике интернет-хоста: не встраивать IP-адреса
способами, вызывающими вышеупомянутые проблемы.
3. Рекомендации
Разработчикам интернет-хостов и маршрутизаторов, включая изготовителей
сетевых продуктов, не следует предполагать, что их продукты будут
развёртываться и использоваться только в единственном глобальном
Интернете, который они наблюдают сегодня. Множество частных или будущих
межсетевых объединений, в которых будут использоваться эти продукты,
могут не позволять этим хостам устанавливать связь с произвольными
хостами в глобальном Интернете. Поскольку режимы отказа продукта,
возникающие вследствие неизвестной будущей межсетевой среды, не могут
быть полностью исследованы, следует избегать предположений относительно
долговечности нашего нынешнего Интернета.
Следующие рекомендации представлены как лучшая практика на сегодняшний
день.
3.1. Отключение неиспользуемых возможностей
Поставщикам следует по умолчанию отключать ненужные возможности
в своих продуктах. Это особенно верно для возможностей, генерирующих
незапрошенный интернет-трафик. Таким образом, эти хосты будут
консервативны в отношении создаваемого ими незапрошенного
интернет-трафика. Например, одним из наиболее распространённых
применений встроенных IP-адресов было жёсткое кодирование в продуктах
адресов широко известных общедоступных серверов Simple Network Time
Protocol (SNTP RFC 2030 [8]). Однако только небольшая доля пользователей
получит пользу от того, что эти продукты имеют некоторое представление о
текущих дате и времени.
3.2. Предоставление пользовательского интерфейса для IP-возможностей
Поставщикам следует предоставлять интерфейс оператора для каждой
возможности, генерирующей незапрошенный интернет-трафик. Яркий пример
таков: резолверу Domain Name System следует иметь интерфейс, позволяющий
оператору либо явно задать выбор серверов, либо включить стандартный
автоматизированный протокол конфигурирования, такой как DHCP,
определённый RFC 2132 [9]. Эти возможности следует изначально отключать
в интерфейсе оператора, а последующее включение этих возможностей следует
сопровождать предупреждением оператора о существовании этой возможности.
Это повысит вероятность того, что владелец или оператор продукта сможет
участвовать в определении и смягчении проблем при их возникновении.
RFC 2606 [2] определяет зарезервированные IANA домены «example.com»,
«example.net» и «example.org» для использования в примерах конфигураций
и документации. Они являются кандидатами для использования в документации
пользовательского интерфейса.
3.3. Использование доменных имён как идентификаторов служб
Интернет-хостам следует использовать Domain Name System для
определения IP-адресов, связанных с необходимыми им интернет-службами.
При использовании доменных имён в качестве идентификаторов служб в
конфигурациях развёрнутых интернет-хостов разработчикам и поставщикам
рекомендуется вводить имена служб. Эти имена следует размещать в домене,
который они либо контролируют, либо имеют разрешение использовать по
соглашению с его оператором (например, для общедоступных служб,
предоставляемых интернет-сообществом). Обычно это делается путём добавления
к доменному имени префикса, специфичного для службы.
Например, поставщик с именем «Example, Inc.» и доменом «example.com» мог
бы настроить свой продукт для поиска своего SNTP-сервера по имени
«sntp-server.config.example.com» или даже по имени, специфичному для
продукта и версии, такому как «sntp-
server.v1.widget.config.example.com». Здесь пространство имён
«config.example.com» выделено для конфигурации продукта этого поставщика,
при этом поддомены вводятся по мере необходимости. Такие специализированные
доменные имена позволяют осуществлять постоянное обслуживание и
переконфигурирование служб для их клиентских хостов и могут содействовать
непрерывному измерению использования службы в течение срока службы
продукта.
Альтернативой изобретению специфичных для поставщика соглашений об
именовании доменов для идентификаторов служб продукта является
использование записей ресурсов (RR) SRV, определённых RFC 2782 [10].
Записи SRV являются универсальным типом RR, использующим специфичный для
службы префикс в сочетании с базовым доменным именем. Например,
поддерживающий SRV клиент SNTP мог бы обнаружить предложенный Example,
Inc. сервер NTP, выполнив запрос типа SRV для поиска «_ntp._udp.example.com».
Однако обратите внимание, что простое жёсткое кодирование идентификаторов
служб в виде DNS-имён вместо IP-адресов не является панацеей. Записи в
пространстве доменных имён также эфемерны и могут менять владельцев по
различным причинам, включая приобретения и судебные разбирательства.
Поэтому разработчикам и поставщикам следует исследовать потенциальные
режимы отказа продукта, возникающие вследствие утраты административного
контроля над данным доменом по какой бы то ни было причине.
3.4. Использование специализированных зарезервированных IP-адресов, когда они доступны
В конфигурациях по умолчанию, документации и примерах конфигураций для
интернет-хостов следует использовать интернет-адреса, находящиеся
в специальных блоках, зарезервированных для этих целей, а не уникальные,
глобально маршрутизируемые IP-адреса. Для IPv4 RFC 3330 [3] указывает,
что блок 192.0.2.0/24 назначен для использования в документации и
примерах кода. Префикс глобального одноадресного IPv6-адреса
2001:DB8::/32 аналогично зарезервирован для целей документации RFC 3849
[4]. Частные интернет-адреса, определённые RFC 1918 [5], не следует
использовать для таких целей.
3.5. Обнаружение и использование локальных служб
Поставщикам служб и операторам корпоративных сетей следует объявлять
идентичности подходящих локальных служб, таких как NTP. Очень часто эти
службы существуют, но отсутствуют объявление и автоматизированное
конфигурирование их использования. Например, протокол DHCP, определённый
RFC 2132 [9], позволяет настроить сервер для ответа на клиентские запросы
об идентификаторах служб. Когда локальные службы, включая NTP, доступны,
но не повсеместно объявляются с использованием таких распространённых
протоколов, разработчики с большей вероятностью будут развёртывать
специальные механизмы инициализации, которые без необходимости опираются
на центральные службы.
3.6. Недопущение упоминания IP-адресов служб
Операторам, предоставляющим публичные службы в глобальном Интернете, таким как участники сообщества NTP, следует считать явное объявление IP-адресов публичных служб устаревшим. Эти адреса являются кратковременными. Поэтому их широкое цитирование в индексах публичных служб препятствует возможности переконфигурировать службу, когда это необходимо для реагирования на непредвиденный рост трафика и вышеупомянутые проблемы.
4. Соображения безопасности
Встраивание или «жёсткое кодирование» IP-адресов в конфигурации хоста
часто означает, что применяется основанная на хосте модель доверия и
что интернет-хосту с данным адресом тем или иным образом доверяют. Из-за
кратковременности ролей глобально маршрутизируемых IP-адресов практика
встраивания их в микропрограммное обеспечение продуктов или конфигурации
по умолчанию создаёт риск безопасности, при котором неизвестным сторонам
можно непреднамеренно доверять.
Разработчики интернет-хостов могут испытывать соблазн реализовать в
продукте некий механизм удалённого управления, посредством которого
конфигурацию его интернет-хоста можно изменять без опоры на оператора или
пользователя, взаимодействия с ними или даже их ведома. Это порождает
собственные проблемы безопасности. Если такая схема реализована, её
наличие следует полностью раскрыть заказчику, оператору и пользователю,
чтобы можно было принять информированное решение, возможно в соответствии
с местной политикой безопасности или конфиденциальности. Более того,
существенная вероятность того, что злоумышленники воспользуются таким
механизмом удалённого управления, может полностью свести на нет любую
потенциальную выгоду схемы удалённого управления. Поэтому механизмы
удалённого управления следует по умолчанию отключать, чтобы пользователь
затем мог включать и отключать их.
5. Заключение
Когда развёртывается большое количество однородных интернет-хостов,
особенно важно, чтобы как их разработчики, так и другие члены интернет-
сообщества тщательно оценивали качество реализации хостов и возможность их
переконфигурирования.
Реализаторам служб хостов следует избегать любого использования уникальных
глобально маршрутизируемых IP-адресов в фиксированной части конфигурации
реализации службы. Если требуется предварительно сконфигурированное
состояние, следует позаботиться об использовании подходящего
идентификатора службы и стандартных механизмов для динамического
разрешения идентификатора в IP-адрес. Кроме того, любые такие
идентификаторы следует иметь возможность изменять на месте эксплуатации через
обычный интерфейс команд и управления для службы.
6. Благодарности
Автор благодарит следующих рецензентов за их вклад в этот документ: Paul
Barford, Geoff Huston, David Meyer, Mike O'Connor, Michael Patton, Tom
Petch и Pekka Savola. Harald Alvestrand, Spencer Dawkins, Ted Hardie,
David Kessens и Thomas Narten предоставили ценные отзывы в ходе
рассмотрения AD и IESG.
7.1. Нормативные ссылки
[1] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J.
Postel, "Internet Registry IP Allocation Guidelines", BCP 12,
RFC 2050, November 1996.
[2] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names",
BCP 32, RFC 2606, June 1999.
[3] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[4] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
[5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
7.2. Информационные ссылки
[6] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
Services", BCP 17, RFC 2219, October 1997.
[7] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC 2101, February 1997.
[8] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 2030, October 1996.
[9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[10] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[11] Plonka, D., "Flawed Routers Flood University of Wisconsin
Internet Time Server", August 2003.
http://www.cs.wisc.edu/~plonka/netgear-sntp/
Приложение A. Предыстория
В мае 2003 года Университет Висконсина обнаружил, что производитель
сетевых продуктов NetGear изготовил и поставил более 700 000 маршрутизаторов
с микропрограммным обеспечением, содержащим жёстко закодированную ссылку на
IP-адрес одного из NTP-серверов Университета: 128.105.39.11, который также
был известен как "ntp1.cs.wisc.edu", публичный NTP-сервер уровня stratum-2.
Из-за этой встроенной фиксированной конфигурации и не связанной с ней ошибки
в клиенте SNTP затронутые продукты иногда демонстрируют режим отказа, при
котором каждый дефектный маршрутизатор создаёт один запрос в секунду,
направленный на IP-адрес 128.105.39.11, и, следовательно, создаёт
крупномасштабный поток интернет-трафика с сотен тысяч адресов источников,
направленный в сеть Университета, что приводит к значительным проблемам
эксплуатации.
Эти дефектные маршрутизаторы широко развёрнуты по всему глобальному
Интернету и, вероятно, будут использоваться ещё многие годы. Поэтому
Университет Висконсина при содействии NetGear создаст новую службу времени
anycast, предназначенную для смягчения ущерба, вызываемого неправильной
работой этих дефектных маршрутизаторов.
Технический отчёт с подробностями этой ситуации доступен во Всемирной
паутине: Flawed Routers Flood University of Wisconsin Internet Time Server
[11].