О документе
Рабочая группа по сетям J. Klensin
Запрос комментариев: 4084 Май 2005
BCP: 104
Категория: Лучшая современная практика
Терминология для описания интернет-подключения
1.1. Проблема и требование
Разные ISP и другие поставщики предлагают широкий спектр продуктов,
обозначаемых как «Интернет» или «доступ к Интернету». Эти продукты
предлагают разные виды функциональности, и вследствие этого некоторые
могут подходить для определённых пользователей и способов применения,
но не для других. Например, услуга, предоставляющая доступ только к Web
(в данном контексте — той части Интернета, которая доступна через
протоколы HTTP и HTTPS), может подходить тому, кто заинтересован
исключительно в просмотре Web и почтовых услугах на основе Web. Она не
будет подходить тому, кому необходимо загружать файлы или чаще
пользоваться электронной почтой. И она, вероятно, будет ещё менее
подходить тому, кому необходимо эксплуатировать серверы для других
пользователей, кому требуются возможности виртуальной частной сети
(VPN) или другой защищённый доступ к удалённому офису либо кому
необходимо синхронизировать почту для автономного использования.
Недавние и быстро развивающиеся изменения в среде электронной почты
Интернета привели к дополнительным ограничениям на отправку и
получение электронной почты. Эти ограничения, большинство из которых
разработано в рамках добросовестных попыток предотвратить
нежелательную почту или бороться с ней, могут вводиться независимо от
описанных ниже типов услуг и отдельно рассматриваются в разделе 3.
Этот документ описывает только функции, предоставляемые или
разрешённые поставщиком услуг. Он не описывает и не может описывать
функции, проходящие через различное оборудование, предоставленное
пользователем, и поддерживаемые им.
Термины СЛЕДУЕТ (SHOULD), ДОЛЖЕН (MUST) и МОЖЕТ (MAY) в этом документе
пишутся прописными буквами в соответствии с определением в [1].
1.2. Принятие и непейоративная терминология
Предлагаемые здесь определения имеют небольшую ценность, если
поставщики услуг и производители не готовы их принять. Предлагаемые
термины не имеют целью быть пейоративными, несмотря на мнение
некоторых членов сообщества IETF, что некоторые из этих моделей
подключения просто «неработоспособны» или «на самом деле не являются
интернет-услугой». Упоминание в этом документе конкретной услуги или
модели не подразумевает её одобрения, а лишь признаёт нечто, что
существует или может существовать на рынке. Таким образом, описанная
в этом документе Лучшая современная практика относится к терминологии
и информации, которую следует предоставлять пользователю, а не к
типам услуг, которые следует предлагать.
2. Общая терминология
В этом разделе перечислены основные термины IP-услуг. Есть надежда,
что поставщики услуг примут эти термины, чтобы лучше определять услуги
для потенциальных пользователей или клиентов. Термины относятся к
намерению поставщика (ISP), выраженному либо техническими мерами, либо
условиями предоставления услуги. Может быть возможно обойти конкретные
реализации этих характерных типов подключения, но такая свобода в
целом не является намерением поставщика и вряд ли будет поддержана,
если обходные решения перестанут работать.
Термины услуг перечислены в порядке возрастания возможностей, чтобы
достичь «полного интернет-подключения».
o Web-подключение.
Эта услуга предоставляет подключение к Web, то есть к услугам,
поддерживаемым через «Web-браузер» (такой как Firefox, Internet
Explorer, Mozilla, Netscape, Lynx или Opera), особенно к услугам,
использующим протоколы HTTP или HTTPS. Другие услуги, как правило,
не поддерживаются. В частности, может не быть доступа к электронной
почте POP3 или IMAP4, зашифрованным туннелям или другим механизмам
VPN.
Используемые адреса могут быть частными и/или недостижимыми
глобально. Как правило, они динамические (дальнейшее обсуждение
этой терминологии и её последствий см. в обсуждении динамических
адресов в разделе 3) и относительно кратковременные (часы или дни,
а не месяцы или годы). Эти адреса часто объявляются как
«динамические» тем, кто ведёт списки коммутируемых или динамических
адресов. Поставщик может применять к соединениям фильтрующий
Web-прокси; этот прокси может изменять и перенаправлять URL на
сайты, отличные от сайта, первоначально указанного пользователем
или во встроенной ссылке.
o Подключение только клиента, без публичного адреса.
Эта услуга предоставляет доступ к Интернету без поддержки серверов
или большинства одноранговых функций. IP-адрес, назначаемый клиенту,
является динамическим и обычно назначается из непубличного
адресного пространства. Серверы и одноранговые функции обычно не
поддерживаются системами преобразования сетевых адресов (NAT),
необходимость которых обусловлена использованием частных адресов.
(Более точная классификация типов NAT, приведённая в [2], в
некоторой степени ортогональна этому документу, однако она может
предоставляться как дополнительные термины, как описано в разделе
4.)
Фильтрующие Web-прокси распространены при таком типе услуг, и
поставщику СЛЕДУЕТ (SHOULD) указывать, присутствует ли такой прокси.
o Только клиент, публичный адрес.
Эта услуга предоставляет доступ к Интернету без поддержки серверов
или большинства одноранговых функций. IP-адрес, назначаемый клиенту,
находится в публичном адресном пространстве. Обычно он номинально
является динамическим или иным образом может измениться, но может
не изменяться месяцами. Большинство VPN и сходных подключений будут
работать с этой услугой. Поставщик может запрещать использование
серверных функций либо юридическими (договорными) ограничениями,
либо фильтрацией входящих попыток подключения.
Фильтрующие Web-прокси необычны при таком типе услуг, и поставщику
СЛЕДУЕТ (SHOULD) указывать, если такой прокси присутствует.
o Интернет-подключение с межсетевым экраном.
Эта услуга предоставляет доступ к Интернету и поддерживает
большинство серверов и большинство одноранговых функций с одним или
(обычно) несколькими статическими публичными адресами. Она сходна с
«Полным интернет-подключением», описанным ниже, и применимы все
описанные там оговорки и ограничения. Однако в рамках этой услуги
между клиентом и публичным Интернетом размещается управляемый
поставщиком «межсетевой экран», обычно по запросу клиента и за
дополнительную плату по сравнению с услугами без межсетевого
экрана. Обычно в силу договорных соглашений с клиентом это может
приводить к блокированию некоторых услуг.
Другие услуги могут перехватываться прокси, механизмами фильтрации
содержимого или шлюзами приложений. Поставщику СЛЕДУЕТ (SHOULD)
указывать, какие услуги блокируются и какие перехватываются или
изменяются иными способами.
В большинстве регионов такой вариант услуги предлагается как
дополнительная платная опция к тому, что иначе было бы Полным
интернет-подключением. Он отличается от приведённых выше моделей
тем, что любые услуги фильтрации или блокирования в конечном счёте
выполняются по запросу клиента, а не навязываются как ограничения
услуги.
o Полное интернет-подключение.
Эта услуга предоставляет пользователю полное интернет-подключение
с одним или несколькими статическими публичными адресами.
Динамические адреса, существующие достаточно долго, чтобы сделать
эксплуатацию серверов практически осуществимой без записей DNS с
высокой динамичностью, возможны при условии, что для третьих сторон
они не характеризуются как «динамические».
Фильтрующие Web-прокси, прокси перехвата, NAT и другие навязываемые
поставщиком ограничения на входящие или исходящие порты и трафик
несовместимы с таким типом услуги. Серверы в подключённой локальной
сети клиента обычно считаются нормальным явлением. Единственными
совместимыми ограничениями являются ограничения пропускной
способности и запреты на злоупотребление сетью или незаконную
деятельность.
3. Вопросы фильтрации или безопасности и терминология
Как упоминалось во Введении, стремление контролировать или ограничить
нежелательный сетевой трафик привело к дополнительным ограничениям
поведения и возможностей интернет-услуг. Такой нежелательный трафик
может включать нежелательную почту различных типов (включая «спам»),
черви, вирусы и их воздействие, а в некоторых случаях — конкретное
содержимое.
В целом существенные ограничения наиболее вероятны при Web-подключении
и услугах без публичного адреса, но некоторые текущие рекомендации
применяли бы ограничения на всех уровнях. Некоторые из этих почтовых
ограничений могут предотвращать отправку исходящей почты (кроме как
через серверы, эксплуатируемые ISP для этой цели), могут предотвращать
использование обратных адресов по выбору пользователя и могут даже
предотвращать доступ к хранилищам почты (кроме поставляемых
поставщиком) с помощью протоколов удалённого доступа, таких как POP3
или IMAP4. Поскольку у пользователей могут быть обоснованные причины
для доступа к удалённым файловым службам, удалённым серверам отправки
почты (или, по меньшей мере, для использования предпочитаемых ими
адресов электронной почты из нескольких мест) и для доступа к удалённым
хранилищам почты (опять же, почти необходимого условия при
использовании одного адреса), важно, чтобы поставщики раскрывали,
какие услуги они предоставляют, а также фильтры и условия, которые
они вводят.
Несколько ключевых вопросов фильтрации электронной почты имеют особую
важность.
o Динамические адреса.
Ряд систем, включая несколько систем «чёрных списков», основан на
предположении, что большинство нежелательной электронной почты
исходит от систем с динамическими адресами, особенно систем
коммутируемого доступа и домашних широкополосных систем. Поэтому
они пытаются предотвратить использование этих адресов для отправки
почты или выполнения некоторых других услуг, кроме как через
системы поставщика, назначенные для этой цели.
Для выявления систем с динамическими адресами используются разные
методы, включая объявление поставщиком таких адресов операторам
чёрных списков, эвристики, использующие определённые диапазоны
адресов, и проверку доменных имён обратного отображения, чтобы
установить, содержат ли они характерные строки, такие как «dsl» или
«dial». В некоторых случаях отсутствие DNS-адреса обратного
отображения принимается как указание на то, что адрес является
«динамическим». (Запрет соединений на основании отсутствия записи
DNS обратного отображения был методом, разработанным для FTP-серверов
много лет назад; было установлено, что он имеет довольно высокую
частоту отказов: как запрещая допустимые попытки подключения, так и
не предотвращая недопустимые.) Поставщикам услуг СЛЕДУЕТ (SHOULD)
описывать, что они делают в этой области для входящего и исходящего
трафика сообщений, и пользователям следует знать, что если адрес
объявлен как «динамический», использовать его для отправки почты
произвольной системе может быть невозможно, даже если в остальном
предоставляется Полное интернет-подключение.
o Непубличные адреса и NAT.
Системы NAT, используемые для отображения между частным и публичным
адресными пространствами, могут поддерживать соединения с удалёнными
почтовыми системами для исходящей и входящей почты, но условия
предоставления услуг часто запрещают использование систем, не
поставляемых поставщиком подключения, и запрещают эксплуатацию
«серверов» (обычно без точного определения) на клиентском
подключении.
o Фильтрация исходящих портов поставщиком.
Другой распространённый приём заключается в блокировании соединений с
серверами, не находящимися под контролем провайдера, путём блокирования
TCP-«портов», обычно используемых для функций обмена сообщениями. У разных
провайдеров разные представления об этом. Некоторые запрещают своим клиентам
обращаться к внешним SMTP-серверам для отправки сообщений, но разрешают
использовать протокол передачи сообщений ([3]) с аутентификацией отправителя.
Другие пытаются блокировать все исходящие протоколы, связанные с обменом
сообщениями, включая протоколы удалённого получения почты; однако это менее
распространено в службах с публичными адресами, чем в службах, зависящих от
частных адресов и NAT. Если присутствует фильтрация такого типа, особенно в
службах «Только клиент, публичный адрес» и «Полная связность с Интернетом»,
провайдер ДОЛЖЕН (MUST) указать этот факт (см. также раздел 4).
Третьи могут перенаправлять исходящий почтовый трафик на собственные
серверы, исходя из того, что это устраняет необходимость перенастраивать
переносные машины при их подключении из другого сетевого местоположения.
Опять же, такое перенаправление ДОЛЖНО (MUST) раскрываться, особенно потому,
что оно может иметь существенные последствия для безопасности и
конфиденциальности.
В более общем случае фильтры, блокирующие часть или всю почту,
отправляемую в удалённые системы (или передаваемую им) (иначе чем через
поддерживаемые провайдером серверы), либо пытающиеся перенаправить этот трафик
на собственные серверы, как обсуждалось выше, становятся обычным явлением и
их СЛЕДУЕТ (SHOULD) раскрывать.
4. Дополнительная терминология
Эти дополнительные термины, хотя и не столь существенные для понимания
предложения службы, как указанные выше, приводятся как дополнительная
информация, которую провайдер службы может выбрать для предоставления в
dополнение к этим общим определениям. Например, потенциальный клиент может
использовать относящиеся к нему термины, чтобы составить перечень конкретных
вопросов.
o Поддержка версий.
Включает ли служба поддержку только IPv4, поддержку как IPv4, так и
IPv6 либо только поддержку IPv6?
o Поддержка аутентификации.
Какие технические механизмы используются службой для установления и,
возможно, аутентификации соединений? Примерами могут быть DHCP без
aутентификации, PPP, RADIUS или перехват HTTP.
o VPN и туннели.
Блокируется или разрешается IPSec? Разрешаются ли другие методы
туннелирования на IP-уровне или ниже него, такие как L2TP? Предпринимаются ли
какие-либо попытки блокировать механизмы туннелирования на уровне приложений,
такие как SSH?
o Поддержка многоадресной рассылки
Имеет ли пользовательская машина доступ к пакетам и службам
многоадресной рассылки?
o Поддержка DNS.
Обязаны ли пользователи использовать DNS-серверы, предоставляемые
провайдером службы, или DNS-запросам разрешено достигать произвольных
серверов?
o Службы, связанные с IP.
Блокируются или разрешаются в целом сообщения ICMP к площадкам конечных
пользователей и от них? Блокируются ли конкретные функции, такие как ping и
traceroute, и, если да, в какой точке сети?
o Поддержка роуминга.
Преднамеренно ли служба включает поддержку IP-роуминга и, если да, как
это определяется? Предусмотрена ли для «широкополосных» подключений какая-либо
схема коммутируемого доступа для резервирования или поездок клиента? Если она
присутствует, имеет ли эта схема полный доступ к почтовым ящикам и т. д.?
o Предоставляемые службы приложений.
Предоставляются ли в составе службы почтовые службы и/или Web-хостинг и
на каких условиях? В перечне почтовых служб следует указать, предоставляются ли
POP3, IMAP4 или Web-доступ, в каких сочетаниях, а также какие типы служб
aутентификации и конфиденциальности поддерживаются или требуются для каждого из
них.
o Использование и блокирование исходящих служб приложений.
Блокирует ли служба использование SMTP или передачу почты не на свои
серверы либо перехватывает такие передачи и направляет их на свои серверы?
Ограничивают ли её серверы пользователя использованием её доменных имён в
исходящей электронной почте? (Относительно электронной почты в частности также
см. раздел 3 выше.) Поддерживается или блокируется команда FTP PASV?
Применяются ли блокировки или перехваты к другим механизмам совместного
использования либо передачи файлов, к приложениям для конференций или к частным
службам приложений?
В более общем случае провайдеру следует указывать любые действия службы
по блокированию, ограничению или изменению назначения исходящего использования
(т. е. использования служб, не поставляемых провайдером или не находящихся в
сети провайдера) служб приложений.
o Блокирование входящих служб приложений.
Помимо вопросов, обусловленных динамическим или частным адресным
пространством (когда оно имеется), предпринимает ли служба какие-либо другие
меры, специально ограничивающие соединения, которые могут устанавливаться с
оборудованием, эксплуатируемым клиентом? В частности, запрещены ли входящие
SMTP, HTTP или HTTPS, FTP либо различные одноранговые или другие соединения
(возможно, включая приложения, специально не распознаваемые провайдером) и,
если да, какие именно?
o Фильтрация содержимого приложений.
Службе следует объявить, предоставляет ли она фильтрацию или защиту от
червей или атак отказа в обслуживании, направленных против её клиентов,
фильтрацию вирусов и спама для её почтовых служб (если таковые имеются),
недискреционную фильтрацию содержимого или фильтрацию «родительского контроля»
и так далее.
o Прослушивание и перехват.
Службе СЛЕДУЕТ (SHOULD) указывать, подлежит ли проходящий через неё
трафик законному перехвату и будет ли провайдер предпринимать упреждающую
попытку уведомить пользователя о таком перехвате, когда такое уведомление
законно. Аналогичные вопросы можно задать о данных трафика, которые хранятся
для возможного использования правоохранительными органами.
5. Соображения безопасности
Этот документ посвящён терминологии, а не протоколам, поэтому он не
поднимает каких-либо особых вопросов безопасности. Однако если предложенный
тип терминологии будет широко принят, может стать проще выявлять связанные с
безопасностью ожидания для конкретных хостов, LAN и типов соединений.
6. Благодарности
Этот документ был вдохновлён перепиской по электронной почте с Vernon
Schryver, Paul Vixie и Nathaniel Bornstein. Хотя предложения выработать такие
определения существовали много лет, та переписка убедила автора, что наконец
пришло время вынести на обсуждение исходный вариант, чтобы посмотреть, сможет
ли IETF действительно продвинуть его дальше. Harald Alvestrand, Brian
Carpenter, George Michaelson, Vernon Schryver и другие внесли несколько
предложений к первоначальному черновику, в результате чего были уточнены
формулировки второго, а Stephane Bortzmeyer, Brian Carpenter, Tony Finch, Susan
Harris, David Kessens, Pekka Savola и Vernon Schryver внесли весьма полезные
предложения, которые были включены в последующие версии. Susan Harris также
исключительно внимательно прочитала предпоследнюю версию, за что выражается
большая признательность, как и за редакторские предложения RFC Editor.
7. Информационные ссылки
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
December 1998.