Журналietf Том10, выпуск 2 • Ноябрь 2014 года...

IETF 90 Журнал IETF • Ноябрь 2014 года • Том 10, выпуск 2

1 _____________________________________________________________________________________________________________________________________________________________

Отчет о конференции IETF 90, июль 2014 года, г. Торонто, Канада. Публикуется Internet Society (ISOC) совместно с Инженерным советом Интернета*

От редактора Мэт Форд (Mat Ford)

рекрасный канадский город Торонто стал местом проведения 90-й конференции Инженерного совета Интернета, ключевым организатором которой выступила компания Ericsson. Как обычно, журнал IETF представляет вашему вниманию отчет о наиболее интересных мероприятиях и

дискуссиях и рассказывает о людях, внесших свой вклад в успешное проведение очередной конференции IETF.

Главная статья этого номера посвящена автономным сетям, которые представляют собой существенный шаг вперед в развитии сетей автоматического конфигурирования. В этом выпуске вы также найдете статью о семинаре по тестированию концепции Интернета вещей (Internet-of-Things Plugfest), состоявшемся в ходе конференции IETF 90, информацию о семинаре «Эволюция стековой памяти в сетевых устройствах» (Stack Evolution in a Middlebox Internet), который пройдет в январе 2015 года, и статью о маршрутизации на локаторах контента, описывающую технологию, продемонстрированную на мероприятии Bits-n-Bites, организованном в рамках конференции IETF 90.

Мы поздравляем обладателя приза «За достижения в прикладных исследованиях в области сетевых технологий», а также представляем отчет о мероприятии ISOC, где обсуждались вопросы безопасности и защиты личной информации в сети Интернет.

Завершают выпуск наши постоянные рубрики с обращением председателей Инженерного совета Интернета (IETF), Совета по архитектуре Интернета (IAB) и Рабочей группы по исследованиям Интернета (IRTF), а также актуальные темы, ставшие предметом обсуждения на пленарных заседаниях. Более подробная информация о работе Инженерного совета Интернета содержится в итоговом отчете Рабочей группы, который доступен по адресу: http://wiki.tools.ietf.org/area/int/trac/wiki/IETF90.

Выражаем огромную благодарность всем нашим авторам. Пожалуйста, отправляйте свои комментарии и предложения по адресу [email protected]. Оформить подписку на печатную или электронную версию издания можно по адресу: www.internetsociety.org/publications/ietf-journal/ietf-journal-subscription.

Автономные сети Брайан Карпентер (Brian Carpenter)

рамках конференции IETF 90 была организована BoF-сессия под названием «Сценарии использования для автономных сетей» (Use Cases for Autonomic Networking (UCAN)), которая вызвала большой интерес среди участников. Соответствующий список рассылки называется

ANIMA — «Интегрированная модель и подход к созданию автономной сети». Что же такое автономная сеть?

Словарь дает такое определение слову «автономный»: «относящийся, влияющий или контролируемый автономной (вегетативной) нервной системой» — однако смысл от этого яснее не становится. Вегетативная нервная система играет важную роль в жизнедеятельности организма: именно она управляет такими жизненно важными функциями, как дыхание и глотание,

Продолжение на стр. 4

* Статьи, опубликованные в журнале IETF, не отражают точку зрения либо позицию Инженерного совета Интернета или Internet Society (ISOC).

П

В

Журнал IETF (Инженерного совета Интернета)

Том 10, выпуск 2 • Ноябрь 2014 года

В этом выпуске:

От редактора ................................. 1

Автономные сети ........................... 1

Обращение председателя Инженерного совета Интернета (IETF) ........................... 2

Обращение председателя Совета по архитектуре Интернета (IAB) ............................. 3

Преодоление препятствий на пути эволюции Интернета:

Объявление о семинаре SEMI ..... 6

По словам экспертов, экономические и политические факторы препятствуют эффективной маршрутизации интернет-данных............................................ 7

Экспертная группа Internet Society изучает вопрос безопасности личной информации в Интернете ........... 10

Маршрутизация информации на локаторах контента ................ 13

Безопасность маршрутизации в Интернете:

Cтоит ли игра свеч? .................... 17

Семинар по тестированию Plugfest, посвященный маломощным сетям с потерями, демонстрирует

выполнение кода Интернета вещей ........................................... 18

Новости Рабочей группы по исследованиям Интернета ......... 21

Новости об изменении функций IANA .............................. 22

Неформальные собрания Инженерного совета Интернета: последние новости ......................................... 23

Краткая информация о конференции IETF 90 .................... 26

Календарь .................................... 27


2 _____________________________________________________________________________________________________________________________________________________________

Обращение председателя IETF Яри Аркко, председатель IETF

онференция IETF 90 собрала большое количество участников — в этом году ее посетил 1 231 человек из 54 стран мира. Больше всего мне запомнились дискуссии в рамках семинара на тему Интернета вещей, обсуждение безопасности и защиты личной информации в сети Интернет, а также изменения функций

IANA.

Я бы хотел поблагодарить всех участников, присутствовавших на конференции лично или удаленно, включая участника, приславшего робота, который принял участие в конференции от его имени! Я бы также хотел поблагодарить наших спонсоров, в особенности компанию Ericsson, нашего главного организатора.

Концепция Интернета вещей

Обсуждению этой концепции в рамках конференции IETF уделяется большое внимание, и с каждой конференцией интерес к ней возрастает! В этот раз добавились три новых направления работы:

• Семинар по тестированию Plugfest, посвященный маломощным сетям с потерями, участники которого протестировали разработки друг друга. Такого рода тестирование является одной из отличительных особенностей IETF. Находясь формально не на мероприятии, разработчики часто собираются во время конференции IETF для проведения подобного тестирования.

• Рабочая группа ACE, занимающаяся вопросами безопасности и авторизации в сетях интеллектуальных объектов.

• Мероприятие Bits-n-Bites, сменившее формат и ключевую тему. На этот раз 10 организаций продемонстрировали свои решения для Интернета вещей большой аудитории заинтересованных участников. Мы планируем продолжить серию мероприятий Bits -and-Bites на следующих конференциях IETF и ждем ваших предложений по темам, которые вы хотели бы обсудить.

В рамках данного мероприятия обсуждалось, каким образом растущая популярность шифрования влияет на кэширование и другие функции сети.

Безопасность и конфиденциальность

Ранее в этом году мы пришли к выводу о том, что Инженерный совет Интернета должен приложить все усилия для повышения эффективности интернет-технологий в плане противодействия тотальному надзору за пользователями. Повышение безопасности в сети Интернет — непростая задача, но мы решаем ее одновременно в нескольких направлениях, в том числе обновляем протоколы TLS и HTTP (см. результаты деятельности рабочих групп TLS и HTTPBIS).

В рамках данного мероприятия обсуждалось, каким образом растущая популярность шифрования влияет на кэширование и другие функции сети. Несмотря на то что многое еще предстоит сделать, уже сейчас совершенно ясно, что HTTPS остается лучшим решением для обеспечения безопасной передачи данных. Для другого трафика могут быть предложены различные решения по кэшированию и туннелированию.


Задача Инженерного совета Интернета заключается в улучшении работы Интернета через создание высококачественной технической документации, которая помогает людям создавать и использовать Интернет, а также управлять им. См. http://www.ietf.org.

Актуальная информация по документации и протоколам

Группы по стандартизации инженерных решений в Интернете (IESG)

https://datatracker.ietf.org/iesg/ann/new/

К

Яри Аркко (Jari Arkko)


3 _____________________________________________________________________________________________________________________________________________________________

Обращение председателя Совета по архитектуре Интернета (IAB) Расс Хаусли (Russ Housley)

Главные события встречи Совета по архитектуре Интернета

В мае 2014 года в Канкуне, Мексика, состоялась трехдневная встреча Совета по архитектуре Интернета с представителями Сетевого информационного центра стран Латинской Америки и Карибского бассейна (LACNIC). Один из трех дней был посвящен совместной встрече с участием Группы по стандартизации инженерных решений в Интернете (IESG). Кроме того, мы пообщались с представителями LACNIC и надеемся привлечь большее количество инженеров из Латинской Америки и стран Карибского бассейна к участию в мероприятиях IETF.

Совет по архитектуре Интернета пересмотрел свои программы, чтобы сосредоточиться на наиболее важных для современного Интернета вопросах.

Совет по архитектуре Интернета пересмотрел свои программы, чтобы сосредоточиться на наиболее важных для современного Интернета вопросах. В частности, в качестве ответного шага на громкие разоблачения, связанные с практикой слежки за пользователями Интернета со стороны спецслужб, Совет по архитектуре Интернета в 2014 году запустил Программу по обеспечению безопасности и конфиденциальности.

Текущие программы Совета:

• Помощь в чрезвычайных ситуациях.

• Стратегия IANA.

• Интернационализация.

• Эволюция стеков IP.

• Координация работы с Сектором по стандартизации Международного союза электросвязи (ITU-T).

• Координация работы с другими организациями, занимающимися разработкой стандартов.

• Разрешение имен.

• Программа по обеспечению безопасности и конфиденциальности.

• Редактор RFC (включает RSOC).

Более подробная информация о каждой из этих программ доступна по адресу: www.iab.org/activities/programs/.

Совет по архитектуре Интернета призывает Национальный институт стандартов и технологий (NIST) к открытости и прозрачности в разработке стандартов

Совет по архитектуре Интернета направил свои замечания в Национальный институт стандартов и технологий США (NIST) с призывом повысить прозрачность и открытость процессов разработки стандартов. Эти замечания особенно важны в связи с тем, что по крайней мере один из стандартов безопасности NIST содержит существенные недостатки. С полным текстом замечаний можно ознакомиться по адресу: www.iab.org/wp-content/IAB-uploads/2014/04/IAB-NIST7977-20140407.pdf.


Совет по архитектуре Интернета выполняет обязанности комитета Инженерного совета Интернета, а также является совещательным органом для Internet Society (ISOC). В сферу его ответственности входит надзор за деятельностью IETF, контроль за процессом разработки стандартов Интернета и назначение редактора RFC. См. http://www.iab.org.

Расс Хаусли, председатель Совета по архитектуре Интернета


4 _____________________________________________________________________________________________________________________________________________________________

Автономные сети (продолжение)

На автономные сети можно взглянуть сквозь призму технологий «plug and play для ISP» или «plug and play для локальной сети предприятия».

без сознательного контроля. Именно это послужило источником вдохновения для разработки концепции автономных вычислений, которая была представлена корпорацией IBM в 2001 году и должна была способствовать максимальному самоуправлению компьютерных систем. В Википедии дается более подробное объяснение этого понятия: «Автономность компьютерной системы определяется характеристиками самоуправления распределенных вычислительных ресурсов, способностью адаптироваться к непредсказуемым изменениям, при этом внутренняя сложность остается спрятанной от оператора или пользователя». Под созданием автономных сетей, которые стали предметом активной исследовательской деятельности в последние годы, понимается применение этих идей в сетях. Эти вопросы, в частности, обсуждаются в Исследовательской группе по управлению сетями, сформированной в рамках Рабочей группы по исследованиям Интернета (IRTF).

Автономные сети (АС)

На автономные сети можно взглянуть сквозь призму технологий «plug and play для ISP» или «plug and play для локальной сети предприятия». Такой подход символизирует развитие первоначальной концепции «plug and play» для домашних сетей, которая долгое время считалась обязательным требованием (см., например, отчет о деятельности рабочей группы ETF HOMENET). Cамоуправление подразумевает самостоятельное конфигурирование, самооптимизацию, самовосстановление и самозащиту. АС переводят рабочие вычислительные характеристики в алгоритмы на уровне узла, с тем чтобы минимизировать зависимость от администратора или центрального управления. Входящие в состав АС узлы находят информацию об окружающей сети и обмениваются параметрами настройки с соседними элементами и другими узлами. В идеале, автономные узлы используют стабильные методы управления замкнутым контуром для самоуправления вместо более традиционных, нисходящих инструментов конфигурации и мониторинга сетей с целью задания и проверки параметров. Кроме того, узлы могут обладать способностью к обучению и приобретению знаний, в том числе способностью к самостоятельной адаптации процессов принятия решений на основе информации и знаний, полученных из той среды, в которой они находятся. В наиболее сложных случаях данные, вводимые в автономные механизмы, могут подвергаться углубленному анализу.

[Автономные сети] переводят рабочие вычислительные характеристики в алгоритмы на уровне узла, с тем чтобы минимизировать зависимость от администратора или центрального управления.

Больше чем научная фантастика

Некоторые компоненты небольших сетей, включая автономные домашние и офисные сети, уже на протяжении многих лет выполняют конфигурацию самостоятельно. Более того, множество существующих протоколов обладает целым набором автономных свойств (например, для алгоритма связующего дерева конфигурация вручную не требуется вообще, а для некоторых протоколов маршрутизации конфигурация вручную требуется лишь в незначительном объеме). В последнее время некоторые крупные поставщики сетевого оборудования выпустили прототипы и исходные продукты автономных протоколов. При этом очевидно, что если речь идет об АС в связи с крупными сетями со множеством поставщиков, необходимо опираться на какие-то базовые стандарты.

Почему сейчас

Основной мотив не нов: крупные сетевые операторы — интернет-провайдеры (ISP) и предприятия — испытывают все возрастающие трудности в связи с централизованным конфигурированием сотен или даже тысяч элементов сети. Сегодня, после многих лет исследований и обсуждений, идеи по созданию автономных сетей становятся более конкретными. К счастью, обеспечение достаточных вычислительных мощностей и памяти для сетевых элементов, поддерживающих АС, в данный момент представляется экономически рентабельным. Это означает, что настало время для стандартизации.

Сетевые параметры

Во время BoF-сессии UCAN было предложено несколько сценариев использования для крупных сетей:


