RFC 4441 The IEEE 802/IETF Relationship

Please enter banners and links.

image_print
Network Working Group                                      B. Aboba, Ed.
Request for Comments: 4441                   Internet Architecture Board
Category: Informational                                       March 2006

Взаимодействие IEEE 802 и IETF

The IEEE 802/IETF Relationship

PDF

Статус документа

В этом документе содержится информация для сообщества Internet. Документ не задает каких-либо стандартов Internet. Допускается свободное распространение документа.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

Начиная с конца 1980-х, IEEE 802 и IETF сотрудничают по вопросам разработки баз SNMP1 MIB, а также приложений AAA2. В данном документе описаны правила и процедуры, разработанные для взаимодействия этих организаций, а также рассмотрена история взаимодействия.

Оглавление

Исключено в версии HTML.

 

1. Введение

Начиная с конца 1980-х, IEEE 802 и IETF сотрудничают по вопросам разработки MIB3 и приложений AAA, относящихся к стандартам IEEE. К числу совместных работ относятся Bridge MIB [RFC1493] [RFC4188], MIB для фильтрации групповых адресов и расширений VLAN [RFC2674] [RFC4363], Hub MIB [RFC2108], Ethernet-like Interfaces MIB [RFC3635], the MAU MIB [RFC3636],WAN Interfaces Sublayer MIB [RFC3637], Power Ethernet MIB [RFC3621], рекомендации по использованию IEEE 802.1X RADIUS [RFC3580], пересмотренная спецификация протокола EAP4 [RFC3748], RADIUS/EAP [RFC3579] и спецификация машины состояний EAP [RFC4137]. В данном документе описаны правила и процедуры, разработанные для взаимодействия между IETF и IEEE 802. В приложении A подробно описана история взаимодействия.

Для повышения эффективности взаимодействия между IETF и IEEE 802 ряд членов IESG5 и IAB6 (включая Bert Wijnen, James Kempf и Bernard Aboba) встретились с членами Исполнительного комитета IEEE 802 в Ванкувере (Канада) в январе 2004 г. На этой встрече обсуждались многочисленные вопросы и были утверждены новые процедуры взаимодействия.

1.1. Организационные связи

Рабочие группы IETF организованы по направлениям, имеющим одного или нескольких руководителей (Area Director). Руководители направлений и Председатель IETF составляют Исполнительный комитет (IESG). Рабочие группы IEEE 802 имеют одну или несколько групп для решения задач (Task Group). Председатели рабочих групп IEEE 802 и Председатель IEEE 802 образуют Исполнительный комитет IEEE 802 (ExComm).

При необходимости IAB или IESG назначает членов IETF, ответственных за связи с другими организациями. Сюда включается связь с IEEE 802, а также связи с рабочими группами IEEE 802. Специальная страница7 на сайте IETF содержит список таких лиц, а также ссылку на архив документов (liaison statement), полученных IETF [Liaison-Page]. Процесс IETF по управлению организационными связями описан в документе [BCP102], процедуры обработки входящих документов описаны в [BCP103]. Для того, чтобы запросы IEEE 802 в адрес IETF корректно архивировались и обрабатывались, при подаче таких запросов следует использовать специальные средства (IETF liaison management tool). Имя пользователя и пароль для доступа к этим средствам можно получить, написав письмо по адресу iesg-secretary@ietf.org. При отсутствии доступа к этим средствам можно отправлять запросы по адресу statements@ietf.org. Однако в последнем случае задержка обработки запросов существенно возрастет, поскольку она будет выполняться вручную сотрудниками Секретариата IETF.

Запросы IETF в адрес IEEE 802 следует направлять председателям рабочих групп IEEE 802, к которым имеет отношение запрос, с передачей копии председателю IEEE 802 и ответственным за связи с 802 в составе IETF. Процедуры IEEE 802 по взаимодействию с другими комитетами по стандартизации описаны в параграфе 14.1 документа [Policy]. Архивы такого взаимодействия вдутся независимо рабочими группами IEEE 802.

1.2. Доступ к архивам IEEE 802

Доступ к стандартам IEEE 802, выпущенным более 6 месяцев назад, обеспечивается бесплатно через сайт IEEE 802 в рамках программы Get IEEE 802 [GetIEEE-802]. При взаимодействии между IETF и IEEE 802 зачастую возникает потребность в доступе к рабочим (work-in-progress) документам IEEE 802. Хотя в прошлом рабочие группы IETF получали доступ к рабочим документам IEEE 802, каждый такой случай рассматривался отдельно и процесс согласования требовал значительного времени и усилий. Для упрощения получения доступа членов рабочих групп IETF, сотрудничающих с IEEE 802, Paul Nikolich (Руководитель IEEE 802) Paul Nikolich (Руководитель IEEE 802) в июле 2004 г. направил в IETF запрос [IEEE-802Liaison], описывающий процедуру получения членами рабочих групп IETF доступа к незавершенным работам IEEE 802. Руководители рабочих групп IEEE 802 имеют право включать людей в свои группы и могут воспользоваться этим правом для включения в группу руководителей рабочих групп IETF по их запросам. Руководитель рабочей группы IETF получает имя и пароль для доступа к архивам рабочей группы IEEE 802 и может передавать это имя и пароль другим участникам своей группы IETF. Поскольку участие в работе групп IETF возможно в заочной форме, руководители групп IETF будут предоставлять эту информацию любому желающему. Однако, в силу того, что рабочие документы IEEE 802 защищены законом об авторских правах, включение материалов из этих документов в документы IETF или рассылка имени пользователя и пароля через почтовую конференцию или web-сайт не допускается.

