Аннотация
По мере развития Интернета многие типы устройств рекламировались и продавались как «Internet connectivity» (подключение к Интернету). Поскольку они могут значительно различаться по возможностям, которые они предлагают, по диапазону вариантов и отсутствию какой-либо стандартной терминологии, попытка провести различие между этими услугами вызвала значительную путаницу среди потребителей. В этом документе приводится список терминов и определений, которые могут быть полезны поставщикам, потребителям и, возможно, регуляторам при разъяснении типа и характера предлагаемых услуг.
Скачать оригинальный документ на английском языке RFC 4084 PDF
Оглавление
1. Введение
1.1. Проблема и требование
1.2. Принятие и не уничижительная терминология
2. Общая терминология
2.1. Интернет-соединение
2.2. Только подключение клиента, без публичного адреса
2.3. Только клиент, публичный адрес
2.4. Брэндмауэрное Интернет-соединение
2.5. Полное интернет-соединение
3. Фильтрация или вопросы безопасности и терминология
3.1. Динамические адреса
3.2. Непубличные адреса и NAT
3.3. Фильтрация исходящих портов от провайдера
4. Дополнительная терминология
5. Вопросы безопасности
6. Благодарности
7. Информационные ссылки
Статус этой заметки
В этом документе описываются передовые практики Интернета для интернет-сообщества, а также запрашивается обсуждение и предложения по улучшению. Распространение этой заметки не ограничено.
Уведомление об авторских правах
Copyright (C) Интернет-общество (2005).
1. Введение
1.1. Проблема и требование
Различные интернет-провайдеры и другие провайдеры предлагают широкий спектр продуктов, которые обозначаются как «Интернет» или «Доступ в Интернет». Эти продукты предлагают различные типы функциональных возможностей, и, в результате, некоторые из них могут подходить для определенных пользователей и применений, а не для других. Например, служба, которая предлагает только доступ к Интернету (в этом контексте часть Интернета, доступная по протоколам HTTP и HTTPS), может подойти кому-то, кто исключительно заинтересован в просмотре и в почтовых веб-службах. , Это не подходит для тех, кому нужно загружать файлы или использовать электронную почту чаще. И это, вероятно, будет еще менее подходящим для тех, кому нужно управлять серверами для других пользователей, которым нужны возможности виртуальной частной сети (VPN) или другого защищенного доступа к удаленному офису, или кому нужно синхронизировать почту для автономного использования.
Недавние и быстро развивающиеся изменения в среде электронной почты в Интернете привели к дополнительным ограничениям на отправку и получение электронной почты. Эти ограничения, большинство из которых были разработаны как часть попыток предотвратить нежелательную почту или бороться с ними, могут быть введены независимо от типов услуг, описанных ниже, и обсуждаются отдельно в разделе 3.
Этот документ описывает только функции, предоставляемые или разрешенные поставщиком услуг. Он не определяет и не может определять функции, которые проходят через него и поддерживаются различным пользовательским оборудованием.
Термины СЛЕДУЕТ, ДОЛЖНЫ или МОГУТ быть написаны с заглавной буквы в этом документе, как определено в [1].
1.2. Принятие и не уничижительная терминология
Определения, предложенные здесь, имеют небольшую ценность, если поставщики услуг и поставщики не желают их принимать. Предполагается, что предложенные термины не являются уничижительными, несмотря на убеждение некоторых членов сообщества IETF в том, что некоторые из этих моделей подключения просто «сломаны» или «на самом деле не являются интернет-службой». Упоминание конкретной услуги или модели в этом документе не означает ее одобрения, а только признание того, что существует или может существовать на рынке. Таким образом, наилучшая текущая практика, описанная в этом документе, касается терминологии и информации, которая должна быть предоставлена пользователю, а не типов предлагаемых услуг.
2. Общая терминология
В этом разделе перечислены основные условия предоставления услуг IP. Есть надежда, что поставщики услуг примут эти условия, чтобы лучше определить услуги для потенциальных пользователей или клиентов. Термины относятся к намерению поставщика (ISP), как выражено либо в технических мерах, либо в условиях обслуживания. Может быть возможным обойти конкретные реализации этих характерных типов подключения, но эта свобода, как правило, не является целью поставщика и вряд ли будет поддерживаться, если обходные пути перестают работать.
Условия обслуживания перечислены в порядке возрастания возможностей для достижения «полного подключения к Интернету».
2.1. Интернет-соединение (Web connectivity)
Эта служба обеспечивает подключение к сети, т. е. К службам, поддерживаемым через «веб-браузер» (например, Firefox, Internet Explorer, Mozilla, Netscape, Lynx или Opera), особенно к этим службам, использующим протоколы HTTP или HTTPS. Другие сервисы обычно не поддерживаются. В частности, может отсутствовать доступ к электронной почте POP3 или IMAP4, зашифрованным туннелям или другим механизмам VPN.
Используемые адреса могут быть частными и / или глобально недоступными. Как правило, они динамические (см. Обсуждение динамических адресов в разделе 3 для дальнейшего обсуждения этой терминологии и ее последствий) и относительно недолговечные (часы или дни, а не месяцы или годы). Эти адреса часто объявляются «динамическими» для тех, кто ведет списки коммутируемых или динамических адресов. Поставщик может наложить фильтрующий веб-прокси на соединения; этот прокси-сервер может изменять и перенаправлять URL-адреса на другие сайты, отличные от тех, которые изначально были указаны пользователем или встроенной ссылкой.
2.2. Только подключение клиента, без публичного адреса (Client connectivity only, without a public address)
Эта служба обеспечивает доступ к Интернету без поддержки серверов или большинства одноранговых функций. IP-адрес, назначенный клиенту, является динамическим и типично назначается из непубличного адресного пространства. Серверы и одноранговые функции обычно не поддерживаются системами преобразования сетевых адресов (NAT), которые требуются при использовании частных адресов. (Более точная классификация типов NAT, приведенная в [2], несколько ортогональна этому документу, но они могут быть предоставлены в качестве дополнительных терминов, как описано в Разделе 4.) Фильтрация веб-прокси распространена в этом типе службы, и Поставщик ДОЛЖЕН указать, присутствует ли он или нет.
2.3. Только клиент, публичный адрес (Client only, public address)
Эта служба обеспечивает доступ к Интернету без поддержки серверов или большинства одноранговых функций. IP-адрес, назначенный клиенту, находится в общедоступном адресном пространстве. Обычно он номинально динамичен или иным образом подвержен изменениям, но не может меняться месяцами одновременно. Большинство VPN и аналогичных соединений будут работать с этим сервисом. Поставщик может запретить использование серверных функций либо с помощью юридических (договорных) ограничений, либо путем фильтрации входящих попыток подключения.
Фильтрация веб-прокси редко встречается в этом типе сервиса, и провайдер ДОЛЖЕН указать, присутствует ли он.
2.4. Брэндмауэрное Интернет-соединение (Firewalled Internet Connectivity)
Эта служба обеспечивает доступ к Интернету и поддерживает большинство серверов и большинство одноранговых функций с одним или (обычно) несколькими статическими публичными адресами. Это похоже на «Полное подключение к Интернету», приведенное ниже, и применяются все описанные там квалификации и ограничения. Однако эта служба размещает управляемый провайдером «межсетевой экран» между клиентом и общедоступным Интернетом, как правило, по запросу клиента и за дополнительную плату по сравнению с услугами без брандмауэра. Обычно по договоренности с клиентом это может привести к блокировке некоторых услуг.
Другие сервисы могут быть перехвачены прокси, механизмами фильтрации контента или шлюзами приложений. Поставщик ДОЛЖЕН указать, какие услуги заблокированы, а какие перехвачены или изменены другими способами.
В большинстве областей это соглашение об услугах предлагается в качестве дополнительного, за дополнительную плату, по сравнению с полным подключением к Интернету. Он отличается от моделей, приведенных выше, тем, что любые услуги фильтрации или блокировки в конечном итоге выполняются по запросу клиента, а не налагаются как ограничения на обслуживание.
2.5. Полное интернет-соединение (Full Internet Connectivity)
Эта служба обеспечивает пользователю полное подключение к Интернету с одним или несколькими статическими общедоступными адресами. Динамические адреса, которые достаточно долговечны, чтобы сделать работающие серверы практичными без высокодинамичных записей DNS, возможны при условии, что они не охарактеризованы как «динамические» для третьих сторон.
Фильтрация веб-прокси, прокси-серверов перехвата, NAT и других ограничений, налагаемых провайдером на входящие или исходящие порты и трафик, несовместимы с этим типом услуг. Серверы в подключенной клиентской локальной сети обычно считаются нормальными. Единственными совместимыми ограничениями являются ограничения полосы пропускания и запреты на злоупотребление сетью или незаконные действия.
3. Фильтрация или вопросы безопасности и терминология
Как упоминалось во введении, усилия по контролю или ограничению нежелательного сетевого трафика привели к дополнительным ограничениям поведения и возможностей интернет-сервисов. Такой нежелательный трафик может включать нежелательную почту различного типа (включая «спам»), червей, вирусы и их влияние, а в некоторых случаях — конкретный контент.
В целом, существенные ограничения, скорее всего, будут встречаться с подключением к Интернету и службами, не имеющими публичного адреса, но некоторые текущие рекомендации будут применять ограничения на всех уровнях. Некоторые из этих почтовых ограничений могут препятствовать отправке исходящей почты (кроме как через серверы, управляемые интернет-провайдером для этой цели), могут препятствовать использованию обратных адресов по выбору пользователя и даже могут препятствовать доступу к почтовым репозиториям (кроме тех, которые предоставляются поставщиком). ) протоколами удаленного доступа, такими как POP3 или IMAP4. Поскольку у пользователей могут быть законные причины для доступа к удаленным файловым службам, удаленным почтовым серверам отправки (или, по крайней мере, для использования их предпочитаемых адресов электронной почты из нескольких мест), а также для доступа к удаленным почтовым репозиториям (опять же, почти требование, если один адрес важно), важно, чтобы провайдеры раскрыли услуги, которые они предоставляют, а также фильтры и условия, которые они навязывают.
Несколько ключевых вопросов в фильтрации электронной почты имеют особое значение.
3.1. Динамические адреса (Dynamic Addresses)
Ряд систем, в том числе несколько систем «черного списка», основаны на предположении, что большинство нежелательных сообщений электронной почты исходит от систем с динамическими адресами, особенно систем удаленного доступа и домашних широкополосных систем. Следовательно, они пытаются предотвратить использование адресов для отправки почты или предоставления некоторых других услуг, кроме как через системы провайдеров, предназначенные для этой цели.
Различные методы используются для идентификации систем с динамическими адресами, включая объявление провайдерами таких адресов операторам черного списка, эвристики, использующие определенные диапазоны адресов, и проверку доменных имен с обратным отображением, чтобы определить, содержат ли они контрольные строки, такие как «dsl» или « набирать номер». В некоторых случаях отсутствие адреса DNS с обратным отображением рассматривается как указание на то, что адрес является «динамическим». (Запрет на подключения, основанный на отсутствии записи DNS с обратным отображением, был техникой, разработанной для FTP-серверов много лет назад; было обнаружено, что он имеет довольно высокую частоту сбоев, как запрещающих попытки законных подключений, так и не предотвращающих незаконные). Поставщики услуг ДОЛЖНЫ описать, что они делают в этой области как для входящего, так и исходящего трафика сообщений, и пользователи должны знать, что, если адрес объявляется как «динамический», может быть невозможно использовать его для отправки почты в произвольную систему. даже если обеспечено полное интернет-соединение.
3.2. Непубличные адреса и NAT (Non-public addresses and NATs)
Системы NAT, которые используются для сопоставления между частными и общедоступными адресными пространствами, могут поддерживать соединения с удаленными почтовыми системами для исходящей и входящей почты, но условия обслуживания часто запрещают использование систем, не поставляемых поставщиком связи, и запрещают работу «серверов». «(как правило, не определено точно) на клиентском соединении.
3.3. Фильтрация исходящих портов от провайдера (Outbound port filtering from the provider)
Другой распространенный метод заключается в блокировании подключений к серверам вне контроля провайдера путем блокирования TCP-портов, которые обычно используются для функций обмена сообщениями. У разных провайдеров разные теории на этот счет. Некоторые запрещают своим клиентам доступ к внешним SMTP-серверам для отправки сообщений, но они разрешают использовать протокол отправки почты ([3]) с аутентификацией отправителя. Другие пытаются заблокировать все исходящие протоколы, связанные с обменом сообщениями, включая протоколы удаленного извлечения почты; однако, это менее распространено в публичных адресных службах, чем в тех, которые зависят от частных адресов и NAT. Если этот тип фильтрации присутствует, особенно с услугами «Только клиент, общедоступный адрес» и «Полное подключение к Интернету», поставщик ДОЛЖЕН указать этот факт (см. Также Раздел 4).
Третьи могут перенаправлять (перенаправлять) исходящий почтовый трафик на свои собственные серверы, полагая, что это устраняет необходимость перенастройки портативных компьютеров при их подключении из другого сетевого расположения. Опять же, такая утечка ДОЛЖНА быть раскрыта, тем более что она может иметь значительные последствия для безопасности и конфиденциальности.
В более общем смысле фильтры, которые блокируют часть или всю почту, отправляемую (или отправляемую) в удаленные системы (кроме серверов, поддерживаемых провайдерами), или которые пытаются перенаправить этот трафик на их собственные серверы, как обсуждалось выше, становятся обычными и СЛЕДУЕТ быть раскрытым.
4. Дополнительная терминология
Эти дополнительные термины, хотя они и не являются базовыми для понимания предложения услуг, как те, которые указаны выше, перечислены в качестве дополнительной информации, которую поставщик услуг может выбрать для дополнения этих общих определений. Потенциальный клиент может использовать те, которые имеют отношение к делу, например, для составления списка конкретных вопросов.
Поддержка версий (Version support)
Включает ли служба только поддержку IPv4, поддержку как IPv4, так и IPv6 или только поддержку IPv6?
Поддержка аутентификации (Authentication support)
Какие технические механизмы используются службой для установления и, возможно, проверки подлинности соединений? Примерами могут быть перехват DHCP, PPP, RADIUS или HTTP без аутентификации.
VPN и туннели (VPNs and Tunnels)
IPSec заблокирован или разрешен? Разрешены ли другие методы туннелирования на уровне IP или ниже, такие как L2TP? Есть ли попытка заблокировать механизмы туннеля уровня приложений, такие как SSH?
Поддержка многоадресной рассылки (Multicast support)
Имеет ли пользовательский компьютер доступ к многоадресным пакетам и службам?
Поддержка DNS (DNS support)
Обязаны ли пользователи использовать DNS-серверы, предоставляемые поставщиком услуг, или разрешено ли DNS-запросам достигать произвольных серверов?
Услуги, связанные с IP (IP-related services)
Сообщения ICMP на сайты конечных пользователей и с них обычно блокируются или разрешены? Блокированы ли определенные функции, такие как ping и traceroute, и, если да, в какой точке сети?
Поддержка роуминга (Roaming support)
Включает ли служба намеренно поддержку IP-роуминга и, если да, как это определяется? Для «широкополосных» подключений предусмотрена ли какая-либо схема коммутируемого доступа для резервного копирования или для клиентов? Имеется ли у этого соглашения полный доступ к почтовым ящикам и т. д..
Прикладные услуги предоставляются (Applications services provided)
Предоставляются ли услуги электронной почты и / или веб-хостинг как часть сервиса и на какой основе? В списке служб электронной почты должно быть указано, предоставляются ли POP3, IMAP4 или веб-доступ и в каких сочетаниях, а также какие типы служб проверки подлинности и конфиденциальности поддерживаются или требуются для каждого из них.
Использование и блокирование служб исходящих приложений (Use and Blocking of Outbound Applications Services)
Служба блокирует использование SMTP или отправку почты на другие, кроме своих собственных серверов, или перехватывает такие отправки и направляет их на свои серверы? Ограничивают ли его серверы использование пользователями своих доменных имен в исходящей электронной почте? (Что касается электронной почты, см. Также раздел 3 выше.) Поддерживается или блокируется команда FTP PASV? Наложены ли блоки или перехваты на другие механизмы совместного использования файлов или передачи файлов, на приложения для проведения конференций или на службы для частных приложений?
В более общем смысле, провайдер должен идентифицировать любые действия службы, чтобы блокировать, ограничивать или изменять назначение исходящего использования (то есть использования услуг, не предоставленных провайдером или в сети провайдера) сервисов приложений.
Блокировка служб входящих приложений (Blocking of Inbound Applications Services)
В дополнение к проблемам, возникающим из-за динамического или частного адресного пространства (если оно имеется), принимает ли служба какие-либо другие меры, которые конкретно ограничивают соединения, которые могут быть установлены с оборудованием, эксплуатируемым клиентом? В частности, запрещены ли входящие SMTP, HTTP или HTTPS, FTP или различные одноранговые или другие соединения (возможно, включая приложения, которые не были специально распознаны поставщиком) и, если да, то какие?
Приложения фильтрация контента (Application Content Filtering)
Служба должна указывать, обеспечивает ли она фильтрацию или защиту от червей или атак типа «отказ в обслуживании» против своих клиентов, фильтрацию вирусов и спама для своих почтовых служб (если таковые имеются), недискреционную фильтрацию содержимого или «родительский контроль» и т. д.
Прослушивание телефонных разговоров и перехват (Wiretapping and interception)
Службе СЛЕДУЕТ указывать, подлежит ли трафик, проходящий через нее, законному перехвату, и будет ли провайдер делать упреждающую попытку проинформировать пользователя о таком перехвате, когда такое уведомление является законным. Аналогичные вопросы могут быть заданы для данных о дорожном движении, которые хранятся для возможного использования правоохранительными органами.
5. Вопросы безопасности
Этот документ посвящен терминологии, а не протоколам, поэтому он не вызывает каких-либо особых проблем безопасности. Однако, если предложенный тип терминологии будет широко принят, может оказаться проще определить ожидания, связанные с безопасностью конкретных хостов, локальных сетей и типов соединений.
6. Благодарности
Этот документ был вдохновлен беседой по электронной почте с Верноном Шрайвером, Полом Викси и Натаниэлем Борнштейном. Несмотря на то, что в течение многих лет поступали предложения о разработке таких определений, этот разговор убедил автора в том, что наконец настало время поставить на стол соломенную палочку, чтобы посмотреть, действительно ли IETF сможет его продвинуть. Харальд Альвестранд, Брайан Карпентер, Джордж Майклсон, Вернон Шрайвер и другие внесли несколько предложений по первоначальному проекту, которые привели к разъяснениям ко второму, и Стефан Борцмейер, Брайан Карпентер, Тони Финч, Сьюзен Харрис, Дэвид Кессенс, Пекка Савола и Вернон Шривер сделал очень полезные предложения, которые были включены в последующие версии. Сьюзен Харрис также внимательно прочитала предпоследнюю версию, что очень ценится, как и редакционные предложения редактора RFC.
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.
Адрес автора
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Klensin