5 _____________________________________________________________________________________________________________________________________________________________

управление адресами и префиксами сети, оптимизация мобильных ретрансляционных линий, маршрутизация с учетом рисков, поиск нарушений соглашения об уровне сервиса (SLA). Начинают появляться и другие примеры, включая мониторинг и составление отчетов, и это еще далеко не все. В качестве самостоятельных сценариев использования можно рассматривать два фундаментальных аспекта АС: безопасная самонастройка новых устройств и создание безопасной автономной плоскости, которая будет использоваться отдельными приложениями АС.

Сохранение контроля

С одной стороны, желательно сократить необходимость в трудоемком вмешательстве человека;; с другой — важно, чтобы администраторы могли обеспечить выполнение всех необходимых функций сети и приемлемый уровень защищенности, даже если многие узлы являются самоконфигурирующимися и самоуправляемыми. Поэтому

Важно, чтобы администраторы могли обеспечить выполнение всех необходимых функций сети и приемлемый уровень защищенности, даже если многие узлы являются самоконфигурирующимися и самоуправляемыми.

модель АС должна предусматривать механизм передачи намерений администраторов-людей на все самоуправляемые узлы в таких случаях, как управление ресурсами, требования технического обслуживания и политика безопасности. В то же время в реальных сетях механизмы АС должны будут сосуществовать с традиционными инструментами управления и мониторинга в течение многих лет, поэтому необходимо обеспечить возможность поэтапного внедрения технологии АС.

Дальнейшие шаги

На момент написания данной статьи в IETF обсуждался вопрос о создании рабочей группы ANIMA. Комплексное решение для автономных сетей пока остается очень амбициозной целью. Для начала предлагается решить намного более скромные задачи: определить минимальный набор конкретных компонентов инфраструктуры для поддержки автономного взаимодействия между устройствами, а также найти применение этим компонентам в одном или двух элементарных сценариях общего использования. Главная цель, следовательно, заключается в разработке компонентов общей инфраструктуры для реализации распределенных функций. Такая инфраструктура должна обеспечивать реализацию следующих функций:

• общий способ определения узлов;;

• общую модель безопасности;;

• механизм обнаружения;;

• переговорный механизм для осуществления замкнутых взаимодействий;;

• безопасный и логически разделенный коммуникационный канал;;

• корректную модель автономного управления.

В список начальных целей намеренно не были включены некоторые важные темы, так как они считаются отдельными вопросами, которые следует рассмотреть позже:

• механизм трансляции политики на автономные узлы;;

• применение методов анализа данных автономными узлами;;

• другие внешние информационные ресурсы;;

• интеграция автономности в масштабе всей системы.

Дополнительные источники

draft-irtf-nmrg-autonomic-network-deinitions и draft-irtf-nmrg-an-gap-analysis Список рассылки: [email protected]

Благодарности

Лео Доррендорф (Leo Dorrendorf), Шэн Цзян (Sheng Jiang) и Александр Петреску (Alexandre Petrescu) просмотрели некоторые проекты документов, подготовленных Рабочей группой Интернета по исследованиям и Инженерным советом Интернета, и высказали ряд ценных идей и замечаний.

Обращение председателя IETF (продолжение)

Состоялось первое заседание новой рабочей группы TCPINC по вопросу разработки нового слоя гибкой безопасности. Эта разработка в основном предназначена для веб-приложений, которые в настоящее время не применяют меры защиты на транспортном уровне.

IANA (Уполномоченная организация по распределению нумерации в сети Интернет)

Инженерный совет Интернета активно обсуждает передачу функций IANA, анонсированную правительством США в марте. Меня эти изменения вполне устраивают, но мы, команда Инженерного совета Интернета, также рассматриваем их как часть более длительной эволюции, которая уже происходит в нашем отношении к контролю со стороны IANA. За последние 15 лет мы разработали контракты, механизмы контроля и процессы, которые в данный момент являются частью нашей работы в рамках IANA.

Наша конференция стала подтверждением того, что сообщество Инженерного совета Интернета уверено в том, что эти механизмы будут востребованы в будущем. В ближайшие недели и месяцы мы документально оформим наши представления о том, как эти механизмы отвечают требованиям контроля. Лично я настроен оптимистично. Через несколько недель после конференции мы создали рабочую группу IANAPLAN, которая стала площадкой для обсуждения этого вопроса. (Более подробную информацию см. в разделе «Новости о передаче функций IANA» на стр. 22.)

Следующая конференция

Следующая конференция IETF 91 пройдет с 9 по 14 ноября в Гонолулу, Гавайи. Приглашаю всех принять участие в этой конференции!

Между конференциями Инженерный совет Интернета продолжает работу со списками рассылки. Чего ожидать в ближайшие месяцы? Продолжится работа над такими крупными проектами, как WebRTC, HTTP 2.0 и т. д. Основные события, которые нас ожидают впереди, включают публикацию финальной версии HTTP 2.0 RFC (в этом году), а также завершение нашей части работы по передаче функций IANA (которую планируется закончить до конца 2014 года). Если вы хотите присоединиться к нам и принять участие в этой важной работе, посетите нашу страницу для новых участников.


6 _____________________________________________________________________________________________________________________________________________________________

Обращение председателя Совета по архитектуре Интернета (IAB) (продолжение)

Передача руководящих функций IANA

Совет по архитектуре Интернета направил в Корпорацию Интернета по распределению адресов и номеров (ICANN) свои комментарии относительно принципов, механизмов и процесса разработки плана передачи руководящих функций IANA от Национального управления по телекоммуникациям и информации США (NTIA) глобальному интернет-сообществу. NTIA обратилось с просьбой к ICANN об упрощении процесса выдвижения предложений, а Совет по архитектуре Интернета представил эти комментарии в проекте плана. С полным текстом комментариев можно ознакомиться по адресу: www.iab.org/wp-content/IAB-uploads/2014/04/iab-response-to-20140408-20140428a.pdf.

В ходе конференции IETF 90 участники BoF-сессии IANAPLAN задали направление по созданию плана сообщества IETF для параметров протокола IANA. Сообщество приняло следующее решение: в рамках Программы эволюции IANA, подготовленной Советом по архитектуре Интернета, будет разработана документация, которая позже будет передана новой рабочей группе для анализа и комментариев. После того как

Сообщество приняло следующее решение: в рамках Программы эволюции IANA, подготовленной Советом по архитектуре Интернета, будет разработана документация, которая позже будет передана новой рабочей группе в для анализа и комментариев.

рабочая группа придет к консенсусу, всем участникам Инженерного совета Интернета будет предоставлена последняя возможность внести свои предложения. После этого план будет направлен Группе по координации передачи руководящих функций IANA (ICG), которая объединит его с планами, разработанными другими сообществами. В итоге после изучения объединенного плана интернет-сообществом ICG представит его в NTIA.

Группа ICG состоит из 30 членов и двух координаторов, которые представляют большое число организаций, связанных с Интернетом.

• Инженерный совет Интернета в группе ICG представляют Расс Хаусли и Линн Сент-Амур (Lynn St.Amour).

• Группу по стандартизации инженерных решений в Интернете в ICG представляют Алисса Купер (Alissa Cooper) и Яри Аркко.

• Председателем группы ICG избрана Алисса Купер.

Перечень членов ICG приведен на странице: www.icann.org/resources/pages/ coordination-group-2014-06-17-en.

Важные события после конференции IETF 89

• Сара Бэнкс (Sarah Banks) и Роберт Спаркс (Robert Sparks) назначены Инженерным советом Интернета членами Комитета по надзору за рабочими предложениями RFC (RSOC).

• Шон Тернер (Sean Turner) назначен Инженерным советом Интернета членом Попечительского совета Internet Society (ISOC).

• Мэтт Миллер (Matt Miller) назначен Инженерным советом Интернета на пост менеджера по связям в ECMA TC39.

• Инженерный совет Интернета опубликовал RFC 7288 касательно «Отражений на брандмауэрах с хостом».

• Инженерный совет Интернета опубликовал RFC 7295 касательно «Отчета с семинара IAB/IRTF по отслеживанию перегрузок сети».

• Инженерный совет Интернета опубликовал RFC 7305 касательно «Отчета с семинара IAB по внедрению и переходу на интернет-технологии (ITAT)».

• Инженерный совет Интернета опубликовал RFC 7241 касательно «Связи IEEE 802/IETF».

ПРЕОДОЛЕНИЕ ПРЕПЯТСТВИЙ НА ПУТИ ЭВОЛЮЦИИ ИНТЕРНЕТА: ОБЪЯВЛЕНИЕ О СЕМИНАРЕ SEMI

Одна из задач, с которой сталкиваются технические специалисты, занимающиеся разработкой новых, более совершенных путей передачи данных через Интернет, заключается в растущем количестве устройств в сети, что приводит к разрыву соединений, как только устройства сталкиваются с чем-то новым или неожиданным. Так называемые миддлбоксы (сетевые устройства) также затрудняют простую доработку существующих путей доставки данных интернет-приложений. Образно это можно представить как информационную автостраду, где на всех основных перекрестках установлены автоматические шлагбаумы, и если они не найдут ваш номерной знак там, где он должен быть, вашу машину не пропустят.

