draft-francisco-capwap-ctp-evaluation-00.txt   draft-francisco-capwap-ctp-evaluation-01.txt 
Operations Group I. Singh Operations Group I. Singh
Internet Draft P. Francisco Internet Draft P. Francisco
Expires: December 2005 Chantry Networks Expires: December 2005 M. Montemurro
Chantry Networks
June 2005 June 2005
Evaluation of CAPWAP Tunneling Protocol (CTP) Evaluation of CAPWAP Tunneling Protocol (CTP)
draft-francisco-capwap-ctp-evaluation-00.txt draft-francisco-capwap-ctp-evaluation-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 23 skipping to change at page 2, line 23
3.1.2 Support for Traffic Separation........................3 3.1.2 Support for Traffic Separation........................3
3.1.3 Wireless Terminal Transparency........................4 3.1.3 Wireless Terminal Transparency........................4
3.1.4 Configuration Consistency.............................4 3.1.4 Configuration Consistency.............................4
3.1.5 Firmware Trigger......................................4 3.1.5 Firmware Trigger......................................4
3.1.6 Monitoring and Exchange of System-wide Resource State.5 3.1.6 Monitoring and Exchange of System-wide Resource State.5
3.1.7 Resource Control Objective............................5 3.1.7 Resource Control Objective............................5
3.1.8 CAPWAP Protocol Security..............................6 3.1.8 CAPWAP Protocol Security..............................6
3.1.9 System-wide Security..................................6 3.1.9 System-wide Security..................................6
3.1.10 IEEE 802.11i Considerations..........................7 3.1.10 IEEE 802.11i Considerations..........................7
3.1.11 Interoperability Objective...........................7 3.1.11 Interoperability Objective...........................7
3.1.12 Vendor Independence..................................8 3.1.12 Protocol Specifications..............................8
3.1.13 Vendor Flexibility...................................8 3.1.13 Vendor Independence..................................8
3.1.14 Vendor Flexibility...................................9
3.1.15 NAT Traversal........................................9
3.2 Desirable Objectives.......................................9 3.2 Desirable Objectives.......................................9
3.2.1 Multiple Authentication Mechanisms....................9 3.2.1 Multiple Authentication Mechanisms....................9
3.2.2 Support for Future Wireless Technologies..............9 3.2.2 Support for Future Wireless Technologies.............10
3.2.3 Support for New IEEE Requirements.....................9 3.2.3 Support for New IEEE Requirements....................10
3.2.4 Interconnection Objective............................10 3.2.4 Interconnection Objective............................10
3.2.5 Access Control.......................................10 3.2.5 Access Control.......................................11
3.3 Non-objectives............................................10 3.3 Non-objectives............................................11
3.3.1 Support for Non-CAPWAP WTPs..........................10 3.3.1 Support for Non-CAPWAP WTPs..........................11
3.3.2 Technical Specifications.............................11 3.3.2 Technical Specifications.............................11
3.4 Operator Requirements.....................................11 3.4 Operator Requirements.....................................12
3.4.1 AP Fast Handoff......................................11 3.4.1 AP Fast Handoff......................................12
4. Compliance Table..............................................11 4. Compliance Table..............................................12
5. Security considerations.......................................12 5. Security considerations.......................................13
6. References....................................................12 6. References....................................................13
7. Author's Addresses............................................12 7. Author's Addresses............................................13
Intellectual Property and Copyright Statements ...............13 Intellectual Property and Copyright Statements ...............13
1. Definitions 1.
Definitions
1.1 Conventions used in this document 1.1
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1] document are to be interpreted as described in RFC-2119 [1]
2. Introduction 2.
Introduction
The authors of the CAPWAP Tunneling Protocol(CTP) [2] believe that The authors of the CAPWAP Tunneling Protocol(CTP) [2] believe that
CTP provides a robust solution in the form of a protocol that CTP provides a robust solution in the form of a protocol that
addresses the issues raised in the CAPWAP Problem Statement draft addresses the issues raised in the CAPWAP Problem Statement draft
[3]. CTP can be run over an L2 or an L3 network and it is extensible [3]. CTP can be run over an L2 or an L3 network and it is extensible
to support WTPs which terminate other radio technologies than IEEE to support WTPs which terminate other radio technologies than IEEE
802.11. 802.11.
Given below is a brief analysis of the protocol with respect to the Given below is a brief analysis of the protocol with respect to the
objectives draft [4] that has been presented and discussed in the WG. objectives draft [4] that has been presented and discussed in the WG.
3. Objectives Responses 3.
3.1 Mandatory and Accepted Objectives Objectives Responses
3.1
Mandatory and Accepted Objectives
3.1.1 Logical Groups 3.1.1
Logical Groups
The ability to control and manage physical WTPs in terms of logical The ability to control and manage physical WTPs in terms of logical
groups. groups.
3.1.1.1 Protocol Evaluation 3.1.1.1
CTP natively recognizes WTP devices as logical groups. The protocol Protocol Evaluation
provides capabilities discovery mechanisms (CTP_CAP_REQ/RESP) to The CTP protocol allows the AP and WTP to exchange information on
allow a device to enumerate physical and logical associations. These logical groups as part of the capabilities exchange
associations are then carried forth into the protocol exchange and (CTP_CAP_REQ/RESP). The AC uses this information to provision logical
state machines to decouple the logical operations such as Virtual groups on the WTP as part of the configuration transaction.
Radios from physical resources. The CTP header in the control and data messages provides a mechanism
to segment traffic between logical groups.
3.1.1.2 Compliance 3.1.1.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.1.2 Support for Traffic Separation 3.1.2
Support for Traffic Separation
This objective pertains to the need to maintain separation of control This objective pertains to the need to maintain separation of control
and data traffic in the operation of the protocol. and data traffic in the operation of the protocol.
3.1.2.1 Protocol Evaluation 3.1.2.1
CTP provides specific message types providing for support of easy Protocol Evaluation
separation of control and data paths. The CTP payload is explicitly CTP provides specific message types control and data traffic. CTP
enumerated with itĂs own type (CTP Draft Section 5.3.1, CTP_DATA). In data traffic can either be tunneled to the AC or bridged locally at
addition the CTP implementation, by terminating the 802.1d conversion the WTP. Control traffic will always travel between the AC and the
at the WTP, provides a configurable option per logical WTP device to WTP.
indicate whether data traffic should be returned to the controller,
via tunneling, or natively be handled by the WTP by bridging locally
onto the wired network. This only applies to data packets, whereas
the control channel within CTP is completely separate and terminates
at the controller always.
3.1.2.2 Compliance 3.1.2.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.1.3 Wireless Terminal Transparency 3.1.3
Wireless Terminal Transparency
This objective specifies the need for the protocol to be client This objective specifies the need for the protocol to be client
agnostic. That is, the wireless terminals need not be aware of the agnostic. That is, the wireless terminals need not be aware of the
existence of the CAPWAP protocol running underneath. existence of the CAPWAP protocol running underneath.
3.1.3.1 Protocol Evaluation 3.1.3.1
CTP provides mainly a set of provisioning methods for the WTPs Protocol Evaluation
operations and data tunneling, but itĂs operation is transparent to CTP defines a protocol for the provisioning and control of WTPs. The
the connecting client. The connecting client simply interacts with protocol is agnostic to wireless MAC technology and entirely
the WTPĂs wireless MAC implementation and itĂs traffic is bridge to transparent to a wireless terminal. Shipping products using CTP
the network point of presence which may selectively be the controller demonstrate that this protocol does not have any adverse effects,
or the local wired infrastructure. In Controller mode the traffic is interoperability or otherwise, on the wireless terminals.
encapsulated for transport but the client remains un-aware that
additional transport is taking place. Shipping products with CTP
implementations have shown that this protocol does not have any
adverse effects, interoperability or otherwise, on the wireless
terminals.
3.1.3.2 Compliance 3.1.3.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.1.4 Configuration Consistency 3.1.4
Configuration Consistency
This objectives pertains to the protocolĂs ability to provide This objectives pertains to the protocolĂs ability to provide
consistent state information of the WTPs at the AC. consistent configuration state information of the WTPs at the AC.
3.1.4.1 Protocol Evaluation 3.1.4.1
CTP makes provisions for the periodic retrieval of WTP information Protocol Evaluation
(CTP_Stats_REQ/RESP, CTP_STATS_Notify) such as RF statistics and Load CTP defines a configuration transaction where the AC can exchange
factors as per standard MIB specifications. configuration with the WTP. The mechanism uses an SNMP data payload
encapsulated inside a CTP frame. The WTP must acknowledge the
configuration update to confirm that the configuration state on the
WTP is synchronized with the AC.
3.1.4.2 Compliance The protocol makes use of the SNMP MIB that is defined in the IEEE
802.11 standard and its amendments. This provides a generic mechanism
for configuration which is agnostic to wireless technologies and
updates to wireless standards.
3.1.4.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.1.5 Firmware Trigger 3.1.5
Firmware Trigger
This objective states that the protocol must have the ability to This objective states that the protocol must have the ability to
trigger WTP firmware updates. It does not necessarily state the need trigger WTP firmware updates. It does not necessarily state the need
for the protocol to integrate a software update mechanism within the for the protocol to integrate a software update mechanism within the
protocol itself. protocol itself.
3.1.5.1 Protocol Evaluation 3.1.5.1
Protocol Evaluation
After the device capability exchange phase (CTP-CAP_REQ/RESP) which After the device capability exchange phase (CTP-CAP_REQ/RESP) which
allows for the identification of the type of WTP connecting, CTP allows for the identification of the type of WTP connecting, CTP
protocol specifies a phase of firmware image validation (CTP- protocol specifies a phase of firmware image validation (CTP-
Software-upgrade-req/resp, section 5.1.5) by which the WTP indicates Software-upgrade-req/resp, section 5.1.5) where the WTP indicates the
to the Controller what version of image it is currently running and version of its firmware to the Controller. The controller can
the response validates and requests an update if necessary. evaluate the version of the WTP software and signal the WTP to update
Conversely, the Controller may explicitly request (Under its image. CTP does not specify the actual method for firmware
administratorĂs control) the firmware upgrade for a specified WTP. upgrade, but rather assumes the application of standardized binary
CTP does not specify the actual method for firmware upgrade, but transport protocols (FTP/TFTP).
rather assumes the application of standardized binary transport
protocols (FTP/TFTP).
3.1.5.2 Compliance 3.1.5.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.1.6 Monitoring and Exchange of System-wide Resource State 3.1.6
Monitoring and Exchange of System-wide Resource State
This objective states that the protocol must incorporate the ability This objective states that the protocol must incorporate the ability
for the WTP to send statistics, congestion indications and other for the WTP to send statistics, congestion indications and other
pertinent wireless state information to the AC. pertinent wireless state information to the AC.
3.1.6.1 Protocol Evaluation 3.1.6.1
CTP protocol provides for the periodic exchange of a WTPĂs Protocol Evaluation
CTP protocol defines frames for the periodic exchange of a WTPĂs
operational statistics (CTP-Stats-req/resp, CTP-Stats-Notify, Section operational statistics (CTP-Stats-req/resp, CTP-Stats-Notify, Section
5.2.7-9). The statistics characteristics may be enhanced to convey 5.2.7-9). The protocol uses an SNMP format for the statistics based
necessary information set. on MIB definitions from the 802.11 standard and its amendments. This
protocol mechanism is agnostic to wireless technology and updates to
existing wireless standards.
3.1.6.2 Compliance 3.1.6.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.1.7 Resource Control Objective 3.1.7
Resource Control Objective
This objective pertains to the ability of the protocol to provide a This objective pertains to the ability of the protocol to provide a
mapping mechanism of the IEEE 802.11e QOS priorities across the mapping mechanism of the IEEE 802.11e QOS priorities across the
wireless and wired infrastructure. wireless and wired infrastructure.
3.1.7.1 Protocol Evaluation 3.1.7.1
CTP, by virtue of being an IP based transport protocol, provides Protocol Evaluation
CTP defines a two tiered mechanism for QoS that addresses the
switching segment as well as the wireless medium. The QoS strategy
for the protocol involves mapping the QoS marking of the data frame
to the CTP frame.
Across the switched segment, CTP is an IP protocol that provides
several mechanisms to ensure the preservation of QoS markers within several mechanisms to ensure the preservation of QoS markers within
the original data packet. The protocol header (CTP Section 4.1) the original data packet. The protocol header (CTP Section 4.1)
natively defines an 8-bit field for relaying of QoS policy related natively defines an 8-bit field for relaying of QoS policy related
information in a transport independent manner. This allows the WTP information in a transport independent manner. Alternatively, CTP
and Controller to classify and guarantee the preservation of any could use 802.1p tagging to preserve QoS across the switched segment.
802.11e identifiers between the two entities. In addition, CTP This allows the WTP and Controller to classify and guarantee the
implementation must copy the TOS fields of the original data packet preservation of QoS across the switched network.
onto the tunnel header. The corresponding QoS markers are also
mapped to the layer 2 if 802.1q implemented in the interconnecting
network.
3.1.7.2 Compliance CTP makes use of the 802.11e standard to preserve QoS across the
wireless medium. The mapping for QoS data frames to 802.11e QoS
frames is defined in the 802.11e amendment to the 802.11 standard.
3.1.7.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.1.8 CAPWAP Protocol Security 3.1.8
CAPWAP Protocol Security
This objective concerns the security of the CAPWAP protocol. The This objective concerns the security of the CAPWAP protocol. The
protocol must support mutual authentication of the WTP and the AC and protocol must support mutual authentication of the WTP and the AC and
the communication channel between the two entities must be secured. the communication channel between the two entities must be secured.
In addition, however, the protocol must not preclude the possibility In addition, however, the protocol must not preclude the possibility
of supporting asymmetric authentication mechanisms. of supporting asymmetric authentication mechanisms.
3.1.8.1 Protocol Evaluation 3.1.8.1
Protocol Evaluation
First of all, as currently defined, CTP does not support a pre-shared First of all, as currently defined, CTP does not support a pre-shared
key mechanism for mutual authentication. It assumes the existence of key mechanism for mutual authentication. It assumes the existence of
digital certificates on the WTP and AC. The mutual authentication digital certificates on the WTP and AC. The mutual authentication
mechanism between WTP and AC using digital certificates as described mechanism between WTP and AC using digital certificates as described
in the CTP draft is very similar to the method employed in the LWAPP in the CTP draft is very similar to the method employed in the LWAPP
draft [5]. As such, some of the recent comments on the WG email list draft [5]. As such, some of the recent comments on the WG email list
regarding the security of LWAPPĂs mutual authentication also applies regarding the security of LWAPPĂs mutual authentication also applies
to CTP. Specifically in the area of the generation of the encryption to CTP. Specifically in the area of the generation of the encryption
key. Currently CTP specifies that the encryption key is generated by key. Currently CTP specifies that the encryption key is generated by
the AC and is securely transported to the WTP. An obvious the AC and is securely transported to the WTP. An obvious
skipping to change at page 6, line 37 skipping to change at page 6, line 40
the generation of the encryption key by providing independently the generation of the encryption key by providing independently
generated random material for the session keys. generated random material for the session keys.
Also, based on discussion on the WG list it is not clear whether the Also, based on discussion on the WG list it is not clear whether the
use of pre-shared key for mutual authentication is required or simply use of pre-shared key for mutual authentication is required or simply
that the authentication must be mutual. Nevertheless, we believe that the authentication must be mutual. Nevertheless, we believe
that adding another method of mutual authentication, ie. with using that adding another method of mutual authentication, ie. with using
pre-shared keys, will enhance the flexibility of the CTP protocol, pre-shared keys, will enhance the flexibility of the CTP protocol,
but at the cost of increased protocol complexity. but at the cost of increased protocol complexity.
3.1.8.2 Compliance 3.1.8.2
Compliance
CTP is partially compliant with this objective. CTP is partially compliant with this objective.
3.1.9 System-wide Security 3.1.9
System-wide Security
The protocol must not adversely affect the security of the wireless The protocol must not adversely affect the security of the wireless
and wired networks on which it runs. and wired networks on which it runs.
3.1.9.1 Protocol Evaluation 3.1.9.1
Protocol Evaluation
CTP defines that any exchanges of control based material such as PMK CTP defines that any exchanges of control based material such as PMK
is natively encrypted. All Control messages are mutually encrypted is natively encrypted. All Control messages are mutually encrypted
between the WTP and controller. In lieu of a thorough security and between the WTP and controller. In lieu of a thorough security and
cryptographic analysis of the protocol by peers, the authors believe cryptographic analysis of the protocol by peers, the authors believe
that the encryption/keying mechanism currently provides adequate that the encryption/keying mechanism currently provides adequate
protection against un-authorized compromise of the transported protection against un-authorized compromise of the transported
information which, in turn, would not adversely affect the security information which, in turn, would not adversely affect the security
of the wireless or wired network. of the wireless or wired network.
3.1.9.2 Compliance 3.1.9.2
Compliance
The protocol is partially compliant with this objective pending a The protocol is partially compliant with this objective pending a
thorough security and cryptographic review. thorough security and cryptographic review.
3.1.10 IEEE 802.11i Considerations 3.1.10
IEEE 802.11i Considerations
The CAPWAP protocol must determine the exact structure of the The CAPWAP protocol must determine the exact structure of the
centralized WLAN architecture in which authentication needs to be centralized WLAN architecture in which authentication needs to be
supported, i.e. the location of major authentication components. supported, i.e. the location of major authentication components.
This may be achieved during WTP initialization where major This may be achieved during WTP initialization where major
capabilities are distinguished. capabilities are distinguished.
The protocol must allow for the exchange of key information when The protocol must allow for the exchange of key information when
authenticator and encryption roles are located in distinct entities. authenticator and encryption roles are located in distinct entities.
3.1.10.1 Protocol Evaluation 3.1.10.1
During the capabilities exchange phase of the CTP protocol it is Protocol Evaluation
determined whether the WTP implementation is a split-MAC or a local- The CTP protocol has separated the 802.11i security function into two
MAC implementation. This would in turn lead the AC to engage the components, EAP Authenticator and Key Management. The EAP
appropriate authentication modules of 802.11i. The CTP protocol Authenticator and Key Management functions provide a natural
defines that all control exchanges between WTP and Controller are delineation point between 802.11i functions. The location of the
encrypted with own key pairs. Therefore , the keying information components is negotiated between the AC and WTP during the
that is required is appropriately transported between WTP and AC in a capabilities exchange and registration. The components can either co-
secure fashion. For local-MAC implementation any frames relating to located or separate on the WTP or the AC. Any exchange of security
authentication are relayed as control messages (CTP-Auth-Req/resp). association information between the AC and the WTP is protected
For split-MAC, the transport of this sensitive information may also either by 802.11i mechanisms or by CTP mechanisms.
be carried as payload for the same message and therefore provide
encryption for transport.
3.1.10.2 Compliance 3.1.10.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.1.11 Interoperability Objective 3.1.11
Interoperability Objective
The objective specifies that the protocol must include a capabilities The objective specifies that the protocol must include a capabilities
exchange mechanism so that different types of WTPs can be managed by exchange mechanism so that different types of WTPs can be managed by
ACs. That is, local-MAC and split-MAC WTPs may be recognized by the ACs. That is, local-MAC and split-MAC WTPs may be recognized by the
AC through protocol exchange and appropriate handling within the AC through protocol exchange and appropriate handling within the
protocol would ensue as a result of this capability exchange. protocol would ensue as a result of this capability exchange.
3.1.11.1 Protocol Evaluation 3.1.11.1
Protocol Evaluation
The CTP protocol as specified, provides a mechanism for capabilities The CTP protocol as specified, provides a mechanism for capabilities
exchange (CTP-caps-req/resp) that could be leveraged to allow the WTP exchange (CTP-caps-req/resp) that allows the WTP and the Controller
and the Controller to negotiate the operational mode as to whether to negotiate their operational mode. The capabilities exchange for
split-MAC or Local-MAC is implemented in the WTP. In its current control and data traffic is treated independently.
form the draft does not specify the differences in the transport and
configuration that would occur if the WTP supports split-MAC. The
authors are aware of this limitation in the draft and are working on
the same.
3.1.11.2 Compliance Control traffic in split-MAC mode indicates that the WTP will forward
In its current form CTP is partially compliant with this objective. all wireless MAC management traffic (i.e. IEEE 802.11) to the AC.
3.1.11.3 Protocol Specifications Control traffic in local-MAC mode indicates that all 802.11
management frames will terminate at the WTP. CTP defines update
messages to allow the WTP to signal the AC for updates to wireless
client connection states.
Data traffic in split-MAC modes indicates that the WTP will forward
all traffic to the AC. The format for the traffic can be either
wireless MAC dependent (i.e. IEEE 802.11) or IEEE 802.3 depending
whether the control channel is split-MAC or local-MAC.
Data traffic in local-MAC mode indicates that data frames will be
bridged locally by the AP to its switching segment. The switching
segment may be present locally at the AP or at the Controller. For
Controller handled bridged access the CTP protocol provides a
tunneling method for 802.3 frame encapsulation.
3.1.11.2
Compliance
CTP is compliant with this objective.
3.1.12
Protocol Specifications
This objective states that any vendor of a WTP or AC or any person This objective states that any vendor of a WTP or AC or any person
may implement the CAPWAP protocol and that all such implementations may implement the CAPWAP protocol and that all such implementations
should interoperate. should interoperate.
3.1.11.4 Protocol Evaluation 3.1.12.1
Protocol Evaluation
CTP specification fully specify the protocol and its operation within CTP specification fully specify the protocol and its operation within
WTPs and ACs. It also indicates the configuration and statistics WTPs and ACs. It also indicates the configuration and statistics
capabilities come from MIB specifications that are published by IEEE capabilities come from MIB specifications that are published by IEEE
that fully describe the managed objects within an WTP. Although full that fully describe the managed objects within an WTP. The authors
MIB specifications from IEEE are considered work in progress the believe that the work done by the IEEE will enable full
authors believe that the work done there will enable full interoperability as the specifications coming from IEEE will be
interoperability as, presumably, the specifications coming from IEEE complete and not require any knowledge of any vendor specific
will be complete and not require any knowledge of any vendor specific
wireless device information. wireless device information.
3.1.11.5 Compliance 3.1.12.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.1.12 Vendor Independence 3.1.13
Vendor Independence
This objective states that the CAPWAP protocol must not be reliant on This objective states that the CAPWAP protocol must not be reliant on
any underlying vendor implementation of hardware of either the WTP or any underlying vendor implementation of hardware of either the WTP or
the AC. the AC.
3.1.12.1 Protocol Evaluation 3.1.13.1
Protocol Evaluation
CTP does not assume any underlying hardware architecture of the WTPs CTP does not assume any underlying hardware architecture of the WTPs
or the ACs. In addition any dependency on MIB definitions in its or the ACs. In addition any dependency on MIB definitions in its
current form also does not assume any reliance on hardware current form also does not assume any reliance on hardware
specifications. specifications.
3.1.12.2 Compliance 3.1.13.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.1.13 Vendor Flexibility 3.1.14
Vendor Flexibility
The protocol must not be bound to any specific MAC. The protocol must not be bound to any specific MAC.
3.1.13.1 Protocol Evaluation 3.1.14.1
Protocol Evaluation
CTP has been completely implemented on hardware from at least two CTP has been completely implemented on hardware from at least two
different vendors whose wireless MAC implementations are completely different vendors whose wireless MAC implementations are completely
independent. Given this fact as well as CTPĂs inherent agnosticity independent. Given this fact as well as CTPĂs inherent agnosticity
of wireless implementation, CTP can be implemented without knowledge of wireless implementation, CTP can be implemented without knowledge
of underlying vendor hardware. of underlying vendor hardware.
3.1.13.2 Compliance 3.1.14.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.2 Desirable Objectives 3.1.15
NAT Traversal
The protocol must not prevent operation across WLAN topologies which
include NAT segments.
3.2.1 Multiple Authentication Mechanisms 3.1.15.1
Protocol Evaluation
CTP provides an authentication mechanism which uses AC and WTP
identifiers to establish a secure connection without a dependency on
MAC or IP address. The CTP protocol is primarily transported as UDP
payload. Typical NAT implementations are IP and TCP/UDP port based.
Since CTP is transported above these layers, CTP will work properly
through NAT devices. The WTP can be statically configured to discover
the AC through a NAT segment.
3.1.15.2
Compliance
CTP is compliant with this objective.
3.2
Desirable Objectives
3.2.1
Multiple Authentication Mechanisms
This objective specifies the requirement that the protocol should be This objective specifies the requirement that the protocol should be
able to support authentication mechanisms other than IEEE 802.11i. able to support authentication mechanisms other than IEEE 802.11i.
3.2.1.1 Protocol Evaluation 3.2.1.1
Protocol Evaluation
Since CTP is wireless terminal agnostic, and since the PMK key Since CTP is wireless terminal agnostic, and since the PMK key
exchange is generic (for example, does not assume any authentication exchange is generic (for example, does not assume any authentication
mechanism in the form of an EAP type), CTP does not prevent the mechanism in the form of an EAP type), CTP does not prevent the
operation of any other authentication mechanism. operation of any other authentication mechanisms.
3.2.1.2 Compliance CTP logically separates the EAP-Authentication function from the Key
Management function. Different authentication or key management
frameworks can be substituted without affecting the protocol
behavior.
3.2.1.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.2.2 Support for Future Wireless Technologies 3.2.2
Support for Future Wireless Technologies
This objective states that the protocol should be able to be extended This objective states that the protocol should be able to be extended
to future layer 2 wireless technologies and should not be limited to to future layer 2 wireless technologies and should not be limited to
only supporting IEEE 802.11. only supporting IEEE 802.11.
3.2.2.1 Protocol Evaluation 3.2.2.1
Protocol Evaluation
The current specification lists alternative layer 2 wireless The current specification lists alternative layer 2 wireless
technologies that and be indicated as part of the capabilities technologies that and be indicated as part of the capabilities
exchange phase. The protocol is sufficiently modular in that the exchange phase. The protocol is sufficiently modular in that the
configuration, statistics and other management functions of these configuration, statistics and other management functions of these
wireless devices can be supported. If indeed there are layer 2 wireless devices can be supported. If indeed there are layer 2
wireless specific elements that need to be added, those are easily wireless specific elements that need to be added, those are easily
supported by extensions to the protocol. supported by extensions to the protocol.
3.2.2.2 Compliance 3.2.2.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.2.3 Support for New IEEE Requirements 3.2.3
Support for New IEEE Requirements
The protocol must be able to accommodate defined changes or The protocol must be able to accommodate defined changes or
extensions to the IEEE 802.11 specifications. extensions to the IEEE 802.11 specifications.
3.2.3.1 Protocol Evaluation 3.2.3.1
Currently CTP maps 802.11 specific messages into generic messages Protocol Evaluation
within CTP. In other words it provides an abstraction layer to layer CTP provides an abstraction layer to accommodate any type of wireless
2 wireless specific commands and functions. As new 802.11 MAC technology. It provides control messages to exchange basic state
specifications arise, whether the intelligence to interpret them is information between the AC and the WTP. It provides a split MAC
required in the AC or the WTP is irrelevant. There will be work mechanism where all MAC frames can be forwarded and handled at the
required to interpret these new extensions on both the AC as well as controller. It uses SNMP-based encapsulation to provide a generic
the WTP. The CTP specification is constructed so that a new mechanism for exchanging configuration and statistics data . New
extension would result in a new message type. So it can accommodate 802.11 amendments can be easily accommodated by the protocol. There
the changes as they arise. will be work required to interpret the impact of the amendment on
both the AC and the WTP to determine whether further message
definition is required.
3.2.3.2 Compliance 3.2.3.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.2.4 Interconnection Objective 3.2.4
Interconnection Objective
The CAPWAP protocol must not be constrained by the underlying The CAPWAP protocol must not be constrained by the underlying
transport technologies of the wired medium. transport technologies of the wired medium.
3.2.4.1 Protocol Evaluation 3.2.4.1
Protocol Evaluation
CTP is agnostic to the underlying transport technology as it is CTP is agnostic to the underlying transport technology as it is
implemented as UDP. This was done with the assumption that the implemented as UDP. This was done with the assumption that the
transport technology can carry IP packets across its medium either L2 transport technology can carry IP packets across its medium either L2
or L3 network. Currently CTP is IPv4 specific and needs to be or L3 network. In itĂs current definition CTP is transported as UDP
updated to be IP version agnostic as well. payload therefore directly abstracted from IPv4/v6 base.
3.2.4.2 Compliance 3.2.4.2
CTP is partially compliant with this objective in terms of not having Compliance
specified IPv6 header types. CTP is compliant with this objective in terms of not having specified
IPv6 header types.
3.2.5 Access Control 3.2.5
Access Control
This objective pertains to the ability of the protocol to exchange This objective pertains to the ability of the protocol to exchange
information required for access control of WTPs and wireless information required for access control of WTPs and wireless
terminals. terminals.
3.2.5.1 Protocol Evaluation 3.2.5.1
Protocol Evaluation
CTP provides specific messages, e.g. CTP-MU- CTP provides specific messages, e.g. CTP-MU-
Connect/Disconnect/Authenticate messages, that control the access of Connect/Disconnect/Authenticate messages, that control the access of
wireless terminals. In addition to the actual mutual authentication wireless terminals. In addition to the actual mutual authentication
of WTPs and ACs, the registration phase contains a AP-ID field that of WTPs and ACs, the registration phase contains a AP-ID field that
needs to be verified by the AC. This field needs to be checked by needs to be verified by the AC. This field needs to be checked by
the AC and the mechanism for this check is not within the scope of the AC and the mechanism for this check is not within the scope of
any CAPWAP work. However, the CTP protocol itself provides this any CAPWAP work. However, the CTP protocol itself provides this
identification token as a means of access control of the WTP. identification token as a means of access control of the WTP.
3.2.5.2 Compliance 3.2.5.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.3 Non-objectives 3.3
Non-objectives
The current objectives draft states this section as ˘Rejected The current objectives draft states this section as ˘Rejected
Objectives÷. We have used the term ˘Non-Objectives÷ for this section Objectives÷. We have used the term ˘Non-Objectives÷ for this section
based on the discussion on the WG email list. based on the discussion on the WG email list.
3.3.1 Support for Non-CAPWAP WTPs 3.3.1
Support for Non-CAPWAP WTPs
This objective states that the CAPWAP protocol should be capable of This objective states that the CAPWAP protocol should be capable of
recognizing legacy WTPs and existing network management systems. recognizing legacy WTPs and existing network management systems.
3.3.1.1 Protocol Evaluation 3.3.1.1
Protocol Evaluation
This requirement is more of a feature for centralized WLAN network This requirement is more of a feature for centralized WLAN network
applications and thus does not apply to the CAPWAP problem statement. applications and thus does not apply to the CAPWAP problem statement.
3.3.1.2 Compliance 3.3.1.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.3.2 Technical Specifications 3.3.2
Technical Specifications
This objective states that WTP vendors should not have to share This objective states that WTP vendors should not have to share
technical specifications for hardware and software to AC vendors in technical specifications for hardware and software to AC vendors in
order for interoperability to be achieved. order for interoperability to be achieved.
3.3.2.1 Protocol Evaluation 3.3.2.1
Protocol Evaluation
As discussed earlier, CTP is hardware and vendor agnostic. As discussed earlier, CTP is hardware and vendor agnostic.
3.3.2.2 Compliance 3.3.2.2
Compliance
CTP is compliant with this objective. CTP is compliant with this objective.
3.4 Operator Requirements 3.4
Operator Requirements
3.4.1 AP Fast Handoff 3.4.1
AP Fast Handoff
This objective states that the CAPWAP protocol operations must not This objective states that the CAPWAP protocol operations must not
impede or obstruct the efficiency of fast handoff procedures. impede or obstruct the efficiency of fast handoff procedures.
3.4.1.1 Protocol Evaluation 3.4.1.1
Protocol Evaluation
In the CTP protocol, the signaling of roaming events are efficiently In the CTP protocol, the signaling of roaming events are efficiently
encoded in the CTP-MU messages. Also, the 802.1x messaging is encoded in the CTP-MU messages. Also, the 802.1x messaging is
centralized allowing efficient use of CPU resources at the AC. In centralized allowing efficient use of CPU resources at the AC. In
effect, the mere existence of the centralized architecture ensures effect, the mere existence of the centralized architecture ensures
that the efficiency of fast handoffs is improved rather than impeded. that the efficiency of fast handoffs is improved rather than impeded.
3.4.1.2 Compliance 3.4.1.2
Compliance
CTP complies with this objective. CTP complies with this objective.
4. Compliance Table 4.
Compliance Table
Given below is a table summarizing the compliance to the objectives. Given below is a table summarizing the compliance to the objectives.
C = Compliant, P = Partially compliant, N = Non-compliant. C = Compliant, P = Partially compliant, N = Non-compliant.
+----------------------------------------------------+------------+ +----------------------------------------------------+------------+
| Objective Type | Compliance | | Objective Type | Compliance |
+----------------------------------------------------+------------+ +----------------------------------------------------+------------+
| Logical Groups | C | | Logical Groups | C |
| Support for Traffic Separation | C | | Support for Traffic Separation | C |
| Wireless Terminal Transparency | C | | Wireless Terminal Transparency | C |
| Configuration Consistency | C | | Configuration Consistency | C |
| Firmware Trigger | C | | Firmware Trigger | C |
| Monitoring & Exchange of System-wide Resource State| C | | Monitoring & Exchange of System-wide Resource State| C |
| Resource Control Objective | C | | Resource Control Objective | C |
| CAPWAP Protocol Security | P | | CAPWAP Protocol Security | P |
| System-wide Security | P | | System-wide Security | C |
| IEEE 802.11i Considerations | C | | IEEE 802.11i Considerations | C |
| Interoperability Objective | P | | Interoperability Objective | C |
| Protocol Specifications | C | | Protocol Specifications | C |
| Vendor Independence | C | | Vendor Independence | C |
| Vendor Flexibility | C | | Vendor Flexibility | C |
| NAT Traversal | C |
| Multiple Authentication Mechanisms | C | | Multiple Authentication Mechanisms | C |
| Support for Future Wireless Technologies | C | | Support for Future Wireless Technologies | C |
| Support for New IEEE Requirements | C | | Support for New IEEE Requirements | C |
| Interconnection Objective | P | | Interconnection Objective | C |
| Access Control | C | | Access Control | C |
| Support for Non-CAPWAP WTPs | C | | Support for Non-CAPWAP WTPs | C |
| Technical Specifications | C | | Technical Specifications | C |
| AP Fast Handoff | C | | AP Fast Handoff | C |
+----------------------------------------------------+------------+ +----------------------------------------------------+------------+
5. Security considerations 5.
Security considerations
This document provides a self evaluation of CTP in respect to the This document provides a self evaluation of CTP in respect to the
CAPWAP objectives. The CTP draft itself has a section that CAPWAP objectives. The CTP draft itself has a section that
catalogues all the pertinent security concerns. Therefore, in this catalogues all the pertinent security concerns. Therefore, in this
draft there are no new security considerations to be discussed. draft there are no new security considerations to be discussed.
6. References 6.
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997 Levels", BCP 14, RFC 2119, March 1997
[2] Singh, I., et. al., ˘CAPWAP Tunneling Protocol÷, draft-singh- [2] Singh, I., et. al., ˘CAPWAP Tunneling Protocol÷, draft-singh-
capwap-ctp-01.txt (work in progress), April 2005. capwap-ctp-01.txt (work in progress), April 2005.
[3] Calhoun, P., "CAPWAP Problem Statement", draft-ietf-capwap- [3] Calhoun, P., "CAPWAP Problem Statement", draft-ietf-capwap-
problem-statement-02.txt (work in progress), September 2004. problem-statement-02.txt (work in progress), September 2004.
[4] Govindan, S., et. al., ˘Objectives for Control and Provisioning [4] Govindan, S., et. al., ˘Objectives for Control and Provisioning
of Wireless Access Points (CAPWAP)÷, draft-ietf-capwap-objectives- of Wireless Access Points (CAPWAP)÷, draft-ietf-capwap-objectives-
02.txt (work in progress), April 2005 02.txt (work in progress), April 2005
[5] Calhoun, et. al., ˘Light Weight Access Point Protocol (LWAPP)÷, [5] Calhoun, et. al., ˘Light Weight Access Point Protocol (LWAPP)÷,
draft-ohara-capwap-lwapp-02.txt (work in progress), April 2005 draft-ohara-capwap-lwapp-02.txt (work in progress), April 2005
7. Author's Addresses 7.
Author's Addresses
Paulo Francisco Paulo Francisco
Chantry Networks Inc. Chantry Networks Inc.
1900 Minnesota Court 1900 Minnesota Court
Mississauga, ON L5N 3C9 Mississauga, ON L5N 3C9
Canada Canada
Phone: +1 905-363-6410 Phone: +1 905-363-6410
Email: paulo.francisco@siemens.com Email: paulo.francisco@siemens.com
skipping to change at page 13, line 17 skipping to change at page 14, line 4
Canada Canada
Phone: +1 905-363-6410 Phone: +1 905-363-6410
Email: paulo.francisco@siemens.com Email: paulo.francisco@siemens.com
Inderpreet Singh Inderpreet Singh
Chantry Networks Inc. Chantry Networks Inc.
1900 Minnesota Court 1900 Minnesota Court
Mississauga, ON L5N 3C9 Mississauga, ON L5N 3C9
Canada Canada
Phone: +1 905-363-6412 Phone: +1 905-363-6412
Email: inderpreet.singh@siemens.com Email: inderpreet.singh@siemens.com
Michael Montemurro
Chantry Networks Inc.
1900 Minnesota Court
Mississauga, ON L5N 3C9
Canada
Phone: +1 905-363-6413
Email: michael.montemurro@siemens.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/