1.3. Просмотр новых работ

Для того, чтобы обеспечить IEEE 802 возможность обзора документов, предложенных рабочими группами IETF, а IETF – возможность обзора IEEE 802 PAR8, используется почтовая рассылка New Work. Исполнительный комитет IEEE 802 является подписчиком этой рассылки, поэтому он может получать IETF WG Charters. Предложенные документы IEEE 802 PAR также рассылаются по списку New Work. Когда анонсы New Work представляют специфический интерес, они также (вручную) пересылаются в соответствующие списки рассылок IETF и IEEE 802.

Однако в момент появления IETF WG Charter или IEEE 802 PAR в рассылке New Work, соответствующие сроки IETF BOF или IEEE 802 Call for Interest уже вышли, интерес был продемонстрирован и была проделана значительная работа по созданию Charter или PAR. Если в этом момент будет обнаружена проблема, зачастую будет уже слишком поздно вносить серьезные изменения. Следовательно, в тех случая, когда работа затрагивает спорные вопросы, обсуждение между IETF и IEEE 802 лучше начинать как можно раньше.

1.4. Обзор MIB

С учетом расходов на поездки компаниям становится все труднее найти сотрудников, которые участвуют в конференциях как IEEE 802, так и IETF. По этой причине нужен иной вариант передачи MIB в рабочую группу IETF. Для того, чтобы обеспечить более широкий доступ к MIB, разработанным группами IEEE 802, для них рекомендуется следовать документу [RFC4181] и рассматривать эти базы с использованием процесса контроля качества IETF (‘MIB Doctors’). Группа IEEE 802 может запросить выделение ‘MIB Doctor’ для оказания помощи в проверке MIB, обратившись к руководителю направления IETF Operations and Management.

За счет стандартизации IEEE 802 MIB в рамках IEEE 802 с использованием процесса контроля качества SNMP IETF и IEEE 802 добиваются гарантии качества при одновременном снижении издержек. Пробное использование этого процесса было проведено в IEEE 802.1, для которого MIB Doctor (David Harrington) согласился просмотреть IEEE 802.1 MIB. В настоящее время обсуждается вопрос переноса некоторых документов IEEE 802.1 MIB, опубликованных как RFC в IEEE 802.1 [MIB-TRANSFER].

1.5. Обзор EAP

Несколько стандартов IEEE 802, включая [IEEE-802.1X-2004], [IEEE-802.11i] и [IEEE-802.16e] опираются на протокол EAP [RFC3748] и управление ключами EAP, описанное в [KEYFRAME]. Вместо разработки своих методов EAP или расширения управления ключами EAP рабочим группам IEEE 802 следует направить в IETF запрос, описывающий нужную функциональность, или запросить обзор предварительного стандарта. Совсем недавно рабочей группой EAP был проведен обзор (с точки зрения безопасности) предварительного стандарта IEEE 802.16e D8 [EAPREVIEW] по запросу руководителя IEEE 802.16 Роджера Маркса (Roger Marks) [IEEE-802.16-Liaison1] [IEEE-802.16-Liaison2].

1.6. Обзор AAA

Рабочим группам IEEE 802, нуждающимся в новых приложениях AAA, следует направлять запросы в IETF. Если требуются новые атрибуты, а не новые приложения, может быть подан документ Internet-Draft и сделан запрос на его рассмотрение в связанные с AAA рабочие группы (например, AAA или RADEXT). Для атрибутов общего назначения, в особенности для тех, которые могут быть полезны для множества приложений предпочтительно выделение значений из пространства стандартных атрибутов IETF для создания IEEE 802 VSA9. Как сказано в [RFC3575]: «RADIUS определяет механизм для связанных с производителем расширений10 (Атрибут 26) и следует использовать такие атрибуты вместо выделения глобальных типов атрибутов, связанных лишь с реализацией RADIUS от одного производителя, в тех случаях, когда интероперабельность не считается полезной».