В своей выдающейся работе, посвященной исследованию этой проблемы (http://conferences.sigcomm.org/imc/2011/docs/p181.pdf), Михио Хонда (Michio Honda) и группа соавторов отмечают, что «по меньшей мере 25 % маршрутов в какой-то мере служили препятствием для [данных], без учета стандартной защиты с помощью брандмауэра».

Чтобы более детально обсудить способы обнаружения и определения характеристик поведения этих сетевых устройств, а также найти пути обхода этих препятствий, Совет по архитектуре Интернета организует семинар «Эволюция стековой памяти в сетевых устройствах» (Stack Evolution in a Middlebox Internet (SEMI)), который пройдет в январе 2015 года в Цюрихе, Швейцария.

Посещение семинара только по приглашениям. Предполагаемым участникам было предложено представить краткое описание своей позиции по одному или нескольким вопросам, которые будут рассматриваться в ходе семинара. Более подробная информация о целях и задачах семинара содержится в информационном письме, которое можно скачать по ссылке: www.iab.org/wp-content/IAB-uploads/2014/09/stackevo-cfp.pdf. Представленные участниками краткие описания будут публиковаться на сайте IAB по мере их поступления (www.iab.org/activities/workshops/semi/).

Спонсоры семинара SEMI — Совет по архитектуре Интернета, Internet Society (ISOC) и Высшая техническая школа Цюриха (ETH Zurich). Сопредседатели семинара — Мирья Кюлевинд (Mirja Kuhlewind) и Брайан Траммелль (Brian Trammell) из ETH Zurich.


7 _____________________________________________________________________________________________________________________________________________________________

Конечно, есть люди и правительства, которые мечтают привязать внутрисетевой трафик к географическим и геополитическим границам, — заявил модератор панельной дискуссии Эндрю Салливан (Andrew Sullivan), член Совета по архитектуре Интернета и директор по архитектуре в Dyn. — Но существуют и реальные географические препятствия, влияющие на работу сети».

Первым докладчиком стал Антонио Гамба-Бари (Antonio Gamba-Bari), аспирант факультета информационных технологий Торонтского университета, член проекта IXmaps. IXmaps — это инструмент для составления интернет-карт, позволяющий конечному пользователю проследить, как его персональные данные перемещаются по Интернету, и оценить риски нарушения конфиденциальности. Разработка IXmaps началась в 2009 году, и с тех пор этот инструмент приобрел особое значение, поскольку пролил свет на методы наблюдения за интернет-трафиком, которые применяет Управление национальной безопасности США (NSA).

«Мы предлагаем людям, находящимся в разных географических точках и имеющим разных интернет-провайдеров, установить и запустить нашу программу контроля прохождения сигнала по сети, которая будет пополнять нашу базу данных маршрутов через парсинг имени хоста, сравнение задержек и топологический анализ», — заявил Гамба-Бари. — Мы определяем географическое положение промежуточных маршрутизаторов для составления карты маршрутов, по которым посылаются их пакеты. Мы выделяем точки обмена там, где эти маршруты проходят сквозь сайты, предположительно находящиеся под наблюдением NSA».

IXmaps удалось собрать свыше 30 000 маршрутов от более чем 250 участников и данные отслеживания с более чем 2 500 URL. Задача IXmaps — развеять представление об Интернете как об «облаке» и показать, что Интернет на самом

деле состоит из нескольких точек обмена, через которые проходит огромный объем трафика. Например, в США почти весь интернет-трафик проходит через коммутационные центры в 18 городах. Кроме того, трафик, который начинается и заканчивается в Канаде, часто проходит через США — этот феномен IXmaps называет «маршрутизацией по типу бумеранга».

«Есть люди и правительства, которые мечтают привязать внутрисетевой трафик к географическим и геополитическим границам.

Но существуют и реальные географические препятствия, влияющие на работу сети».

– Эндрю Салливан, модератор

Разработчиков IXmaps волнует то, что NSA обладает широкой системой наблюдения, которая перехватывает, копирует, анализирует и сохраняет весь интернет-трафик в американских сетях.

«Наша работа показала, что перехват трафика, осуществляемый NSA всего в 18 городах США, охватывает почти 100 % всего внутреннего трафика США, — заявил Гамба-Бари. — Иностранный трафик, проходящий через США транзитом, также, с большой вероятностью, перехватывается. Исходя из полученных данных, можно предположить, что 25 % внутреннего трафика Канады отправляется по маршруту через США и, следовательно, отслеживается NSA».

Исследователи Торонтского университета работают над трансформацией IXmaps из прототипа в инструмент более широкого применения, который можно использовать для составления карт интернет-маршрутов и анализа политики безопасности,

благодаря гранту, выделенному регистратурой канадского национального домена (CIRA).

Цель их работы — сделать инструмент IXmaps более надежным и универсальным, а также повысить точность компонента, отвечающего за геолокацию. Разработчики IXmaps также надеются, что их инструмент получит распространение за пределами Северной Америки.

«Мы ждем предложений по выводу IXmaps на мировой уровень и улучшению его устойчивости, — заявил Гамба-Бари. — Это будет программное обеспечение с открытым исходным кодом, чтобы каждый мог с легкостью развивать его по своему желанию». После этого директор по стратегии развития Internet Society (ISOC) Джейн Коффин (Jane Coffin) рассказала о работе по построению локальной инфраструктуры, которая включает в себя точки обмена интернет-трафиком (IXP), а также о человеческую, техническую и

управленческую инфраструктуру вокруг них.

IXP представляет собой «физическое место встречи различных IP-сетей для обмена трафиком и поддержки локальной принадлежности локального трафика, — пояснила Коффин, добавив, что это больше чем просто коробки и провода. — 95 % из этого составляет инженерная деятельность человека: каким образом будет найден общий язык между интернет-провайдерами, сетевыми операторами, сетями исследовательских и образовательных учреждений».

Продолжение на следующей странице

Эндрю Салливан, модератор панельной дискуссии, член Совета по архитектуре Интернета и директор по архитектуре Dyn

По словам экспертов, экономические и политические факторы препятствуют эффективной маршрутизации интернет-данных Кэролин Даффи Марсан (Carolyn Duffy Marsan)

огласно выводам технического пленарного заседания IETF 90, посвященного взаимодействию интернет-топологии с географией, при создании более эффективной системы маршрутизации сообщество инженеров Интернета сталкивается со множеством экономических и политических барьеров.

С


8 _____________________________________________________________________________________________________________________________________________________________

По словам экспертов, экономические и политические факторы препятствуют эффективной маршрутизации интернет-данных (продолжение)

Создавая IXP в отдаленных географических точках, Internet Society (ISOC) формирует местные сообщества. «Стоит вам улучшить качество интернет-услуг, как спрос на них сразу возрастает, — отметила Коффин. — Латентность снижается, а качество оказания услуги возрастает».

Помимо этого, появление точек обмена интернет-трафиком влечет за собой развитие контента. «Контент создается предприятиями, которые доверяют этой инфраструктуре, — подчеркивает Коффин. — Нам известно, что этот фактор служит своеобразным катализатором развития всей сети Интернет;; мы знаем об этом из собственного опыта и наблюдали своими глазами».

«Стоит вам улучшить качество интернет-услуг, как спрос на них сразу возрастает. Латентность снижается, а качество оказания услуги возрастает».

– Джейн Коффин, участник панельной дискуссии

Например, новая точка обмена интернет-трафиком в Кении привела к сокращению латентности с диапазона от 200 до 600 миллисекунд до диапазона от 2 до 10 миллисекунд. В результате появления новой точки обмена интернет-трафиком не только конечные пользователи в Кении ощутили возросшее качество Интернета, но

и местные операторы мобильной связи сократили затраты на международный транзит на 1,5 млн долларов США в год. Более того, точка обмена трафиком позволила стимулировать оказание государственных услуг в электронном виде и обмен информацией с налоговыми органами Кении.

Коффин также упомянула об аналогичном повышении качества связи и сокращении затрат в Аргентине и Бразилии. «В Эквадоре до установки IXP международный транзит обходился в 100 долларов США за мегабит в секунду, — отметила Коффин. — Сейчас локальный трафик стоит 1 доллар США за мегабит в секунду».

По словам Коффин, развивающиеся страны могут использовать новые точки обмена трафиком для внедрения перспективных технологий, таких как шифрование открытым ключом, IPv6 и домены верхнего уровня. «После установки в Кито в 2009 году кэширующего сервера для сети доставки контента [CDN] трафик вырос на 700 %. Это местный трафик», — добавила она.

По словам Коффин, во всем мире насчитывается более 350 точек обмена трафиком. ISOC не только занимается строительством новых точек обмена трафиком по всему земному шару, но и помогает развивать уже существующие IXP. ISOC предоставляет оборудование, техническую поддержку и экономическое руководство, а также сотрудничает с местным правительством. Коффин упомянула два существующих проекта в Африканском союзе под названием Axis I и II. В рамках данных проектов проведено 30 семинаров по обмену передовым опытом и в этом году запущено четыре точки обмена интернет-трафиком.

Кроме того, оказана спонсорская поддержка пяти региональным конференциям по всей Африке с целью собрать вместе представителей регулирующих и надзорных органов, а также сетевых операторов для обсуждения важности развития региональной интернет-инфраструктуры.

В Африке огромное количество стран, не имеющих выхода к морю, поэтому государственным структурам в некоторых из них важно сотрудничать друг с другом, — заявила Коффин. — Например, в Зимбабве прокладка кабеля длиной около 100 метров растянулась на почти два месяца из-за того, что кабель должен был пройти по мосту, которому присвоен статус исторического памятника».

Коффин подчеркнула, что точки обмена интернет-трафиком проектируются с целью сохранения локального трафика с более высоким уровнем качества и более низкими затратами, а не для централизации трафика и установления государственного контроля.

По словам Коффин, ISOC работает совместно с региональными регистраторами интернет-адресов, такими как LACNIC в Латинской Америке, а также с сетевыми информационными центрами отдельных стран, например NIC.br в Бразилии. Крупные корпорации поддерживают эту работу, предоставляя гранты и оборудование.

Коффин подчеркнула, что точки обмена интернет-трафиком проектируются с целью сохранения локального трафика с более высоким уровнем качества и более низкими затратами, а не для централизации трафика и установления государственного контроля. «Они не предназначены для использования в качестве средств мониторинга для углубленного анализа пакетов. По крайней мере, такова наша философия», — заявила она.

И последнее: Амогх Дхамдхере (Amogh Dhamdhere) представил данные о сетевой топологии и географии, полученные из Центра по прикладному анализу интернет-данных (CAIDA) Калифорнийского университета, Сан-Диего. CAIDA управляет инфраструктурой измерения параметров сети под названием Archipelago, которая состоит из 102 мониторов, осуществляющих сбор данных о трафике IPv4 и IPv6 в 39 странах. Archipelago осуществляет сбор маршрутов из всей области адресов IPv4 и IPv6, а также измерение альтернативных идентификаций для топологий на уровне маршрутизатора и измерение междоменного затора.

Дхамдхере, научный сотрудник CAIDA, рассказал о том, что с 2007 года инфраструктуре Archipelago удалось собрать 6 терабайт сжатых данных и что вся эта информация доступна для исследователей и операторов сетей. CAIDA предоставляет сырые трассировки маршрутов в оригинальной форме, организованные комплекты топологических данных и асинхронные числовые топологии для IPv4 и IPv6.

Джейн Коффин, участник панельной дискуссии и директор по стратегии развития Internet Society (ISOC)


9 _____________________________________________________________________________________________________________________________________________________________

«Одна из целей проекта, над которым мы сейчас работаем и под который получено финансирование, заключается в том, чтобы облегчить доступ к данным и их использование для исследователей и людей, интересующихся такими методами анализа, — заявил Дхамдхере. — Мы разрабатываем поддержку для множественных запросов этих данных маршрутизации и планируем объединить эти данные с другими типами данных, например, данными геолокации, аннотированными топологиями уровня АС и топологиями уровня маршрутизатора».

Кроме того, CAIDA планирует предоставлять данные, которые можно использовать для регионального анализа, например, при измерении количества маршрутов для коммуникации внутри Канады, которые покинули Канаду и прошли сквозь сетевые концентраторы США.

«Предположим, что мы сумели предсказать, что определенный регион подвергнется воздействию природных катаклизмов — урагана или шторма, или там произойдут антиправительственные выступления. Мы бы хотели узнать через работающие в данный момент мониторы все маршруты, которые проходят через этот регион, — сказал Дхамдхере. — Эти маршруты могут быть перенаправлены или даже отключены, когда произойдет такое событие».

По его словам, центр CAIDA ищет волонтеров, которые могут предоставить хостинг для дополнительных мониторов Archipelago — компьютеров Raspberry Pi, которые стоят всего 35 долларов США за штуку. Люди с мониторами Archipelago могут воспользоваться интерактивным сервисом «топология по запросу», который называется Vela: он визуализирует маршруты на карте. Другой сервис CAIDA основан на геолокации на базе DNS: он дает подсказки о географическом нахождении домена. И последнее: CAIDA предлагает хранилище инструментов и данных об

автономных системах (АС), включая карту, где применяются данные геолокации для определения АС с развернутой инфраструктурой.

Центр CAIDA ищет волонтеров, которые могут предоставить хостинг для дополнительных мониторов Archipelago — компьютеров Raspberry Pi, стоящих всего 35 долларов США за штуку. Люди с мониторами Archipelago могут воспользоваться интерактивным сервисом «топология по запросу», который называется Vela: он визуализирует маршруты на карте.

«У нас есть интерфейс, через который операторы могут вносить исправления в наши вычисления», — поясняет Дхамдхере.

Один из проектов, над которым работает в данный момент центр CAIDA, представляет собой данные, которыми сети обмениваются с IXP.

«Мы пытаемся расширить сеть точек обмена интернет-трафиком, под которым на самом деле подразумевается комплекс объединенных сетей, — заявил Дхамдхере. — Недавно мы провели работу по извлечению ретроспективных данных информационного обмена... чтобы выяснить на основании совместного размещения разных сетей в точках обмена трафиком, какие методы информационного обмена они представляют и как эти системы эволюционировали с течением времени;;

причем оказалось, что просто изучая ретроспективные данные информационного обмена, можно узнать много интересного, например, о географии распространения сетей».

Полученные данные были использованы специалистами CAIDA для анализа отключений Интернета на уровне страны, аналогичных тем, которые имели место во время событий Арабской весны, а также для изучения влияния природных катаклизмов, таких как землетрясения и ураганы. CAIDA «прилагает усилия к тому, чтобы разработать метрики и инструменты для автоматического определения отключений такого типа», — пояснил Дхамдхере.

По его словам, большая часть данных, результаты исследования и инструменты CAIDA доступны в режиме онлайн для сообщества IETF. «Если вы хотите сотрудничать с нами по какому-либо направлению или просто получить доступ к данным, свяжитесь с нами», — добавил он.

Салливан задал участникам панельной дискуссии вопрос о том, почему сетевые операторы не инвестируют в строительство точек обмена трафиком, даже если для более эффективной работы желательно сохранять локальность трафика. По словам Коффин, в таких странах, как Чад, оператор сети не может позволить себе строительство новой инфраструктуры. В других странах, например в Кот-д’Ивуаре, должностные лица не имеют материальных стимулов для построения сообществ вокруг IXP. Она отметила, что Internet Society должно объяснять правительствам разных стран важность точек обмена интернет-трафиком и то, что преимущества не всегда бывают очевидны. По ее словам, легче построить IXP, если есть возможность выделить оборудование и людей для его установки, а также организовать обучение персонала, который будет поддерживать точку обмена трафиком.

Что касается маршрутизации по типу бумеранга, Гамба-Бари предположил, что такая маршрутизация может быть обусловлена отсутствием сетевой инфраструктуры, которая могла бы поддержать более прямой путь. Например, трафик из Галифакса в Ванкувер должен проходить через США. В других случаях неэффективность информационного канала объясняется работой сетей, которые осуществляют обмен информационными ресурсами с одними сетями, но не осуществляют его с другими. Именно поэтому трафик из одного здания в другое в пределах Торонто может в итоге пройти через территорию США.


Техническое пленарное заседание IETF 90 завершилось оживленной сессией вопросов и ответов с участием присутствующих.


10 _____________________________________________________________________________________________________________________________________________________________

Присутствующий на конференции Жак Латур (Jacques Latour) из регистратуры CIRA также прокомментировал выступление, указав на то, что крупные операторы канадских сетей выступают против строительства новых IXP или обмена информацией с локальными интернет-провайдерами, так как это напрямую влияет на их доход. По его словам, все новые точки обмена интернет-трафиком в Канаде привлекают операторов связи первого уровня (Tier-1) из других стран, которые составляют конкуренцию канадским провайдерам и способствуют снижению цен, что благоприятно сказывается на потребителях. Регистратура канадского национального домена CIRA помогает устанавливать новые точки обмена трафиком в каждой провинции.

«IXP — это сердце Интернета, — заявил Латур. — Именно благодаря им создается пропускная способность. Именно они привлекают провайдеров контента. Именно благодаря им люди могут получить большой объем данных и заплатить меньше».

Коффин добавила, что для построения заинтересованного сообщества вокруг новых точек обмена трафиком в развивающихся странах, для объяснения экономических преимуществ и разрешения сомнений по поводу слежки за пользователями требуется не один год.

В Тринидаде этот процесс занял семь лет, в Боливии — три года. «Построить заинтересованное сообщество очень сложно, — отметила Коффин. — Это не грибы — попрыскал водой, и они сами выросли. Построение сообщества требует много времени и энергии».

Модератор Андрей Робачевски (Andrei Robachevsky), менеджер технологических программ ISOC, отметил, что техническое экспертное сообщество не до конца понимает, что такое безопасность и конфиденциальность Интернета в целом.

«У некоторых фундаментальных элементов есть общеизвестные уязвимые места. Например, протоколы BGP [пограничный шлюзовой протокол] и TLS [Протокол защиты транспортного уровня]. Несмотря на постоянную работу по улучшению этих элементов, результаты ее внедряются не повсеместно, — заявил Робачевски. — В то же время, если посмотреть на Интернет, он зарекомендовал себя как очень жизнеспособная система. Что не позволяет Интернету распасться на части? Технология? Люди? Деньги?»

Робачевски попросил четырех экспертов сформулировать ключевые вопросы, которые будут определять ситуацию с безопасностью и защитой личной информации в Интернете следующие 10 лет.

Люси Линч (Lucy Lynch), руководитель направления «Доверие и идентификация» в ISOC, отметила, что основной проблемой при решении вопросов безопасности и конфиденциальности информации в Интернете является масштаб.

«Я думаю, что у нас есть необходимые инструменты для обеспечения безопасности и конфиденциальности. Иногда они хорошо работают вместе, иногда — конфликтуют, — сказала Линч. — Но у нас нет системного понимания того, как следует комбинировать эти элементы в условиях увеличения масштаба. Нашей конечной целью, к которой мы должны прийти через 10 лет, является выработка системного подхода на основе имеющихся в данный момент элементов, который позволит нам работать в новом масштабе».

Модератор Андрей Робачевски (Andrei Robachevsky), менеджер технологических программ ISOC, отметил, что техническое экспертное сообщество не до конца понимает, что такое безопасность и конфиденциальность Интернета в целом.

По словам экспертов, экономические и политические факторы препятствуют эффективной маршрутизации интернет-данных (продолжение)

Амогх Дхамдхере, участник панельной дискуссии и научный сотрудник Центра по прикладному анализу интернет-данных (CAIDA) Калифорнийского университета, Сан-Диего

Панельная дискуссия Internet Society (ISOC) посвящена вопросам безопасности и конфиденциальности информации в Интернете На протяжении следующего десятилетия эта непрекращающаяся борьба окажется под влиянием новых задач и технологий

Кэролин Даффи Марсан (Carolyn Duffy Marsan)

На сегодняшний день в мире нет чудодейственного технического средства, которое позволило бы решить проблемы безопасности и конфиденциальности в Интернете в ближайшие 10 лет. К такому выводу пришли эксперты в ходе дискуссии, прошедшей при спонсорской поддержке Internet Society (ISOC) в рамках конференции IETF 90 в Торонто.

Андрей Робачевски, модератор и менеджер технологических программ Internet Society (справа)


11 _____________________________________________________________________________________________________________________________________________________________

Венди Зельтцер (Wendy Seltzer), участник панельной дискуссии и консультант по стратегии, руководитель направления «Технологии и общество» в Консорциуме Всемирной паутины, W3C (в центре)

«В процессе разработки технологий и развития на базе этих технологий нам необходимо задуматься о способах взаимодействия с общественным органами, а также властными и надзорными структурами, чтобы гарантировать наличие у наших систем свойств, необходимых для защиты пользователей».

Венди Зельтцер, участник панельной дискуссии

Ведущий инженер Cisco Дейв Оран (Dave Oran) отметил, что Интернет все чаще отражает все проблемы физического мира, включая конфликты, политику, финансовые вопросы и криминальную активность. «Наша задача на ближайшие 10 лет — проверить, можем ли мы использовать Интернет для улучшения мира в целом с точки зрения технологий, политики и космополитизма, — заметил Оран. — Это очень трудная задача, но у нас достаточно средств для ее решения. Именно поэтому, я думаю, определенные технологии для обеспечения безопасности и создания безопасной среды будут играть крайне важную роль».

По словам Венди Зельтцер, консультанта по стратегии и руководителя направления «Технологии и общество» в W3C, решить проблему безопасности и конфиденциальности информации в Интернете с применением только технологических средств невозможно.

«В процессе разработки технологий и развития на базе этих технологий нам необходимо задуматься о способах взаимодействия с общественным органами, а также властными и надзорными структурами, чтобы гарантировать наличие у наших систем свойств, необходимых для защиты пользователей», — отметила Зельтцер. — Некоторые из необходимых мер — это, например, проектировать систему с учетом простоты ее использования, чтобы конечный пользователь, будь то технический специалист или обычный пользователь, мог понимать, какой выбор мы ему предлагаем и, принимая решение, мог оценить соответствующие риски».

Дэнни Макферсон (Danny McPherson), старший вице-президент и директор по вопросам безопасности компании Verisign, отметил, что дополнительные системы безопасности, такие как устройства чтения идентификационных карт и карты маршрутов, помогут защитить инфраструктуру сети, но, в свою очередь, также генерируют еще большее количество данных, которые могут быть использованы не по назначению с точки зрения защиты личной информации. Он подчеркнул, что как только поступает информация об угрозе безопасности в отношении IP-адреса или доменного имени, их уже невозможно реабилитировать.

«С увеличением количества индикаторов компрометации информации, компьютерных атак и других средств защиты, применяемых людьми для защиты систем, одной из важнейших проблем становится понятие «выжженной земли», — пояснил Макферсон. — Большая часть той информации, обмен которой осуществляется в процессе обеспечения безопасности, представляет собой пространство адресов или пространство имен, а также, возможно, какие-то поведенческие аспекты хоста, которые наводят на мысль о деятельности вредоносных программ. Интересно то, что в случае с пространством имен восстановить хорошую репутацию сложно. Мы действуем по принципу «выжженной земли». Если я возьму ранее использовавшееся доменное имя или IP-адрес, насколько они будут пригодны к использованию, и сколько информации, связанной с ними, остается от деятельности предыдущего владельца?»

Макферсон развил мысль далее, поделившись своими сомнениями по поводу обмена информацией в группах, посвященных обсуждению вопросов безопасности. «В настоящее время отсутствует процесс удаления ложной информации из данных, которыми обмениваются эти группы.

Закрытые группы, которые пытаются обеспечить защиту от некоторых видов атак, ботнета или действий киберпреступников... очень эффективны, —

сказал он. — Но не существует подробной истории, характеризующей происхождение этих данных, способов возврата информации, восстановления репутации или схемы действий, в случае если в эти данные закралась ложная информация. За 10 лет нам предстоит увидеть немало «выжженной земли» в сфере адресов и имен. Будет трудно найти ситуации, в которых IP-адрес не оказался во внимании какой-либо [системы обнаружения нежелательного проникновения] или сенсора [системы предотвращения нежелательного проникновения] либо не попал в какой-либо черный список».

Робачевски попросил участников панельной дискуссии описать новые подходы к безопасности или защите личной информации, которые могут стать революционными.

Дэнни Макферсон, участник панельной дискуссии, старший вице-президент и директор по вопросам безопасности компании Verisign

Оран поделился аргументами за и против альтернативной архитектуры, известной как «построение сетей с информационной ориентацией» (ICN), над которой он работал на протяжении трех лет. В то время как в Интернете все усилия направлены на защиту транспортных каналов посредством таких протоколов, как TLS и IPsec, ICN не занимается каналами, а защищает контент с помощью встроенного механизма шифрования.

«У такого подхода есть несколько преимуществ. Проще понять цепь обеспечения сохранности контента;; к тому же такой подход позволяет защитить неподвижный контент таким же образом, как он был защищен в системе коммуникаций, — пояснил Оран. — Эти системы были разработаны со встроенными целостностью и функцией анализа источников происхождения данных».



12 _____________________________________________________________________________________________________________________________________________________________

Экспертная группа ISOC изучает вопрос безопасности личной информации в Интернете (продолжение)

Оран отметил, что в то время как источник данных в архитектуре ICN является анонимным, имя контента является публичным. «Вы обмениваете анонимность потребителя на анонимность контента, — сказал он. — Не ясно, равнозначный ли это обмен».

В то время как подход ICN исключает многие типы атак, он все же оставляет Интернет открытым для распределенных атак типа «отказ в обслуживании» (DDoS). «Непонятно, как бы развивались бизнес-модели Интернета в архитектуре ICN, — добавил Оран.

«Волшебного средства не существует. Сложные проблемы по-прежнему остаются сложными. Вопросы управления доверием все еще остаются нерешенными как в мире ICN, так и в мире IP».

— Дейв Оран, участник панельной дискуссии

«Волшебного средства не существует, — отметил Оран. — Сложные проблемы по-прежнему остаются сложными. Вопросы управления доверием все еще остаются нерешенными как в мире ICN, так и в мире IP».

Оран упомянул две другие перспективные технологии: функциональное шифрование и системы обработки запросов, сохраняющие конфиденциальность информации. Функциональное шифрование позволяет пользователю проводить вычисления с использованием зашифрованных данных, что удобно для сетевых устройств, выполняющих операции с данными. Но для того, чтобы функциональное шифрование применялось на практике, современная технология вычислений должна быть на порядок быстрее. В то же время системы обработки запросов, обеспечивающие конфиденциальность информации, пытаются повысить уровень защищенности крупных систем баз данных, ограничивая обработку запросов по зашифрованным данным. Дейв Оран, участник панельной дискуссии и ведущий инженер Cisco (в центре)

«Это лишь некоторые технологии, которые могут занять важное место в нашей жизни в Интернете в течение последующих лет», — заключил Оран.

Зельтцер добавила, что системы обработки запросов, сохраняющие конфиденциальность, зависят от взаимосвязанных протоколов, для которых центры сбора данных ограничивают обмен данными, а участники ограничивают разглашение своих данных.

«Наряду с математическими инструментами нам необходима и социальная организация распределенных систем и технологий, которая основывается на контроле со стороны конечного пользователя и позволяет нам как пользователям требовать лучшего обеспечения безопасности и конфиденциальности информации в системах, которыми мы пользуемся», — пояснила она.

По словам Люси Линч, в будущем на технических специалистов будет возложена ответственность за поддержание баланса между безопасностью и конфиденциальностью информации, и в ближайшие несколько лет эта борьба не закончится. Она отметила, что отношения между центрами сбора данных и пользователями в настоящее время асимметричны, так как центры сбора данных обладают большими полномочиями, а субъекты личных данных таких полномочий не имеют.

«Люди не платят деньги за право быть частью этих систем. Вместо денег они платят данными. Экономическая модель, которая могла бы поменять представление обо всем этом, должна сместить акцент с защиты субъекта персональных данных таким образом, чтобы конфиденциальность информации была сохранена;; но в таком случае субъект данных должен быть готов отдать что-то взамен — либо свои реальные и анонимизированные данные, либо деньги или что-то другое, — заявила Линч. — Речь скорее идет об установлении баланса между безопасностью,

конфиденциальностью, секретностью и пользой для общества».

В ответ на вопрос из аудитории Оран отметил, что сообщество технических специалистов Интернета в настоящее время лучше владеет вопросами безопасности и конфиденциальности информации, чем 10 лет назад, а также что в следующем десятилетии нас ожидают еще более существенные улучшения.

В будущем на технических специалистов будет возложена ответственность за поддержание баланса между безопасностью и конфиденциальностью информации... и в ближайшие несколько лет эта борьба не закончится.

«Сегодня недопустимо разрабатывать и тем более внедрять технологии, не владея вопросами обеспечения безопасности и не учитывая параметры безопасности при разработке этих технологий, — заявил Оран. — Я настроен достаточно оптимистично и думаю, что мы преодолели смену парадигм. Невозможно представить, чтобы какая-то компания далеко продвинулась в разработке технологии, и никто не спросил бы, насколько эта технология безопасна, какова модель угрозы, каковы ее уязвимые места, как она изменяет направление атаки».

Дейв Оран, участник панельной дискуссии и ведущий инженер Cisco (в центре)


13 _____________________________________________________________________________________________________________________________________________________________

Примечание редактора: В данной статье описаны некоторые новые технологические разработки, которые были продемонстрированы во время конференции IETF 90 на мероприятии Bits-n-Bites в Торонто. Кроме того, в ней освещаются некоторые подробности инновационной деятельности Группы по исследованиям сетей с информационной ориентацией, созданной в рамках Рабочей группы по исследованиям Интернета. Более подробную информацию по данной теме см. на https://irtf.org/icnrg.

Ограничения маршрутизации, основанной на имени

Имя ресурса указывает на то, что мы ищем, а адрес (локатор) указывает на то, где это находится. Исходя из этого определения, два основных варианта, являющиеся в данный момент предметом исследования, допускают маршрутизацию по именам контента (с IP-адресами, поддерживающими семантику сетевого локатора) или введение другого уровня преобразования адресов (оверлей) путем расширения семантики IP-адреса за счет указания имени местоположения, из которого может быть получена эта информация.

Недостаток первого варианта — ограниченное масштабирование (относительно объема памяти), поскольку такие концепции, как построение сетей с ориентацией на контент (CCN)1, противопоставляются пространствам имен, при разработке которых не учитывались вопросы производительности и масштабирования. Действительно, информация о маршрутизации для каждого объекта контента должна содержаться в таблице маршрутизации, а так как количество объектов контента очень велико (от 1015 до 1022)2, главной проблемой становится размер таблицы маршрутизации. Представьте, что таблицы маршрутизации включают одну запись на каждый домен верхнего уровня. В таком случае таблица маршрутизации, основанная на именах, вместила бы 2 x 108 маршрутов (по сравнению с 5 x 105 маршрутами BGP, как это было в середине 2014 года). Более того, рост размера таблиц маршрутизации и соответствующий рост

объема обработки информации со временем станут более интенсивными, так как количество доменов увеличивается на 10–15 % в год (согласно отчету Verisign за апрель 2013 года). И последнее: внедрение пространства имен нового контента —сложная задача, а поддержание иерархической древовидной структуры (резюмирование) — задача еще более непростая. Второй вариант чреват теми же трудностями, что и любой оверлей сети, согласно афоризму Д. Уилера (D. Wheeler), в котором описывается проблема большого количества уровней косвенности: «Все проблемы в компьютерных науках можно решить, добавив уровень косвенности... но обычно с его созданием появляется еще одна проблема».

Если имена становятся фундаментальной структурой процесса обмена информацией, маршрутизация на основе имен становится узким местом для масштабирования и производительности. Поэтому нет способов избежать разрешения имени с определением адреса, кроме перегрузки имен семантикой локатора.

Если имена становятся фундаментальной структурой процесса обмена информацией, маршрутизация на основе имен становится узким местом для масштабирования и производительности. Поэтому нет способов избежать разрешения имени с определением адреса, кроме перегрузки имен семантикой локатора. В результате

такие традиционные подходы к ICN, как CCN или их многочисленные варианты (см. «Сети с контентом, имеющим имя»3 и «Сети с данными, имеющими имя»4), переносят эту операцию в сферу функциональности протоколов сетевого уровня. С другой стороны, такой подход усложняет проблему ограниченного масштабирования памяти при маршрутизации по кратчайшему пути c допустимым удлинением маршрута, равным 1 (stretch-1), что уже было отмечено в многочисленных экспериментальных и теоретических исследованиях.

Локаторы контента

В обоих вариантах фундаментальная проблема такова: локализация и маршрутизация ссылаются на определенные функции, связанные с объектами (адрес и путь), которые не могут быть получены один из другого на основании локальной информации. Более того, чем выше уровень информации, на котором принимается решение о маршрутизации, тем больше затраты памяти. С другой стороны, с понижением уровня благодаря предоставлению дополнительных процессов разрешения повышается стоимость коммуникации и времени ожидания. Из этого наблюдения можно сделать следующие выводы: 1) форвардинг на основании контента требует сохранения локаторов (вместо имен) в качестве единицы информации для принятия решений о маршрутизации или форвардинге;; 2) пространство локаторов, например, X, всегда должно решать проблему масштабирования памяти при маршрутизации по кратчайшему пути с допустимым удлинением маршрута, равным 1 (stretch-1). Таким образом, функция локализации, выполняемая в x ∈ X, должна после разрешения имени контента в соответствующий локатор, например, y ∈ X, вычислить расстояние d(x,y), а функция маршрутизации (распределенная естественным образом) должна осуществлять локальное и независимое определение смежного узла для любого направления по пути без петель, чтобы входящие сообщения, отправленные по направлению y, могли его достичь. Следовательно, мы ищем пространство локаторов X, которое может быть вычислено на конечных точках с помощью функции локализации и на промежуточных узлах с помощью функции маршрутизации.


