[要約] 要約：RFC 4565は、候補の制御およびワイヤレスアクセスポイント（CAPWAP）プロトコルの評価に関するものであり、CAPWAPプロトコルの機能と性能を評価するためのガイドラインを提供しています。目的：RFC 4565の目的は、CAPWAPプロトコルの実装者やネットワーク管理者に、プロトコルの適切な選択と設定に関する情報を提供し、ワイヤレスネットワークの制御と管理を向上させることです。
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
ワイヤレスアクセスポイント（CAPWAP）プロトコルの候補制御とプロビジョニングの評価
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).
Copyright（c）The Internet Society（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.
このドキュメントは、ワイヤレスアクセスポイントワーキンググループ（CAPWAP WG）評価チームの制御とプロビジョニングのプロセスと調査結果の記録です。評価チームは、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.
このドキュメントは、ワイヤレスアクセスポイントワーキンググループ（CAPWAP WG）評価チームの制御とプロビジョニングのプロセスと調査結果の記録です。評価チームは、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人のチームメンバーを割り当てて評価ブリーフを書きました。1人のメンバーが「プロ」ブリーフを書くように割り当てられ、提案の寛大な解釈を取ることができました。この評価者は、疑いの恩恵を受けることができます。2番目の評価者が「con」ブリーフを書くために割り当てられ、評価を実行する際に厳格な基準を使用する必要がありました。
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.
「Pro」と「Con」メンバーは、候補プロトコルが各目標をどの程度満たしているかを独立して評価しました。各目標は、障害の「f」、部分的な「p」、または目的を完全に満たすための「c」として採点されました。
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人の評価チームは、各候補者がブリーフについて議論するために通信を開催しました。ワーキンググループの椅子の1つは、会議にもアドバイザリー能力で存在していました。各評価者は、サポートの詳細を記録したブリーフを提示しました。チームは問題について議論し、各目標のチーム評価を提供しました。これらの議論は、会議の議事録に文書化されています。チームの評価は、コンプライアンス評価に使用されます。
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
ダレン・ローハー、ロービング・プラネット
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.
私は、ワイヤレスネットワーク向けのネットワークおよびセキュリティ管理ソフトウェアを書くRoving Planetのシニアアーキテクトとして雇用されています。私は11年以上にわたる商業的な経験を持っています。私は、大学、大企業、および4年以上にわたって主要なインターネットサービスプロバイダー向けにネットワークとネットワーク管理システムを実装および運営してきました。また、ソフトウェア開発の経験があり、非常に大規模な分散DNSシステムを管理するためのシステムなど、Webベースのネットワークおよびシステム管理ツールを作成しました。私は数年間IETF標準プロセスを目撃しました。私の最初のイベントはIETF 28です。このポイントの前にワーキンググループの活動に直接参加することはめったにありません。私の知る限り、私の会社は、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エリアのAAAドクターであるRadext WGの共同椅子であり、私の会社のコアルーターエンジニアリンググループに雇用されています。私は以前、AAA WGのプロトコル評価チームに参加しており、RFC 3127 [RFC3127]の共著者です。私はIEEE 802.11iタスクグループの積極的な貢献者であり、以前は私の会社のWLANエンジニアリンググループで雇用されていました。提出されたプロトコルのいずれにも参加していません。私の会社は、従業員が提出物の1つを共著している少なくとも1つの会社とOEM関係を持っていますが、現時点ではWLAN製品に直接関与していません。
Oleg Volinsky, Colubris Networks
Oleg Volinsky、Colubris Networks
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ベンダーであるColubris Networksのエンタープライズグループのメンバーです。コアルーターからホームネットワーキング機器まで、ネットワーク製品の設計と開発の経験が10年以上あります。長年にわたり、私はさまざまなIETFグループに参加してきました。私は1年以上CapWap WGのメンバーでした。私の現在の立場では、CAPWAP基準の開発と、結果のプロトコルの潜在的な統合を会社の製品に監視してきました。候補者プロトコルドラフトのいずれにも参加していません。私は、スタッフが候補者のプロトコルを作成した企業のいずれにも働いていません。
Behcet Sarikaya, University of Northern British Columbia
ブリティッシュコロンビア州北部大学、ベーセットサリカヤ
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を評価する評価ドラフト（Andy Leeと）を提出しました。また、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.
「Light Weight Access Point Protocol」[LWApp]は、Seamoby Working Groupに最初に提出された最初のCapWapプロトコルでした。LWAPPは、認証およびユーザーデータのカプセル化、および管理および構成情報要素のためのオリジナルソリューションを提案しています。LWAPPは「スプリットMAC」プロトコルとして発信されましたが、最近の変更により、ローカルMACのサポートも追加されています。LWAPPは、メリーランド大学情報システムセキュリティラボのCharles Clancyからセキュリティレビューを受けています。
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）に戻るTunneledを使用するRAW 802.11フレームの使用です。ローカルおよびスプリットMACモードの両方で、RAW 802.11フレームは、管理と制御のためにACに転送されます。さらに、スプリットMACモードでは、ユーザーデータがACにRAW 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.
「Secure Light Access Point Protocol」[Slapp]は、ACとワイヤレス終端ポイント（WTP）と提案されている標準データグラム輸送の間のユーザーデータトンネルの一般的なルーティングカプセル化（GRE）などのよく知られた確立されたテクノロジーの使用と区別されます。制御チャネル輸送のセキュリティ[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 Controlパケットにカプセル化されたネイティブ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 Local-MACモードでは、ユーザーデータフレームが802.3フレームとしてACにGREを使用してブリッジまたはトンネルを戻すことができます。スプリットMACモードでは、ユーザーデータは常にネイティブ802.11フレームとしてACに戻ってきます。ユーザーデータの暗号化は、Split-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 Tunneling Protocol」[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モードの拡張として定義されます。CTPのスプリットMAC操作のバージョンでは、ワイヤレス管理フレームが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プロトコルの中で最も柔軟なものの1つになります。ただし、既存の標準を活用する代わりに、新しいセキュリティとデータのトンネルメカニズムを定義します。
"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は802.11サービス品質（QOS）パラメーターを定義します。さらに、プロトコルは、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.
各候補プロトコルには、セキュリティに関する考慮事項セクションとセキュリティプロパティがあります。CapWap目標文書[OBJ]には、セキュリティ関連の要件が含まれています。評価チームは、候補者プロトコルがCAPWAP目標に必要なセキュリティ機能を実装するかどうか、どのように実装するかを検討しました。ただし、この評価チームはセキュリティチームではなく、徹底的なセキュリティ評価やテストを実行していません。CAPWAPワーキンググループから出てくるプロトコルは、目標を完全に満たすためにIETFセキュリティレビューを受ける必要があります。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
lwapp
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は、「add wlan」と呼ばれるコントロールメッセージを提供します。このメッセージは、ACによって使用されて、一意のID、つまりそのサービスセット識別子（SSID）を備えたWLANを作成します。このWLANのWTPには、独自の基本的なサービスセット識別子（BSSID）があります。LWAPPはこの目的を満たしています。
SLAPP
スラップ
SLAPP explicitly supports 0-255 BSSIDs.
SLAPPは、0-255 BSSIDSを明示的にサポートしています。
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
If a protocol distinguishes a data message from a control message, then it meets this objective.
プロトコルがデータメッセージをコントロールメッセージと区別する場合、この目的を満たします。
LWAPP
lwapp
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
スラップ
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プロトコルは、DTLを使用してコントロールをカプセル化し、オプションでは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
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
lwapp
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
スラップ
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
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
lwapp
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
スラップ
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.
CTPによるSNMPの使用により、構成の一貫性が簡単になります。MIBで指定されている場合、デフォルト値を利用できます。
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
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を1回だけ再起動し、新しいファームウェアイメージの実行を開始できます。これにより、ファームウェアの画像が大きい場合、ファイルの読み込みのリンクが非常に遅い場合、またはWTPの再起動時間が長くなると、ダウンタイムが意味のある減少をもたらす可能性があります。
A protocol would only fail compliance if no method was specified for updating of firmware.
プロトコルは、ファームウェアの更新にメソッドが指定されていない場合にのみ、コンプライアンスに失敗します。
LWAPP
lwapp
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によって開始されます（wtpが最初にACに関連付けられている場合）、他の時間ではありません。ファームウェアチェックと更新は、WTPにリセットメッセージを送信することにより、ACによって間接的に「トリガー」される可能性があります。結果の再起動により、ファームウェアチェックと更新が実行されます。LWAPPは、そのファームウェアトリガーがステートマシンのスタートアップフェーズでのみ使用できるため、部分的に準拠しています。
SLAPP
スラップ
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-Update-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
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
lwapp
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
スラップ
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統計輸送は、制御チャネルを介して提供され、情報要素と呼ばれるスラップ定義の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 stats-notify」というコントロールメッセージを定義します。このコントロールメッセージには、SNMP OIDの形式の統計が含まれており、WTPからACに送信されます。このアプローチは、標準の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 MIBSの使用を推奨しています。ただし、提案は、追加の構成情報と統計情報が必要であることを認めていますが、これらのMIB拡張機能を指定していません。CTPは、これらの拡張機能を提案に追加する必要があります。また、目標を完全に満たすためには、この統計と構成の最小セットが要件になる必要があります。
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
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
lwapp
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を使用すると、添付されている新しいモバイルステーションごとにACからWTPに送信された各モバイルリクエストの追加のモバイルステーションベースのQOS構成を可能にします。パケットの優先順位付けは、個々のWTPに任されています。各ステーションが実施する4つの異なるQoSポリシーを構成できます。更新モバイルQoSメッセージ要素を使用して、特定のモバイルステーションのWTPでQoSポリシーを変更できます。LWAPPは、802.11E 802.1pとIP TOSと一致するため、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
スラップ
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クラスのマッピングの構成を可能にするメカニズムをサポートおよび指定できる標準機能の1つとして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-Valueメッセージを定義します。これは、WTPによってサポートされている各グループに対して送信されます。WICOPは、DSCPタグの構成と802.1pの優先順位値の明示的な方法を提供しません。SNMP OID構成法を使用してこれらのパラメーターを構成することは可能ですが、WICOPは特定のMIBを明示的に識別しません。全体として、WICOPはリソースコントロールCapWapの目標を部分的に満たしています。指定された目的に完全に準拠するためには、プロトコルは802.1pおよびDSCPマッピングを構成する明確な方法を特定する必要があります。
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
lwapp
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の主要な管理部分を含むセキュリティメカニズムは正しいようです。1つのサードパーティのセキュリティレビューが実行されました。ただし、CAPWAP固有のキー交換メカニズムが定義されているため、さらなるセキュリティレビューが必要です。LWAPPは目標に準拠しています。
SLAPP
スラップ
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は2つの理由で目標を順守していません。
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はセッションキーを相互に導き出しません。第二に、CTPは明示的な相互認証を実行しません。なぜなら、2つの当事者が認証することはキーを確認しないためです。
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
lwapp
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
スラップ
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およびauth-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
lwapp
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は、[モバイルメッセージの追加]を使用して、暗号化されたコントロールチャネルを使用してPairwise Transient Key（PTK）をWTPに送信します。ACで暗号化が終了すると、特別な要件はありません。LWAPPは準拠しています。
SLAPP
スラップ
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が暗号化エンドポイントである場合、PTKとグループのトップキー（GTK）をWTPに送信するコントロールメッセージを定義します。このコントロールメッセージは、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が暗号化エンドポイントである場合、802.11i PTKおよびGTKキーをWTPに送信するための制御メッセージの仕様がありません。これに基づいて、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
lwapp
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は、スプリットとローカルの両方のアーキテクチャをサポートするため、目的の文字に準拠しています。LWAPPは、スプリットマックアーキテクチャをサポートすることに特に豊富です。ただし、LWAPPのLocal-MACのサポートはやや制限されており、拡大することができます。LWAPPには、ローカルMACデータフレームをACに戻すことができるモードがありません。可能な拡張と問題の議論については、この評価の推奨事項セクションで説明します。
SLAPP
スラップ
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
lwapp
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
スラップ
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.
前述のように、主に特定のMIBの定義がないため、CTPに完全な仕様が欠けている領域がいくつかあります。
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
lwapp
LWAPP is compliant.
LWAPPは準拠しています。
SLAPP
スラップ
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
lwapp
LWAPP is compliant.
LWAPPは準拠しています。
SLAPP
スラップ
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
lwapp
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）を克服するには、ACまたはデータ終端ポイントアドレスがWTPの観点から翻訳されている場合、NATデバイスで静的NATマッピングを作成する必要があります。WTPは、NAT'Dネットワークの隠されたアドレス空間で機能できるはずです。
SLAPP
スラップ
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
lwapp
LWAPP allows for multiple STA authentication mechanisms.
LWAPPは、複数のSTA認証メカニズムを可能にします。
SLAPP
スラップ
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
lwapp
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
スラップ
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制御抽象化、複数の種類のネイティブワイヤレス管理フレームの転送を拡張する方法、およびユーザーデータトンネリングの多くのオプションを提供します。構成管理はSNMPの拡張であり、新しいMIBSを概念として簡単にプラグインすることができます。これにより、CTPは将来のワイヤレステクノロジーをサポートするための特に柔軟な提案になります。さらに、CTPは802.11に加えて、すでに複数のワイヤレスプロトコルタイプを定義しています。
WiCoP
WICOP
WiCoP could be used for other wireless technologies.
WICOPは、他のワイヤレステクノロジーに使用できます。
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
lwapp
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.
LWAPPによるネイティブ802.11フレーム転送の広範な使用により、多くの802.11の変更に対して透明性を持つことができます。ただし、MACレイヤーの変化をACのパケット処理機能に適応させる負担をシフトします。
SLAPP
スラップ
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.
Slappによる制御および管理のためにネイティブ802.11フレームを使用すると、Slappは802.11の変化に対する透明性の尺度を可能にします。Slappは、ユーザーデータを802.3フレームとしてTunnElsというモードもサポートしているため、ワイヤレスインフラストラクチャの変更に適応するための追加のアーキテクチャオプションがあります。
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フレームにブリッジし、ACに戻し、ワイヤレスMACレイヤーの変更から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
lwapp
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に対応するための尺度を明示的に定義しています。LWAPPは、2つのコントロールメッセージにIPアドレスを搭載しているため、これに敏感です。
SLAPP
スラップ
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
lwapp
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の制御プロトコルJOINフェーズで認証されています。
SLAPP
スラップ
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は、WTPの複数の認証方法をサポートしています。さらに、SLAPPは、ACに転送された802.11管理フレームまたはSlappの情報要素プリミティブを介して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）を使用した高度な暗号化標準（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の将来を考えると、DTLはCapWapに固有のセキュリティ方法に代わる賢明な代替手段かもしれません。さらに、DTLの使用は、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モードでのトンネリング方法も提供しています。ローカルMACデータトンネリングとは、802.3イーサネットフレームとしてユーザーデータのトンネルをWTPに戻し、それ以外の場合はローカル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またはアプリケーション対応の治療があります。将来のワイヤレステクノロジーとの透明性と互換性の向上は、802.3、アクセスポイントとACまたはネットワーク内のその他の終了ポイントの間の共通形式でユーザーデータをカプセル化する場合にも可能です。
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.
もう1つの可能性は、ネイティブワイヤレスMACが将来変化する場合、このMACの変更をサポートする新しいWTPがワイヤレスMAC-> 802.3統合関数をサポートできる場合、ワイヤレスMACレイヤーの変更はACに対して透明なままであり、それでも多くを維持することができます。データトンネリングがもたらすことができる利点の。
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は、ワイヤレスレイヤー2 MACに依存しないレイヤー1ワイヤレス情報（受信信号強度表示（RSSI）および信号対雑音比（SNR））を含むトンネルユーザーデータのヘッダーをサポートしています。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はローカルMACアーキテクチャを狭く定義して、データフレームをACに戻すオプションを除外しています。すべての提案と既存の専有業界の実装にわたる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プロトコルの一部である場合、評価チームは、ワーキンググループが必須として1つの方法を選択し、その他の方法をオプションとして選択することを推奨します。さらに、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.
どのモードが必須であるかを選択することは重要な決定であり、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は、802.11バインディングからSTA削除関数を抽出しました。ただし、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メソッドに対して冗長であると考えています。チームは、LWAPPプロトコルからレイヤー2メソッドのカプセル化を削除することを推奨します。
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 Standard 802.11i、「Medium Access Control（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] Yang、L.、Zerfos、P。、およびE. Sadot、「ワイヤレスアクセスポイントの制御とプロビジョニングのための建築分類（CAPWAP）」、RFC 4118、2005年6月。
[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] Govindan、S.、Ed。、Cheng、H.、Yao、Zh。、Zhou、Wh。、およびL. Yang、「ワイヤレスアクセスポイントの制御とプロビジョニングの目的（CAPWAP）、RFC 4564、7月2006年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[CTP] Singh , I., Francisco, P., Pakulski , K., and F. Backes, "CAPWAP Tunneling Protocol (CTP)", Work in Progress, April 2005.
[CTP] Singh、I.、Francisco、P.、Pakulski、K。、およびF. Backes、「Capwap Tunneling Protocol（CTP）」、2005年4月の作業。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、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] Calhoun、P.、O'hara、B.、Kelly、S.、Suri、R.、Williams、M.、Hares、S。、およびN. Cam Winget、「Light Weight Access Point Protocol（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] Mitton、D.、St.Johns、M.、Barkley、S.、Nelson、D.、Patil、B.、Stevens、M.、およびB. Wolff、「認証、承認、および会計：プロトコル評価"、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.、Harkins、D。、およびS. Ponnuswamy、「Slapp：Secure light Access Point Protocol」、2005年5月の作業。
[WICOP] Iino, S., Govindan, S., Sugiura, M., and H. Cheng, "Wireless LAN Control Protocol (WiCoP)", Work in Progress, March 2005.
[WICOP] IINO、S.、Govindan、S.、Sugiura、M。、およびH. Cheng、「ワイヤレスLANコントロールプロトコル（WICOP）」、2005年3月、Work in Progress。
Authors' Addresses
著者のアドレス
Darren P. Loher Envysion, Inc. 2010 S. 8th Street Boulder, CO 80302 USA
Darren P. Loher Engysion、Inc。2010 S. 8th Street Boulder、Co 80302 USA
Phone: +1.303.667.8761
EMail: dplore@gmail.com
David B. Nelson Enterasys Networks, Inc. 50 Minuteman Road Anover, MA 01810-1008 USA
David B. Nelson Enterasys Networks、Inc。50 Minuteman Road Anover、MA 01810-1008 USA
Phone: +1.978.684.1330
EMail: dnelson@enterasys.com
Oleg Volinsky Colubris Networks, Inc. 200 West Street Waltham, MA 02451 USA
Oleg Volinsky Colubris Networks、Inc。200 West Street Waltham、MA 02451 USA
Phone: +1.781.547.0329
EMail: ovolinsky@colubris.com
Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 100 Plano、TX 75075 USA
Phone: +1.972.509.5599
EMail: sarikaya@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
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.
この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。