J. Klensin May 2005
NetReq
BCP: 104 Category: Best Current Practice
Терминология для описания услуг по подключению к Internet
Terminology for Describing Internet Connectivity
Статус документа
В этом документе рассматривается позитивный опыт (Best Current Practices), который может быть полезен сообществу Internet. Документ служит приглашением к дискуссии в целях дальнейшего совершенствования и может распространяться свободно.
Авторские права
Copyright (C) The Internet Society (2005).
Тезисы
Когда сеть Internet развилась достаточно сильно, началась активная реклама и продажа “подключения к Internet1”. В силу того, что предложения могут существенно различаться по своим возможностям, набору опций, а также по причине отсутствия стандартизо­ванной терминологии, конечные пользователи зачастую не могут разобраться с предлагаемыми услугами. В этом документе при­водится список терминов и определений, описывающих различные типы сервиса, которые могут предлагаться. Эти определения могут оказаться полезными для провайдеров, потребителей и (возможно) контролирующих органов.
Оглавление
1. Введение ................................................................................................................................................................................ ...... .................... 1
1.1. Проблема и требования ................................................................................................................................................................ .....1. .
1.2. Адаптация терминов ................................................................................................................................................................... ...... .1
2. Общая терминология ................................................................................................................................................................................ ..2...
3. Терминология, относящаяся к фильтрации и безопасности .................................................................................................................. 3
4. Дополнительные термины ....................................................................................................................................................................... ..3...
5. Вопросы безопасности ........................................................................................................................................................ ....... .................... 4
6. Благодарности .......................................................................................................................................................................................... ....4...
7. Литература ................................................................................................................................................................................................ ...4..
1. Введение
1.1. Проблема и требования
Различные поставщики услуг доступа в Internet (ISP) и другие провайдеры предлагают широкий спектр продукции и услуг, обозначаемых как "Internet" или "доступ в Internet". Эта продукция характеризуется различным набором функций и, в результате, может оказаться подходящей для одних пользователей и совершенно неприемлемой для других. Например, сервис, который обес­печивает только доступ в Web (в контексте этого документа – часть Internet, доступная по протоколам HTTP и HTTPS), может устроить тех, кто интересуется исключительно Web-серверами и почтовыми системами на базе Web. Однако такой сервис не подойдет тем, кто хочет загружать из сети файлы или использовать электронную почту более интенсивно. Очевидно, что еще меньше такой сервис подойдет тем, кто предоставляет свои серверы для других пользователей или нуждается в каналах VPN (вир­туальные частные сети) или иных системах организации защищенного доступа в удаленный офис, а так же тем, кому нужна син­хронизация электронной почты для работы с ней без постоянного доступа в сеть (offline0.
Недавние и быстротекущие изменения в среде электронной почты Internet привели к дополнительным ограничениям на передачу и получение (retrieving) почты. Эти ограничения, большинство из которых разработаны как часть системы предотвращения неза-прошенной почты2, могут вводиться независимо от типа сервиса, описанного ниже, и рассматриваются отдельно в главе 3.
В данном документе описываются лишь функции, предлагаемые или разрешаемые сервис-провайдерами. В документе не описы­ваются функции, которые могут поддерживаться различным пользовательским оборудованием.
Термины SHOULD (следует), MUST (должно), и MAY (можно) выделяются в этом документе, как описано в [1].
1.2. Адаптация терминов
Приведенные здесь определения будут иметь мало смысла, если сервис-провайдеры не примут их. Предложенные здесь термины не следует рассматривать как “уничижительные”, несмотря на то, что ряд членов сообщества IETF считает некоторые из описан­ных здесь типов сервиса “забытыми” (broken) или не относящимися к "Internet-сервису” (not really an Internet service0. Упоминание того или иного типа сервиса или модели в данном документе не является подтверждением или признанием существования или возможности существования его на реальном рынке. Таким образом, опыт (Best Current Practice), описываемый в этом документе, относится к терминологии, а приведенная информация предназначена для пользователей и не задает типов сервиса, которые следует предлагать.
1В оригинале используется термин “Internet connectivity”. Прим. перев.
2Спама. Прим. перев.
Перевод RFC 4084
2. Общая терминология
В этом параграфе перечислены основные типы сервиса IP. Есть надежда, что сервис-провайдеры примут эти определения для того, чтобы лучше определить услуги, предлагаемые потенциальным пользователям и заказчикам. Термины, относящиеся к про­вайдерам (ISP), выражены в технических параметрах или условиях обслуживания. Возможна работа над конкретной реализацией этих характерных типов подключения, но такая свобода обычно не имеет смысла для провайдеров и не факт, что она будет под­держиваться в случае прекращения работ в этом направлении.
Определения типов обслуживания приводятся в порядке возрастания возможностей вплоть до полнофункционального подключе­ния к Internet3.
♦    Web connectivity (Web-подключение).
Этот тип сервиса обеспечивает подключение к Web, т. е., к службам, поддерживаемым с помощью Web-браузеров (таких, как Firefox, Internet Explorer, Mozilla, Netscape, Lynx или Opera), в частности, к службам, работающим по протоколам HTTP и HTTPS. Другие типы сервиса в общем случае не поддерживаются. В частности, такой тип сервиса может не предоставлять до­ступа к электронной почте по протоколам POP3 или IMAP4, не поддерживать шифрованные туннели и другие механизмы VPN.
Используемые для такого сервиса адреса могут быть приватными и/или недоступными в глобальном масштабе. Адреса обыч­но выделяются динамически (см. обсуждение в параграфе 3) и срок их использования достаточно мал (часы или дни). Такие адреса часто анонсируются как динамические (dynamic) для тех, кто поддерживает списки динамических адресов, используе­мых для коммутируемого доступа. Провайдер может использовать фильтрацию с помощью Web-прокси для соединений; прок­си-сервер может изменять или перенаправлять URL на другие сайты взамен тех, которые указаны пользователем или приведе­ны в ссылке.
♦    Client connectivity only, without a public address (подключение в качестве клиента без предоставления публичного адреса).
Этот тип сервиса обеспечивает доступ в Internet без поддержки возможности организации серверов и реализации большинства функций peer-to-peer. Выделяемый пользователю адрес IP является динамическим и обычно относится к приватным блокам. Серверы и функции peer-to-peer обычно не поддерживаются системами трансляции адресов (NAT), которые требуются при ис­пользовании приватных адресов. Более точное описание категорий NAT в документе [2] в некоторых случаях отличается от трактовки в данном документа. Такие функции могут рассматриваться как отдельные типы сервиса, описанные в главе 4.
Для этого типа сервиса обычно используются фильтрующие Web-прокси, и провайдерам следует указывать наличие или отсут­ствие такого сервера.
♦    Client only, public address (подключение в качестве клиента с предоставлением публичного адреса).
Этот тип сервиса обеспечивает доступ в Internet без поддержки возможности организации серверов и реализации большинства функций peer-to-peer. Пользователю предоставляется публичный4 адрес IP. Адрес обычно выделяется динамически или может быть изменен в любое время, но работа с одним адресом может продолжаться в течение месяцев. С этим типом обслуживания работает большинство систем VPN5 и подобных им соединений. Провайдер может запретить пользователю организацию сер­веров на уровне контракта или путем фильтрации попыток входящих (к пользователю) соединений.
Фильтрующие Web-прокси нехарактерны для этого типа сервиса и провайдерам следует сообщать о наличии таких серверов.
♦    Firewalled Internet Connectivity (подключение с использованием межсетевого экрана).
Этот тип сервиса обеспечивает доступ в Internet и поддерживает возможность организации серверов и использования большинства функций peer-to-peer functions с предоставлением клиенту одного публичного адреса IP или блока таких адресов (обычная практика). Этот тип сервиса похож на полнофункциональное подключение, описанное ниже, и к нему применимы все описанные для этого сервиса классификации и ограничения. Однако для данного типа сервиса используется подключение через поддерживаемый провайдером межсетевой экран6, который находится между пользователем и публичной частью Internet. Поддержка межсетевого экрана обычно включается по запросу заказчика и повышает стоимость обслуживания. Усло­вия фильтрации пользовательского трафика на межсетевом экране оговариваются в контракте и могут обеспечивать блокиро­вание некоторых услуг.
Отдельные типы сервиса могут перехватываться прокси-серверами, системами фильтрации содержимого и шлюзами приложе­ний. Провайдерам следует указывать какие типы сервиса они блокируют, перехватывают или меняют тем или иным способом.
В большинстве случаев услуги межсетевого экранирования предлагаются в качестве платного дополнения к сервису Full Internet Connectivity, который отличается от описанной выше модели тем, что любая фильтрация или блокирование трафика выполняются по запросу заказчика, а не как ограничение возможностей пользователей.
♦    Full Internet Connectivity (полнофункциональное подключение).
Этот тип сервиса обеспечивает пользователям полнофункциональное подключение к Internet с предоставлением одного пуб­личного адреса или блока таких адресов. Клиентам могут предоставляться динамические адреса с большим сроком жизни, ко­торые не будут требовать частой замены записей DNS для серверов и будут представляться удаленным хостам как статиче­ские.
Фильтрующие Web-прокси, перехватывающие прокси-серверы, NAT и иные вносимые провайдером ограничения для входя­щего или исходящего трафика или портов несовместимы с этим типом сервиса. Серверы в локальной сети пользователя обыч­но рассматриваются как нормальное явление. Допустимыми для такого сервиса ограничениями являются полоса канала и запрет на недопустимое использование ресурсов и противоправные действия.
3В оригинале - "full Internet connectivity". Прим. перев. 4Маршрутизируемый через Internet. Прим. перев. 5Virtual Private network – виртуальная частная сеть. Прим. перев. 6Firewall. В русском языке часто используется термин брандмауэ
или транслитерация “фаервол”. Прим. перев.
2                                                            rfc.com.ru
Перевод RFC 4084
3. Терминология, относящаяся к фильтрации и безопасности
Как было отмечено во введении, усилия по контролю или ограничению нежелательного трафика могут приводить к дополнитель­ным ограничениям сервиса Internet. К нежелательному трафику может относиться незапрошенная электронная почта различных видов (включая спам), программные черви, вирусы и (в некоторых случаях) определенные типы информации (контента).
В общем случае максимальные ограничения очевидно будут связаны с такими типами сервиса, как Web-подключение и подклю­чение без предоставления публичного адреса, но некоторые рекомендации предлагают применять ограничения ко всем уровням сервиса. Некоторые ограничения для электронной почты не позволяют клиента передавать почту напрямую (однако можно пере­давать почту через сервер провайдера), запрещают пользователю устанавливать произвольный обратный адрес в письмах и могут даже закрывать доступ к серверам электронной почты (за исключением предоставленных провайдером) по протоколам типа POP3 или IMAP4. Поскольку пользователям может требоваться доступ к файловым серверам и удаленным почтовым серверам (хотя бы для того, чтобы можно было пользоваться своим электронным адресом из разных мест), важно, чтобы провайдеры указывали до­ступные при подключении службы и вводимые ограничения.
Некоторые вопросы фильтрации электронной почты имеют особую важность и рассмотрены ниже.
♦    Динамические адреса.
Множество систем, включая некоторые “черные списки” (blacklist), работают на основе допущения, что значительная часть незапрошенной почты поступает от хостов с динамическими адресами, особенно от компьютеров с коммутируемым доступом по телефонным линиям или домашних систем, подключенных по широкополосным каналам. Следовательно, предпринимают­ся попытки предотвратить передачу почты с таких адресов (за исключением передачи сообщений через серверы провайдера).
Для идентификации систем с динамическими адресами используются различные методы, включая анонсирование провайдера­ми динамически распределяемых блоков держателям “черных списков”, эвристические методы, преобразование адресов в до­менные имена и проверка наличия в полученном имени подстрок типа "dsl" или "dial". В некоторых случаях отсутствие ре-версной записи DNS трактуется как принадлежность адреса к числу динамических. Отметим, что метод запрета соединений FTP с адресов, для которых отсутствует возможность обратного преобразования DNS, был разработан несколько лет назад и показал свою несостоятельность (множество ложных срабатываний и частый пропуск действительно динамических адресов). Провайдерам следует описывать свои требования (действия) в данном направлении как для входящего, так и для исходящего трафика. Пользователей следует предупреждать о том, что анонсирование провайдером динамических адресов может делать невозможной прямую передачу электронной почты даже для сервиса типа Full Internet Connectivity.
♦    Приватные адреса и трансляция NAT.
Системы NAT, используемые для преобразования приватных адресов в публичные (и обратно) позволяют подключаться к уда­ленным почтовым службам и передавать почтовый трафик в обоих направлениях, но соглашения с провайдерами зачастую запрещают использование серверов, не относящихся к сети провайдера, а также использование клиентских станций в качестве почтовых серверов (обычно это требование не определено достаточно четко).
♦    Фильтрация провайдером исходящего трафика по портам.
Другим распространенным способом блокирования соединений с серверами за пределами сети провайдера является фильтра­ция соединений с портами TCP. Разные провайдеры имеют различные “теории” на сей счет. Некоторые запрещают своим кли­ентам использовать внешние серверы SMTP для отправки сообщений, но позволяют использовать такие функции при наличии аутентификации отправителя [3]. Другие провайдеры пытаются блокировать все связанны с отправкой почты соединения (та­кой подход реже используется для клиентов с публичными адресами, нежели для клиентов с приватными адресами и NAT). При использовании такой фильтрации, особенно для сервиса типа "Client only, public address" или "Full Internet Connectivity", провайдер должен сообщать об этом клиентам (см. также главу 4).
Некоторые провайдеры могут перенаправлять исходящий почтовый трафик на свои серверы и теоретически это избавляет от необходимости изменять конфигурацию мобильных хостов, которые могут подключаться к разным провайдерам. О таком перенаправлении почтового трафика провайдеры должны оповещать своих пользователей (особенно в тех случаях, когда это оказывает существенное влияние на безопасность и конфиденциальность).
Фильтры, которые блокируют передачу (или получение) почты полностью или частично, а также пытаются перенаправлять почтовый трафик на серверы провайдера, становятся все более распространенными и о них следует оповещать пользователей.
4. Дополнительные термины
Эти дополнительные термины хоть и не играют столь важную роль в описании типов сервиса, как рассмотренные выше термины, приведены здесь для того, чтобы сервис-провайдеры могли выбрать и описать дополнительные услуги, предлагаемые заказчикам. Потенциальные заказчики могут использовать эти термины для оценки услуг того или иного провайдера.
♦    Поддержка версий протокола.
Версии протокола IP, поддерживаемые провайдером - только IPv4, IPv4 и IPv6 или только IPv6.
♦    Поддержка аутентификации.
Технические механизмы, используемые провайдером для организации и аутентификации соединений. Примерами могут слу­жить DHCP, PPP, RADIUS, перехват (interception) HTTP.
♦    VPN и туннели.
Поддерживается ли использование IPSec? Поддерживаются ли другие механизмы организации туннелей на уровне IP или ниже (например, L2TP)? Предпринимаются ли попытки блокирования туннельных механизмов прикладного уровня (напри­мер, SSH)?
♦    Поддержка групповой адресации.
Может ли пользовательская станция принимать пакеты с групповой адресацией?
♦    Поддержка DNS.
3
Перевод RFC 4084
Требуется ли от клиента использование DNS-серверов провайдера или запросы DNS могут отправляться на произвольные сер­веры?
♦    ICMP и traceroute.
Пропускаются ли сообщения ICMP в направлении пользователя и от него? Блокируется ли использование таких инструментов, как ping и traceroute (если да, то в какой точке сети)?
♦    Роуминг.
Поддерживает ли провайдер IP-роуминг? Поддерживается ли для широкополосных соединений возможность организации коммутируемого соединения в качестве резервного или при отъезде в другое место? Как в случае работы с роумингом осуще­ствляется доступ к электронной почте и т. п.?
♦    Электронная почта и хостинг.
Предоставляется ли электронная почта и/или Web-хостинг в составе сервиса? Для почтовых служб следует определить тип до­ступа к почтовым ящикам (POP3, IMAP4 или Web, а также средства аутентификации для каждого из вариантов доступа.
♦    Блокировка исходящих соединений с серверами.
Блокирует ли провайдер использование чужих серверов SMTP или перехватывает их и перенаправляет их на свой сервер? Ограничивается ли на почтовых серверах использование “чужих” доменов в исходящих почтовых сообщениях (см. также гла­ву 3)? Поддерживается ли команда FTP PASV? Блокируются (перехватываются) ли обращения в файлообменные сети или ис­пользование других механизмов передачи файлов, а также серверы конференций и приватных приложений?
Провайдерам следует указывать все свои ограничения на использование чужих серверов приложений (т. е., серверов, не под­держиваемых за пределами сети данного провайдера).
♦    Блокирование входящих соединений с серверами.
Использует ли провайдер какие-либо ограничения для соединений, которые может организовывать пользовательское оборудо­вание, в дополнение к ограничениям, связанным с динамическими и приватными адресами? В частности, следует выяснить блокируются ли входящие соединения SMTP, HTTP, HTTPS, FTP, peer-to-peer и др.?
♦    Фильтрация содержимого.
Провайдерам следует сообщать своим пользователям о средствах фильтрации, используемых для предотвращения червей, ви­русов и спама, атак на службы или ограничения доступа к Web (в частности, для детей).
♦    “Прослушивание” и перехват.
В описание сервиса следует включать сведения о возможности законного перехвата проходящего через сеть провайдера тра­фика. Провайдеру следует также оповещать пользователей будут ли они получать от провайдера предупреждение об активиза­ции такого перехвата. Аналогичные вопросы следует задать и по поводу хранящейся у провайдера данных о трафике пользо­вателей.
5. Вопросы безопасности
Данный документ посвящен терминологии, а не протоколам, следовательно, он не оказывает какого-либо влияния на вопросы безопасности. Однако при широком распространении предложенной здесь терминологии она может упростить идентификацию связанных с безопасностью ожиданий для отдельных хостов, ЛВС и типов подключения.
6. Благодарности
Толчком к созданию этого документа послужила переписка по электронной почте с Верноном Шрайнером (Vernon Schryver), Паулем Викси (Paul Vixie0 и Натаниэлем Борнстейном (Nathaniel Bornstein). Разговоры о необходимости разработки таких опреде­лений велись уже много лет, упомянутая переписка убедила автора в том, что настало время перейти от слов к делу. 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 21197, 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 24767, December 1998.
Адрес автора
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
7На сайте rfc.com.ru имеется перевод этого документа на русский язык. Прим. перев.
rfc.com.ru                                                                                     4                                                            rfc.com.ru
Перевод RFC 4084
 
Перевод на русский язык
Николай Малых nmalykh@bilim.com
Полное заявление авторских прав
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Интеллектуальная собственность
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
5
Одна, две, три путаны - любое количество по первому вашему звонку. | Хотите интим-досуг, пройдите по ссылке прямо сейчас.