Маршрутизация информации на локаторах контента Димитри Пападимитриу (Dimitri Papadimitriou), Сахел Саххаф (Sahel Sahhaf) и Ваутер Таверньер (Wouter Tavernier)

ост объемов интернет-трафика для таких приложений, как мобильное видео и облачные вычисления, привел к появлению различных технологий, осуществляющих распределение контента с применением кэширования и репликации. Поскольку эти технологии распространения контента являются проприетарными и применяются в хранилищах данных, они не допускают уникальности или безопасной идентификации информации, обладающей именем, вне зависимости от канала распределения. Более того эти технологии обычно внедряются в качестве оверлея, что приводит к излишней неэффективности. В качестве основы всех предложенных в последнее время подходов к созданию сетей с информационной ориентацией (ICN) можно выделить две модели: модель оверлея и модель маршрутизации, основанная на имени. Цель последней — сделать данные независимыми от сети либо физического местоположения, приложения, поддержки хранилища, а также от транспортного канала или канала распределения для обеспечения мобильности пользователя и контента.

P


14 _____________________________________________________________________________________________________________________________________________________________

Маршрутизация информации на локаторах контента (продолжение)

В идеале, пространство локаторов должно быть по возможности независимым от изменений топологии, вместе с тем предоставляя необходимую информацию для расчета расстояний, где проходит его вычисление, при условии, что разные ресиверы вычисляют расстояния по той же функции расстояния.

