Задавшись целью отыскать показательный пример ожесточенной борьбы производителей на телекоммуникационном рынке, достаточно проанализировать ситуацию, сложившуюся вокруг стека протоколов IPSec. В водоворот, порожденный соответствующим стандартом IETF, с каждым месяцем вовлекаются все новые силы.
Свой вклад в разыгравшуюся стихию вносят далеко не бесхитростные компании-конкуренты. Как только встает вопрос о взаимодействии продуктов IPSec, обнаруживается, что эти фирмы готовы сесть за стол переговоров и согласовать текст очередной порции спецификаций. Подливают масла в огонь и минимум четыре организации, сделавшие себе имя на тестировании: как это ни странно, они частенько занимают диаметрально противоположные позиции. Не остаются в стороне около дюжины объединений пользователей, хотя, надо признать, роль последних явно не соответствует их истинному весу.
Несмотря на то что основная часть спецификаций IPSec, в том числе регламентирующих туннелирование данных, передаваемых между компьютерами, и методы их шифрования, уже получила статус стандарта, споры о путях его совершенствования не утихают. Поставщики и компании, специализирующиеся на тестировании продуктов, ведут ожесточенные словесные баталии по вопросу о соответствии согласованному стандарту его первых реализаций. А и без того неторопливые процедуры принятия решений в стенах IETF, кажется, окончательно затормозили развитие данной области, и ранее не отличавшейся особой динамичностью.
«Образованная в IETF группа IPSec Working Group работает уже семь лет. Обычно подобная структура в составе консорциума выполняет поставленные перед ней задачи за год-полтора», — замечает Рон Калли, ведущий менеджер по средствам сетевой обработки корпорации Microsoft.
По правде говоря, существуют веские причины, осложняющие деятельность указанной рабочей группы. Стандарт на средства защиты данных в IP-сетях, первоначально создававшийся исключительно для версии IPv6, — материя непростая. К тому же конечная цель деятельности IPSec Working Group со временем претерпела значительные изменения.
«Разработка стандарта отняла столько времени прежде всего из-за того, что технологии, на которые ориентировались члены группы, не стояли на месте, — рассказывает Эндрю Ньюман, старший аналитик из Йельского университета. — Первая версия стандарта создавалась в ту пору, когда в надежной защите данных не было особой необходимости».
Однако с тех пор многое изменилось. Сегодня типичная компания использует протокол IP в локальных сетях, при организации удаленного доступа, для подключения разбросанных офисов и в приложениях электронной коммерции. Современные организации буквально наводнены многочисленными серверами удаленного доступа (RAS), инфраструктурами для обмена общедоступными ключами и средствами преобразования сетевых адресов. И охватить подобное нагромождение единой системой информационной безопасности, да еще безукоризненно соответствующей стандарту, — тяжелая задача.
Впрочем, те же аргументы справедливы и в отношении любой другой широко распространенной стандартизованной технологии, особенно если речь заходит о взаимодействии продуктов разных поставщиков. За то время, пока велась работа над протоколами IPSec, технология Secure Sockets Layer (SSL) успела прорасти из посеянных семян и превратиться в цветущее поле. Да и язык XML доказал, что различные производители при всей антагонистичности своих маркетинговых позиций способны быстро скооперироваться, когда в этом возникает острая необходимость.
Но тогда почему возник затор на пути обеспечения взаимодействия продуктов, основанных на IPSec? Как могло получиться, что после стольких выставок и публичных демонстраций состояние дел в области совместимости остается в лучшем случае неопределенным?
К ответу на эти вопросы причастны все действующие стороны. Компании, напрямую заинтересованные в продвижении определенных технологий, являются источником концептуальных разногласий внутри рабочей группы по IPSec; организации, занимающиеся тестированием, фактически работают на производителей, а голос пользователей остается практически незамеченным.
Если верить многочисленным маркетинговым заявлениям поставщиков, ситуация с совместимостью продуктов IPSec на самом деле гораздо лучше, чем кажется. По правде говоря, определенная степень взаимодействия средств IPSec действительно достигнута, однако оно проявляется только в том случае, когда требуется организовать туннельную передачу между шлюзами с фиксированными IP-адресами и имеется возможность обмениваться ключами вне сети. Если производители утверждают, что их продукты способны взаимодействовать с изделиями других компаний или даже демонстрируют сертификаты с печатями International Computer Security Association (ICSA), можете не сомневаться: речь идет всего лишь о поддержке стандарта IPSec.
«Базовая функциональность уже реализована, причем случилось это не вчера, — замечает Боб Московитц, сопредседатель IPSec Working Group и один из руководителей ICSA. — Тем не менее многие проблемы до сих пор остаются нерешенными. Например, применение протоколов Internet Key Exchange (IKE) с заранее согласованными ключами требует статических IP-адресов, а это не позволяет работать по коммутируемым телефонным линиям».
Определенные в рамках IPSec процедуры IKE предназначены для согласования параметров защищенной передачи, включая используемый в ходе сеанса алгоритм шифрования данных, между участниками сеанса связи. Очевидно, применение статических адресов и заранее согласованных ключей устроит далеко не всех пользователей. Тем из них, кто работает через обычные аналоговые модемы, присваиваются динамические IP-адреса, а партнеры и клиенты компании, получающие доступ в корпоративную экстрасеть, не могут заранее знать, какие ключи будут применяться для обеспечения информационной безопасности.
Вот почему споры о путях усовершенствования стандарта в целях поддержки удаленного доступа не утихают ни на минуту. В составе IETF даже была сформирована специальная рабочая группа по безопасному удаленному доступу; по имеющимся данным, это уже третья попытка ведущих поставщиков создать структуру, занимающуюся данной проблемой. Кажется, на сей раз она увенчалась успехом.
Участники дебатов разделились на три лагеря. Одни настаивают на использовании протокола туннелирования Layer 2 Tunneling Protocol (L2TP). Другие призывают модифицировать согласующие процедуры IKE, чтобы обеспечить поддержку более ранних методов идентификации, используемых в Internet; в рамках данного направления уже предложено несколько вариантов технологии. Наконец, представители третьей группы пытаются убедить своих оппонентов в необходимости обеспечить поддержку протокола Dynamic Host Configuration Protocol (подробнее о нем см. «Сети», 1999, № 10, с. 96. — Прим. ред.) в процедурах IKE; их предложения суммированы в проекте стандарта, который был представлен на рассмотрение IETF в декабре прошлого года.
Чтобы выяснить, какова в этом вопросе позиция того или иного производителя, достаточно проанализировать его общие воззрения в области защиты данных.
Скажем, корпорация Microsoft, в свое время вместе с Cisco Systems способствовавшая появлению на свет протокола L2TP, сегодня возглавляет ряды сторонников комбинированного подхода на базе L2TP/IPSec. L2TP возник в результате своеобразного скрещивания протокола Point-to-Point Tunneling Protocol фирмы Microsoft и технологии Layer 2 Forwarding компании Cisco (см. врезку «Технологии VPN...»).
Фирма TimeStep, традиционно позиционирующая себя в качестве поставщика VPN-продуктов для IP-сетей, разработала проект спецификаций IETF с предварительным названием IKE-XAUTH, в котором основной упор сделан на применение метода Remote Access Dial-In User Service (RADIUS) в процедурах IKE. Добавка «XAUTH» возникла как сокращение от eXternal AUTHorization (внешняя авторизация). Более того, TimeStep уже выпустила версию своего шлюза Permit Enterprise Version 2.0, основанную на указанных спецификациях.
Среди других расширений архитектуры IKE заслуживают упоминания Hybrid Mode компании Check Point Software (в ней также используется метод авторизации XAUTH) и Crack корпорации Network Alchemy.
Направление, связанное с протоколом DHCP, сегодня возглавляет компания RedCreek Communications. Разработчики из RedCreek отмечают, что предложенный ими метод (а ему посвящены уже две рабочие спецификации) позволяет настроить конфигурацию и идентифицировать клиентскую систему удаленного доступа, воспользовавшись уже существующими протоколами и процедурами IKE в немодифицированном виде. Компания RedCreek была в числе первых производителей, поддержавших самую раннюю версию IKE под названием ISAKMP/Oakley.
Эта трехполюсная картина оказалась несколько смазанной после того как некоторые апологеты протокола L2TP решили поддержать RedCreek. Корпорации Intel, Microsoft и Sun Microsystems активно участвовали в подготовке первой версии спецификаций DHCP, а Microsoft — и второй версии.
Между тем очевидно, что та же Microsoft направляет всю свою мощь на поддержку технологии, использующей L2TP. Судя по всему, фирма при этом ничем не рискует, ведь в предварительном варианте L2TP все равно предусмотрено применение протокола DHCP.
По заявлению сторонников решений на базе L2TP over IPSec, преимущество данной технологии заключается в том, что она соединяет развитые средства инкапсуляции трафика, предусмотренные в L2TP, с надежными функциями защиты данных протокола IPSec. К тому же оба протокола уже успели на практике проявить свои сильные стороны и продемонстрировать способность к взаимодействию, а все сложности их реализации ложатся на плечи производителей. а не заказчиков.
Противники данного подхода приводят свои аргументы. По их мнению, схема L2TP over IPSec создает немалые проблемы для пользователей, так как два протокола поддерживать сложнее, чем один. Кроме того, алгоритмам, заложенным в предварительном варианте спецификаций, недостает эффективности, поскольку идентификация пользователя на другом конце соединения производится уже после того, как соединение установлено. А если пользователь не прошел авторизацию на доступ к предоставляемым услугам, соединение будет разорвано.
Еще один часто повторяемый аргумент заключается в том, что метод L2TP over IPSec повышает долю служебных данных в общем объеме трафика. Парируя это обвинение, представители Microsoft утверждают, что протокол L2TP допускает сжатие заголовков пакетов, так что суммарный размер передаваемых пакетов возрастает всего на один байт.
На перспективность рассматриваемой схемы указывают некоторые аналитики, не участвующие в работе IETF. Их доводы сводятся к тому, что L2TP сегодня активно используется для инкапсуляции в IP-пакеты самых разных типов трафика, а кроме того, он получил широкое распространение в корпоративных сетях.
«Во многих компаниях окончательный переход на IP еще не состоялся, — утверждает Эрик Зайнс, аналитик из компании TeleChoice. — В них по-прежнему применяются IPX и SNA. В отличие от IPSec, протокол L2TP не предназначен для формирования туннелей на втором уровне модели OSI. Почему бы в таком случае не использовать в корпоративной сети сразу оба протокола?»
Сторонники модернизации протоколов IKE (в целях ужесточения процедуры авторизации) указывают на элегантность такого решения с точки зрения пользователей, особенно тех, в чьих компаниях не поддерживается протокол L2TP. В подобной ситуации дело ограничится написанием дополнительного кода, а достигнутое за счет этого расширения функциональных возможностей позволит поддерживать устаревшие системы защиты, включая RADIUS.
Но и у этой идеи нашлись недоброжелатели, ссылающиеся на плохую проработку предварительных спецификаций. Их главный аргумент связан со схемой преобразования сетевых адресов (NAT).
Как известно, протокол NAT был предложен с целью преодолеть ограниченность адресного пространства в четвертой версии IP. Он позволяет организациям использовать собственные незарегистрированные IP-адреса для тех сетевых устройств, которые не имеют выхода во внешний мир, и небольшое количество зарегистрированных адресов для отправки пакетов в глобальную сеть. Устройства, поддерживающие NAT, неплохо защищены от непрошеных «пришельцев», поскольку, не узнав IP-адрес сетевого узла, хакер не сможет добраться до него из глобальной сети.
Между тем процедуры обмена ключами IKE фактически нивелируют преимущества NAT, поскольку IP-адрес помещается в зашифрованную часть пакета. В лучшем случае это означает, что внутренние адреса окажутся выставлеными на всеобщее обозрение, в худшем возникнут проблемы с маршрутизацией пакетов, поскольку содержащиеся в них IP-адреса будут зашифрованы.
Использование цифровых сертификатов также не решает полностью задачу идентификации пользователей. Несмотря на то что обмен сертификатами между сторонами описан в одном из технических документов IETF, алгоритмы проверки их подлинности остаются неопределенными, а это означает, что такие алгоритмы каждый производитель будет реализовывать на свой лад. По мнению экспертов, данная ситуация никак не способствует достижению совместимости продуктов разных поставщиков, поскольку пользователю придется иметь дело с многочисленными фирменными расширениями основного стандарта.
Какому же техническому решению отдадут предпочтение пользователи? Дать определенный ответ на поставленный вопрос практически невозможно в связи с тем, что единственным сколько-нибудь объективным источником информации в данной области является профессиональная пресса. Производители же при составлении спецификаций будущих стандартов лоббируют не те технологии, которые являются самыми эффективными, а те, что обещают им максимальный рыночный успех. Весьма показателен в этом отношении пример RedCreek и TimeStep — небольших компаний, развивших завидную активность в деле стандартизации средств защиты данных и выпуска соответствующих продуктов.
В сложившейся ситуации лучшим источником информации для сетевого администратора могли бы стать сведения, полученные от других корпоративных пользователей, однако их мнение остается практически неучтенным. Несмотря на то что IETF является открытой организацией, пользователи имеют довольно ограниченное влияние на принимаемые ею решения, а на всех заседаниях рабочих групп постоянно присутствуют только представители компаний-поставщиков. К тому же обсуждение вопросов информационной безопасности настолько перегружены техническими деталями, что большинство пользователей просто не смогут стать полноценными участниками сегодняшних дебатов, предварительно не изучив все технические предложения, которые им предшествовали.
Даже Московитц, ранее участвовавший в заседаниях IPSec Working Group в качестве основного представителя интересов пользователей, ныне также выступает на стороне производителей. Свою деятельность в IETF он начинал, будучи сотрудником корпорации Chrysler. Председателем рабочей группы Московитц остается и по сей день, однако его основная должность теперь иная — он возглавляет организованную в ICSA лабораторию тестирования IPSec-продуктов на совместимость. Опыт бывшего пользователя при тестировании трудно переоценить, однако ICSA — коммерческая организация и сохраняющиеся проблемы в области взаимодействия продуктов приносят ей немалый доход. (Достаточно сказать, что стоимость тестирования каждого устройства составляет около 25 тыс. долл.) По этой причине многие члены рабочей группы обвиняют Московитца в непоследовательности.
Более того, ассоциация ICSA тестирует на соответствие спецификациям IPSec (а точнее, части этих спецификаций) только те продукты, которые уже присутствуют на рынке. Она же занимается рядом других аспектов защиты данных. ICSA не публикует результаты своей деятельности, однако известно, что большая часть продуктов не проходит предусмотренные для них тесты. Это обстоятельство сильно раздражает производителей, которые ждут от ассоциации помощи в достижении совместимости с существующим стандартом и его новыми версиями.
Страсти накалились до такой степени, что несколько изготовителей приняли решение о создании параллельной организационной структуры, получившей название Virtual Private Network Consortium (VPNC). Ее возглавил Пол Хофман, известный своей активной деятельностью в консорциуме Internet Mail Consortium. «Все члены новой организации выражают крайнее недовольство работой ICSA, эта ассоциация совершенно не оправдала возлагавшихся на нее надежд», — говорит он. И тут же добавляет: «Однако если члены ICSA примут решение оказывать реальное содействие преодолению проблем совместимости, в существовании консорциума VPNC отпадет всякая необходимость».
Между тем руководитель ICSA расценивает сложившуюся ситуацию как стремление разделить поставщиков на плохих и хороших. «Хофман представляет все так, будто именно ему удалось сдвинуть дело с мертвой точки, а ICSA только тем и занималась, что вставляла палки в колеса, — объясняет Московитц. — В действительности мы возвращаем протестированные устройства их производителям и даем свое заключение относительно недостатков, которые следует устранить. Мы не стремимся надевать на себя белые одежды, но и не хотим представать в образе козла отпущения. На мой взгляд, нет ничего зазорного в существовании двух похожих организаций».
Впрочем, Хофман признает, что современный рынок до такой степени раздираем противоречиями, что «узкое место» в области взаимодействия возникло по вине самих поставщиков. По его мнению, низкие темпы продвижения здесь обусловлены не недостатками в работе органов стандартизации, а политикой производителей, которые не стремятся связаться друг с другом и начать совместную деятельность. Вопрос о совместимости продуктов разных компаний начинает волновать их только тогда, когда речь заходит о какой-нибудь сверхпопулярной функции.
В налаживании непродолжительных контактов фирмам может помочь IPSec Developers Forum. Эта организация, созданная в феврале 1998 г. компанией RADGUARD, позволяет двум изготовителям провести попарное тестирование разрабатываемых продуктов. Участие в IPSec Developers Forum бесплатное.
Аналогичную работу проводит американский Национальный институт по стандартам и тестированию (NIST). На его Web-сервере размещены инструментальные средства, которые позволяют поставщикам протестировать продукты IPSec на соответствие стандарту, воспользовавшись реальным соединением Internet. Например, производители могут проверить функционирование своих продуктов в одиночном сеансе согласования параметров защищенной передачи.
Несмотря на подобную активность разных организаций, проблема заключается в том, что результаты тестирования пользователям недоступны. В качестве объяснения такой закрытости обычно приводится стандартный тезис: если телекоммуникационное сообщество узнает о том, какие устройства в ходе тестирования потерпели фиаско, их изготовители откажутся участвовать в дальнейших испытаниях.
К счастью, и здесь существует одно исключение. Ассоциация ICSA публикует свои комментарии к продуктам, получающим сертификат с ее печатью. В этих документах детально описаны условия тестирования, а также процедуры настройки конфигурации и управления, которые позволили достичь взаимодействия. Эти длинные описания заставляют компании продолжать совершенствовать предлагаемые реализации стандарта IPSec.
Web-серверы таких организаций, как VPNC, IPSec Developers Forum и NIST, являются для пользователей ценнейшим ресурсом, поскольку они позволяют по крупицам восстановить истинную картину, которая сложилась в сфере взаимодействия различных реализаций IPSec. Консорциум VPNC публикует таблицы, из которых видно, какие устройства разных производителей успешно прошли тест на взаимодействие друг с другом, а IPSec Developers Forum и NIST сообщают результаты испытаний по запросам пользователей. Кроме того, на сервере NIST доступны технические спецификации, в соответствии с которыми проводится тестирование; они будут полезны сетевым инженерам, стремящимся повысить свою квалификацию в области защиты данных средствами IPSec.
Итак, сегодня настала пора пользователям активно вмешаться в сложившуюся ситуацию. Будущее сетей удаленного доступа создается именно сейчас и, к сожалению, практически без участия тех, кому с этими сетями придется иметь дело.
В составе операционной системы Windows 2000 компании Microsoft, поставки которой начинаются в феврале, появятся средства формирования виртуальных частных сетей (VPN) на базе протокола IPSec. В этой связи возникает закономерный вопрос: в какой степени VPN-продукты других производителей смогут взаимодействовать с новым детищем фирмы из Редмонда?
Кажется, ответ на него положительный, хотя и звучит он без особого энтузиазма. Многие поставщики VPN-продуктов не скрывают своего явно враждебного отношения к последней разработке фирмы Microsoft, упрекая ее за то, что предложенная в Windows 2000 реализация протокола IPSec сопряжена с повышением доли «накладных расходов» и замедляет обработку транзакций. Правда, те же самые компании (Check Point Software, Newbridge Networks и др.) не смогут проигнорировать сотни тысяч, а то и миллионы пользователей, которые через какое-то время установят на своих настольных компьютерах новую операционную систему от Microsoft.
Включенные в состав Windows 2000 средства VPN разрабатывались совместно с фирмой Cisco Systems. Они объединяют протокол туннелирования трафика Layer 2 Tunneling Protocol (L2TP) и алгоритмы шифрования, предусмотренные в IPSec. Это позволяет поддерживать протоколы третьего уровня, отличные от IP, а также методы идентификации, активно используемые в электронной коммерции при осуществлении сделок между компаниями (business-to-business). Любопытнее всего то, что до самого последнего времени было неясно, сумеет ли вообще Microsot включить средства VPN в состав Windows 2000.
Официальное представление новой операционной системы было запланировано на 17 февраля. К ее выходу многие производители поспешили обеспечить поддержку комбинации протоколов L2TP/IPSec в собственных продуктах. Например, корпорация TimeStep намерена уже в этом году выпустить обновленную версию шлюза Permit Gateway, которая будет поддерживать L2TP, а значит, сможет работать с клиентским ПО производства Microsoft и TimeStep. Впрочем, по мнению руководителей компании, туннелирование средствами L2TP ляжет тяжелым бременем на пользователя, поскольку основным недостатком этого протокола является плохая масштабируемость.
Другому известному поставщику VPN-продуктов — фирме RADGUARD — также придется скорректировать свою стратегию в связи с грядущим вторжением в данный сектор рынка компании Microsoft.
«Если в сети уже используется IP, применять протокол L2TP нет никакой необходимости, — считает Ирис Тал, менеджер RADGUARD по технической поддержке. — Этот протокол вызывает эффект двойного туннелирования и потому сильно увеличивает долю служебных данных в общем объеме трафика. Однако появление клиентского ПО фирмы Microsoft заставит нас обеспечить поддержку L2TP в своих продуктах».
«Конечно, если бы Microsoft воздержалась от включения средств VPN в свою операционную систему, проблем было бы гораздо меньше, — полагает представитель фирмы Check Point, клиентские продукты которой сегодня установлены на 15 млн настольных станций по всему миру. — Но теперь мы просто вынуждены поддерживать программное обеспечение от Microsoft, ведь к концу года оно наверняка появится на большинстве ПК в составе корпоративных сетей».
Реализованная Microsoft идея объединения протоколов IPSec и L2TP сама по себе не нова. Так, техасская фирма Ashley Laurent, специализирующаяся на разработке программных средств защиты данных для крупных заказчиков, включая IBM, в рамках одного из контрактов создает код IPSec на базе механизмов туннелирования трафика, предусмотренных протоколом L2TP. По заявлению руководителей компании, такая деятельность не вызывает у них особого оптимизма и они не решились бы рекомендовать этот протокол своим клиентам. Проведенный специалистами Ashley Laurent анализ технологий VPN, появившихся в Windows 2000, выявил их недостаточную стабильность, а увеличение объема передаваемого трафика (за счет служебных данных) составило 10%.
Деятельность консорциума IETF и таких организаций, как International Computer Security Association (ICSA), в области IPSec пока не привела к разрешению всех технических противоречий, которые препятствуют созданию устойчиво работающих программ-клиентов, к тому же способных взаимодействовать друг с другом. Не исключено, что появившийся в прошлом году документ IETF, регламентирующий применение протокола динамического управления IP-адресами DHCP в туннелях IPSec («DHCP Configuration of IPSec in Tunnel Mode») ,и предложенные компанией TimeStep спецификации XAUTH со временем позволят заменить функции L2TP в продуктах Microsoft.
Попытки поставщиков достичь совместимости своих VPN-продуктов, как и дискуссии по проблемам построения клиентской части ПО IPSec имеют многолетнюю историю. На этом фоне реализация средств защиты трафика в Windows 2000 с точки зрения пользователя выглядит очень заманчиво. Тандем L2TP/IPSec жизненно необходим клиентам Microsoft, поскольку он позволяет использовать различные протоколы идентификации на основе паролей, включая PAP, CHAP, MSCHAP и Extensible Authentication Protocol (EAP). Более того, в составе Windows 2000 появился сервер RADIUS, готовый взять на себя обработку запросов перечисленных протоколов. Технологии VPN, разработанные в недрах Microsoft, окажутся полезными и для шифрования трафика при проведении многоточечных конференций, например с использованием пакета NetMeeting.
Конечно, оппонентами Microsoft являются далеко не все производители. Достаточно сказать, что разработкой или тестированием модулей на базе L2TP/IPSec для своих продуктов сегодня занимаются такие фирмы, как 3Com, Lucent Technologies, Nortel Networks, Altiga Networks и Network Alchemy. Тем не менее даже сотрудники Microsoft признают, что критика, разразившаяся в адрес компании, отчасти справедлива. Чтобы хоть как-то нивелировать эффект увеличения «накладных расходов», связанный с применением функций VPN, программисты Microsoft предусмотрели в Windows 2000 возможность запуска акселераторов шифрования, которые заказчики могут разрабатывать самостоятельно или с привлечением независимых организаций. Подобные ускорители обещают заметно повысить производительность процедур обработки транзакций на компьютерах с новой операционной системой семейства Windows.
Возможно, уже в начале весны фирма nCipher представит версию своего акселератора nFast, специально разработанную под Windows 2000. Корпорация 3Com предлагает плату Typhoon аналогичного функционального назначения, а в лабораториях Intel ведутся работы по созданию сопроцессора, который ускоряет шифрование данных в среде Windows 2000.
Эллен МЕССМЕРВот как распределились ответы американских респондентов на вопрос: «Какие из перечисленных обстоятельств являются для вас основными препятствиями к формированию виртуальных частных сетей через Internet?».
(допускалось несколько вариантов ответов). |
Источник: Canhers In-Stat Group.