Если требуется выделение значений VSA, IEEE 802 рекомендуется создавать одинаковый формат для всех значений, а не использовать для каждой рабочей группы IEEE 802 свой формат VSA. Формат VSA, определенный в [IEEE-802.11F] не подходит для этого, поскольку поле Type имеет размер 1 октет, что позволяет задать только 255 атрибутов. Недавно был создан список AAA Doctors в рамках директората направления IETF Operations and Management, работающий аналогично MIB Doctors. Хотя специалисты из списка AAA Doctors еще не приглашались для работ по рассмотрению AAA за пределами IETF, эта группа может быть полезна рабочим группам IEEE 802, которым необходима помощь с AAA.

1.7. Обзор документов

По мере расширения сферы взаимодействия между IEEE 802 и IETF процесс обзора документов вышел за рамки традиционных тем SNMP MIB и AAA. Например, в процессе работы IETF CAPWAP WG у комитета IEEE 802.11 был запрошен обзор документа CAPWAP Taxonomy [RFC4118]; Дороти Стэнли (Dorothy Stanley) организовала для этой цели специальную группу. IEEE 802.11 был также проведен обзор [IDSEL] и [IABLINK]. В рамках IETF комментарии IEEE 802 обрабатывались с использованием обычных для рабочих групп и IETF процессов.

Члены IETF могут вносить свои комментарии в процессе голосования IEEE 802, независимо от наличия у них права голоса в IEEE 802. Комментарии должны вноситься в формате заданном для голосования в отведенные для голосования сроки.

1.8. Выделение значений EtherType

Пространство значений EtherType весьма ограничено, поэтому выделение новых значений производиться исключительно по необходимости. Для связанных применений следует запрашивать одно значение EtherType с дополнительными полями, служащими в качестве идентификаторов субпротокола, вместо выделения множества значений EtherType. Правила распределения значений EtherType описаны в [TYPE-TUT].

Хотя IEEE 802 обычно взимает плату за выделение значений EtherType, IEEE 802 будет рассматривать вопрос о бесплатном выделении значений для предложенных стандартов11 IETF по запросам IESG.

2. Вопросы безопасности

IEEE 802 все чаще вовлекается в разработку стандартов безопасности на канальном уровне. Опыт показывает, что это весьма полезно с точки зрения дополнительного просмотра рабочих документов до их публикации. Однако такая практика встречает некоторые возражения, поскольку доступ к рабочим документам зачастую жестко контролируется. Например, потребовалось специальное разрешение IEEE 802.11i для получения доступа к рабочему варианту стандарта безопасности. Связи между рабочими группами IEEE 802 и IETF могут помочь в получении доступа к документам для их обзора.

Опыт также показывает, что стандарты IETF могут быть написаны не с тем уровнем ясности, который требуется для процессов стандартизации IEEE 802. В случае EAP [RFC3748] процесс разработки машины состояний EAP [RFC4137] показал пользу в части описания некоторых аспектов, требующих дополнительного разъяснения, и совместный обзор открыл находящиеся в разработке документы IEEE 802 и IETF для более широкого круга, нежели было возможно до этого.

Аналогично, разработка [IEEE-802.11i], [RFC3748], [KEYFRAME] и [RFC4017] привела к более глубокому пониманию ограничений и уязвимостей защиты системы EAP/AAA. Как было описано в [Housley], нецелесообразно разрабатывать новые приложения AAA для управления ключами без завершения анализа безопасности, подобного приведенному в [KEYFRAME].

По причине недостатков спецификации RADIUS [RFC2865] протоколы расширений могут сравнительно просто создавать серьезные проблемы безопасности. По этой причине IETF рекомендуется рассмотреть расширения IEEE 802 RADIUS, а документ IANA Considerations for RADIUS [RFC3575] был пересмотрен, чтобы такой обзор требовался в большинстве случаев.

3. Литература

[BCP102] Daigle, L. and Internet Architecture Board, “IAB Processes for Management of IETF Liaison Relationships”, BCP 102, RFC 4052, April 2005.

[BCP103] Trowbridge, S., Bradner, S., and F. Baker, “Procedures for Handling Liaison Statements to and from the IETF”, BCP 103, RFC 4053, April 2005.

[EAPREVIEW] EAP WG letter to Roger Marks, June 2005, http://www.drizzle.com/~aboba/EAP/review.txt.

[GetIEEE-802] IEEE Standards Association Get IEEE 802 (R) Program, http://standards.ieee.org/getieee802/portfolio.html.

[IDSEL] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, “Identity Selection Hints for the Extensible Authentication Protocol (EAP)”, RFC 4284, January 2006.

[Housley] Housley, R. and B. Aboba, “AAA Key Management”, Work in Progress, November 2005.

[IABLINK] Aboba, B., “Architectural Implications of Link Indications”, Work in Progress, August 2005.

[IEEE-80211Liaison1] IEEE 802.11 liaison letter to Harald Alvestrand, February 2002, https://www.ietf.org/IESG/LIAISON/ieee802.11.txt

[IEEE-80211Liaison2] Input To IETF EAP Working Group on Methods and Key Strength, March 2003, http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt.