Предстоит определить, какое пространство значений локатора лучше всех выступит в такой комбинированной роли. Очевидным выбором было бы так называемое пространство меток, обусловленное топологией. Однако такое пространство значений предрасположено к перенумерации, даже в случае нелокальных топологических изменений, следовательно, оно неприемлемо. Другой возможный вариант — повторно использовать пространство IP-адресов, так как существующие протоколы маршрутизации работают с использованием пространства локаторов. Однако IP-локаторы не имеют ассоциированного показателя расстояния, что означает, что расчет расстояния и выборочная локализация контента невозможны, если объект с одинаковым контентом доступен во множестве местоположений. В идеале, пространство локаторов должно быть по возможности независимым от изменений топологии, вместе с тем предоставляя необходимую информацию для расчета расстояний, где проходит его вычисление, при условии, что разные ресиверы вычисляют расстояния по той же функции расстояния (позже мы увидим последствия выбора модели при детализации расчета координат). Вместо

этого, ассоциируя объекты данных с локаторами контента из (гео)метрического пространства (X,d), где каждому элементу пространства X соответствует глобально уникальная геометрическая координата, а d — это функция (или метрика) расстояния, верифицирующая "x,y E X, d(x,y) = d(y,x) > 0, когда x * y, иначе d(x,y) = d(y,x) = 0 вместе с неравенством треугольника, мы выполняем эти требования и предотвращаем перенумерацию в случае топологического изменения.

Геометрическая маршрутизация на локаторах контента

Кроме того, выбор пространства координат должен выполняться параллельно с разработкой схемы маршрутизации, способной обращаться к пространству памяти (O(n.(log(n))), характеризуя такие алгоритмы маршрутизации c допустимым удлинением маршрута, равным 1 (stretch-1), как пограничный шлюзовой протокол (BGP). С этой целью мы представляем «Геометрическую маршрутизацию информации»5 в качестве варианта геометрической маршрутизации, в которой расстояния между узлами вычисляются по длине соответствующих геодезических сегментов, взятых из гиперболической плоскости H2. С точки зрения распределения информации по маршрутам, эта схема маршрутизации реализует следующий измененный алгоритм вектора расстояния, обеспечивая конструирование геодезических сегментов. Эти сегменты комбинируются посредством процедур, аналогичных маршрутизации по путям либо участкам. Для сокращения количества маршрутов наборы координат представлены в геометрических областях. Поскольку геометрические координаты ассоциированы с местоположениями объектов контента, обращение к основной модели осуществляется посредством маршрутизации геометрической информации. Координаты могут быть рассчитаны в автономном режиме с применением различных методов: с

помощью реализации сохраняющего расстояние графа задачи или варианта алгоритма Вивальди в гиперболическом пространстве, представленном моделью гиперболоида (также известной как «модель Лоида»). Искажение, привнесенное гиперболической моделью, определяется двумя параметрами: функцией расстояния и кривизной, которая представляет собой величину, определяющую степень отклонения объекта в пространстве от плоскости. Вместо того чтобы выбрать гиперболическую кривизну пространства, которая дает минимальную ошибку (позволяя избежать метода проб и ошибок с вложением функций), мы используем фундаментальную формулу, которая относит кривизну k гиперболического пространства к величине δ топологического графа:

k

21ln(

Другими словами, знание

геометрических свойств сетевой топологии дает алгоритм расчета координат аналогичной вычислительной сложности для канонического алгоритма Вивальди с евклидовым расстоянием. Если бы процедура вычисления координат не могла быть унифицирована с помощью примитивного обмена передаваемой информацией, простое расширение до инверсного сетевого протокола ARP позволило бы осуществлять предоставление координат.

Знание геометрических свойств сетевой топологии дает алгоритм расчета координат аналогичной вычислительной сложности для канонического алгоритма Вивальди с евклидовым расстоянием.


15 _____________________________________________________________________________________________________________________________________________________________

Рис. 1. Регистрация и разрешение имени контента

Предложенный подход не опирается на конструкцию виртуальной карты, полученную с применением эмпирических правил, извлеченных из скрытого гиперболического пространства, которое лежит в основе наблюдаемой топологии интернет-маршрутизатора/АС, а применяет наблюдаемые топологические характеристики.

Рис. 2. Пример операции маршрутизации геометрической информации В сравнении с моделью на основании карты, предложенной в «Форвардинг на основе жадных алгоритмов в динамичных безмасштабных сетях в гиперболических метрических пространствах» (Greedy forwarding in dynamic scale-free networks embedded in hyperbolic metric spaces)6, данный подход не опирается на конструкцию виртуальной карты, полученную с применением эмпирических правил, извлеченных из скрытого гиперболического пространства, которое лежит в основе наблюдаемой топологии интернет-маршрутизатора/АС, а применяет наблюдаемые топологические характеристики.

По сравнению с пограничным шлюзовым протоколом (BGP) с геолокацией IP он опирается на обмен локаторами контента, извлеченными из пространства IP-адресов (также известен как модель с активным источником данных).

Однако пространство локаторов IP не имеет ассоциированной метрики расстояния для предотвращения выборочной локализации, когда объект с одинаковым контентом доступен во множестве местоположений.

Для иллюстрации работы этой модели маршрутизации информации допустим, что запрашивающая сторона r, ассоциированная с координатой x, запрашивает данный объект контента и выдает запрос в соответствии с процессом, показанным на рис. 1.

Как показано в средней части рис. 2, запрашивающая сторона получает локатор (координату) y1, который ассоциируется с сервером s1.

Так как путь, соответствующий минимальному расстоянию сетевого сегмента dG(r,s1) (красного цвета), не соответствует пути с кратчайшим гиперболическим расстоянием dH(r,s1) (синего цвета), процесс выбора пути зависит от метрики расстояния. Более того, так как копия данного объекта может быть доступна на множестве серверов s1,s4, что обычно и происходит в распределенных информационных системах, запрашивающая сторона может получить ответ, в который будет входить несколько локаторов, то есть комплекс координат y1,y4 (правая часть рис. 2). Из этого комплекса координат может быть

определено гиперболическое расстояние dH.

Следовательно, он также может выбрать «ближайший» сервер, на котором доступен данный объект контента, выполнив расчет минимального расстояния dH, которое на самом деле отличается от расстояния, которое было бы получено, если бы для осуществления этого выбора использовалось расстояние сетевого сегмента dG.

Действительно, обратившись к правой стороне рис. 2, можно увидеть, что mindG(r,s1),dG(r,s4) = dG(r,s1) (синего цвета), в то время как mindH(r,s1),dH(r,s4) = dH(r,s4) (зеленого цвета);; следовательно, выбор ближайшего сервера отличается для метрического графа XG и для топологического графа V(G).

Можно провести и обратную операцию: при получении входящих пакетов, в заголовок которых входит координата, ассоциированная с источником


Терминал r: выбор между серверами контента s1 и s4

Контент Хост контента

1a. Запрос регистра: <content name> <server_name>

1b. Ответ регистра: <content name> <locator>

2a. Запрос разрешения: <content_name> [(<attributes>)]

2b. Ответ разрешения: <content name> <locator_1> (<locator_2>,…,<locator_k>)

Назначение локатора

Локатор контента

Гео-Лок

Имя контента

Терминал Регистрация и разрешение имени

контента


16 _____________________________________________________________________________________________________________________________________________________________

Маршрутизация информации на локаторах контента (продолжение)

x (то есть, локатор, ассоциированный с запрашивающим терминалом r), адрес назначения может определить расстояние d(s1,r), не привлекая дополнительное разрешение или трансляцию. Этот метод исключает запрос на обнаружение пути реверсивного форвардинга от y1 обратно к запрашивающей стороне x, как в случае с использованием имени объекта контента для продвижения запроса в сторону хоста контента.

Заключение и дальнейшие шаги

Мы предлагаем схему альтернативной маршрутизации для ICN, в которой имена контента являются назначенными локаторами, а геометрическая маршрутизация выполняется по этим локаторам. Данная модель, в которой решения о маршрутизации принимаются на локаторах контента, не использует разрешение имя-локатор на промежуточных узлах, а рассматривает вместо этого разрешение имени по конечным хостам, предоставляя им нужную информацию для выбора адреса назначения. Отличительная особенность такой модели адресации и маршрутизации обусловливается: 1) свойством локаторов контента, основанных на координатах: эти координаты могут быть использованы функцией распределенной маршрутизации для принятия решений по маршрутизации;; 2) тем фактом, что поскольку функции локализации и маршрутизации выполняются на локаторах контента, в результате локализуется кэшированный контент. Действительно, поскольку различие между сервером и локатором кэша отсутствует, если промежуточный узел хранит локальную копию объекта контента, он может зарегистрировать ее как любой другой объект, сохраненный на сервере контента. Соответственно, запрашивающая сторона могла бы получить от резолвера имен локатор или набор локаторов контента, ассоциированный с промежуточным узлом или набором узлов вместо сервера.

Для демонстрации успешной работы предложенной схемы маршрутизации информации (на основе роста функциональности и потенциальной производительности памяти, пропускной способности, а также задержки при пересылке пакета от отправителя получателю) мы разработали новые элементы маршрутизации и форвардинга, чтобы обеспечить обработку пакетов в соответствии с операциями геометрической маршрутизации. Мы провели экспериментальную оценку этой модели и схемы маршрутизации информации на испытательном стенде iLab.t и сравнили ее с передачей данных по сети с информационной ориентацией, основанной на протоколе BGP с IP-геолокацией7. По отношению к последней мы получаем коэффициент n (количество узлов) в пространстве памяти, необходимом для хранения маршрутной информации, и коэффициент V(n) в пространстве памяти, необходимый для хранения таблиц маршрутизации, ограничивая растяжение пути маршрутизации до небольшой дополнительной константы

(характеризующей геометрические характеристики топологии). Понятие

Наша дальнейшая работа будет посвящена исследованию возможной унификации процедур вычисления координат с базисными элементами обмена маршрутной информацией. Кроме того, предстоит исследовать новые подходы к кэшированию с применением топологических характеристик (таких как степень и центральность узла).

