Обзор свежих RFC и комментарии к некоторым из них
Практическая значимость сего документа для среднестатистического отечественного (равно, впрочем, как и "импортного") сетевика кажется мне сомнительной. Поэтому позволяю себе краткий пересказ этой спецификации с целью чисто общеобразовательной.
Итак, документ описывает пространство имен URN'ов (Uniform Resource Name), содержащих идентификаторы объектов (Object Identifier, OID). У некоторой части аудитории, по всей видимости, возникнет вопрос: что это еще за URN и чем он отличается от других URx — URL, URI?
URI — общий термин для идентификации ресурсов каким-либо способом. Первый способ — по месторасположению (URL), и второй — по уникальному в рамках Сети, постоянному, не зависящему от месторасположения и доступности ресурса имени (URN). То бишь URN суть подмножество, тип URI. Выглядеть URN может вот так: urn:namespace: data1.data2,more-data, где namespace (пространство имен) определяет, каким образом используются данные, указанные после второго ":".
Можно провести аналогию с префиксом URL — http:// , telnet:// и т. д. Пространства имен должны быть стандартными и зарегистрированными. Хороший пример для осмысления назначения URN дает энциклопедия на whatis.com: urn:def:blue_laser
Здесь def — пространство имен, ассоциирующееся, скажем, с каталогом всех сетевых библиотек, словарей, справочников и энциклопедий, доступным по какому-то протоколу, а blue_laser — имя термина, расшифровку которого мы получим, обратившись по данному URN.
Впрочем, мы отвлеклись, вернемся к RFC3001.
Вводится стандартный нэймспейс (ничего если я так фривольно скалькирую этот термин? ;) под названием oid. Для идентификаторов объектов. OID — это серии цифр, разделенных каким-то образом. Например:
o1.3.6.1 — Internet OID
o1.3.6.1.4.1 — назначенные IANA OID'ы компаний, используемые для частных MIBи тому подобных вещей
o1.3.6.1.2.1.27 — MIB приложений
o0.9.2342.19200300.100.4 — OID'ы, используемые в проектах каталогов для идентификации классов объектов X.500
Кто будет регистрировать эти URN'ы и как это все реально использовать — пока не понятно.
3002 Overview of 2000 IAB Wireless Internetworking Workshop. D. Mitzel. November 2000. (Format: TXT=101466 bytes) (Status: INFORMATIONAL)
Беспроводные технологии, включая беспроводные локальные сети, передачу данных по сотовым сетям (radio (GSM, 3GPP и т.д.), спутниковые технологии, с каждым днем становятся все актуальнее и важнее. По прогнозам, к 2003 году беспроводная часть Интернет приблизится по масштабам к Интернету проводному.
Однако как показывает практика мобильные операторы не торопятся использовать IPv4, TCP, полную поддержку HTTP/HTML и многие другие интернет-приложения и стандарты в своей деятельности.
Причины могут быть различными — удорожание оконечных устройств, ограничения полосы пропускания, очевидная неполнота и несовершенство протоколов, неоправданные усложнения, а также проблемы адресации сетевого уровня. IAB считает, что такое положение вещей создает определенные проблемы на "проводно-беспроводной границе" — ухудшается качество сквозного взаимодействия, возникают проблемы с безопасностью, а также появляется необходимость той или иной формы автоматической модификации контента.
IAB пришла к выводу, что такое положение вещей представляет угрозу для развития "комбинированного" Интернета и ставит под сомнение удобство и простоту его использоввания. Вот почему с 29 февраля по 2 марта IAB провела грандиозный семинар по проблемам беспроводного интернета. Основные направления и темы дискуссий:
• беспроводные локальные сети;
• сотовые технологии;
• WAP;
• беспроводные системы в авиации и ближенем космосе;
• передача голоса по IP (VoIP) в беспроводных сетях;
• безопасность беспроводных сетей;
• транспортный подуровень и качество сервиса (QoS) в беспроводных сетях;
• использование веб-протоколов на беспроводных малоэкранных терминалах;
• требования к адресации;
• требования к компрессии и выявлению ошибочных битов.
Фундаметнальный вопрос, который необходимо было решить в ходе дискуссий: в чем суть проблем и что именно нужно сделать чтобы унифицировать Интернет вплоть до уровня приложений?
В RFC 3002 вы найдете отчет по результатам семинара, а именно:
• в секции 1 — приблизительно то же словоблудие, что вы только что прочитали;
• в секции 2 — обзор индивидуальных презентаций, проводившихся в ходе семинара. Всего 21 штука в формате pdf и ppt (все больше в последнем) с краткими аннотациями.
• в секции 3 — детальный обзор дискуссий.
• в секции 4 — самое интересное: выводы и рекомендации мобильным операторам, IRTF и IETF на ближайшие пару лет.
• в секции 5 — соглашения по безопасности, стандартный раздел любого RFC, куда уж без этого.
• в приложении А — информация об участниках семинара.
• в приложении Б — контактная информация автора.
Поскольку объем материала этого документа достаточно велик, познакомить вас с "фактурой" нет никакой возможности, разве что в рамках отдельного материала (я подумаю над этим ;). Но вообще-то документ небезинтересен, да и тема больно уж модная ;)
3003 The audio/mpeg Media Type. M. Nilsson. November 2000. (Format: TXT=8381 bytes) (Status: PROPOSED STANDARD)
Угу, не прошло и полвека, как нам наконец-таки "предложили стандарт" для MIME-типа mpeg.
Регистрационная информация:
To: ietf-types@iana.org Subject: Registration of MIME media type audio/mpeg
Имя медиа-типа MIME: audio.
Имя медиа-подтипа (subtype): mpeg.
Обязательные параметры: нету таких.
Опциональные параметры: тоже нету.
Соглашения по кодировке: при работе по интернет-сетям подразумевается, что нижние уровни следят за ошибками передачи, таким образом данные audio/mpeg могут включать кадры, сгенерированные без CRC. Аудиоданные MPEG суть данные бинарные и должны быть кодированы в случае небинарного транспорта, например, для электронной почты уместным будет кодирование по BASE64.
Соглашения по безопасности: MPEG является тэговым форматом данных, некоторые тэги доступны для приватного использования. То бишь теоретически любой произвольный материал может передаваться в качестве MPEG-потока, в том числе и исполняемый код. Поэтому данные, содержащие исполняемый контент не желательно посылать и решительно нельзя исполнять при приеме!
Объекты аudio/mpeg не шифруются или подписываются с помощью внутренних механизмов — при необходимости используйте внешние средства для обеспечения конфиденциальности.
Соглашения по интероперабельности: MPEG считается очень интероперабельным ;)
Приложения, использующие этот медиа-тип: да все подряд MPEG-энкодеры/декодеры можно использовать ;)
Дополнительная информация:
Magic number(s): нету такого.
Расширения файлов: .mp1, .mp2, .mp3.
Коды типа файлов Macintosh: MPEG.
Идентификатор объекта (OID): тоже нету.
Ну вот, собственно, и все :)
3004 The User Class Option for DHCP. G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat. November 2000. (Format: TXT=10423 bytes) (Status: PROPOSED STANDARD)
Опция User Class (Класс Пользователя) для того, чтобы клиент DHCP мог идентифицировать тип или категорию пользователя/приложения, которого он представляет.
Сообразно с этим типом (далее — классом) юзеру назначается адрес из соответсвующего адресного пула и производятся другие настройки системы. Эта опция должна быть конфигурабильна пользователем (в более широком смысле — конфигурабельна на стороне клиента ;)
Ну например, администратор DHCP может завести классы пользователей "бухгалтерия" и "маркетинг". Клиенты могут быть отконфигурированы таким образом, чтобы люди из бухгалтерии получали в качестве принт-сервера один принтер, а маркетологи — другой.
Эта опция может содержать сразу несколько классов пользователей, сервер же волен интерпретировать такую ситуацию в зависимости от реализации и/или конфигурации.
Формат таков:
CodeLenValue 77NUser Class Data ('Len' octets)где поле Value состоит из одной или более записей User Class Data (данные класса пользователя) следующего формата:UC_Len_iUser_Class_Data_i L_iOpaque-Data ('UC_Len_i' octets)Значение UC_Len_i не включает самое себя и должно быть ненулевым. Пусть m — количество записей класса пользователя, передаваемых в опции. Тогда общая длина Len = UC_Len_1 + UC_Len_2 + ... + UC_Len_m + m.Как видно из формата опции, ее код (уже зарегистрированнный IANA) — 77.
3005 IETF Discussion List Charter. S. Harris. November 2000. (Format: TXT=5682 bytes) (Also BCP0045) (Status: BEST CURRENT PRACTICE)
3006 Integrated Services in the Presence of Compressible Flows. B. Davie, S. Casner, C. Iturralde, D. Oran, J. Wroclawski. November 2000. (Format: TXT=31588 bytes) (Status: PROPOSED STANDARD)
3007 Secure Domain Name System (DNS) Dynamic Update. B.Wellington. November 2000. (Format: TXT=18056 bytes) (Obsoletes RFC2137) (Updates RFC2535, RFC2136) (Status: PROPOSED STANDARD)
3008 Domain Name System Security (DNSSEC) Signing Authority. B. Wellington. November 2000. (Format: TXT=13484 bytes) (Updates RFC2535) (Status: PROPOSED STANDARD)
Два документа по безопасности DNS-процедур. Оба предполагают удовлетворительное знание системы DNS, оба дополняют RFC2535 (Domain Name System Security Extensions), порождены одним и тем же автором и оба ссылаются друг на друга, так что читать их вам придется (если есть желание это делать ;) оба и (насколько позволяет "многозадачность") одновременно.
В первом (3007) речь идет о методе безопасного динамического обновления зон DNS. Аутентификация сообщений динамического обновления отделяется от последующей проверки достоверности данных по DNSSEC.
Первый раздел содержит краткий обзор технологий динамического обновления в DNS, защищенных транзакций (записи TSIG и SIG(0), сравнение аутентификации на уровне сообщений и на уровне данных, понятие электронных подписей сообщений и данных DNS, требования к подписи.
Начиная со второго раздела идет собственно технология: аутентификация, политики безопасности, типы пользователей... И в четвертом разделе — тонкости, связанные со взаимодействием с DNSSEC.
Второй документ (3008) представляет собой пересмотренную и исправленную модель подписи подтверждения полномочий DNSSEC.
Пересмотренная модель была создана для внесения ясности в содержимое предыдущих документов, а также для упрощения разрешения имен в "безопасном" DNS.
Вобщем, читайте сначала предыдущие документы, а потом уж беритесь за "внесение ясности" ;)
3009 Registration of parityfec MIME types. J. Rosenberg, H. Schulzrinne. November 2000. (Format: TXT=16022 bytes) (Status: PROPOSED STANDARD)
3010 NFS version 4 Protocol. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. December 2000. (Format: TXT=450434 bytes) (Obsoletes RFC1813, RFC1094) (Status: PROPOSED STANDARD)
3011 The IPv4 Subnet Selection Option for DHCP. G. Waters. November 2000. (Format: TXT=13967 bytes) (Status: PROPOSED STANDARD)
Опять опция DHCP, и тоже под грифом "Предложенный Стандарт". На сей раз речь идет о новом методе выбора подсети, из которой клиенту выдается IP-адрес.
Для начала напомним, как этот выбор обычно происходит. Сервер определяет подсеть, из которой исходит запрос, и подбирает для клиента адрес из этой подсети либо из другой, находящейся в том же сегменте сети. Определяет он это вот как:
• смотрит, что указано в поле giaddr (адрес хоста-ретранслятора DHCP) пришедшего пакета, или, если поле giaddr нулевое
• использует адрес подсети, в которой находится локальный интерфейс, на котором появился пакет.
Новая опция позволяет клиенту "заказать" подсеть, из которой ему будут выбирать адрес, причем использование опции имеет приемущество перед традиционным методом раздачи адресов.
Опция выбора подсети — стандартная опция DHCP, ей назначен номер 118. Опция содержит IPv4-адрес (одна штука), являющийся адресом подсети. Если конфигурация сервера позволяет ему отвечать на эту опцию, и она содержится в запросе клиента, он (сервер) должен выдать адрес либо а) из указанной в опции подсети, либо б) из подсети, расположенной в том же сегменте, что и указанная в запросе.
Формат таков:
CodeLenIPv4 Address 1184A1A2A3A43012 Mobile IPv4 Challenge/ Response Extensions. C. Perkins, P. Calhoun. November 2000. (Format: TXT=37005 bytes) (Status: PROPOSED STANDARD)
3013 Recommended Internet Service Provider Security Services and Procedures. T. Killalea. November 2000. (Format: TXT=27905 bytes) (Also BCP0046) (Status: BEST CURRENT PRACTICE)
Еще один документ, ставящий своей целью наставление на путь истинный наших (и "ихних") замечательных интернет-сервис-провайдеров.
Еще один потому, что не так давно практически то же самое вы могли лицезреть в "Приложении к руководству по безопасности предприятия для сервис-провайдеров" (в оригинале это звучало как Site Security Handbook Addendum for ISPs. — Internet Draft, а в нашей газете публиковался русский перевод "Как выбирать поставщика интернет-услуг") и этой же теме посвящена парочка выходивших ранее BCP- и FYI-документов. Ить... был бы толк какой-нибудь ощутимый от этих ненавязчевых рекомендаций...
Итак, реферативно излагаю приведенные в документе рекомендации:
1. Провайдеру желательно прислушаться к RFC2142 и завести почтовый ящик SECURITY для общих вопросов безопасности, ABUSE для жалоб на ненадлежащее поведение юзеров и NOC для обсуждения вопросов сетевой инфраструктуры. Желательно также иметь на вебе ресурс со стандартным именем плана http://www.ISP-name-here.net/security/.
Провайдер также обязан содержать записи о себе в базах данных whois и других надлежащих местах в порядке — информация должна быть доступна, полна и достоверна.
2. Провайдеру желательно иметь ясную политику и процедуры по сообщению информации об различных инцидентах в этой области клиентам, другим провайдерам, группам реагирования (CSIRT), органам правосудия, журналистам и просто интересующейся публике. Такого рода коммуникации могут осущетсвляться по защищенному каналу.
...Далее следует более подробное описание форм представления подобной информации, а также основы функционирования CSIRT'ов.
3. Каждый провайдер должен (точнее — ему очень желательно) иметь Политику надлежащего использования, которая в понятных и однозначных выражениях определяет, что клиент должен и чего не должен делать применительно к различным компонентам сети, включая типы трафика, разрешенные в сети. Политика должна быть документирована и пользовательские контракты должны опираться на нее.
4. Далее следуют рекомендации по сетевой инфраструктуре, затрагивающие такие вопросы, как прописывание себя и своих сетей в Internet Routing Registry (как это есть по русски? ;), инфраструктура маршрутизации, входящая и исходящая фильтрация адресов источника, фильтрация маршрутной информации.
5. И в заключение даны советы по системному администрированию: максимизация защищенности критических служб (почта, веб-хостинг и др.), изничтожение у себя в сети открытых анонимных мэйл-релеев, желательно использование расширения SMTP Mail Submission, при котором клиенты отправляют свою исходящую почту по отдельному, отличному от 25, порту, по стандарту — 587 (более подробно это и другие расширения мы опишем в следующем номере "СР").
В хвосте документа, как обычно, список ссылок, что равнозначно списку полезного (я бы сказала — обязательного для ISP) чтива.
3014 Notification Log MIB. R. Kavasseri. November 2000. (Format: TXT=48287 bytes) (Status: PROPOSED STANDARD)
3015 Megaco Protocol 1.0. F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers. November 2000. (Format: TXT=385432 bytes) (Obsoletes RFC2885, RFC2886) (Status: PROPOSED STANDARD)
3016 RTP Payload Format for MPEG-4 Audio/Visual Streams. Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata. November 2000. (Format: TXT=47070 bytes) (Status: PROPOSED STANDARD)
3017 XML DTD for Roaming Access Phone Book. M. Riegel, G. Zorn. December 2000. (Format: TXT=59762 bytes) (Status: PROPOSED STANDARD)
3020 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function. P. Pate, B. Lynch, K. Rehbehn. December 2000. (Format: TXT=67736 bytes) (Status: PROPOSED STANDARD)
3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages. G. Vaudreuil. December 2000. (Format: TXT=23405 bytes) (Obsoletes RFC1830) (Status: PROPOSED STANDARD)
Кратко: эта спецификация определяет два новых расширения SMTP. Первое дает возможность клиенту и серверу договоритсья об использовании альтернативной DATA команды — BDAT для более эффективной пересылки длинных MIME-сообщений. Ключевое слово для этого расширения (в ответе на команду EHLO) — CHUNKING (деление на куски).
Второе расширение использует преимущества команды BDAT для разрешения посылки MIME-сообщений, которые используют кодировку для бинарной передачи (ужас что за фраза получилась, лучше я вам по-человечески в следующем номере в статье про расширения SMTP расскажу как оно работает ;)
Рубрику ведет Alice D. Saemon
alice@nestor.minsk.by
Сетевые решения. Статья была опубликована в номере 01 за 2001 год в рубрике RFC