[IEEE-802.11F] Institute of Electrical and Electronics Engineers, “IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation”, IEEE 802.11F, June 2003 (now deprecated).

[IEEE-802Liaison] IEEE 802 Liaison letter to Bert Wijnen and Bernard Aboba, July 26, 2004, http://www.ietf.org/IESG/LIAISON/file41.pdf.

[IEEE-802.1X-MIB] Norseth, K., “Definitions for Port Access Control (IEEE 802.1X) MIB”, Work in Progress, November 2003.

[IEEE-802.1X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE P802.1X-2001, June 2001.

[IEEE-802.1X-2004] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE P802.1X-2004, December 2004.

[IEEE-802.1D] ISO/IEC 15802-3 Information technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Common specifications – Part 3: Media access Control (MAC) Bridges, (also ANSI/IEEE Std 802.1D-1998), 1998.

[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q, January 1998.

[IEEE-802.3] ISO/IEC 8802-3 Information technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Common specifications – Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 1996.

[IEEE-802.11] Information technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE P802.11-2003, 2003.

[IEEE-802.11i] IEEE Supplement to Standard for Telecommunications and Information Exchange Between Systems – LAN/MAN Specific Requirements – Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security, IEEE P802.11i, July 2004.

[IEEE-802.16e] IEEE Standard for Local and Metropolitan Area Networks – Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands, IEEE P802.16e, September 2005.

[IEEE-802.16-Liaison1] Liaison letter from IEEE 802.16 to Bernard Aboba, March 17, 2005, http://ieee802.org/16/liaison/docs/L80216-05_025.pdf.

[IEEE-802.16-Liaison2] Liaison letter from IEEE 802.16 to Bernard Aboba, May 5, 2005, http://ieee802.org/16/liaison/docs/L80216-05_039.pdf.

[KEYFRAME] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz, “Extensible Authentication Protocol (EAP) Key Management Framework”, Work in Progress, October 2005.

[Liaison-Page] IETF Liaison Activities, http://www.ietf.org/liaisonActivities.html.

[MIB-TRANSFER] Harrington, D., “Transferring MIB Work from IETF Bridge WG to IEEE 802.1 WG”, Work in Progress, October 2005.

[Mishra] Mishra, A. and W. Arbaugh, “An Initial Security Analysis of the IEEE 802.1X Standard”, Department of Computer Science, University of Maryland College Park, CS-TR-4328, February 2002.

[Policy] IEEE Project 802 LAN MAN Standards Committee (LMSC) Policies and Procedures, September 14, 2005, http://www.ieee802.org/policies-and-procedures.pdf.

[RFC1493] Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, “Definitions of Managed Objects for Bridges”, RFC 1493, July 1993.

[RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, “Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2”, RFC 2108, February 1997.

[RFC2284] Blunk, L. and J. Vollbrecht, “PPP Extensible Authentication Protocol (EAP)”, RFC 2284, March 1998.

[RFC2390] Bradley, T., Brown, C., and A. Malis, “Inverse Address Resolution Protocol”, RFC 2390, September 1998.

[RFC2674] Bell, E., Smith, A., Langille, P., Rijhsinghani, A., and K. McCloghrie, “Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions”, RFC 2674, August 1999.

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS)”, RFC 2865, June 2000.

[RFC2866] Rigney, C., “RADIUS Accounting”, RFC 2866, June 2000.

[RFC2867] Zorn, G., Aboba, B., and D. Mitton, “RADIUS Accounting Modifications for Tunnel Protocol Support”, RFC 2867, June 2000.

[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, “RADIUS Attributes for Tunnel Protocol Support”, RFC 2868, June 2000.

[RFC2869] Rigney, C., Willats, W., and P. Calhoun, “RADIUS Extensions”, RFC 2869, June 2000.

[RFC3162] Aboba, B., Zorn, G., and D. Mitton, “RADIUS and IPv6”, RFC 3162, August 2001.

[RFC3575] Aboba, B., “IANA Considerations for RADIUS (Remote Authentication Dial In User Service)”, RFC 3575, July 2003.

[RFC3579] Aboba, B. and P. Calhoun, “RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)”, RFC 3579, September 2003.

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, “IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines”, RFC 3580, September 2003.

[RFC3621] Berger, A. and D. Romascanu, “Power Ethernet MIB”, RFC 3621, December 2003.

[RFC3635] Flick, J., “Definitions of Managed Objects for the Ethernet-like Interface Types”, RFC 3635, September 2003.

[RFC3636] Flick, J., “Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)”, RFC 3636, September 2003.

[RFC3637] Heard, C.M., Ed., “Definitions of Managed Objects for the Ethernet WAN Interface Sublayer”, RFC 3637, September 2003.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP)”, RFC 3748, June 2004.

[RFC4017] Stanley, D., Walker, J., and B. Aboba, “Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs”, RFC 4017, March 2005.

[RFC4118] Yang, L., Zerfos, P., and E. Sadot, “Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)”, RFC 4118, June 2005.