расстояния в геометрической маршрутизации и кэшировании в промежуточных узлах влияет на использование вычислительных мощностей и приводит к большей сбалансированности трафика в каналах связи и существенному уменьшению задержки при пересылке информации между терминалами и серверами. Наша дальнейшая работа будет посвящена исследованию возможной унификации процедур вычисления координат с базисными элементами обмена маршрутной информацией. Кроме того, предстоит исследовать новые подходы к кэшированию с применением топологических характеристик (таких как степень и центральность узла). Более важным является то, что исследование маршрутизации информации по локаторам контента может также стать источником для новых исследований, которые объединят алгоритмы адресации и маршрутизации.

Литература 1. Т. Копонен, М. Чавла, Б. Г. Чун, А. Ермолинский,

К. Х. Ким, С. Шенкер и И. Стоика, «Сетевая архитектура с ориентацией на данные (и не только)», материалы Конференции по прикладным программам, технологиям, архитектуре и протоколам для компьютерных коммуникаций 2007 г. (T. Koponen, M. Chawla, B. G. Chun, A. Ermolinskiy, K. H. Kim, S. Shenker, and I. Stoica, "A data-oriented (and beyond) network architecture," Proc. of 2007 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications), ACM SIGCOMM '07, стр. 181–192, Нью-Йорк, США.

2. Д. Кутшер (ред.), «Задачи для исследователя ICN» (D. Kutscher (Ed.), "ICN research challenges"), незавершенная работа, февраль 2014 г.

3. В. Якобсон, Д. К. Сметтерс, Дж. Д. Торнтон, М. Ф. Пласс, Н. Х. Бриггс и Р. Л. Брайнард, «Сети с контентом, имеющим имя», материалы форума CoNEXT 2009 (V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L. Braynard, "Networking named content," Proc. of CoNEXT 2009), стр. 1–12, Рим, Италия, декабрь 2009 г.

4. Л. Чжан, А. Афанасьев, Дж. Берк, В. Джейкобсон, К. Клаффи, П. Кроули, К. Пападопулос, Л. Ван и Б. Чжан, «Сети с данными, имеющими имя» (L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, K. Claffy, P. Crowley, C. Papadopoulos, L. Wang, and B. Zhang, "Named Data Networking"), ACM SIGCOMM Computer Communication Review (CCR), 44(3):66–73, июль 2014 г.

5. Д. Пападимитриу, Д. Колле, П. Ауденаерт и П. Демеестер, «Маршрутизация геометрической информации», материалы Международной конференции IEEE по модернизированным сетевым и телекоммуникационным системам (ANTS) (D. Papadimitriou, D. Colle, P. Audenaert, and P. Demeester, "Geometric information routing", Proc. of IEEE International Conference on Advanced Networks and Telecommuncations Systems (ANTS)), стр. 1–8, декабрь 2013 г.

6. Ф. Пападопулос, Д. Криоуков, М. Богуа и А. Вахдат, «Форвардинг на основе жадных алгоритмов в динамичных безмасштабных сетях в гиперболических метрических пространствах», материалы IEEE INFOCOM 2010 (F. Papadopoulos, D. Krioukov, M. Bogua, and A. Vahdat, "Greedy forwarding in dynamic scale-free networks embedded in hyperbolic metric spaces", Proc. of IEEE INFOCOM 2010), стр. 1–9, 2010 г.

7. С. Саххаф, Д. Пападимитриу, В. Таверньер, Д. Колле и М. Пикавет, «Эксперименты с маршрутизацией геометрической информации на локаторах контента», будет опубликовано в материалах CNERT2014 (S. Sahhaf, D. Papadimitriou, W. Tavernier, D. Colle, and M. Pickavet, "Experimentation of geometric information routing on content locators", To appear in Proceedings of CNERT2014), совмещенной с Международной конференцией по сетевым протоколам (ICNP) 2014,

октябрь 2014 г.


17 _____________________________________________________________________________________________________________________________________________________________

Безопасность маршрутизации в Интернете: стоит ли игра свеч? Мэт Форд (Mat Ford)

ходе открытого заседания Рабочей группы по исследованиям Интернета в Торонто третий приз «За достижения в прикладных исследованиях в области сетевых технологий» за 2014 год был вручен Роберту Лычеву и соавторам

за исследования преимуществ в сфере безопасности, обеспечиваемых частично развернутой архитектурой S*BGP.

Многие широко применяемые в Интернете коммуникационные протоколы не были изначально разработаны в целях обеспечения безопасности — они были предназначены для сторон, доверяющих друг другу. С развитием Интернета появились новые протоколы, направленные на защиту отдельных уязвимых мест. Внедрение этих протоколов может занять длительное время;; следовательно, вопросы взаимодействия новых протоколов, обеспечивающих более высокий уровень защищенности, с устаревшими незащищенными протоколами имеют большое значение.

Что касается маршрутизации интернет-трафика, то в этой сфере ключевой технологией является пограничный шлюзовой протокол (BGP). Была проведена большая работа по защите уязвимых мест в обеспечении безопасности BGP благодаря таким разработкам, как Инфраструктура открытого ключа ресурса (RPKI) и Безопасные расширения BGP (BGPSEC). Лычев и соавторы заинтересовались характеристиками безопасности BGPSEC при частичном развертывании. Речь, в частности, идет о преимуществах частично развернутых BGPSEC над RPKI, или «стоит ли сок (дополнительные преимущества в сфере безопасности) усилий по его выжиманию (дополнительных усилий по развертыванию)?»

В своем исследовании «Безопасность при частичном развертывании BGP» (BGP Security in Partial Deployment) (материалы ACM SIGCOMM, Гонконг, Китай, август 2013 г.), Лычев и его соавторы, Шарон Голдберг (Sharon Goldberg) и Майкл Шапира (Michael Schapira), отмечают, что (1) частично развернутые меры безопасности иногда вызывают появление новых уязвимых мест и что (2) частичное развертывание предоставляет лишь небольшие преимущества перед RPKI, если операторы не ставят безопасность выше всех остальных требований в своих политиках маршрутизации.

«На этой конференции я узнал много нового, познакомился с большим количеством людей, и я надеюсь на совместную работу с некоторыми из них в ближайшем будущем».

Роберт Лычев, победитель ANRP 2014

Говоря о награде и поездке на конференцию IETF в Торонто, Лычев отметил: «На этой конференции я узнал много нового, познакомился с большим количеством людей, и я надеюсь на совместную работу с некоторыми из них в ближайшем будущем».

Презентация Роберта доступна по адресу: www.ietf.org/proceedings/90/slides/slides-90-irtfopen-1.pdf. Аудиофайл доступен по адресу: http://recordings.conf.meetecho.com/ Playout/watch.jsp?recording=IETF90_ IRTFOPEN&chapter=chapter_0 (начало на отметке 00:09:00).

Номинации ANRP 2015

Период выдвижения номинантов на соискание премий, которые будут вручены в 2015 году, закончился

31 октября 2014 г.

Роберт Лычев (справа) получает награду из рук Ларса Эггерта (Lars Eggert), председателя Рабочей группы по исследованиям Интернета.

В


18 _____________________________________________________________________________________________________________________________________________________________

Введение

Разработкой решений для беспроводных сетей ограниченных устройств, также известных как маломощные сети и сети с потерями, которые по праву можно назвать краеугольным камнем Интернета вещей, занимаются несколько рабочих групп.

• Рабочие группы 6lo (WPAN) разработали стандарты для эффективного переноса (длинных) пакетов IPv6 на (короткие) фреймы IEEE802.15.4 и другие технологии уровня каналов связи.

• Рабочая группа ROLL определила протокол маршрутизации RPL, который

делает возможными многоскачковые топологии в ограниченных сетях.

• Рабочая группа 6TiSCH получила право на запуск верхнего стека на базе протокола IPv6 поверх IEEE802.15.4 TSCH.

Технология TSCH, широко применяемая в маломощных беспроводных решениях для мониторинга в промышленности, гарантирует сверхнизкую мощность и высокую надежность, а также привносит детерминизм в LLN.

• Другие группы в сфере LLN, включая рабочие группы CoRE, ACE, DICE и LWIG.

Каждая из указанных выше рабочих групп занимается изучением одного из подмножеств Интернета вещей. Именно поэтому очень важно не забывать о целостной картине и постоянно интегрировать RFC и I-D, поступающие от этих рабочих групп, в одну рабочую сеть, чтобы иметь возможность выявлять потенциальные конфликты или пробелы. С этой целью рабочие группы 6TiSCH, 6lo и ROLL провели на конференции IETF 90 совместный семинар по тестированию Plugfest3 под председательством Ксавье Вилайосана из Открытого университета Каталонии и Инес Роблес из LMF Ericsson.

Технические результаты

Паскаль Туберт (Pascal Thubert) из Cisco Systems4 и Томас Ваттейн из Linear Technology5 представили совместную разработку архитектуры с множеством LLN, подготовленную РГ 6TiSCH. Они соединили две беспроводные сети SmartMesh IP через два промышленных сетевых коммутатора Cisco i3000. SmartMesh IP от Linear Technology

