Network Working Group D. Loher
Request for Comments: 4565 Envysion, Inc.
Category: Informational D. Nelson
Enterasys Networks, Inc.
O. Volinsky
Colubris Networks, Inc.
B. Sarikaya
Huawei USA
July 2006
Evaluation of Candidate Control and Provisioning
of Wireless Access Points (CAPWAP) Protocols
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005.
この文書では、プロセスおよびワイヤレスアクセスポイントのワーキンググループ（WG CAPWAP）評価チームの管理とプロビジョニングの調査結果の記録です。彼らは2005年6月26日にワーキンググループに提出されたとして、評価チームは4候補プロトコルを検討しました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................3
2. Process Description .............................................3
2.1. Ratings ....................................................3
3. Member Statements ...............................................4
4. Protocol Proposals and Highlights ...............................5
4.1. LWAPP ......................................................5
4.2. SLAPP ......................................................6
4.3. CTP ........................................................6
4.4. WiCoP ......................................................7
5. Security Considerations .........................................7
6. Mandatory Objective Compliance Evaluation .......................8
6.1. Logical Groups .............................................8
6.2. Traffic Separation .........................................8
6.3. STA Transparency ...........................................9
6.4. Configuration Consistency .................................10
6.5. Firmware Trigger ..........................................11
6.6. Monitor and Exchange of System-wide Resource State ........12
6.7. Resource Control ..........................................13
6.8. Protocol Security .........................................15
6.9. System-Wide Security ......................................16
6.10. 802.11i Considerations ...................................17
6.11. Interoperability .........................................17
6.12. Protocol Specifications ..................................18
6.13. Vendor Independence ......................................19
6.14. Vendor Flexibility .......................................19
6.15. NAT Traversal ............................................20
7. Desirable Objective Compliance Evaluation ......................20
7.1. Multiple Authentication ...................................20
7.2. Future Wireless Technologies ..............................21
7.3. New IEEE Requirements .....................................21
7.4. Interconnection (IPv6) ....................................22
7.5. Access Control ............................................23
8. Evaluation Summary and Conclusions .............................24
9. Protocol Recommendation ........................................24
9.1. High-Priority Recommendations Relevant to
Mandatory Objectives ......................................25
9.1.1. Information Elements ...............................25
9.1.2. Control Channel Security ...........................25
9.1.3. Data Tunneling Modes ...............................26
9.2. Additional Recommendations Relevant to Desirable
Objectives ................................................27
9.2.1. Access Control .....................................27
9.2.2. Removal of Layer 2 Encapsulation for Data
Tunneling ..........................................28
9.2.3. Data Encapsulation Standard ........................28
10. Normative References ..........................................29
11. Informative References ........................................29
This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005.
この文書では、プロセスおよびワイヤレスアクセスポイントのワーキンググループ（WG CAPWAP）評価チームの管理とプロビジョニングの調査結果の記録です。彼らは2005年6月26日にワーキンググループに提出されたとして、評価チームは4候補プロトコルを検討しました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This document uses terminology defined in RFC 4118 [ARCH], RFC 4564 [OBJ], and IEEE 802.11i [802.11i].
この文書は、RFC 4118で定義された用語を使用し、[ARCH]、RFC 4564 [OBJ]、およびIEEE 802.11iの[802.11iの]。
The process to be described here has been adopted from a previous evaluation in IETF [RFC3127]. The CAPWAP objectives in RFC 4564 [OBJ] were used to set the scope and direction for the evaluators and was the primary source of requirements. However, the evaluation team also used their expert knowledge and professional experience to consider how well a candidate protocol met the working group objectives.
ここで説明する処理は、IETFの前の評価[RFC3127]から採用されています。 RFC 4564 [OBJ]でCAPWAPの目的は、評価者のための範囲および方向を設定するために使用され、要件の主要な供給源でした。しかし、評価チームはまた、候補プロトコルがワーキンググループの目標を満たしてどれだけ考慮するために彼らの専門知識と専門的な経験を使用していました。
For each of the 4 candidate protocols, the evaluation document editor assigned 2 team members to write evaluation briefs. One member was assigned to write a "Pro" brief and could take a generous interpretation of the proposal; this evaluator could grant benefit of doubt. A second evaluator was assigned to write a "Con" brief and was required to use strict criteria when performing the evaluation.
4つの候補プロトコルのそれぞれについて、評価文書エディタは、評価ブリーフを書くために2人のチームのメンバーを割り当て。あるメンバーは「プロ」簡潔に書くために割り当てられていたと提案の寛大な解釈を取ることができます。この評価者は、疑いの利益を与えることができます。第二の評価は、「コン」簡潔に書くために割り当てられたと評価を行う際に厳密な基準を使用する必要がありました。
The "Pro" and "Con" members independently evaluated how well the candidate protocol met each objective. Each objective was scored as an 'F' for failure, 'P' for partial, or 'C' for completely meeting the objective.
「プロ」と「コン」のメンバーは、独立候補プロトコルは、各目標を達成した方法も評価しました。各目的は、故障のために「F」、部分的、または完全に目的を満たすための「C」の「P」として記録しました。
F - Failure to Comply
F - 従いません
The evaluation team believes the proposal does not meet the objective. This could be due to the proposal completely missing any functionality towards the objective. A proposal could also receive an 'F' for improperly implementing the objective.
評価チームは、提案が目標を満たしていないと考えています。これは完全に客観的に向けたあらゆる機能が不足しているの提案によるものである可能性があります。提案はまた、不適切な目的を実現するための「F」を受け取ることができます。
P - Partial Compliance
P - 部分的なコンプライアンス
The proposal has some functionality that addresses the objective, but it is incomplete or ambiguous.
提案は、客観的に対処するいくつかの機能を持っていますが、それは不完全または曖昧です。
C - Compliant
C - 準拠
The proposal fully specifies functionality meeting the objective. The specification must be detailed enough that interoperable implementations are likely from reading the proposal alone. If the method is ambiguous or particularly complex, an explanation, use cases, or even diagrams may need to be supplied in order to receive a compliant rating.
提案は完全に目的を満たす機能を指定します。仕様は、相互運用可能な実装だけでは提案書を読んでから、可能性が高いことを十分に詳細に説明しなければなりません。この方法は、曖昧な又は特に複雑な場合、説明は、ケースを使用して、あるいは図準拠格付けを受信するために供給される必要があるかもしれません。
The 4-person evaluation team held a teleconference for each candidate to discuss the briefs. One of the working group chairs was also present at the meeting in an advisory capacity. Each evaluator presented a brief with supporting details. The team discussed the issues and delivered a team rating for each objective. These discussions are documented in the meeting minutes. The team ratings are used for the compliance evaluation.
4人の評価チームは、ブリーフを議論するために、各候補者のための会議を開催しました。ワーキンググループの椅子の一つは、顧問での会議でも存在しました。各評価者は、詳細をサポートして簡単に提示しました。チームは、問題を議論し、それぞれの目的のためにチームの格付けを配信しました。これらの議論は、議事録に記載されています。チームの評価は、コンプライアンス評価のために使用されています。
The candidate protocols were scored only on the information written in their draft. This means that a particular protocol might actually meet the specifics of a requirement, but if the proposal did not state, describe, or reference how that requirement was met, it might be scored lower.
候補プロトコルは唯一彼らの草案に書き込まれた情報に採点しました。これは、特定のプロトコルが実際に要件の仕様を満たしていますが、提案は述べるなかった場合は、その要件が満たされたか、それは低得点かもしれない記述、または参照可能性があることを意味します。
Darren Loher, Roving Planet
ダレンLoher、ロービングプラネット
I am employed as the senior architect at Roving Planet, which writes network and security management software for wireless networks. I have over 11 years of commercial experience designing and operating networks. I have implemented and operated networks and network management systems for a university, large enterprises, and a major Internet service provider for over 4 years. I also have software development experience and have written web-based network and systems management tools including a system for managing a very large distributed DNS system. I have witnessed the IETF standards process for several years, my first event being IETF 28. I have rarely directly participated in any working group activities before this point. To my knowledge, my company has no direct relationship with any companies that have authored the CAPWAP protocol submissions.
私は、ワイヤレスネットワークのためのネットワークおよびセキュリティ管理ソフトウェアを書き込みロービングプラネットのシニアアーキテクトとして採用しています。私は、市販の経験の設計と動作ネットワークの11年以上のを持っています。私は、大学、大企業、および4年以上にわたって主要なインターネットサービスプロバイダのネットワークおよびネットワーク管理システムを導入し、運用しています。私はまた、ソフトウェア開発の経験があり、非常に大規模な分散DNSシステムを管理するためのシステムを含む、ウェブベースのネットワークおよびシステム管理ツールを書かれています。私は、私の最初のイベントは、IETF 28.私はめったに直接この時点の前に任意のワーキンググループの活動に参加していないこと、数年前からIETF標準化プロセスを目撃しました。私の知る限りでは、私の会社は、CAPWAPプロトコルの提出を執筆しているすべての企業とは直接関係はありません。
David Nelson, Enterasys
デビッド・ネルソン、エンテラシス
I am currently cochair of the RADEXT WG, AAA Doctor in O&M Area, and employed in the core router engineering group of my company. I have previously served on a protocol evaluation team in the AAA WG, and am a coauthor of RFC 3127 [RFC3127]. I was an active contributor in the IEEE 802.11i task group, and previously employed in the WLAN engineering group of my company. I have had no participation in any of the submitted protocols. My company does have an OEM relationship with at least one company whose employees have coauthored one of the submissions, but I have no direct involvement with our WLAN product at this time.
私は現在、O＆MエリアでRADEXT WG、AAA医師のcochairだ、と私の会社のコアルータエンジニアリンググループに採用します。私は以前AAA WGにおけるプロトコルの評価チームを務め、およびRFC 3127 [RFC3127]の共著者をしていています。私は、IEEE 802.11iのタスクグループで積極的に貢献した、と以前に私の会社のWLANエンジニアリンググループに採用します。私は、提出されたプロトコルのいずれにも参加していたなかったです。私の会社は、従業員の提出のいずれかを共同執筆している少なくとも一つの会社とのOEM関係を持っていませんが、私はこの時点で私たちのWLAN製品とは直接関わりを持っていません。
Oleg Volinsky, Colubris Networks
オレグヴォルィーニ、Kolibrisネットワーク
I am a member of the Enterprise group of Colubris Networks, a WLAN vendor. I have over 10 years of experience in design and development of network products from core routers to home networking equipment. Over years I have participated in various IETF groups. I have been a member of CAPWAP WG for over a year. In my current position I have been monitoring the developments of CAPWAP standards and potential integration of the resulting protocol into the company's products. I have not participated in any of the candidate protocol drafts. I have not worked for any of the companies whose staff authored any of the candidate protocols.
私はコルブリス・ネットワークス、WLANベンダーのエンタープライズ・グループのメンバーです。私は、コア・ルータからホームネットワーク機器にネットワーク製品の設計・開発における10年以上の経験を持っています。長年にわたり、私は様々なIETFのグループに参加しています。私は一年以上CAPWAP WGのメンバーとなっています。私の現在の位置では、私は、同社の製品にCAPWAP基準となるプロトコルの潜在的な統合の進展を監視してきました。私は候補プロトコルドラフトのいずれかに参加していません。私は、そのスタッフの候補プロトコルのいずれかを執筆企業のいずれかのために働いていません。
Behcet Sarikaya, University of Northern British Columbia
ベーチェットSarikaya、ノーザン・ブリティッシュコロンビア大学
I am currently Professor of Computer Science at UNBC. I have so far 5 years of experience in IETF as a member of mobile networking-related working groups. I have made numerous I-D contributions and am a coauthor of one RFC. I have submitted an evaluation draft (with Andy Lee) that evaluated LWAPP, CTP, and WiCoP. Also I submitted another draft (on CAPWAPHP) that used LWAPP, CTP, WiCoP, and SLAPP as transport. I also have research interests on next-generation access point/controller architectures. I have no involvement in any of the candidate protocol drafts, have not contributed any of the drafts. I have not worked in any of the companies whose staff has produced any of the candidate protocols.
私は現在、UNBCのコンピュータサイエンスの教授です。私は、モバイルネットワーキング関連のワーキンググループの一員として、IETFでの経験のこれまでの5年間を持っています。私は、多くのI-Dの貢献をしたと1つのRFCの共著者をしていています。私はLWAPP、CTP、およびWiCoPを評価した（アンディ・リーとの）評価案を提出しました。また、私はトランスポートとしてLWAPP、CTP、WiCoP、およびSLAPPを使用（CAPWAPHP上の）別の案を提出しました。私はまた、次世代のアクセスポイント/コントローラアーキテクチャの研究関心を持っています。私は候補プロトコルドラフトのいずれにも関与していない、ドラフトのいずれかに貢献していません。私は、そのスタッフの候補プロトコルのいずれかを生産している会社のいずれにも働いていません。
The following proposals were submitted as proposals to the CAPWAP working group.
以下の提案は、CAPWAPワーキンググループへの提案として提出されました。
The "Light Weight Access Point Protocol" [LWAPP] was the first CAPWAP protocol originally submitted to Seamoby Working Group. LWAPP proposes original solutions for authentication and user data encapsulation as well as management and configuration information elements. LWAPP originated as a "split MAC" protocol, but recent changes have added local MAC support as well. LWAPP has received a security review from Charles Clancy of the University of Maryland Information Systems Security Lab.
「ライトウェイトアクセスポイントプロトコル」[LWAPP]は、もともとSeamobyワーキンググループに提出された最初のCAPWAPプロトコルでした。 LWAPPは、元の認証およびユーザデータのカプセル化のためのソリューションならびに管理および構成情報要素を提案しています。 LWAPPは、「スプリットMAC」プロトコルとして始まったが、最近の変化は、同様にローカルMACのサポートが追加されました。 LWAPPは、メリーランド情報システムセキュリティ研究室の大学のチャールズ・クランシーからセキュリティレビューを受けています。
LWAPP is the most detailed CAPWAP proposal. It provides a thorough specification of the discovery, security, and system management methods. LWAPP focuses on the 802.11 WLAN-specific monitoring and configuration. A key feature of LWAPP is its use of raw 802.11 frames that are tunneled back to the Access Controller (AC) for processing. In both local- and split-MAC modes, raw 802.11 frames are forwarded to the AC for management and control. In addition, in split-MAC mode, user data is tunneled in raw 802.11 form to the AC. While in concept, LWAPP could be used for other wireless technologies, LWAPP defines very few primitives that are independent of the 802.11 layer.
LWAPPは、最も詳細なCAPWAPの提案です。それは発見、セキュリティ、およびシステム管理方法の徹底した仕様を提供します。 LWAPPは802.11 WLAN固有の監視や構成に焦点を当てています。 LWAPPの重要な特徴は、処理のためにアクセスコントローラ（AC）に戻ってトンネリングされた生802.11フレームの使用です。ローカルからとスプリットMAC両方のモードにおいて、生802.11フレームは、管理および制御のためのACに転送されます。また、スプリットMACモードでは、ユーザデータがACに生802.11形態でトンネリングされます。コンセプトに、LWAPPは、他の無線技術を使用することができる一方で、LWAPPは802.11層から独立している非常に少数のプリミティブを定義します。
"Secure Light Access Point Protocol" [SLAPP] distinguishes itself with the use of well-known, established technologies such as Generic Routing Encapsulation (GRE) for user data tunneling between the AC and Wireless Termination Point (WTP) and the proposed standard Datagram Transport Layer Security [DTLS] for the control channel transport.
ACおよびワイヤレス終端ポイント（WTP）との間のユーザ・データ・トンネリングのような汎用ルーティングカプセル化（GRE）のような周知の確立された技術を用いてそれ自体を区別する[SLAPP]「光アクセスポイントプロトコルセキュア」と提案された標準データグラムトランスポート制御チャネル・トランスポートのセキュリティ[DTLS]をレイヤ。
4 modes of operation are supported, 2 local-MAC modes and 2 split-MAC modes. STA control may be performed by the AC using native 802.11 frames that are encapsulated in SLAPP control packets across all modes. (STA refers to a wireless station, typically a laptop.)
操作の4つのモードは、2ローカルMACモードと2スプリットMACモードをサポートしています。 STA制御は、すべてのモードを横切っSLAPP制御パケットにカプセル化されたネイティブ802.11フレームを使用してACによって行うことができます。 （STAは、ラップトップ、典型的には、無線局をいいます。）
In SLAPP local-MAC modes, user data frames may be bridged or tunneled back using GRE to the AC as 802.3 frames. In the split-MAC modes, user data is always tunneled back to the AC as native 802.11 frames. Encryption of user data may be performed at either the AC or the WTP in split-MAC mode.
SLAPPローカル-MACモードで、ユーザ・データ・フレームは、架橋または802.3フレームとしてACにGREを使用してバックトンネリングすることができます。スプリットMACモードでは、ユーザーデータは常にネイティブ802.11フレームとして戻ってACにトンネリングされます。ユーザデータの暗号化は、スプリットMACモードではACまたはWTPのいずれかで行うことができます。
"CAPWAP Tunneling Protocol" [CTP] distinguishes itself with its use of Simple Network Management Protocol (SNMP) to define configuration and management data that it then encapsulates in an encrypted control channel. CTP was originally designed as a local-MAC protocol but the new version has split-MAC support as well. In addition, CTP is clearly designed from the beginning to be compatible with multiple wireless technologies.
「CAPWAPトンネリングプロトコル」[CTP]は、それが次いで、暗号化された制御チャネル内にカプセル化した構成と管理データを定義するために簡易ネットワーク管理プロトコル（SNMP）の使用と、それ自体を区別する。 CTPは、もともと地元-MACプロトコルとして設計されましたが、新しいバージョンでは、スプリットMACのたサポートを同様。また、CTPは明らかに、複数の無線技術と互換性があるように最初から設計されています。
CTP defines information elements for management and control between the AC and WTP. CTP control messages are specified for STA session state, configuration, and statistics.
CTPは、ACとWTP間の管理および制御のための情報要素を定義します。 CTP制御メッセージは、STAのセッション状態、コンフィギュレーション、および統計のために指定されています。
In local-MAC mode, CTP does not forward any native wireless frames to the AC. CTP specifies control messages for STA session activity, mobility, and radio frequency (RF) resource management between the AC and WTP. CTP local-MAC mode specifies that the integration function from the wireless network to 802.3 Ethernet is performed at the WTP for all user data. User data may either be bridged at the WTP or encapsulated as 802.3 frames in CTP packets at the WTP and tunneled to the AC.
ローカル-MACモードでは、CTPは、ACに任意のネイティブ無線フレームを転送しません。 CTPは、ACとWTP間STAセッションアクティビティ、モビリティ、および無線周波数（RF）資源管理のための制御メッセージを指定します。 CTPローカル-MACモードは、802.3イーサネットへのワイヤレスネットワークからの統合機能は、すべてのユーザーデータのためにWTPで実行されることを指定します。ユーザデータは、いずれかのWTPで架橋またはWTPでCTPパケット内の802.3フレームとしてカプセル化され、ACにトンネリングすることができます。
CTP's split-MAC mode is defined as an extension to local-MAC mode. In CTP's version of split-MAC operation, wireless management frames are forwarded in their raw format to the AC. User data frames may be bridged locally at the WTP, or they may be encapsulated in CTP packets and tunneled in their native wireless form to the AC.
CTPのスプリットMACモードは、ローカル-MACモードの拡張として定義されます。スプリットMAC演算のCTPのバージョンでは、無線管理フレームは、ACにその生の形式で転送されます。ユーザ・データ・フレームは、WTPで局所的に架橋されていてもよい、またはそれらはCTPパケットにカプセル化し、ACへのネイティブ無線形式でトンネリングすることができます。
CTP supplies STA control abstraction, methods for extending the forwarding of multiple types of native wireless management frames, and many options for user data tunneling. Configuration management is an extension of SNMP. This makes CTP one of the most flexible of the proposed CAPWAP protocols. However, it does define new security and data tunneling mechanisms instead of leveraging existing standards.
CTPは、STA制御抽象化、ネイティブ無線管理フレームの複数の種類の転送を拡張するための方法、およびユーザ・データ・トンネリングのための多くのオプションを供給する。構成管理は、SNMPの拡張機能です。これは、CTP提案CAPWAPプロトコルの最も柔軟のひとつとなっています。しかし、それは代わりに、既存の標準を活用の新しいセキュリティおよびデータトンネリングメカニズムを定義しません。
"Wireless LAN Control Protocol" [WICOP] introduces new discovery, configuration, and management of Wireless LAN (WLAN) systems. The protocol defines a distinct discovery mechanism that integrates WTP-AC capabilities negotiation.
「無線LAN制御プロトコルは、」[WICOP]ワイヤレスLAN（WLAN）システムの新発見、構成、および管理を導入しています。プロトコルは、WTP-AC機能ネゴシエーションを統合異なる検出メカニズムを定義します。
WiCoP defines 802.11 Quality of Service (QoS) parameters. In addition, the protocol proposes to use standard security and authentication methods such as IPsec and Extensible Authentication Protocol (EAP). The protocol needs to go into detail with regards to explicit use of the above-mentioned methods. To ensure interoperable protocol implementations, it is critical to provide users with detailed unambiguous specification.
WiCoPは、サービス（QoS）のパラメータの802.11品質を定義します。また、プロトコルは、IPsecと拡張認証プロトコル（EAP）などの標準的なセキュリティおよび認証方法を使用することを提案します。プロトコルは、上記の方法を明示的に使用に関して詳細に入る必要があります。相互運用可能なプロトコル実装を確保するためには、詳細な明確な仕様をユーザーに提供することが重要です。
Each of the candidate protocols has a Security Considerations section, as well as security properties. The CAPWAP objectives document [OBJ] contains security-related requirements. The evaluation team has considered if and how the candidate protocols implement the security features required by the CAPWAP objectives. However, this evaluation team is not a security team and has not performed a thorough security evaluation or tests. Any protocol coming out of the CAPWAP working group must undergo an IETF security review in order to fully meet the objectives.
候補プロトコルのそれぞれは、Security Considerations部だけでなく、セキュリティ上の特性を有しています。 CAPWAP目的の文書[OBJ]は、セキュリティ関連の要件が含まれています。候補プロトコルはCAPWAPの目的で必要とされるセキュリティ機能を実装する場合、どのように評価チームは考えられています。しかし、この評価チームは、セキュリティチームではなく、徹底したセキュリティ評価やテストを行っていません。 CAPWAPワーキンググループから出てきた任意のプロトコルが完全に目標を達成するために、IETFセキュリティレビューを受けなければなりません。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP：C、SLAPP：C、CTP：C、WiCoP：C
LWAPP
APP
LWAPP provides a control message called "Add WLAN". This message is used by the AC to create a WLAN with a unique ID, i.e., its Service Set Identifier (SSID). The WTPs in this WLAN have their own Basic Service Set Identifiers (BSSIDs). LWAPP meets this objective.
LWAPPは、「WLANを追加」と呼ばれる制御メッセージを提供します。このメッセージは、一意のIDとWLANを作成するために、ACで使用され、すなわち、そのサービスセット識別子（SSID）。このWLANでWTPsは、自分の基本サービスセット識別子（BSSIDを）持っています。 LWAPPは、この目的を満たしています。
SLAPP
RELAX
SLAPP explicitly supports 0-255 BSSIDs.
SLAPPは、明示的に0〜255個のBSSIDをサポートしています。
CTP
CTP
CTP implements a NETWORK_ID attribute that allows a wireless-technology-independent way of creating logical groups. CTP meets this objective.
CTPは、論理グループを作成するための無線技術に依存しない方法を可能NETWORK_ID属性を実装しています。 CTPは、この目的を満たしています。
WiCoP
WiCoP
WiCoP provides control tunnels to manage logical groups. There is one control tunnel for each logical group. WiCoP meets this objective.
WiCoPは論理グループを管理するための制御トンネルを提供します。各論理グループに対して1つの制御トンネルがあります。 WiCoPは、この目的を満たしています。
LWAPP:C, SLAPP:C, CTP:P, WiCoP:P
LWAPP：C、SLAPP：C、CTP：P、WiCoP：P
If a protocol distinguishes a data message from a control message, then it meets this objective.
プロトコルは、制御メッセージからデータ・メッセージを区別する場合、それは、この目的を満たします。
LWAPP
APP
LWAPP separates control messages from data messages using "C-bit". "C-bit" is defined in the LWAPP transport header. When C-bit is equal to zero, the message is a data message. When C-bit is equal to one, the message is a control message. So, LWAPP meets this objective.
LWAPPは、「C-ビット」を使用してデータ・メッセージから制御メッセージを分離します。 「Cビットを」LWAPPトランスポートヘッダに定義されています。 Cビットがゼロに等しい場合、メッセージはデータメッセージです。 Cビットが1に等しい場合、メッセージは制御メッセージです。だから、LWAPPは、この目的を満たしています。
SLAPP
RELAX
The SLAPP protocol encapsulates control using DTLS and optionally, user data with GRE. Of particular note, SLAPP defines 4 "architecture modes" that define how user data is handled in relation to the AC. SLAPP is compliant with this objective.
SLAPPプロトコルはDTLSおよび必要に応じて、GREとのユーザデータを使用してコントロールをカプセル化します。特に注目すべきは、SLAPPは、ユーザデータがACに関連して処理される方法を定義4「アーキテクチャモード」を定義します。 SLAPPは、この目的に準拠しています。
CTP
CTP
CTP defines separate packet frame types for control and data. However, the evaluation team could not find a way to configure the tunneling of user data, so it opted to rate CTP as only partially compliant. It appears that CTP would rely on SNMP MIB Object Identifiers (OIDs) for this function, but none were defined in the specification. Defining the necessary OIDs would make CTP fully compliant.
CTPは、制御およびデータのための別個のパケットのフレームタイプを定義します。しかし、評価チームは、ユーザデータのトンネリングを設定する方法を見つけることができませんでしたので、それは部分的にしか対応としてCTPを評価することにしました。 CTPは、この機能のためのSNMP MIBオブジェクト識別子（OID）に依存しているだろうと表示されますが、いずれも仕様で定義されていませんでした。必要なOIDを定義することはCTPが完全に準拠するだろう。
WiCoP
WiCoP
WiCoP provides for separation between control and data channels. However, tunneling methods are not explicitly described. Because of this, WiCoP partially meets this objective.
WiCoPは、制御及びデータチャネル間の分離を提供します。しかし、トンネリング方法は、明示的に記載されていません。このため、WiCoPは、部分的にこの目的を満たしています。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP：C、SLAPP：C、CTP：C、WiCoP：C
If a protocol does not indicate that STA needs to know about the protocol, then this objective is met.
プロトコルは、STAは、プロトコルについて知る必要があることを示していない場合には、この目的は達成されます。
The protocol must not define any message formats between STA and WTP/AC.
プロトコルは、STAとWTP / ACとの間の任意のメッセージ・フォーマットを定義してはなりません。
LWAPP
APP
LWAPP does not require a STA to be aware of LWAPP. No messages or protocol primitives are defined that the STA must interact with beyond the 802.11 standard. LWAPP is fully compliant.
LWAPPは、LWAPPを認識するようにSTAを必要としません。いかなるメッセージやプロトコルプリミティブは、STAは、802.11標準を超えたと対話しなければならないことを定義されていません。 LWAPPは完全に準拠しています。
SLAPP
RELAX
SLAPP places no requirements on STA network elements. No messages or protocol primitives are defined that the STA must interact with beyond the 802.11 standard.
SLAPPは、STAのネットワーク要素には何の要件を課すません。いかなるメッセージやプロトコルプリミティブは、STAは、802.11標準を超えたと対話しなければならないことを定義されていません。
CTP
CTP
CTP does not require a terminal to know CTP. So, CTP meets this objective.
CTPは、CTPを知るために、端末を必要としません。だから、CTPは、この目的を満たしています。
WiCoP
WiCoP
WiCoP does not require a terminal to know WiCoP. So, WiCoP meets this objective.
WiCoPはWiCoPを知るために、端末を必要としません。だから、WiCoPは、この目的を満たしています。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP：C、SLAPP：C、CTP：C、WiCoP：C
Given the objective of maintaining configurations for a large number of network elements involved in 802.11 wireless networks, the evaluation team would like to recommend that a token, key, or serial number for configuration be implemented for configuration verification.
802.11ワイヤレスネットワークに関係するネットワーク要素の多数のための構成を維持する目的を考えると、評価チームは、コンフィギュレーションのためのトークン、キー、またはシリアル番号が設定の確認のために実施されることをお勧めしたいと思います。
LWAPP
APP
It is possible to obtain and verify all configurable values through LWAPP. Notably, LWAPP takes an approach that only "non-default" settings (defaults are specified by LWAPP) are necessary for transmission when performing configuration consistency checks. This behavior is explicitly specified in LWAPP. LWAPP is compliant with this objective.
LWAPPを通じてすべての設定値を取得し、検証することが可能です。特に、LWAPPは、構成の整合性チェックを行う場合にのみ「非デフォルト」設定（デフォルトはLWAPPによって指定される）を送信するために必要なアプローチを取ります。この動作は、明示的にLWAPPに指定されています。 LWAPPは、この目的に準拠しています。
SLAPP
RELAX
Numerous events and statistics are available to report configuration changes and WTP state. SLAPP does not have any built-in abilities to minimize or optimize configuration consistency verification, but it is compliant with the objective.
数多くのイベントと統計は、構成の変更やWTPの状態を報告するために利用されています。 SLAPPは、設定の整合性の検証を最小限に抑えるか、または最適化するために、任意の組み込みの能力を持っていませんが、それは客観的に準拠しています。
CTP
CTP
CTP's use of SNMP makes configuration consistency checking straightforward. Where specified in a MIB, one could take advantage of default values.
SNMPのCTPの使用は、設定の整合性を簡単なチェックを行います。 MIBに指定された場合は、1がデフォルト値を利用することができます。
WICOP
WICOP
The WiCoP configuration starts with exchange of capability messages between the WTP and AC. Next, configuration control data is sent to the WTP.
WiCoP構成はWTPとAC間の機能メッセージの交換を開始します。次に、構成制御データはWTPに送られます。
WiCoP defines configuration values in groups of configuration data messages. In addition, the protocol supports configuration using MIB objects. To maintain data consistency, each configuration message from the AC is acknowledged by the WTP.
WiCoPは、構成データ・メッセージのグループで構成値を定義します。また、プロトコルは、MIBオブジェクトを使用して構成をサポートしています。データの一貫性を維持するために、ACから各構成メッセージは、WTPにより認められています。
LWAPP:P, SLAPP:P, CTP:P, WiCoP:C
LWAPP：P、SLAPP：P、CTP：P、WiCoP：C
The evaluation team considered the objective and determined that for full compliance, the protocol state machine must support the ability to initiate the process for checking and performing a firmware update independently of other functions.
評価チームは、目標を考慮し、完全に準拠するために、プロトコル状態機械チェックおよび他の機能とは独立してファームウェアのアップデートを実行するためのプロセスを開始する能力をサポートしなければならないことを決定しました。
Many protocols perform a firmware check and update procedure only on system startup time. This method received a partial compliance. The team believed that performing the firmware check only at startup time was unnecessarily limiting and that allowing it to occur at any time in the state machine did not increase complexity of the protocol. Allowing the firmware update process to be initiated during the running state allows more possibilities for minimizing downtime of the WTP during the firmware update process.
多くのプロトコルは、システムの起動時にファームウェアのチェックと更新手順を実行します。この方法は、部分的なコンプライアンスを受けました。チームは唯一の起動時にファームウェアのチェックを行うことが不必要に制限し、それがステートマシンで任意の時点で発生することができますが、プロトコルの複雑さを増加させなかったことであると信じていました。ファームウェア更新プロセスが実行状態中に開始されることを可能にするファームウェア更新プロセス中WTPのダウンタイムを最小化するためのより多くの可能性を可能にします。
For example, the firmware check and download of the image over the network could potentially occur while the WTP was in a running state. After the file transfer was complete, the WTP could be rebooted just once and begin running the new firmware image. This could pose a meaningful reduction in downtime when the firmware image is large, the link for loading the file is very slow, or the WTP reboot time is long.
WTPが実行状態であったが、例えば、ネットワークを介して画像のファームウェアチェック及びダウンロードは、潜在的に起こり得ます。ファイルの転送が完了した後、WTPは一度だけ再起動し、新しいファームウェアイメージの実行を開始することができます。ファームウェアイメージが大きい場合は、ダウンタイムでの有意義な削減をもたらすことができ、ファイルをロードするためのリンクが非常に遅い、またはWTPの再起動時間が長くなります。
A protocol would only fail compliance if no method was specified for updating of firmware.
何の方法は、ファームウェアの更新のために指定されていない場合、プロトコルは、コンプライアンスを失敗していました。
LWAPP
APP
Firmware download is initiated by the WTP only at the Join phase (when a WTP is first associating with an AC) and not at any other time. The firmware check and update could be "triggered" indirectly by the AC by sending a reset message to the WTP. The resulting reboot would cause a firmware check and update to be performed. LWAPP is partially compliant because its firmware trigger can only be used in the startup phases of the state machine.
ファームウェアのダウンロードのみ（WTPは、第1の交流と結合されている）参加位相ではなく、他の任意の時点でWTPによって開始されます。ファームウェアのチェックと更新がWTPにリセットメッセージを送信することにより、ACことにより、間接的に「トリガー」することができます。ファームウェアのチェックと更新を引き起こす結果の再起動が実行されます。そのファームウェアのトリガは、ステートマシンの起動時の段階でのみを使用することができるのでLWAPPは、部分的に準拠しています。
SLAPP
RELAX
SLAP includes a firmware check and update procedure that is performed when a WTP is first connecting to an AC. The firmware check and update can only be "triggered" indirectly by the AC by sending a reset message to the WTP. SLAPP is partially compliant because its firmware trigger can only be used in the startup phases of the state machine.
SLAPは、WTPが最初ACに接続されたときに実行されるファームウェアのチェックおよび更新手順を含みます。ファームウェアのチェックおよび更新は、WTPにリセット・メッセージを送信することにより、ACによって間接的に「トリガー」することができます。そのファームウェアのトリガは、ステートマシンの起動時の段階でのみを使用することができるのでSLAPPは、部分的に準拠しています。
CTP
CTP
The CTP state machine specifies that the firmware upgrade procedure must be performed immediately after the authentication exchange as defined in section 6.2 of [CTP]. However, section 5.2.5 of [CTP] states that the SW-Update-Req message MAY be sent by the AC. This indirectly implies that CTP could support an AC-triggered software update during the regular running state of the WTP. So it seems that CTP might be fully compliant, but the proposal should be clarified for full compliance.
CTP状態マシンは[CTP]のセクション6.2で定義されるようにファームウェアのアップグレード手順は、認証交換の直後に行われなければならないことを指定します。しかし、[CTP]のセクション5.2.5は、SW-更新-REQメッセージは、ACによって送信することができることを述べています。これは間接的にCTPは、WTPの通常の運転状態の時にACトリガ、ソフトウェアの更新をサポートすることができることを意味します。だから、CTPが完全に準拠するかもしれないと思われますが、この提案は完全に準拠するために明確にする必要があります。
WiCoP
WiCoP
In WiCoP, firmware update may be triggered any time in the active state, so WiCoP is fully compliant.
WiCoPでは、ファームウェアの更新は、アクティブ状態の任意の時間をトリガすることができるので、WiCoPは完全に準拠しています。
LWAPP:C, SLAPP:C, CTP:P, WiCoP:C
LWAPP：C、SLAPP：C、CTP：P、WiCoP：C
The evaluation team focused on the protocols supplying 3 methods relevant to statistics from WTPs: The ability to transport statistics, a minimum set of standard data, and the ability to extend what data could be reported or collected.
統計を輸送する能力、標準的なデータの最小セット、およびデータが報告されたかを収集することができるもの拡張する能力：WTPsからの統計に関連する3つの方法を供給プロトコルに焦点を当てた評価チーム。
LWAPP
APP
Statistics are sent by the WTP using an "Event Request" message. LWAPP defines an 802.11 statistics message that covers 802.11 MAC layer properties. LWAPP is compliant.
統計は、「イベント要求」メッセージを使用してWTPで送信されます。 LWAPPは、802.11 MAC層の特性をカバー802.11統計メッセージを定義します。 LWAPPは準拠しています。
SLAPP
RELAX
WLAN statistics transport is supplied via the control channel and encoded in SLAPP-defined TLVs called information elements. 802.11 configuration and statistics information elements are supplied in [SLAPP] 6.1.3.1. These are extendable and include vendor-specific extensions.
WLAN統計輸送は、制御チャネルを介して供給されると情報要素と呼ばれるSLAPP定義のTLVでエンコードされています。 802.11設定および統計情報要素は[SLAPP] 6.1.3.1に供給されます。これらは、拡張可能であり、ベンダー固有の拡張機能が含まれます。
CTP
CTP
CTP defines a control message called "CTP Stats-Notify". This control message contains statistics in the form of SNMP OIDs and is sent from the WTP to AC. This approach is novel because it leverages the use of standard SNMP.
CTPは、「CTP統計-通知」と呼ばれる制御メッセージを定義します。この制御メッセージは、SNMP OIDの形で統計情報が含まれており、ACにWTPから送信されます。それは、標準のSNMPの使用を活用しているため、このアプローチは新規です。
Section 5.3.10 of [CTP] recommends the use of 802.11 MIBs where applicable. However, the proposal acknowledges that additional configuration and statistics information is required, but does not specify these MIB extensions. CTP needs to add these extensions to the proposal. Also, this minimum set of statistics and configuration OIDs must become requirements in order to fully meet the objective.
[CTP]のセクション5.3.10が適用802.11のMIBの使用を推奨しています。しかし、この提案は、追加の設定および統計情報が必要であることを認識し、これらのMIB拡張を指定していません。 CTPは、提案にこれらの拡張機能を追加する必要があります。また、統計および設定のOIDのこの最小セットは完全に目的を達成するために、必要条件になっている必要があります。
WiCoP
WiCoP
The feedback control message sent by the WTP contains many statistics. WiCoP specifies 15 statistics that the WTP needs to send to the AC. New versions of WiCoP can address any new statistics that the AC needs to monitor the WTP. WiCoP meets this objective.
WTPによって送信されたフィードバック制御メッセージは、多くの統計情報が含まれています。 WiCoPはWTPがACに送信する必要がある15件の統計情報を指定します。 WiCoPの新バージョンでは、ACは、WTPを監視するために必要なすべての新しい統計に対処することができます。 WiCoPは、この目的を満たしています。
LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
LWAPP：C、SLAPP：P、CTP：P、WiCoP：P
The evaluation team interpreted the resource control objective to mean that the CAPWAP protocol must map 802.11e QoS markings to the wired network. This mapping must include any encapsulation or tunneling of user data defined by the CAPWAP protocol. Of particular note, the evaluation team agreed that the CAPWAP protocol should supply an explicit capability to configure this mapping. Since most of the protocols relied only on the 802.11e statically defined mapping, most received a partial compliance.
評価チームは、CAPWAPプロトコルは、有線ネットワークにの802.11e QoSマーキングをマッピングしなければならないことを意味するためにリソース制御目標を解釈します。このマッピングは、CAPWAPプロトコルによって定義されたユーザデータの任意のカプセル化やトンネリングを含まなければなりません。特に注目すべきなのは、評価チームはCAPWAPプロトコルは、このマッピングを設定するには、明示的な機能を提供するべきであることに合意しました。プロトコルのほとんどは、802.11eの静的に定義されたマッピングのみに頼っているため、ほとんどの部分コンプライアンスを受けました。
LWAPP
APP
LWAPP defines its own custom TLV structure, which consists of an 8-bit type or class of information value and an additional 8-bit value that indexes to a specific variable.
LWAPPは情報値と特定の変数へのインデックスの追加8ビットの値の8ビットのタイプまたはクラスで構成され、独自のカスタムTLV構造を定義します。
LWAPP allows the mobile station-based QoS configuration in each Add Mobile Request sent by AC to WTP for each new mobile station that is attached. Packet prioritization is left to individual WTPs. 4 different QoS policies for each station to enforce can be configured. Update Mobile QoS message element can be used to change QoS policy at the WTP for a given mobile station. LWAPP should support 8 QoS policies as this matches 802.11e 802.1p and IP TOS, but for this objective, 4 classes is compliant.
LWAPPが取り付けられており、それぞれの新しい移動局のためのWTPにACによって送信される各追加のモバイル要求における移動局ベースのQoS設定を可能にします。パケットの優先順位付けは、個々のWTPsに委ねられています。強制する各ステーションのための4つの異なるQoSポリシーを構成することができます。更新モバイルQoSのメッセージ要素は、与えられた移動局に対するWTPでQoSポリシーを変更するために使用することができます。これはの802.11e 802.1pおよびIP TOSに一致するようLWAPPは8つのQoSポリシーをサポートする必要がありますが、この目的のために、4クラスが準拠しています。
Overall, LWAPP conforms to the resource control objective. It enables QoS configuration and mapping. The control can be applied on a logical group basis and also enables the wireless traffic to be flexibly mapped to the wired segment.
全体的に、LWAPPは、リソース制御目標に準拠しています。これは、QoS設定とマッピングを可能にします。制御論理グループ単位で適用され、また、柔軟有線セグメントにマップする無線トラフィックを可能にすることができます。
SLAPP
RELAX
Although 802.11e specifies 802.1p and Differentiated Service Code Point (DSCP) mappings, there is no explicit support for 802.11e in SLAPP. SLAPP must be updated to add 802.11e as one of the standard capabilities that a WTP could support and specify a mechanism that would allow configuration of mapping the QoS classes.
802.11eのは、802.1pおよび差別化サービスコードポイント（DSCP）のマッピングを指定しますが、SLAPPで802.11eのための明示的なサポートはありません。 SLAPPはWTPは、QoSクラスのマッピングの設定を可能にするメカニズムをサポートして指定することができ、標準的な機能の一つとしての802.11eを追加するために更新する必要があります。
CTP
CTP
CTP requires that the WTP and AC copy the QoS marking of user data to the data message encapsulation. This mapping is accomplished by the CTP Header's 1-byte policy field. However, no configuration of QoS mapping other than copying the user data's already existing markings is defined in CTP. It seems clear that SNMP could be used to configure the mapping to occur differently, but no OIDs are defined that would enable this. Partial compliance is assigned to CTP for this objective.
CTPは、WTPとACは、データメッセージのカプセル化へのユーザデータのQoSマーキングをコピーすることが必要です。このマッピングは、CTPヘッダーの1バイトのポリシーフィールドによって達成されます。ただし、ユーザーデータの既存のマーキングをコピーする以外のQoSマッピングのない設定はCTPに定義されていません。 SNMPが異なっ発生するマッピングを設定するために使用することができますが、何のOIDがこれを可能にするように定義されていないことが明らかに思えます。部分的なコンプライアンスは、この目的のためにCTPに割り当てられています。
WiCoP
WiCoP
Note: WiCoP rating for resource control objectives has been upgraded from Failed to Partial. After an additional review of the WiCoP protocol proposal, it was determined that the protocol partially meets resource control objectives.
注：一部に失敗したから、リソースコントロール目標のためWiCoP評価がアップグレードされました。 WiCoPプロトコルの提案の追加審査した後、それはプロトコルが部分的リソース制御目標を満たしていることを決定しました。
WiCoP protocol starts its QoS configuration with 802.11e capability exchange between the WTP and AC. The QoS capabilities primitives are included in the capability messages.
WiCoPプロトコルは、WTPとAC間の802.11e能力交換とのQoS設定を開始します。 QoS機能プリミティブは機能メッセージに含まれています。
WiCoP defines the QoS-Value message that contains 802.11e configuration parameters. This is sent for each group supported by the WTP. WiCoP does not provide an explicit method for configuration of DSCP tags and 802.1P precedence values. It is possible to configure these parameters through SNMP OID configuration method, but WiCoP does not explicitly identify any specific MIBs. Overall, WiCoP partially meets resource control CAPWAP objectives. In order to be fully compliant with the given objective, the protocol needs to identify a clear method to configure 802.1p and DSCP mappings.
WiCoPは、802.11eの設定パラメータが含まれていたQoS-値のメッセージを定義します。これは、WTPでサポートされているグループごとに送信されます。 WiCoPは、DSCPタグと802.1P precedence値を設定するための明確な方法を提供していません。 SNMP OIDの設定方法を介してこれらのパラメータを設定することは可能ですが、WiCoPは、明示的に特定のMIBを特定していません。全体的に、WiCoPは、部分的にリソース制御CAPWAP目標を満たしています。与えられた目的に完全に準拠するためには、プロトコルは、802.1pおよびDSCPマッピングを設定するための明確な方法を特定する必要があります。
LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
LWAPP：C、SLAPP：C、CTP：F、WiCoP：F
For the purposes of the protocol security objective, the evaluation team primarily considered whether or not the candidate protocols implement the security features required by the CAPWAP objectives. Please refer to the Security Considerations section of this document.
プロトコルのセキュリティ対策方針の目的のために、評価チームは、主に候補プロトコルはCAPWAPの目的で必要とされるセキュリティ機能を実装するかどうかを検討しました。この文書のセキュリティについての考慮事項のセクションを参照してください。
LWAPP
APP
It appears that the security mechanisms, including the key management portions in LWAPP, are correct. One third-party security review has been performed. However, further security review is warranted since a CAPWAP-specific key exchange mechanism is defined. LWAPP is compliant with the objective.
LWAPPで鍵管理部を含むセキュリティ・メカニズムは、正しいことが表示されます。ワンサードパーティのセキュリティレビューが行われています。 CAPWAP固有の鍵交換メカニズムが定義されているので、さらにセキュリティレビューが保証されています。 LWAPPは、客観的に準拠しています。
SLAPP
RELAX
The SLAPP protocol implements authentication of the WTP by the AC using the DTLS protocol. This behavior is defined in both the discovery process and the 802.11 control process. SLAPP allows mutual and asymmetric authentication. SLAPP also gives informative examples of how to properly use the authentication. SLAPP should add another informative example for authentication of the AC by the WTP. SLAPP is compliant with the objective.
SLAPPプロトコルは、DTLSプロトコルを使用してACによってWTPの認証を実現します。この動作は、発見プロセスと802.11制御プロセスの両方で定義されています。 SLAPPは、相互非対称認証を行うことができます。 SLAPPも適切に認証を使用する方法の参考例を示します。 SLAPPはWTPによるACの認証のための別の有益な例を追加する必要があります。 SLAPPは、客観的に準拠しています。
CTP
CTP
The original presentation at IETF63 of the preliminary findings of the evaluation team reported that CTP failed this objective. This was on the basis of asymmetric authentication not being supported by CTP. This was due to a misunderstanding of what was meant by asymmetric authentication by the evaluation team. The definitions of the terminology used in [OBJ] were clarified on the CAPWAP mailing list. CTP in fact does implement a form of asymmetric authentication through the use of public keys.
評価チームの予備調査結果のIETF63で元のプレゼンテーションは、CTPは、この目的を失敗したことを報告しました。これは、CTPでサポートされていない非対称認証に基づいていました。これは、評価チームによる非対称認証によって意味されたものの誤解によるものでした。 [OBJ]で使用される用語の定義は、CAPWAPメーリングリストで明らかにしました。実際にCTPは、公開鍵を使用して非対称認証のフォームを実装しています。
However, CTP still fails to comply with the objective for two reasons:
しかし、CTPはまだ二つの理由目標を遵守していません：
First, CTP does not mutually derive session keys. Second, CTP does not perform explicit mutual authentication because the 2 parties authenticating do not confirm the keys.
まず、CTPは、相互にセッションキーを導出しません。認証2人の当事者が鍵を確認していないため、第二に、CTPは、明示的な相互認証を実行しません。
WiCoP
WiCoP
There is not enough specific information to implement WiCoP protocol security features. Although in concept EAP and IPsec make sense, there is no explicit description on how these methods would be used.
WiCoPプロトコルのセキュリティ機能を実装するための十分な具体的な情報はありません。コンセプトEAPとIPsecで意味をなすが、これらの方法が使用される方法についての明示的な記述がありません。
LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
LWAPP：C、SLAPP：C、CTP：F、WiCoP：F
LWAPP
APP
LWAPP wraps all control and management communication in its authenticated and encrypted control channel. LWAPP does not seem particularly vulnerable to Denial of Service (DoS). LWAPP should make a recommendation that the Join method be throttled to reduce the impact of DoS attacks against it. Use of an established security mechanism such as IPsec would be preferred. However, LWAPP's independent security review lent enough confidence to declare LWAPP compliant with the objective.
LWAPPは、その認証され、暗号化された制御チャネル内のすべての制御と管理通信をラップします。 LWAPPはサービス拒否（DoS）のに対して特に脆弱いないようです。 LWAPPは、参加方法は、それに対するDoS攻撃の影響を低減するためにスロットルさ勧告を行う必要があります。 IPsecなどの確立されたセキュリティメカニズムの使用が好ましいであろう。しかし、LWAPPの独立したセキュリティレビューは、目的とLWAPPの対応を宣言するために十分な自信を貸してくれました。
SLAPP
RELAX
SLAPP is compliant due to wrapping all control and management communication in DTLS. SLAPP also recommends measures to protect against discovery request DoS attacks. DTLS has undergone security review and has at least one known implementation outside of SLAPP. At the time of this writing, DTLS is pending proposed standard status in the IETF.
SLAPPが原因DTLS内のすべての制御と管理通信をラップに準拠しています。 SLAPPも発見要求DoS攻撃から保護するための対策を推奨しています。 DTLSは、セキュリティレビューを受けており、SLAPPの外側に少なくとも1つの既知の実装を持っていました。この記事の執筆時点では、DTLSは、IETFで標準化提案保留状態です。
CTP
CTP
CTP introduces a new, unestablished mechanism for AC-to-WTP authentication. For complete compliance, use of an established security mechanism with detailed specifications for its use in CTP is preferred. Alternatively, a detailed security review could be performed. CTP does not point out or recommend or specify any DoS attack mitigation requirements against Reg-Req and Auth-Req floods, such as a rate limiter. Because CTP received an 'F' on its protocol security objective, it follows that system-wide security must also be rated 'F'.
CTPは、ACツーWTP認証のための新しい、未確立のメカニズムを紹介します。完全に準拠するため、CTPでの使用のための詳細な仕様を持つ確立されたセキュリティ・メカニズムを使用することが好ましいです。また、詳細なセキュリティレビューを行うことができました。 CTPは、このようなレートリミッタとしてのReg-REQと認証-REQ洪水に対する任意のDoS攻撃の緩和の要件を指摘したり推奨したり指定されていません。 CTPは、そのプロトコルのセキュリティ対策方針に「F」を受けているので、システム全体のセキュリティにも「F」の定格されなければならないことになります。
WiCoP
WiCoP
WiCop does not address DoS attack threats. Also, as with the protocol security objective, the protocol needs to explicitly describe its tunnel and authentication methods.
WiCopは、DoS攻撃の脅威に対応していません。また、プロトコルのセキュリティ目的と同様に、プロトコルは、明示的トンネルおよび認証方法を記載する必要があります。
LWAPP:C, SLAPP:C, CTP:F, WiCoP:P
LWAPP：C、SLAPP：C、CTP：F、WiCoP：P
LWAPP
APP
LWAPP explicitly defines mechanisms for handling 802.11i in its modes with encryption terminated at the WTP. In order to accomplish this, the AC sends the Pairwise Transient Key (PTK) using the encrypted control channel to the WTP using the Add Mobile message. When encryption is terminated at the AC, there are no special requirements. LWAPP is compliant.
LWAPPは、明示的にWTPで終了暗号とそのモードで802.11iのを処理するためのメカニズムを定義します。これを実現するためには、ACは、モバイルメッセージを追加使用してWTPに暗号化された制御チャネルを使用した対一時キー（PTK）を送信します。暗号化はACで終了すると、特別な要件はありません。 LWAPPは準拠しています。
SLAPP
RELAX
SLAPP defines a control message to send the PTK and Group Temporal Key (GTK) to the WTP when the WTP is the encryption endpoint. This control message is carried on the DTLS protected control channel. SLAPP is compliant.
SLAPPはWTPは、暗号化エンドポイントであるとき、WTPにPTKとグループ一時的なキー（GTK）を送信するための制御メッセージを定義します。この制御メッセージは、制御チャネル保護DTLS上に担持されます。 SLAPPは準拠しています。
CTP
CTP
CTP lacks a specification for a control message to send 802.11i PTK and GTK keys to a WTP when the WTP is an encryption endpoint. Based on this, CTP fails compliance for this objective. This requirement could be addressed either by defining new control channel information elements or by simply defining SNMP OIDs. The transport of these OIDs would be contained in the secure control channel and therefore protected.
CTPは、WTPは、暗号化エンドポイントであるとき、WTPに802.11iのPTKとGTKキーを送信するための制御メッセージの仕様を欠いています。これに基づき、CTPは、この目的のためにコンプライアンスを失敗しました。この要件は、新たな制御チャネル情報要素を定義することによって、または単にSNMP OIDを定義することによって、どちらか対処することができます。これらのOIDの輸送は、セキュア制御チャネルに含まれるため、保護されます。
WiCoP
WiCoP
WiCoP lacks documentation on how to handle 4-way handshake. The case for encryption at the AC needs clarification.
WiCoPは、4ウェイハンドシェイクを処理する方法に関するドキュメントを欠いています。 ACでの暗号化の場合は、明確にする必要があります。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP：C、SLAPP：C、CTP：C、WiCoP：C
LWAPP
APP
LWAPP supports both split- and local-MAC architectures and is therefore compliant to the letter of the objectives. LWAPP is particularly rich in its support of the split-MAC architecture. However, LWAPP's support of local-MAC is somewhat limited and could be expanded. LWAPP is lacking a mode that allows local-MAC data frames to be tunneled back to the AC. A discussion of possible extensions and issues is discussed in the recommendations section of this evaluation.
LWAPPは、スプリットとローカルMAC両方のアーキテクチャをサポートしていますので、目的の文字に準拠しています。 LWAPPは、スプリットMACアーキテクチャの支援で特に豊富です。しかし、地元の-MACのLWAPPのサポートはやや限られており、拡張することができます。 LWAPPは、ローカルMACデータフレームが戻ってACにトンネリングすることを可能にするモードを欠いています。可能な拡張機能や問題の議論は、この評価の勧告のセクションで説明されています。
SLAPP
RELAX
SLAPP is compliant.
SLAPPは準拠しています。
CTP
CTP
CTP is compliant.
CTPは準拠しています。
WiCoP
WiCoP
WiCoP is compliant.
WiCoPは準拠しています。
LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
LWAPP：C、SLAPP：P、CTP：P、WiCoP：P
LWAPP
APP
LWAPP is nearly fully documented. Only a few sections are noted as incomplete. Detailed descriptions are often given to explain the purpose of the protocol primitives defined that should encourage interoperable implementations.
LWAPPは、ほぼ完全に文書化されています。唯一のいくつかのセクションでは不完全として注目されています。詳細な説明は、多くの場合、相互運用可能な実装を奨励すべきで定義されたプロトコルプリミティブの目的を説明するために与えられています。
SLAPP
RELAX
SLAPP is largely implementable from its specification. It contains enough information to perform an interoperable implementation for its basic elements; however, additional informative references or examples should be provided covering use of information elements, configuring multiple logical groups, and so on.
SLAPPは、その仕様から大幅に実装可能です。それは、その基本的な要素のための相互運用可能な実装を実行するための十分な情報が含まれています。しかし、追加の有益な参照または実施例は、ように、複数の論理グループを構成し、情報要素の使用をカバー提供し、しなければなりません。
CTP
CTP
As noted earlier, there are a few areas where CTP lacks a complete specification, primarily due to the lack of specific MIB definitions.
先に述べたように、CTPは、主に、特定のMIB定義の欠如に、完全な仕様を欠いいくつかの領域があります。
WiCoP
WiCoP
Due to the lack of specific tunnel specifications and authentication specifications, WiCoP is only partially compliant.
原因特定のトンネルの仕様と認証仕様の不足のために、WiCoPは部分的にしか対応しています。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP：C、SLAPP：C、CTP：C、WiCoP：C
LWAPP
APP
LWAPP is compliant.
LWAPPは準拠しています。
SLAPP
RELAX
SLAPP is compliant.
SLAPPは準拠しています。
CTP
CTP
CTP is compliant.
CTPは準拠しています。
WiCoP
WiCoP
WiCoP is compliant.
WiCoPは準拠しています。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP：C、SLAPP：C、CTP：C、WiCoP：C
LWAPP
APP
LWAPP is compliant.
LWAPPは準拠しています。
SLAPP
RELAX
SLAPP is compliant.
SLAPPは準拠しています。
CTP
CTP
CTP is compliant.
CTPは準拠しています。
WiCoP
WiCoP
WiCoP is compliant.
WiCoPは準拠しています。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP：C、SLAPP：C、CTP：C、WiCoP：C
LWAPP
APP
LWAPP may require special considerations due to it carrying the IP address of the AC and data termination points in the payload of encrypted control messages. To overcome Network Address Translation (NAT), static NAT mappings may need to be created at the NAT'ing device if the AC or data termination points addresses are translated from the point of view of the WTP. A WTP should be able to function in the hidden address space of a NAT'd network.
LWAPPは、暗号化された制御メッセージのペイロードにACおよびデータ終端ポイントのIPアドレスを持つことによる特別な配慮が必要な場合があります。ネットワークアドレス変換（NAT）を克服するために、スタティックNATマッピングは、ACまたはデータ終了がアドレスはWTPの観点から翻訳される指す場合NAT'ingデバイスで作成する必要があります。 WTPはNAT'dネットワークの隠されたアドレス空間で機能することができるはずです。
SLAPP
RELAX
SLAPP places no out-of-the-ordinary constraints regarding NAT. A WTP could function in the hidden address space of a NAT'd network without any special configuration.
SLAPP場所NATに関するノーアウトオブ普通の制約。 WTPは、特別な設定なしにNAT'dネットワークの隠されたアドレス空間で機能することができます。
CTP
CTP
CTP places no out-of-the-ordinary constraints regarding NAT. A WTP could function in the hidden address space of a NAT'd network without any special configuration.
CTPは、NATに関していかなるアウトオブ普通の制約を課すません。 WTPは、特別な設定なしにNAT'dネットワークの隠されたアドレス空間で機能することができます。
WiCoP
WiCoP
WiCoP places no out-of-the-ordinary constraints regarding NAT. A WTP could function in the hidden address space of a NAT'd network without any special configuration.
WiCoPは、NATに関していかなるアウトオブ普通の制約を課すません。 WTPは、特別な設定なしにNAT'dネットワークの隠されたアドレス空間で機能することができます。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP：C、SLAPP：C、CTP：C、WiCoP：C
LWAPP
APP
LWAPP allows for multiple STA authentication mechanisms.
LWAPPは、複数のSTAの認証メカニズムが可能になります。
SLAPP
RELAX
SLAPP does not constrain other authentication techniques from being deployed.
SLAPPが展開されてから、他の認証技術を制約しません。
CTP
CTP
CTP supports multiple STA authentication mechanisms.
CTPは、複数のSTAの認証メカニズムをサポートしています。
WiCoP
WiCoP
WiCoP allows for multiple STA authentication mechanisms.
WiCoPは、複数のSTAの認証メカニズムが可能になります。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP：C、SLAPP：C、CTP：C、WiCoP：C
LWAPP
APP
LWAPP could be used for other wireless technologies. However, LWAPP defines very few primitives that are independent of the 802.11 layer.
LWAPPは、他の無線技術を使用することができます。しかし、LWAPPは802.11層から独立している非常に少数のプリミティブを定義します。
SLAPP
RELAX
SLAPP could be used for other wireless technologies. However, SLAPP defines very few primitives that are independent of the 802.11 layer.
SLAPPは、他の無線技術を使用することができます。しかし、SLAPPは802.11層から独立している非常に少数のプリミティブを定義します。
CTP
CTP
CTP supplies STA control abstraction, methods for extending the forwarding of multiple types of native wireless management frames, and many options for user data tunneling. Configuration management is an extension of SNMP, to which new MIBs could, in concept, be easily plugged in. This helps makes CTP a particularly flexible proposal for supporting future wireless technologies. In addition, CTP has already defined multiple wireless protocol types in addition to 802.11.
CTPは、STA制御抽象化、ネイティブ無線管理フレームの複数の種類の転送を拡張するための方法、およびユーザ・データ・トンネリングのための多くのオプションを供給する。構成管理は、新しいMIBが、コンセプトに、簡単にプラグインすることができたし、SNMPの拡張である。これは、CTPに将来の無線技術をサポートするために特に柔軟な提案を行い役立ちます。また、CTPは既に802.11に加えて、複数の無線プロトコルタイプを定義しています。
WiCoP
WiCoP
WiCoP could be used for other wireless technologies.
WiCoPは、他の無線技術を使用することができます。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP：C、SLAPP：C、CTP：C、WiCoP：C
LWAPP
APP
LWAPP's extensive use of native 802.11 frame forwarding allows it to be transparent to many 802.11 changes. It, however, shifts the burden of adapting MAC layer changes to the packet processing capabilities of the AC.
ネイティブ802.11フレーム転送のLWAPPの広範な使用は、多くの802.11変化に透明にすることができます。それは、しかし、ACのパケット処理能力にMACレイヤの変更を適応させる負担をシフトします。
SLAPP
RELAX
SLAPP's use of native 802.11 frames for control and management allows SLAPP a measure of transparency to changes in 802.11. Because SLAPP also supports a mode that tunnels user data as 802.3 frames, it has additional architectural options for adapting to changes on the wireless infrastructure.
制御および管理のためのネイティブ802.11フレームのSLAPPの使用は、802.11の変化にSLAPPに透明度の測定を可能にします。 SLAPPも802.3フレームとしてユーザデータをトンネルモードをサポートしているので、ワイヤレスインフラストラクチャの変化に適応するための追加的な建築のオプションがあります。
CTP
CTP
CTP has perhaps the greatest ability to adapt to changes in IEEE requirements. Architecturally speaking, CTP has several options available for adapting to change. SNMP OIDs are easily extended for additional control and management functions. Native wireless frames can be forwarded directly to the AC if necessary. Wireless frames can be bridged to 802.3 frames and tunneled back to the AC to protect the AC from changes at the wireless MAC layer. These options allow many possible ways to adapt to change of the wireless MAC layer.
CTPは、IEEE要件の変化に適応するために、おそらく最大の能力を持っています。アーキテクチャ的に言えば、CTPは変更に適応のために利用可能ないくつかのオプションがあります。 SNMP OIDは簡単に追加の制御および管理機能のために拡張されています。必要に応じてネイティブ無線フレームがACに直接転送することができます。無線フレームは802.3フレームにブリッジと無線MAC層での変化からACを保護するために戻ってACにトンネリングすることができます。これらのオプションは、多くの可能な方法は、無線MAC層の変化に適応することができます。
WiCoP
WiCoP
Because WiCoP uses 802.11 frames for the data transport, it is transparent to most IEEE changes. Any new IEEE requirements may need new configuration and new capability messages between the WTP and AC. The AC would need to be modified to handle new 802.11 control and management frames.
WiCoPは、データ転送のための802.11フレームを使用しているので、それはほとんどのIEEEの変化に対して透過的です。すべての新しいIEEE要件は、WTPとAC間の新しい構成や新しい機能のメッセージが必要な場合があります。 ACは新しい802.11制御および管理フレームを処理するように変更する必要があります。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP：C、SLAPP：C、CTP：C、WiCoP：C
LWAPP
APP
LWAPP explicitly defines measures for accommodating IPv6. LWAPP is more sensitive to this in part because it carries IP addresses in two control messages.
LWAPPは、明示的にIPv6を収容するための措置を定義します。それは二つの制御メッセージ内のIPアドレスを運ぶためLWAPPは、部分的にこれに敏感です。
SLAPP
RELAX
SLAPP is transparent to the interconnection layer. DTLS and GRE will both operate over IPv6.
SLAPPは、配線層に対して透過的です。 DTLSとGREは、両方のは、IPv6上で動作します。
CTP
CTP
CTP is transparent to the interconnection layer. CTP should be able to operate over IPv6 without any changes.
CTPは、配線層に対して透過的です。 CTPは、何も変更せずにIPv6の上で動作することができるはずです。
WiCoP
WiCoP
WiCoP is transparent to the interconnection layer and should be able to operate over IPv6 without changes.
WiCoPは、配線層に透明であり、変更なしでIPv6の上で動作することができるはずです。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP：C、SLAPP：C、CTP：C、WiCoP：C
LWAPP
APP
LWAPP uses native 802.11 management frames forwarded to the AC for the purpose of performing STA access control. WTPs are authenticated in LWAPP's control protocol Join phase.
LWAPPは、STAへのアクセス制御を行うためにACに転送ネイティブ802.11管理フレームを使用します。 WTPsはLWAPPの制御プロトコルで認証されている段階に参加。
SLAPP
RELAX
SLAPP has support for multiple authentication methods for WTPs. In addition, SLAPP can control STA access via 802.11 management frames forwarded to the AC or via SLAPP's information element primitives.
SLAPPはWTPsのための複数の認証方式をサポートしています。また、SLAPPは、ACまたはSLAPPの情報要素プリミティブを介して転送された802.11管理フレームを介して、STAへのアクセスを制御することができます。
CTP
CTP
CTP specifies STA access control primitives.
CTPは、STAのアクセス制御プリミティブを指定します。
WiCoP
WiCoP
WiCoP specifies access control in [WICOP] section 5.2.2.
WiCoPは[WICOP]セクション5.2.2にアクセス制御を指定します。
See Figure 1 (section numbers correspond to RFC 4564 [OBJ]).
図1を参照してください（セクション番号は、RFC 4564に対応する[OBJ]）。
---------------------------------------------------------------
| CAPWAP Evaluation | LWAPP | SLAPP | CTP | WiCoP |
|---------------------------------------------------------------|
| 5.1.1 Logical Groups | C | C | C | C |
| 5.1.2 Traffic Separation | C | C | P | P |
| 5.1.3 STA Transparency | C | C | C | C |
| 5.1.4 Config Consistency | C | C | C | C |
| 5.1.5 Firmware Trigger | P | P | P | C |
| 5.1.6 Monitor System | C | C | P | C |
| 5.1.7 Resource Control | C | P | P | P |
| 5.1.8 Protocol Security | C | C | F | F |
| 5.1.9 System Security | C | C | F | F |
| 5.1.10 802.11i Consideration | C | C | F | P |
|---------------------------------------------------------------|
| 5.1.11 Interoperability | C | C | C | C |
| 5.1.12 Protocol Specifications | C | P | P | P |
| 5.1.13 Vendor Independence | C | C | C | C |
| 5.1.14 Vendor Flexibility | C | C | C | C |
| 5.1.15 NAT Traversal | C | C | C | C |
|---------------------------------------------------------------|
| Desirable |
|---------------------------------------------------------------|
| 5.2.1 Multiple Authentication | C | C | C | C |
| 5.2.2 Future Wireless | C | C | C | C |
| 5.2.3 New IEEE Requirements | C | C | C | C |
| 5.2.4 Interconnection (IPv6) | C | C | C | C |
| 5.2.5 Access Control | C | C | C | C |
---------------------------------------------------------------
Figure 1: Summary Results
図1：要約結果
The proposals presented offer a variety of novel features that together would deliver a full-featured, flexible, and extensible CAPWAP protocol. The most novel of these features leverage existing standards where feasible. It is this evaluation team's opinion that a mix of the capabilities of the proposals will produce the best CAPWAP protocol.
提示提案は一緒に、フル機能で柔軟かつ拡張可能なCAPWAPプロトコルを送達する新規な特徴の様々な提供します。実現可能なこれらの機能を活用し、既存の規格の最も新しいです。これは、提案の機能の組み合わせが最良のCAPWAPプロトコルを生成します。この評価チームの意見です。
The recommended features are described below. Many of these novel capabilities come from CTP and SLAPP and WiCoP. However, LWAPP has the most complete base protocol and is flexible enough to be extended or modified by the working group. We therefore recommend that LWAPP be used as the basis for the CAPWAP protocol.
推奨される機能は以下のとおりです。これらの新規の機能の多くは、CTPとSLAPPとWiCoPから来ます。しかし、LWAPPは、最も完全なベースプロトコルを有しており、ワーキンググループによって拡張または変更するのに十分に柔軟です。したがって、我々は、LWAPPはCAPWAPプロトコルのための基礎として使用することをお勧めします。
The evaluation team recommends that the working group carefully consider the following issues and recommended changes. The evaluation team believes that a more complete CAPWAP protocol will be delivered by addressing these issues and changes.
評価チームは、ワーキンググループは、慎重に次の問題を考慮して変更を推奨することをお勧めします。評価チームは、より完全なCAPWAPプロトコルは、これらの問題や変化に対処することにより、配信されることと考えています。
LWAPP's attribute value pair system meets the objectives as defined by the working group. However, it has only 8 bits assigned for attribute types, with an additional 8 bits for a specific element within an attribute type. The evaluation team strongly recommends that a larger number of bits be assigned for attribute types and information elements.
ワーキンググループによって定義されているようLWAPPの属性値ペアシステムは、目標を満たしています。しかし、属性タイプ内の特定の要素のための追加の8ビットで、属性タイプに割り当てられた唯一の8ビットを有します。評価チームは強くビットの数が多いほど、属性の種類と情報要素のために割り当てることをお勧めします。
LWAPP's security mechanisms appear satisfactory and could serve CAPWAP going forward. However, the evaluation team recommends adoption of a standard security protocol for the control channel.
LWAPPのセキュリティメカニズムは、満足表示され、今後のCAPWAPを果たすことができました。しかし、評価チームは、制御チャネルのための標準的なセキュリティプロトコルの採用を推奨しています。
There are several motivations for a standards-based security protocol, but the primary disadvantage of a new security protocol is that it will take longer and be more difficult to standardize than reusing an existing IETF standard. First, a new security protocol will face a longer, slower approval processes from the Security Area Directorate and the IESG. The new CAPWAP security protocol will need to pass several tests including the following:
そこ標準ベースのセキュリティプロトコルのためのいくつかの動機がありますが、新しいセキュリティプロトコルの主な欠点は、時間がかかると、既存のIETF標準を再利用するよりも、標準化することがより困難になるということです。まず、新しいセキュリティプロトコルは、セキュリティエリア総局とIESGから長く、遅く承認プロセスに直面するだろう。新しいCAPWAPセキュリティプロトコルは、以下を含むいくつかの試験に合格する必要があります。
What is uniquely required by CAPWAP that is not available from an existing standard protocol? How will CAPWAP's security protocol meet security area requirements for extensibility, such as the ability to support future cipher suites and new key exchange methods? How does this ability compare to established security protocols that have these capabilities?
独自に既存の標準プロトコルからは利用できませんCAPWAPによって何が必要ですか？どのような将来の暗号スイートと新しい鍵交換方式をサポートする機能など、拡張性のためのCAPWAPのセキュリティプロトコルを満たすセキュリティ面積要件は、だろうか？どのようにこの能力は、これらの機能を持っている確立されたセキュリティ・プロトコルと比べてどうですか？
Points such as these are continually receiving more attention in the industry and in the IETF. Extensibility of key exchange methods and cipher suites are becoming industry standard best practices. These issues are important topics in the IETF Security Area Advisory Group (SAAG) and the SecMech BOF, held during the 63rd IETF meeting.
このようなポイントは、継続的に業界に及びIETFでより多くの注目を集めています。鍵交換方式と暗号スイートの拡張性は、業界標準のベストプラクティスになっています。これらの問題は、第63回IETF会議中に開催されたIETFセキュリティエリア諮問グループ（SAAG）とSECMECH BOFにおいて重要なトピックです。
These issues could be nullified by adopting an appropriate existing standard security protocol. IPsec or DTLS could be a standards alternative to LWAPP's specification. DTLS presents a UDP variant of Transport Layer Security (TLS). Although DTLS is relatively new, TLS is a heavily used, tried-and-tested security protocol.
これらの問題は、適切な既存の標準のセキュリティプロトコルを採用することにより、無効にすることができます。 IPSecまたはDTLSはLWAPPの仕様の標準化の代替可能性があります。 DTLSは、トランスポート層セキュリティ（TLS）のUDPバリアントを提示します。 DTLSは比較的新しいですが、TLSは使用頻度の高い、実証済みのテストされたセキュリティプロトコルです。
The evaluation team recommends that whatever security protocol is specified for CAPWAP, its use cases must be described in detail. LWAPP does a good job of this with its proposed, proprietary method. If an updated specification is developed, it should contain at least one mandatory authentication and cipher method. For example, pre-shared key and x.509 certificates could be specified as mandatory authentication methods, and Advanced Encryption Standard (AES) Counter Mode with CBC-MAC Protocol (CCMP) could be selected as a mandatory cipher.
評価チームは、CAPWAPのために指定されているものは何でも、セキュリティプロトコル、その使用例を詳細に説明しなければならないことをお勧めします。 LWAPPは、その提案、独自の方法でこれの良い仕事をしていません。更新仕様が開発されれば、それは、少なくとも1つの必須の認証と暗号方式が含まれている必要があります。例えば、事前共有鍵とX.509証明書は必須の認証方式として指定することができ、及びCBC-MACプロトコル（CCMP）とのAdvanced Encryption Standard（AES）カウンタモードは必須暗号として選択することができます。
Given the possibilities for code reuse, industry reliance on TLS, and the future for TLS, DTLS may be a wise alternative to a security method specific to CAPWAP. In addition, use of DTLS would likely expedite the approval of CAPWAP as a proposed standard over the use of CAPWAP-specific security mechanisms.
コードの再利用、TLS上の業界の信頼、およびTLSのための将来の可能性を考えると、DTLSはCAPWAPに固有のセキュリティ方式に賢明な選択肢かもしれません。また、DTLSを使用する可能性が高いCAPWAP固有のセキュリティメカニズムの使用を超える提案標準としてCAPWAPの承認を迅速化します。
The issue of data encapsulation is closely related to the split- and local-MAC architectures. The split-MAC architecture requires some form of data tunneling. All the proposals except LWAPP offer a method of tunneling in local-MAC mode as well. By local-MAC data tunneling, we mean the tunneling of user data as 802.3 Ethernet frames back to the AC from a WTP that is otherwise in local-MAC mode.
データのカプセル化の問題は密接にスプリットとローカルMACアーキテクチャに関連しています。スプリットMACアーキテクチャは、データトンネルのいくつかのフォームを必要とします。 LWAPPを除くすべての提案は、同様にローカル-MACモードでのトンネリングの方法を提供します。 802.3イーサネットローカル-MACモードで、さもなければあるWTPからバックACにフレームとしてローカルMACデータトンネリングによって、我々は、ユーザデータのトンネリングを意味します。
Tunneling data in local-MAC mode offers the ability for implementers to innovate in several ways even while using a local-MAC architecture. For example, functions such as mobility, flexible user data encryption options, and fast handoffs can be enabled through tunneling of user data back to an AC, or as LWAPP defines, a data termination endpoint, which could be different from the AC. In addition, there are special QoS or application-aware treatments of user data packets such as voice or video. Improved transparency and compatibility with future wireless technologies are also possible when encapsulating user data in a common format, such as 802.3, between the access point and the AC or other termination point in the network.
ローカル-MACモードでのトンネリングデータであっても、ローカルMACアーキテクチャを使用している間、いくつかの方法で革新する実装のための機能を提供しています。例えば、このような移動度のような機能、柔軟なユーザデータの暗号化オプション、および高速ハンドオフバックACへのユーザデータのトンネリングを介して有効にすることができ、またはLWAPPは、ACとは異なる可能性がデータ終端エンドポイントを定義しています。また、特別なQoSや、音声やビデオなどのユーザデータパケットのアプリケーション対応の治療法があります。アクセスポイント及びAC又はネットワーク内の他の終端点との間に、例えば802.3のように、共通のフォーマットでユーザデータをカプセル化する際に、将来の無線技術と改良された透明性及び相溶性も可能です。
Another possibility is when a native wireless MAC changes in the future, if a new WTP that supports this MAC change can also support a wireless MAC -> 802.3 integration function, then the wireless MAC layer change may remain transparent to an AC and still maintain many of the benefits that data tunneling can bring.
、> 802.3統合機能その後、無線MAC層の変化がACに透明残ることがあり、まだ多くを維持 - このMACの変更をサポートする新しいWTPも無線MACをサポートできる場合、ネイティブ無線MACは、将来的に変更したときに別の可能性はありますデータトンネリングをもたらすことができる利点の。
LWAPP does support a header for tunneled user data that contains layer 1 wireless information (Received Signal Strength Indication (RSSI) and Signal-to-Noise Ratio (SNR)) that is independent of the wireless layer 2 MAC. Innovations related to the use of RSSI and SNR at the AC may be retained even when tunneling 802.3 user data across different wireless MACs.
LWAPPは、レイヤ1件の無線情報が含まれているトンネリングユーザデータのヘッダをサポートする（受信信号強度表示（RSSI）と信号対雑音比（SNR））無線レイヤ2のMACとは無関係です。 ACにおけるRSSIとSNRの使用に関連するイノベーションは、異なる無線MACを横切っ802.3ユーザデータをトンネリングしても保持されてもよいです。
It is likely that many other features could be created by innovative implementers using this method. However, LWAPP narrowly defines the local-MAC architecture to exclude an option of tunneling data frames back to the AC. Given the broad support for tunneling 802.3 data frames between the WTP and AC across all the proposals and existing proprietary industry implementations, the evaluation team strongly recommends that the working group consider a data tunneling mode for local-MAC be added to the LWAPP proposal and become part of the standard CAPWAP protocol.
他の多くの機能は、このメソッドを使用して、革新的な実装で作成することができたと思われます。しかし、LWAPPは狭くバックACにトンネルデータフレームのオプションを除外するためにローカルMACアーキテクチャを定義します。すべての提案や既存の独自の業界実装間WTPとAC間のトンネル802.3データフレームのための幅広いサポートを考えると、評価チームは強くワーキンググループがローカル-MACのためのデータトンネルモードはLWAPPの提案に追加することを検討することをお勧めしますとなります標準のCAPWAPプロトコルの一部。
If more than one tunneling mode is part of the CAPWAP protocol, the evaluation team recommends that the working group choose one method as mandatory and other methods as optional. In addition, the CAPWAP protocol must implement the ability to negotiate which tunneling methods are supported through a capabilities exchange. This allows ACs and WTPs freedom to implement a variety of modes but always have the option of falling back to a common mode.
複数のトンネリングモードはCAPWAPプロトコルの一部である場合、評価チームは、ワーキンググループは、オプションとして必須と他の方法として、一つの方法を選択することをお勧めします。また、CAPWAPプロトコルが機能交換を介して支持されているトンネリング方法交渉する能力を実装する必要があります。これは、ACSとWTPsの自由は様々なモードを実装しますが、常に共通モードにフォールバックのオプションを持つことができます。
The choice of which mode(s) should be mandatory is an important decision and may impact many decisions implementers have to make with their hardware and software choices for both WTPs and ACs. The evaluation team believes that the working group should address this issue of local-MAC data tunneling and carefully choose which mode(s) should be mandatory.
どのモード（s）は必須でなければなりませんの選択は重要な決定であると実装がWTPsとACSの両方のための彼らのハードウェアとソフトウェアの選択肢を作るために持っている多くの決定に影響を与える可能性があります。評価チームは、ワーキンググループがローカル-MACデータトンネリングのこの問題に対処し、慎重に義務的であるべきモード（複数可）を選択しなければならないと考えています。
Abstraction of STA access control, such as that implemented in CTP and WiCoP, stands out as a valuable feature as it is fundamental to the operational capabilities of many types of wireless networks, not just 802.11. LWAPP implements station access control as an 802.11- specific function via forwarding of 802.11 control frames to the access controller. LWAPP has abstracted the STA Delete function out of the 802.11 binding. However, the Add STA function is part of the 802.11 binding. It would be useful to implement the wireless MAC independent functions for adding a STA outside of the 802.11 binding.
それは無線ネットワークの多くの種類の運用能力の基本であるようなCTPとWiCoPに実装されるようなSTAのアクセス制御の抽象化は、だけでなく、802.11、貴重な機能として際立っています。 LWAPPは、アクセスコントローラへ802.11制御フレームの転送を介し802.11特定関数としてステーションのアクセス制御を実現します。 LWAPPは、STAは802.11結合のうち、機能を削除し抽象化しています。しかし、STA機能を追加することは802.11結合の一部です。 802.11の結合の外STAを追加するための無線MAC独立した機能を実現するのに有用であろう。
LWAPP currently specifies layer 2 and layer 3 methods for data tunneling. The evaluation team believes that the layer 2 method is redundant to the layer 3 method. The team recommends that the layer 2 method encapsulation be removed from the LWAPP protocol.
LWAPPは、現在、データトンネリングのためのレイヤ2およびレイヤ3つの方法を指定します。評価チームは、レイヤ2の方法は、レイヤ3の方法に冗長であると考えています。チームは、レイヤ2メソッドカプセル化がLWAPPプロトコルから除去することをお勧めします。
LWAPP's layer 3 data encapsulation meets the working group objectives. However, the evaluation team recommends the use of a standards-based protocol for encapsulation of user data between the WTP and AC. GRE or Layer 2 Tunneling Protocol (L2TP) could make good candidates as standards-based encapsulation protocols for data tunneling.
LWAPPのレイヤ3データのカプセル化は、ワーキンググループの目的を満たしています。しかし、評価チームは、WTPとAC間のユーザデータのカプセル化のための標準ベースのプロトコルを使用することを推奨しています。 GREまたはレイヤ2トンネリングプロトコル（L2TP）は、データトンネリングのための標準ベースのカプセル化プロトコルとして有力な候補を作ることができます。
Using a standard gives the opportunity for code reuse, whether it is off-the-shelf microcode for processors, code modules that can be purchased for real-time operating systems, or open-source implementations for Unix-based systems. In addition, L2TP and GRE are designed to encapsulate multiple data types, increasing flexibility for supporting future wireless technologies.
標準を使用することは、リアルタイムオペレーティングシステム、またはUnixベースのシステムのためのオープンソースの実装のために購入することができるプロセッサ、コードモジュールのための既製のマイクロコードであるかどうか、コードの再利用のための機会を与えます。また、L2TPやGREは、将来の無線技術をサポートするための柔軟性を高め、複数のデータ・タイプをカプセル化するために設計されています。
[802.11i] IEEE Standard 802.11i, "Medium Access Control (MAC) Security Enhancements", July 2004.
[802.11i規格] IEEE規格802.11i規格、 "メディアアクセス制御（MAC）セキュリティ強化"、2004年7月。
[ARCH] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[ARCH]ヤン、L.、Zerfos、P.、およびE. Sadot、RFC 4118、2005年6月 "ワイヤレスアクセスポイント（CAPWAP）の管理とプロビジョニングのためのアーキテクチャの分類学"。
[OBJ] Govindan, S., Ed., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4564, July 2006.
[OBJ]ゴヴィンダン、S.編、チェン、H.、ヤオ、ZH。、周、WH。、およびL.ヤン、 "コントロールおよびワイヤレスアクセスポイントのプロビジョニング（CAPWAP）のための目的"、RFC 4564、2011 2006。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、1997年3月。
[CTP] Singh , I., Francisco, P., Pakulski , K., and F. Backes, "CAPWAP Tunneling Protocol (CTP)", Work in Progress, April 2005.
[CTP]シン、I.、サンフランシスコ、P.、Pakulski、K.、およびF. Backes、 "CAPWAPトンネリングプロトコル（CTP）"、進歩、2005年4月の作業。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[LWAPP] Calhoun, P., O'Hara, B., Kelly, S., Suri, R., Williams, M., Hares, S., and N. Cam Winget, "Light Weight Access Point Protocol (LWAPP)", Work in Progress, March 2005.
【LWAPP]カルフーン、P.、オハラ、B.、ケリー、S.、スリ、R.、ウィリアムズ、M.、野兎、S.、およびN.カムウィンゲット、「軽量アクセスポイントプロトコル（LWAPP） 」、進歩、2005年3月に作業。
[RFC3127] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil, B., Stevens, M., and B. Wolff, "Authentication, Authorization, and Accounting: Protocol Evaluation", RFC 3127, June 2001.
[RFC3127]ミットン、D.、St.Johns、M.、バークリー、S.、ネルソン、D.、パティル、B.、スティーブンス、M.、およびB.ヴォルフ、「認証、認可、およびアカウンティング：プロトコル評価」、RFC 3127、2001年6月。
[SLAPP] Narasimhan, P., Harkins, D., and S. Ponnuswamy, "SLAPP : Secure Light Access Point Protocol", Work in Progress, May 2005.
[SLAPP] Narasimhan、P.、ハーキンズ、D.、およびS. Ponnuswamy、 "SLAPP：ライトアクセスポイントプロトコルセキュア"、進歩、2005年5月に作業を。
[WICOP] Iino, S., Govindan, S., Sugiura, M., and H. Cheng, "Wireless LAN Control Protocol (WiCoP)", Work in Progress, March 2005.
【WICOP】飯野、S.、ゴヴィンダン、S.、杉浦、M.、およびH.チェン、 "無線LAN制御プロトコル（WiCoP）"、進歩、2005年3月に働いています。
Authors' Addresses
著者のアドレス
Darren P. Loher Envysion, Inc. 2010 S. 8th Street Boulder, CO 80302 USA
ダレン・P. Loher Envysion、Inc.の2010 S. 8thストリートボルダーUSA
Phone: +1.303.667.8761 EMail: dplore@gmail.com
電話：+1.303.667.8761電子メール：dplore@gmail.com
David B. Nelson Enterasys Networks, Inc. 50 Minuteman Road Anover, MA 01810-1008 USA
デビッド・B・ネルソンエンテラシスネットワークス株式会社50ミニット・ロードAnover、MA 01810から1008 USA
Phone: +1.978.684.1330 EMail: dnelson@enterasys.com
電話：+1.978.684.1330電子メール：dnelson@enterasys.com
Oleg Volinsky Colubris Networks, Inc. 200 West Street Waltham, MA 02451 USA
オレグVolinskyコルブリス・ネットワークス株式会社200西ストリートウォルサム、MA 02451 USA
Phone: +1.781.547.0329 EMail: ovolinsky@colubris.com
電話：+1.781.547.0329電子メール：ovolinsky@colubris.com
Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
ベーチェットSarikaya Huawei社USA 1700アルマ博士スイート100プラノ、TX 75075 USA
Phone: +1.972.509.5599 EMail: sarikaya@ieee.org
電話：+1.972.509.5599電子メール：sarikaya@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
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.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。