[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, “State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator”, RFC 4137, August 2005.

[RFC4181] Heard, C., Ed., “Guidelines for Authors and Reviewers of MIB Documents”, BCP 111, RFC 4181, September 2005.

[RFC4188] Norseth, K. and E. Bell, “Definitions of Managed Objects for Bridges”, RFC 4188, September 2005.

[RFC4363] Levi, D. and D. Harrington, “Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions”, RFC 4363, January 2006.

[TYPE-TUT] IEEE Standards Association, “Use of the IEEE Assigned EtherType Field with IEEE Std 802.3, 1998 Edition Local and Metropolitan Area Networks”, http://standards.ieee.org/regauth/ethertype/type-tut.html.

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

Авторы выражают свою признательность Les Bell, Dan Romascanu, Dave Harrington, Tony Jeffree, Fred Baker, Paul Congdon, Paul Langille и C. M. Heard за их вклад в подготовку документа.

Приложение A. История взаимодействия

A.1. Разработка MIB

A.1.1. Bridge MIB

Взаимодействие между IETF и IEEE 802 началось в конце 1980 годов с баз SNMP MIB, разработанных для стандарта IEEE 802.1D. Поскольку в спецификации IEEE [IEEE-802.1D] даны только функциональные определения счетчиков и операций, рабочая группа IETF Bridge MIB взяла на себя задачу определения Bridge MIB [RFC1493], которая была опубликована в серии RFC. Руководителем Bridge WG был Fred Baker, а позднее – Keith McCloghrie.

Bridge MIB объединяет работу Keith McCloghrie, Eric Decker и Paul Langille с опытом Anil Rijsinghani в части остовного дерева. Mick Seaman (автор 802.1D) и Floyd Backes (разработчик кода для реализации остовного дерева в Digital Equipment) обеспечивали основные контакты с IEEE 802.1. Поскольку Mick, Floyd, Anil и Paul работали в это время в Digital Equipment Corporation, основное взаимодействие между IEEE 802.1 и Bridge MIB WG происходило в коридорах DEC, а не по официальным каналам.

A.1.2. MAU MIB и Hub MIB

В начале 1990-х, когда в IEEE 802.3 завершалась разработка первых стандартов Ethernet, протокол SNMP еще не был доминирующим в сфере управления сетями. В результате этого в раздел (Clause) 30 стандарта IEEE 802.3 [IEEE-802.3] была включена «протоколо-независимая» MIB, которая обновлялась всякий раз, когда стандарт Ethernet расширялся для поддержки более высоких скоростей. Параллельно с этим участники IEEE 802, заинтересованные в управлении сетями, активно формировали рабочую группу IETF HUBMIB WG, которая взяла на себя задачу преобразования определений IEEE 802 в базы SNMP MIB, документированные, как Standards Track RFC. Руководителем IETF HUBMIB WG с 1996 был Dan Romascanu.

В уставе HUBMIB WG явно сказано, что стандарт IEEE 802.3 является отправной точкой для Ethernet MIB, но в то же время отмечена возможность отклонения от модели IEEE – учет лишь части предлагаемых стандартом возможностей или добавление объектов MIB, которые не выводятся напрямую из модели IEEE (главным образом, программные). Если для управления потребуется поддержка на аппаратном уровне IETF HUBMIB WG своевременно передаст информацию об этом в IEEE 802.3.

Сотрудничество IETF HUBMIB WG и IEEE 802.3 продолжается более 10 лет и основано прежде всего на работе нескольких редакторов, поддерживаемых их компаниями, которые брали стандарты IEEE и отображали их на модель управления данными и базы MIB. Созданные в результате базы перечислены ниже.

  • Hub MIB [RFC2108] прошла три итерации и, возможно, завершила свое развитие, поскольку повторители больше не применяются в сетях Ethernet.

  • MAU MIB, обновляемая всякий раз при повышении скорости Ethernet; [RFC3636] включает Ethernet 10 Гбит/с.

  • Ethernet-like Interfaces MIB изначально не входила в число работ HUBMIB WG, но группа приняла на себя ответственность за пересмотр базы, опубликованной в результате, как [RFC3635].

  • WAN Interface Sublayer MIB [RFC3637] и Power Ethernet MIB [RFC3621] были совместно разработаны IEEE 802.3 и IETF HUBMIB WG.

В 2000 году было заключено официальное соглашение между IEEE 802.3 и IETF HUBMIB WG, где Dan Romascanu был назначен представителем IETF. Условия соглашения предоставляют редакторам и другим членам IETF HUBMIB WG персональный доступ к находящимся в работе проектам стандартов IEEE 802.3 с целью разработки MIB еще до официального выпуска стандартов. Пароли и имена пользователей для доступа к документам IEEE 802.3 не публиковались на сайте IETF и в почтовых рассылках.

A.1.3. 802.1p/Q MIB

В 1996 году по завершении разработки стандартов 802.1p и 802.1Q [IEEE-802.1Q] возникла необходимость разработки SNMP MIB с учетом возможностей управления, обеспечиваемых этими стандартами. Связанные с управление положения IEEE 802 изложено так, что они не зависят от протокола, который может применяться для их реализации.

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

Небольшая группа участников 802.1 WG начала независимые работы над этой проблемой, а потом усилия были объединены. Авторы Bridge MIB, на которой базировалась эта работа, обеспечили ее рецензирование.

В конце 1997 эта работа была готова для представления широкому кругу. Andrew Smith работал с Keith McCloghrie — руководителем Bridge MIB WG (в то время неактивной) для организации выступления на конференции IETF в марте 1998 года. После этого рассмотрение и разработка MIB продолжались в процессе стандартизации IETF.

В процессе разработки [RFC2674] не происходило официального взаимодействия между группами IETF Bridge MIB и IEEE 802.1. Разработка этой MIB была успешной благодаря тому, что основные разработчики (Andrew Smith и Les Bell) участвовали в обеих группах IEEE 802.1 и IETF Bridge MIB.

A.1.4. 802.3ad MIB и 802.1X MIB

При разработке стандартов IEEE 802.3ad и IEEE 802.1X было принято решение о разработке MIB, как части стандарта, не ожидая создания рабочей группы IETF для решения этой задачи. Такой подход позволил существенно сократить время разработки MIB.

Поскольку Les Bell среди участников IEEE 802.3ad и IEEE 802.1 был наиболее близок к разработке SNMP MIB, он собрал вместе исходные базы MIB на базе модели управления, с которой группы работали. От групп IEEE 802.3ad и IEEE 802.1X была получена дополнительная помощь в разработке обеих MIB. Tony Jeffree — редактор обоих стандартов — выступил также редактором для MIB.

Проблема при разработке в IEEE 802 этиз баз MIB без привлечения IETF заключалась в недостаточном обзоре и рецензировании. Члены IEEE 802 в основном мало знакомы с MIB и в процессе голосования по стандартам было получено очень мало комментариев.

Для IEEE 802.3ad MIB это означало, что до публикации стандарта основные ошибки не были обнаружены. К сожалению, на момент их обнаружения было уже поздно и корректировки, внесенные руководителем IEEE 802.3ad и редактором документа не были отражены в опубликованном стандарте.

После публикации [IEEE-802.1X] база IEEE 802.1X MIB была рассмотрена рабочей группой Bridge WG и обнаружено несколько синтаксических ошибок, которые были исправлены в версии модуля MIB, разработанного как часть [IEEE-802.1X-2004]. Однако, хотя база [IEEE-802.1X-MIB] была изначально опубликована как документ, над которым продолжается работа Bridge WG, интереса к публикации этой базы в качестве RFC оказалось недостаточно. В результате остался черновой документ с истекшим сроком действия.

A.1.5. 802.1t MIB, 802.1u MIB, 802.1v MIB, 802.1w MIB

802.1t и 802.1u были незначительными изменениями стандартов 802.1D и 802.1Q, требовавшими некоторых дополнений в MIB, опубликованную в [RFC2674]. В 802.1v были добавлены новые возможности, расширяющие схемы классификации VLAN 802.1Q и это тоже потребовало расширения [RFC2674]. В стандарте 802.1w была описана новая версия протокола Spanning Tree, что потребовало переписывания части [RFC1493].

Когда Les Bell возглавил группу IETF Bridge MIB WG в 2001 году, эти вопросы стали новыми направлениями работы и были найдены два добровольца на роль редакторов Internet-Draft. Работа включала также публикацию IEEE 802.1X MIB в форме информационного RFC.

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

A.2. AAA/EAP

С конца 1990-х IEEE 802.1 участвует в работах, связанных с проверкой подлинности и предоставление полномочий [IEEE-802.1X], при этом были обнаружены проблемы в нескольких спецификациях IETF, включая [RFC2284] и [RFC2869]. Аналогичным образом участники IETF обнаружили проблемы в ранних версиях спецификаций использования RADIUS типа [RFC3580], а также в машине состояний IEEE 802.1X [Mishra].

Для решения этих проблем и синхронизации работы групп IEEE 802.1, IETF EAP и IETF AAA WG в процессе разработки [IEEE-802.1X] и [IEEE-802.1X-2004] действия этих групп согласовывались.

Группы IEEE 802.11 типа IEEE 802.11i и IEEE 802.11F также зависят от работ EAP и AAA. Эти взаимоотношения оказались более сложными, поскольку для IEEE 802.11 требовалась разработка методов EAP и модели управления ключами EAP, а это было новым для IETF направлением в отличие от разъяснений и обновлений, которые были нужны для IEEE 802.1.

A.2.1. IEEE 802.1X

IEEE 802.1X-2001 [IEEE-802.1X] определяет инкапсуляцию EAP [RFC2284] для IEEE 802, а также машину состояний для совместного использования IEEE 802.1X и EAP.

В процессе разработки IEEE 802.1X-2001 было обнаружено несколько проблем спецификации RADIUS/EAP [RFC2869] и в результате начата работа по новой версии [RFC3579]. Кроме того, требовались разъяснения по интерпретации атрибутов RADIUS, определенных в [RFC2865], [RFC2866], [RFC2867], [RFC2868], [RFC2869] и [RFC3162], реализациями IEEE 802.1X. Для решения этой задачи в [IEEE-802.1X] было добавлено не являющееся нормативным приложение по использованию RADIUS,опубликованное также в [RFC3580].

После публикации [IEEE-802.1X] формальный анализ машины состояний IEEE 802.1X, выполненный в университете Мэрилэнда, показал несколько проблем безопасности [Mishra]. Обсуждение в рамках IEEE 802.1 показало наличие неясностей в [RFC2284], связанных с отсутствием спецификации для машины состояний EAP.

В то время работа над EAP входила в компетенцию слабоактивной рабочей группы IETF PPPEXT WG. Для выполнения работ по пересмотренной спецификации EAP, а также спецификацией машины состояний EAP в июле 2002 года была сформирована группа IETF EAP WG. Ее сопредседателем стал Bernard Aboba — участник IEEE 802.1 и PPPEXT.

Работа над спецификацией машины состояний EAP [RFC4137] и пересмотренной спецификацией EAP [RFC3748] выполнялась параллельно в EAP WG и проблемы или изменения в одном документе требовали изменения другого документа, а также пересмотра [IEEE-802.1X-2004]. Обновленная спецификация RADIUS/EAP [RFC3579] также была рассмотрена в EAP WG, поскольку к тому моменту группа RADEXT WG еще не была создана.

Пересмотр IEEE 802.1X [IEEE-802.1X-2004] включал:

  • обновленное приложение по использованию RADIUS на основе [RFC3580];

  • разъяснения, основанные на [RFC3579];

  • пересмотр машины состояний IEEE 802.1X на основе [RFC3748] и [RFC4137].

Наличие глубоких связей между [IEEE-802.1X-2004], [RFC3748] и [RFC4137] обусловило организацию взаимодействия между IEEE 802.1X-REV и IETF EAP WG в августе 2002 года. Это позволило участникам IETF EAP WG получить доступ к рабочим документам IEEE 802.1X.

Группы IEEE 802 обязаны рассматривать все полученные комментарии независимо от их источника. Это позволило участникам IETF вносить свои комментарии в процессе голосования IEEE 802 независимо от наличия у них права голоса в IEEE 802. При активном взаимодействии рабочие группы IETF могут быть уверены в том, что голосование IEEE 802 происходит с учетом их комментариев. Голосование для IEEE 802.1X-REV и IEEE 802.11i анонсировалось в списке рассылки EAP WG, как и внутренние заседания IEEE 802.

Аналогично, в процессе голосования IEEE 802.1X-REV были получены комментарии к [RFC3748], [RFC4137] и [RFC3579]. Эти комментарии помещались в список проблем EAP WG Issues List и впоследствии рассматривались.

В апреле 2003 года IESG одобрил публикацию [RFC3580], а в мае – [RFC3579] в серии документов RFC. Процесс рецензирования обоих документов включал процедуру IETF last call, которая анонсировалась в списке рассылки IEEE 802.1. Хотя комментарии при голосовании IEEE 802.1X-REV были учтены в обоих документах, требовалось одобрение их публикации в качестве RFC до спонсорского голосования (Sponsor Ballot), чтобы номера RFC были выделены своевременно во избежание задержки публикации.

В целом, несмотря на сложные взаимосвязи [IEEE-802.1X-2004], [RFC3748] и [RFC4137], документы были выпущены без неоправданной задержки. Это было обеспечено во много работой людей, которые участвовали одновременно в IEEE 802.1 и IETF EAP WG.

A.2.2. IEEE 802.11i

Задачей IEEE 802.11i было повышение уровня безопасности [IEEE-802.11]. Поскольку [IEEE-802.11i] использует IEEE 802.1X, он зависит от стандарта [IEEE-802.1X-2004]. В результате IEEE 802.11i и IEEE 802.1 проводили совместную работу в рамках пленарных заседаний IEEE 802 и создали механизм, обеспечивший членам каждой из групп (а также членам EAP WG) доступ к рабочим материалам IEEE 802.11i.

Зависимость [IEEE-802.11i] от [IEEE-802.1X-2004] привела к наследованию зависимостей [IEEE-802.1X-2004], включая работу и методы EAP, а также поддержку AAA для EAP. Кроме того, поскольку IEEE 802.11i использует EAP управления ключами, а [IEEE-802.1X] не использует, возникли дополнительные требования безопасности к методам EAP.

В феврале 2002 года группа IEEE 802.11 направила в IESG письмо [IEEE-80211Liaison1] с запросом о дополнительных работах по EAP, методам EAP и управлению ключами EAP. Это письмо было представлено на втором EAP BOF во время конференции IETF 53 и передано руководителю EAP WG. В марте 2003 года было направлено другое письмо с дополнительными разъяснениями по требованиям в части работы над методами EAP [IEEE-80211Liaison2]. Это письмо включало запрос IEEE 802.11i к рабочей группе EAP WG на рассмотрение вопроса замены обязательного для реализации метода EAP в [RFC3748] с учетом требований безопасности IEEE 802.11i.

Во время IETF 56 рабочей группой EAP WG был рассмотрен вопрос замены обязательного для реализации метода EAP. Руководителем направления Erik Nordmark было рекомендовано документировать требования IEEE 802.11i в RFC, а группе EAP WG было рекомендовано рассмотреть требования безопасности для методов EAP в разных ситуациях. Рекомендовано было не менять обязательный для реализации метод, поскольку EAP WG не была привлечена для выполнения этой работы. Однако было решено создать документ, описывающий требования к методу EAP для использования в средах WLAN. Этот документ был позднее опубликован в [RFC4017].

Позднее группа IEEE 802.11r была вовлечена в дискуссии, связанные с «быстрой передачей эстафеты» (fast handoff), при которой могли потребоваться расширения AAA, а также изменения в иерархии ключей EAP. Однако направление этой работы не было определено и запросы на совместную работу не сформированы.

В апреле 2003 года Dorothy Stanley назначили представителем IEEE 802.11 в IETF для оказания помощи в координации действий между рабочими группами IEEE 802.11 и IETF WG, включая AAA, BMWG, CAPWAP и EAP.

A.2.3. IEEE 802.11F

Группе IEEE 802.11F была заказана разработка практических рекомендаций для коммуникаций между точками доступа (IAPC12). Как часть разработки протокола взаимодействия точек доступа IAPP13, эти рекомендации требовалась для защищенного взаимодействия между точками доступа, а также для поддержки обратного преобразования MAC-адреса предыдущей точки доступа в ее адрес IP, чтобы обеспечить двум точкам доступа возможность коммуникаций с помощью IAPP. Поскольку две точки доступа могут быть подключены к разным каналам, протокол Inverse ARP [RFC2390] не обеспечивал полного решения задачи.

Группа IEEE 802.11F выбрала расширение протокола RADIUS [RFC2865] для обеспечения обратного преобразования адресов и управления ключами IPsec. Это было достигнуто за счет использования специальных атрибутов (VSA14), а также новых команд RADIUS, добавленных через определение дополнительных значений для атрибута RADIUS Service-Type. В результате рецензии IETF не потребовалось в соответствии с правилами согласования с IANA, указанными в [RFC2865]. Впоследствии раздел согласования с IANA для RADIUS в [RFC3575] был пересмотрен с включением рецензии IETF в большинстве случаев.

Взаимодействие между IEEE 802.11F и рабочими группами IETF типа AAA WG и SEAMOBY WG, открывающее доступ участникам IETF к спецификациям IEEE 802.11F до их публикации, организовано не было. При голосовании по пересмотренной спецификации IEEE 802.11F (Recirculation ballot) принимались во внимание только комментарии, относящиеся к изменениям спецификации. В результате вопросы, относящиеся к расширениям RADIUS в IEEE 802.11F, не были приняты во внимание.

Спецификация IEEE 802.11F представляла собой практические рекомендации по пробному применению (Trial Use Recommended Practice). Исполнительный комитет IEEE 802 отозвал ее 18 ноября 2005 года. В результате параметры RADIUS, выделенные для использования в IEEE 802.11F, вернулись в число доступных для распределения.

Приложение B. Члены IAB на момент создания этого документа

Bernard Aboba

Loa Andersson

Brian Carpenter

Leslie Daigle

Patrik Falstrom

Bob Hinden

Kurtis Lindqvist

David Meyer

Pekka Nikander

Eric Rescorla

Pete Resnick

Jonathan Rosenberg

Lixia Zhang

Адрес автора

Bernard Aboba

Microsoft

One Microsoft Way

Redmond, WA 98052

USA

EMail: bernarda@microsoft.com

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

1Simple Network Management Protocol – простой протокол сетевого управления.

2Authentication, Authorization, and Accounting – аутентификация, проверка полномочий и учет.

3Management Information Bases – базы информации для управления.

4Extensible Authentication Protocol – расширяемый протокол аутентификации.

5Internet Engineering Steering Group.

6Internet Architecture Board.

7Liaison web page.

8Project Authorization Requests.

9Vendor-Specific Attributes – связанные с определенным производителем атрибуты.

10Vendor-Specific extensions — фирменные расширения.

11Standards track.

12Inter-Access Point Communications.

13Inter-Access Point Protocol.

14Vendor-Specific Attribute — фирменный атрибут производителя.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Or