[Важно не забывать о целостной картине и постоянно интегрировать RFC и I-D, поступающие от этих рабочих групп, в одну рабочую сеть, чтобы иметь возможность выявлять потенциальные конфликты или пробелы.

Слева направо: Поуриа Занд (Pouria Zand), Александр Роское (Alexander Roscoe), Виктория Пиментел Гуэрра (Victoria Pimentel Guerra), Юрген Шонвальдер (Jurgen Schonwalder), Самита Чакрабарти (Samita Chakrabarti), Седрик Аджи (Cedric Adjih), Николя Аччеттура (Nicola Accettura), Паскаль Туберт (Pascal Thubert), Пере Тусет (Pere Tuset), Томас Ваттейн (Thomas Watteyne), Томас Ейчингер (Thomas Eichinger), Инес Роблес (Ines Robles), Оливер Хам (Oliver Hahm), Цинь Ван (Qin Wang), Майкл Ричардсон (Michael Richardson), Ксавье Вилайосана (Xavier Vilajosana)

Семинар по тестированию Plugfest, посвященный маломощным сетям с потерями, демонстрирует выполнение кода Интернета вещей Томас Ваттейн (Thomas Watteyne), Инес Роблес (Ines Robles) и Ксавье Вилайосана (Xavier Vilajosana)

В ходе конференции IETF 90 рабочие группы 6TiSCH, 6lo и ROLL провели семинар по тестированию, посвященный маломощным сетям с потерями (LLN), — мероприятие, адресованное всем участникам конференции, заинтересованным в получении практического опыта c технологиями Интернета вещей (IoT). Свои разработки в виде RFC, проектов интернет-документации (I-D), программных инструментов и аппаратного обеспечения, которые относятся к технологии, стандартизованной РГ 6TiSCH, 6lo и ROLL, представили восемь команд. Представленные разработки главным образом ориентированы на переключение каналов с таймслотами IEEE802.15.4e (TSCH), архитектуру 6TiSCH, IPv6 в маломощных беспроводных сетях личного пользования (6LoWPAN)1, а также протокол маршрутизации для маломощных сетей и сетей с потерями (RPL)2. В этой статье речь пойдет о технических задачах и результатах мероприятия, важности выполнения кода и связующей роли таких мероприятий для рабочих групп, занимающихся Интернетом вещей.


19 _____________________________________________________________________________________________________________________________________________________________

представляет собой коммерческий продукт, оснащенный 6LoWPAN и IEEE802.15.4e TSCH, в котором используются технологии, сходные с технологиями, стандартизованными 6TiSCH. Устройства Cisco играют роль базового маршрутизатора 6LoWPAN6, объединяя две независимые беспроводные сети SmartMesh IP под единым префиксом IPv6.

Проект OpenWSN7 Калифорнийского университета в Беркли представляет собой реализацию (с открытым кодом) стека протоколов, стандартизованного РГ 6TiSCH и перенесенного на различные аппаратные и программные средства. Николя Аччеттура (Калифорнийский университет, Беркли), Пере Тусет и Ксавье Вилайосана (Открытый университет Каталонии), Цинь Ван и Тэнфэй Чан (Tengfei Chang) (Пекинский научно-технический университет), Марсело Баррос (Marcelo Barros) и Витор Гарбеллини (Vitor Garbellini) (Федеральный университет Уберландии), а также Томас Ваттейн (координатор проекта OpenWSN) продемонстрировали 10-сенсорную сеть устройств OpenMote, где реализованы последние I-D, разработанные рабочей группой 6TiSCH8,9,10,11. В ходе демонстрации клиент Протокола ограниченного приложения (CoAP) вызывал резервирование ячеек канального уровня в многоскачковом маршруте.

OpenMote12 — это начинающая компания, которая разрабатывает аппаратное обеспечение для Интернета вещей. В ее основе лежит OpenMote — полностью программируемая и простая в использовании коммуникационная платформа с IEEE802.15.4.

Проект OpenWSN Калифорнийского университета в Беркли представляет собой реализацию (с открытым кодом) стека протоколов, стандартизованного РГ 6TiSCH и перенесенного на различные аппаратные и программные средства.

Множество реализаций с открытым кодом, включая OpenWSN, полностью поддерживают OpenMote. Соучредители компании Пере Тусет и Ксавье Вилайосана

продемонстрировали, как превратить OpenMote в беспроводное устройство захвата пакетов для Wireshark, а также обсудили текущую работу по поддержке операционной системы FreeRTOS в энергосберегающем режиме. Седрик Аджи из Национального исследовательского института Франции (Inria) продемонстрировал работу испытательного стенда IoT-LAB13 FIT-IoT. Этот открытый испытательный стенд включает 2 728 беспроводных устройств, используемых на шести площадках во Франции. Веб-интерфейс RESTful позволяет пользователю удаленно резервировать некоторое количество устройств, перепрограммировать их с помощью встроенного ПО и контролировать их активность. На платформах IoT-LABН могут использоваться несколько реализаций с открытым кодом, включая OpenWSN и RIOT14.

Оливер Хам (Inria) и Томас Ейчингер (Свободный университет Берлина) представили RIOT, дружественную операционную систему для Интернета вещей. Они организовали демонстрацию операционной системы RIOT с выполнением стека протоколов из проекта OpenWSN на плате IoT-LAB_M3. Юрген Шонвальдер (Бременский университет Якобса) продемонстрировал реализацию 6loWPAN-MIB15 в Contiki с выполнением AVR Raven.

OpenMote — это начинающая компания, которая разрабатывает аппаратное обеспечение для Интернета вещей. В ее основе лежит OpenMote — полностью программируемая и простая в использовании коммуникационная платформа с IEEE802.15.4.

В этом I-D определяется комплекс счетчиков для мониторинга поведения реализации стека 6LoWPAN для пакетов, ошибок, сжатия, параметров фрагментации и т. д. В ходе демонстрации осуществлялось извлечение этих счетчиков через простой протокол управления сетью (SNMP) и CoAP на устройствах 6lo16.

Винсент Ладевезе (Vincent Ladeveze)17 разрабатывает диссекторы Wireshark для IEEE802.15.4e TSCH и других I-D из РГ 6TiSCH. Он занимается построением 16-канального сниффера IEEE802.15.4 путем соединения 16 устройств, работающих со встроенным ПО OpenWSN, на которых имеется программное обеспечение, группирующее эти потоки захваченных пакетов и направляющее их в Wireshark.


На семинаре Plugfest также была представлена работа по расширению Wireshark для аккуратного разделения пакетов IEEE802.15.4e TSCH.


20 _____________________________________________________________________________________________________________________________________________________________

Семинар по тестированию Plugfest, посвященный маломощным сетям с потерями, демонстрирует выполнение кода Интернета вещей (продолжение)

Способность одновременной проверки состояния 16 частот IEEE802.15.4 необходима для отладки решений по переключению каналов, таких как IEEE802.15.4e TSCH.

Нестор Тиглао (Nestor Tiglao) (Филиппинский университет) представил открытое решение Sewio для сниффера, в котором несколько беспроводных устройств могут располагаться на расстоянии друг от друга и отправлять отчеты через подсеть Ethernet о различных захваченных беспроводных пакетах на единую копию Wireshark. Таким образом, обеспечивается отладка географически протяженных беспроводных сетей.

Нетехнические результаты

Успех семинара по тестированию LLN в рамках конференции IETF 90 подчеркнул важность выполнения кода на ранних стадиях процесса стандартизации.

Семинар по тестированию Plugfest подчеркнул важность постоянной интеграции I-D и RFC, создаваемых разными рабочими группами, а также подтвердил, что такая интеграция является полным и бесконфликтным решением.

Ксавье Вилайосана, соучредитель OpenMote, демонстрирует, как превратить OpenMote в беспроводное устройство захвата пакетов для Wireshark.

[Семинар по тестированию] также поставил вопрос о создании Инженерным советом Интернета органа, который осуществлял бы надзор за деятельностью рабочих групп, занимающихся вопросами Интернета вещей, чтобы выявить потенциальные противоречия на ранних стадиях процесса стандартизации, возможно, задолго до реализации.

В случае продолжения работ по стандартизации в РГ 6TiSCH, когда документы еще находятся на стадии I-D, тестирование реализаций позволяет контролировать то, что предлагается, а также помогает дорабатывать и пересматривать принятые решения с целью повышения качества создаваемых документов. Поскольку возможность формального принятия реализаций повышает качество создаваемых I-D или RFC, мы поддерживаем деятельность в этом направлении, например, программу Code-Match.

Более того, в сфере стандартизации LLN различные РГ фокусируются на отдельных аспектах этой предметной области. Семинар по тестированию Plugfest подчеркнул важность постоянной интеграции I-D и RFC, создаваемых разными рабочими группами, а также подтвердил, что такая интеграция является полным и бесконфликтным решением. Он также поставил вопрос о создании Инженерным советом Интернета органа, который осуществлял бы надзор за деятельностью рабочих групп, занимающихся вопросами Интернета вещей, чтобы выявить потенциальные противоречия на ранних стадиях процесса стандартизации, возможно, задолго до реализации.

Благодарности

Мы благодарим председателей Рабочей группы Майкла Ричардсона, Паскаля Туберта, Самиту Чакрабарти и Ульриха Херберга (Ulrich Herberg) за то, что они согласились принять участие в этом мероприятии;; председателя Инженерного совета Интернета Яри Аркко и директоров областей Адриана Фаррела (Adrian Farrel), Алию Атлас (Alia Atlas) и Теда Лемона (Ted Lemon) за инициативу в организации мероприятия;; Стефани Маккаммон (Stephanie McCammon) за помощь в организации мероприятия. Также выражаем отдельную благодарность командам, принявшим участие в семинаре Plugfest, которые упорно трудились, отказывая себе в отдыхе, и обеспечили успешное проведение семинара.

Томас Ваттейн из Linear Technology представил совместную реализацию архитектуры с множеством LLN, разработанную РГ 6TiSCH.

Ссылки 1. «Формат сжатия для дейтаграмм IPv6 в сетях на

основе IEEE 802.15.4» [RFC 6282] ("Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks" [RFC 6282])

2. «RPL: Протокол маршрутизации IPv6 для маломощных сетей и сетей с потерями» [RFC 6550] (RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC 6550])

3. Руководства и дополнительная информация доступны по адресу: https://bitbucket.org/6tisch/ meetings/wiki/140720a_ietf90_toronto_ plugfest

4. http://www.cisco.com/

5. http:// www.linear.com/dust

6. Базовый маршрутизатор 6LoWPAN [draft-thubert-6lowpan-backbone-router-03, проект в стадии разработки]

7. http://openwsn.berkeley.edu/

8. Минимальная конфигурация 6TiSCH [draft-ietf-6tisch-minimal-02, проект в стадии разработки]

9. Подуровень работы 6TiSCH (6 вершин) [draft-wang-6tisch-6top-sublayer-01, проект в стадии разработки]

10. Планирование без буферизации 6TiSCH [draft-dujovne-6tisch-on-the-fly-03, проект в стадии разработки]

11. Метка потока IPv6 в домене RPL [draft-thubert-6man-flow-label-for-rpl-03, проект в стадии разработки]

12. http://www.openmote.com/

13. https://www.iot-lab.info/

14. http://www.riot-os.org/

15. Определение управляемых объектов для IPv6 в маломощных беспроводных сетях личного пользования (6LoWPAN) [draft-ietf-6lo-6lowpan-mib-01, проект в стадии разработки]

16. Стек 6lo на основе 6LoWPAN (RFC 4944, RFC 6282, RFC 6775) с поддержкой различных канальных уровней

17. Представлен Томасом Ваттейном от имени Винсента

Ладевезе


21 _____________________________________________________________________________________________________________________________________________________________

Новости Рабочей группы по исследованиям Интернета Ларс Эггерт (Lars Eggert)

В ходе конференции IETF 90 в Торонто, Канада, четыре из девяти зарегистрированных исследовательских групп (ИГ) Рабочей группы по исследованиям Интернета провели совещания:

• Сети с информационной ориентацией (ICNRG)

• Криптофорум (CFRG)

• Сети с программным управлением (SDNRG)

• Управление сетями (NMRG)

Кроме совещаний зарегистрированных исследовательских групп также состоялось первое открытое заседание формируемой исследовательской группы по управлению латентностью центра обработки

данных (DCLCRG).

Кроме того, было проведено совещание для обсуждения новой исследовательской группы по виртуализации сетевых функций (NFVRG).

Обе формируемые исследовательские группы планируют провести заседания во время конференции IETF 91 в Гонолулу, Гавайи;; группа NFVRG также запланировала промежуточное совещание в районе залива Сан-Франциско 4 сентября 2014 года.

Третья формируемая исследовательская группа по глобальному доступу в Интернет для всех (GAIA) не проводила совещания в ходе конференции IETF 90;; одно совещание этой группы состоится 20–21 октября 2014 года в Кембридже, Соединенное Королевство, и еще одно совещание планируется совместить с симпозиумом Ассоциации вычислительной техники (ACM) по теме «Компьютеризация для развития» (Computing for Development) в декабре 2014 года.

С момента проведения конференции IETF 89 было опубликовано три новых RFC в потоке IRTF RFC:

• RFC 7122, посвященный слоям конвергенции дейтаграммы для пакетного протокола, ориентированного на отказоустойчивые сети и сети, устойчивые к задержке (DTN), и LTP-протоколу.

• RFC 7242, посвященный TCP-протоколу слоев конвергенции для сетей, устойчивых к задержке.

• RFC 7253 об алгоритме аутентифицированного шифрования OCB.

Открытое совещание Рабочей группы по исследованиям Интернета на конференции IETF 90 стало местом представления исследовательской работы обладателя третьего приза «За достижения в прикладных исследованиях в области сетевых технологий» за 2014 год (ANRP). Роберт Лычев представил свое исследование преимуществ обеспечения безопасности частично развернутой S*BGP (см. «Безопасность маршрутизации в Интернете: стоит ли игра свеч?» на стр. 17). Вторая презентация ANRP была отложена до конференции IETF 91 из-за визовых проблем, поэтому на Открытом совещании IRTF в Гонолулу будут представлены три окончательные презентации, отмеченные призами в 2014 году. Вместо второй презентации ANRP профессор из Торонто Микеле Моска (Michele Mosca) провел обсуждение на тему квантовой криптографии.

Чтобы получать свежие новости о деятельности Рабочей группы по исследованиям Интернета, подпишитесь на список рассылки: www.irtf.org/mailman/ listinfo/irtf-discuss.

Роберт Лычев, обладатель третьего приза «За достижения в прикладных исследованиях в области сетевых технологий» за 2014 год (ANRP), представляет результаты своей работы.

Номинации ANRP 2015

Приз ANRP вручается за плодотворную работу над прикладными исследованиями в области сетевых технологий, которые имеют значение для развития транспортной инфраструктуры Интернета и соответствующих действий по стандартизации. Период выдвижения номинантов на соискание премий ANRP, которые будут вручены в 2015 году, закончился 31 октября 2014 г. С более подробной информацией можно ознакомиться по адресу: https://irtf.org/anrp.


22 _____________________________________________________________________________________________________________________________________________________________

Новости о передаче функций IANA Из блога Яри Аркко от 10 сентября 2014 года. См. оригинал публикации по адресу: www.ietf.org/blog/2014/09/iana-transition-update/

ирокое обсуждение передачи функций Национального управления по телекоммуникациям

и информации США (NTIA) по контролю за деятельностью Уполномоченной организации по распределению нумерации в сети Интернет (IANA) привело к созданию Группы по координации передачи руководящих функций IANA (ICG) (www.icann.org/ stewardship/coordination-group) и Рабочей группы Инженерного совета Интернета под названием IANAPLAN (https://datatracker.ietf.org/doc/charter-ietf-ianaplan/).

Присутствие большого количества заинтересованных сторон, множества мнений, сложная для понимания роль NTIA — все это может привести к путанице. Что же скрывается за происходящим? Какова наша роль в этом процессе? Каковы наши задачи?

Прежде всего, необходимо понять, что функция IANA — учет, а не разработка правил. IANA играет для Интернета очень важную роль, но фактически стратегические решения, такие как назначение доменов верхнего уровня или номеров протоколов, принимаются другими органами. Например, эти решения могут быть приняты путем учета мнений заинтересованных сторон в Корпорации Интернета по распределению адресов и номеров (ICANN) или при единодушном согласии членов Инженерного совета Интернета (IETF).

Во-вторых, передача функций затрагивает роль NTIA, ведь речь идет о передаче контроля интернет-сообществу. Вопрос не в том, кто будет выполнять функции IANA. Этот аспект остается без изменений. Функция контроля налагает определенную ответственность за отслеживание эффективности и принятие необходимых мер по исправлению ситуации. За последние 15 лет сообщество уже не раз выполняло функции контроля, поэтому, по моему мнению, такая передача функций не является резкой переменой, как ее воспринимают некоторые. Основная ответственность за планирование передачи функций лежит на сообществах, которые ежедневно взаимодействуют с IANA, в частности, на Инженерном совете Интернета, региональных интернет-регистратурах (RIR) и сообществах ICANN — gTLD и ccTLD. Предполагается, что эти сообщества будут взаимодействовать с более широким интернет-сообществом, чтобы их планы не

шли вразрез с усилиями гражданского общества, правительства, деловых кругов и т. д.

В Инженерном совете Интернета эту работу выполняет рабочая группа IANAPLAN под председательством Лесли Дайгл (Leslie Daigle) и Марка Бланшета (Marc Blanchet). Аналогичным образом региональные интернет-регистратуры уже создают собственные организации для разработки плана, а различные сообщества в ICANN работают над разработкой плана в рамках Общей рабочей группы. Ссылки на результаты деятельности сообществ находятся на странице ICG по адресу: www.icann.org/en/stewardship/community. Несмотря на то что один год кажется длительным сроком для разработки и принятия плана, разработка плана состоит из множества этапов и включает большое количество дискуссий, которые проходят по всему миру.

Координацией этой деятельности занимается группа ICG, в состав которой входят 32 представителя интернет-сообщества. Работа продвигается полным ходом, и, за редким исключением, все участники уверены, что эти изменения принесут сети Интернет только пользу. Однако сначала предстоит решить несколько сложных задач.

Несмотря на то, что один год кажется длительным сроком для разработки и принятия плана, разработка плана состоит из множества этапов и включает большое количество дискуссий, которые проходят по всему миру.

Первая задача — уложиться в сроки. Следует предусмотреть время, которое понадобится: (a) NTIA для принятия решения, (б) для тестирования новых механизмов, (в) для обеспечения согласованности всех планов и (г) для получения замечаний от сообществ.

Еще одна задача — обеспечить подотчетность. Некоторые рассматривали NTIA как конечную инстанцию на случай, если произойдет неожиданная неприятность. Несмотря на то что не все придерживаются этой точки зрения, каждый

хочет удостовериться в наличии эффективных мер защиты после передачи функций. Для выполнения этого требования корпорация ICANN запустила проект по совершенствованию контроля и отчетности, но найти решение, которое удовлетворит все стороны, будет непросто.

Необходимые решения зависят от обсуждаемых функций IANA. Например, я уверен, что у Инженерного совета Интернета имеются хорошие механизмы для отслеживания деятельности IANA, касающейся параметров протокола. Контракт, заключенный между Инженерным советом Интернета и Корпорацией Интернета по распределению адресов и номеров, определяет обязанности и роли обеих сторон. Любые затруднения ежедневно отслеживаются, любые серьезные проблемы могут быть рассмотрены внутри организаций — вплоть до выполнения пункта о прекращении действия контракта. Аналогично, если стратегические решения Инженерного совета Интернета выполняются неверно, существуют механизмы предупреждения, апелляции, комитет по номинациям и механизмы отзыва, которые позволяют сообществу исправлять ошибки или менять руководителей. Улучшение отслеживаемости в ICANN будет полезным, но не абсолютным требованием для выполнения Инженерным советом Интернета своей роли. Но это утверждение, вероятно, не относится к именам в регистрах IANA, и в этой сфере потребуется серьезная работа.

Третья задача — связаться со всеми сторонами, которые должны участвовать в этом процессе, и прийти к согласию. Всем нам предстоит вести обсуждение с более широким сообществом, чем обычно, ведь значительная поддержка плана передачи функций требует участия представителей различных слоев интернет-сообщества, от инженеров и экспертов по доменным именам до предпринимателей и политиков. Я приложу все усилия к тому, чтобы Инженерный совет Интернета распространил наш план среди широкой аудитории и привлек заинтересованных лиц.

Для содействия РГ IANAPLAN подпишитесь на список рассылки: www.ietf.org/mailman/listinfo/ianaplan

Ш


23 _____________________________________________________________________________________________________________________________________________________________

Неформальные собрания Инженерного совета Интернета: последние новости Мэт Форд

ачало нового проекта в IETF обычно сопровождается BoF-сессией, где обсуждаются цели работы, соответствие целей, которые преследует данная работа, целям IETF, а также уровень заинтересованности и

поддержки данной работы. В этой статье мы представим обзор BoF-сессий, состоявшихся на конференции IETF 89, а также рассмотрим их цели и результаты. Если вы хотите организовать BoF-сессию, ознакомьтесь с RFC 5434: советы по организации успешной BoF-сессии.

Абстракция и контроль транспортных сетей (ACTN)

Описание: Операторы сетей занимаются строительством и управлением мультидоменными сетями. Эти домены могут представлять собой комплексы из каналов связи и узлов, с разными технологиями, административными зонами и набором оборудования.

Во многих случаях установление сквозных соединений, охватывающих множество доменов, представляет сложность для операторов из-за проблем в эксплуатации и вопросов функциональной совместимости. Из-за этих затруднений внедрение новых служб, где часто необходимы соединения, пересекающие множество доменов, требует большого объема планирования и ручной работы для стыковки оборудования и технологий от разных поставщиков. Во многих случаях установление сквозных соединений, охватывающих множество доменов, представляет сложность для операторов из-за проблем в эксплуатации и вопросов функциональной совместимости. Из-за этих затруднений внедрение новых служб, где часто необходимы соединения, пересекающие множество доменов, требует большого объема планирования и ручной работы для стыковки оборудования и технологий от разных поставщиков.

Задача ACTN — упростить эксплуатацию виртуальной сети: создать виртуализованную среду, позволяющую операторам видеть и контролировать множество мультиподсетей, сетей с различными технологиями как единую виртуализованную сеть. Сетевая абстракция транспортных сетей также необходима операторам, осуществляющим консолидацию сетевых служб в многочленные виртуальные транспортные сети. Это позволит ускорить оперативное развертывание новых служб, включая более динамичные и гибкие службы, улучшит общую работу сети и масштабирование существующих служб. В результате обсуждения с операторами была отмечена необходимость в эксплуатации виртуальной сети с абстракцией базовой технологии и доменов поставщиков. Эта BoF-сессия не ставила целей по формированию рабочей группы. Ее задачей было дать операторам возможность рассказать о своей практике эксплуатации сетей, выделить проблемные аспекты, поделиться требованиями и целями виртуализации сети, краткосрочными и долгосрочными целями.


Н

Краснозобый колибри

(Archilochus colubris)


24 _____________________________________________________________________________________________________________________________________________________________

Неформальные собрания Инженерного совета Интернета: последние новости (продолжение)

Материалы: www.ietf.org/proceedings/90/minutes/minutes-90-actn

Результаты: В ходе дискуссии операторы получили возможность рассказать о своих потребностях и трудностях;; кроме того, были подняты некоторые общие темы, например, сквозной режим обслуживания в мультидоменных или многослойных сетях. Что касается работы с протоколами, ясности в этом вопросе было меньше. Обсуждение сценариев использования, возможных решений, определение масштаба проблемы и т. д. продолжатся в списке рассылки.

Пул функций виртуализованной сети (vnfpool)

Описание: Это вторая BoF-сессия по данному вопросу;; предыдущая сессия состоялась в ходе конференции IETF 89. Основной задачей сессии было прийти к консенсусу по уставу для рабочей группы vnfpool. После предыдущей сессии предлагаемый устав был обновлен: основной упор был сделан на организацию пулов в рамках индивидуальных функций виртуализованной сети (VNF), а не на надежность всего графа службы;; была внесена ясность в отношения между vnfpool и рабочей группой по связыванию функций обслуживания;; кроме того, было принято решение исключить синхронизацию состояния службы из объема работ на начальном этапе.

После предыдущей сессии предлагаемый устав был обновлен: основной упор был сделан на организацию пулов в рамках индивидуальных функций виртуализованной сети (VNF), а не на надежность всего графа службы;; была внесена ясность в отношения между vnfpool и рабочей группой по связыванию функций обслуживания;; кроме того, было принято решение исключить синхронизацию состояния службы из объема работ на начальном этапе.

Материалы: www.ietf.org/proceedings/90/minutes/minutes-90-vnfpool

Результаты: Остается неясным, есть ли необходимость в стандартизации новых технологий в этой сфере;; кроме того, для решения некоторых вопросов необходимо привлечь к этой дискуссии более широкое сообщество. Продолжение работы ожидается в списках рассылки.

Рабочая группа по сетям, устойчивым к задержке (DTNWG)

Описание: На сессии были рассмотрены вопросы о переходе технологий, разработанных исследовательской группой IRTF DTN, на этап стандартизации через формирование новой рабочей группы IETF. Присутствующим был представлен проект устава рабочей группы и темы работы, основанные на Пакетном протоколе DTN. Целью сессии было обсуждение проекта устава и представление потенциальных тем работ, а также определение уровня поддержки для проведения работ в рамках IETF. Желаемым результатом по окончании сессии было формирование новой рабочей группы после окончания конференции IETF 90.

Красный кардинал (Cardinalis cardinalis)


25 _____________________________________________________________________________________________________________________________________________________________

Материалы: www.ietf.org/proceedings/90/minutes/minutes-90-dtnwg

Результаты: Несмотря на необходимость дальнейшей доработки устава, сессия прошла продуктивно и с хорошим настроем;; в ходе сессии несколько человек выразили желание работать над документами в рабочей группе DTN.

Сценарии использования в автономных сетях (UCAN)

Описание: По данному вопросу см. статью «Автономные сети» на стр. 1 журнала IETF.

Материалы: www.ietf.org/proceedings/90/minutes/minutes-90-ucan

Результаты: Эта сессия не ставила цели сформировать рабочую группу. Было представлено множество различных сценариев использования. Председатели и другие заинтересованные лица продолжат деятельность по разработке более предметного устава рабочей группы в списке рассылки.

Сессия началась с резюме результатов сессии IETF 89 igovupdate, после чего участники перешли к обсуждению передачи функций NTIA более широкому интернет-сообществу и Группе координации.

IANAPLAN (ianaplan)

Описание: Рабочая группа по организации BoF-сессии. Сессия началась с резюме результатов сессии IETF 89 igovupdate, после чего участники перешли к обсуждению передачи функций NTIA более широкому интернет-сообществу и Группе координации. В конце состоялось обсуждение влияния IETF и предложенных планов действия, включая проект устава рабочей группы. Для получения более подробной информации о передаче функций IANA см. «Новости о передаче функций IANA» под авторством председателя Инженерного совета Интернета Яри Аркко на стр. 22 данного выпуска журнала IETF.

Материалы: www.ietf.org/proceedings/90/minutes/minutes-90-ianaplan

Результаты: Дискуссия прошла успешно. Присутствующие поддержали идею формирования рабочей группы с несколько более ограниченным уставом, чем представленный в ходе BoF-сессии.

Обыкновенный фазан (Phasianus colchicus)


26 _____________________________________________________________________________________________________________________________________________________________

Краткие факты о IETF 90 Оплатили участие: 1 183 (больше запланированного на 113 человек)

Новые участники: 153

Количество стран: 53

Активность IETF после проведения IETF 89 (март — июль 2014 года)

Новые РГ: 3

Закрыто РГ: 0

Зарегистрированные РГ: 123

Новые и исправленные проекты интернет-документов (I-D): 1 848

Опубликованные RFC: 173

• 105 треков стандарта, 7 BCP, 8 экспериментальных , 50 информационных

Социальные медиа

• YouTube: Пленарное заседание технической группы транслировалось в режиме реального времени по 47 каналам, 301 просмотр

• Twitter: 1 186 твитов с тегом #IETF90, поделились #IETF89=19000, 578 новых подписчиков

• В целом 999,5 тыс. просмотров в Facebook и Twitter

Активность IANA после проведения IETF 89

(февраль — июнь 2014 года)

Обработано более 1 705 запросов, связанных с lETF, включая:

• Просмотрено 117 I-D на финальной стадии обсуждения и 130 I-D на стадии оценки

• Просмотрен 151 I-D до получения статуса RFC, 95 из 151 содержали действия для IANA

Сотрудничество с IETF в области документации

• RFC 5226-бис находится в стадии рассмотрения и корректировки, выполняемой членами сообщества. В ближайшее время ожидается переход к финальной стадии обсуждения. См. https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/

Выполнение SLA (январь — июнь 2014 года)

• Средний процент обработки запросов, связанных с IETF: 99 %

IANA и DNSSEC

• По состоянию на 16 июля 2014 года 448 доменов верхнего уровня имеют полную цепочку сертификатов от корневого сертификата. См. http://stats.research.icann.org/dns/tld_report/

Активность редактора RFC после проведения IETF 89 (январь — июль 2014 года) Опубликованные RFC: 217

• 164 IETF (31 IETF без РГ), 5 IAB, 4 IRTF, 13 независимых

Станьте первым хостом в своей ЛВС, получившим журнал IETF!

Получайте последний выпуск журнала IETF сразу после его выхода — в печатном варианте или в электронном виде на ваш адрес электронной почты.

Подпишитесь сегодня: www.internetsociety.org/ietfjournal

Хотите узнавать новости раньше всех? Подпишитесь на наш аккаунт в Twitter @ietfjournal и читайте новые статьи сразу после их публикации.

США


27 _____________________________________________________________________________________________________________________________________________________________

Календарь конференций IETF IETF 91 IETF 93

9–14 ноября 2014 года. 19–24 июля 2015 года.

Организатор: Cisco Организатор: будет определен позднее

Место проведения: Гонолулу, штат Гавайи, США Место проведения: Прага, Чешская Республика IETF 92 IETF 94

22–27 марта 2015 года. 1–6 ноября 2015 года.

Организатор: Google Организатор: WIDE

Место проведения: Даллас, штат Техас, США Место проведения: Иокогама, Япония

Более подробная информация о прошедших и предстоящих

конференциях IETF: www.ietf.org/meeting/

Особая благодарность за организацию конференции IETF 90

Стажировки Internet Society для участия в конференциях Инженерного совета Интернета в рамках программы Лидеров следующего

поколения ISOC осуществляются при спонсорской поддержке

Этот журнал издан благодаря поддержке платиновых спонсоров программ Internet Society:


28 _____________________________________________________________________________________________________________________________________________________________

Журнал IETF Internet Society Galerie Jean-Malbuisson 15 1204 Женева, Швейцария

Издается три раза в год организацией Internet Society (ISOC).

Galerie Jean-Malbuisson 151204 Женева, Швейцария

Редактор Мэт Форд (Mat Ford)

Помощники редактора Меган Крус (Megan Kruse) Мишель Спеклер (Michelle Speckler)

Приглашенный автор Кэролин Марсан (Carolyn Marsan)

Дизайн и верстка Speckler Creative Редакционная коллегия Яри Аркко (Jari Arkko) Мэт Форд (Mat Ford) Расс Хаусли (Russ Housley) Олаф Колкман (Olaf Kolkman) Меган Крус (Megan Kruse) Люси Линч (Lucy Lynch) Грег Вуд (Greg Wood)

Электронная почта [email protected]

Наш адрес в сети www.internetsociety.org/ietfjournal

От редактора Журнал IETF придерживается правописания, приведенного в Оксфордском словаре английского языка, изд. 2-е. Если не указано иное, фотографии ©Connie Tsang и Internet Society.

Журналietf Том10, выпуск 2 • Ноябрь 2014 года...

Documents