Subject: [Capwap] CAPWAP eval team - CTP evaluation

From: Inderpreet Singh <[email-masked]>
Date: Thu, 18 Aug 2005 09:01:02 -0400

Dear Eval Team and Chairs,

The CAPWAP evaluation team independently reviewed the CAPWAP candidate
protocols of which CTP was one.

They evaluated the protocols against the CAPWAP objectives
(http://www.capwap.org/draft-ietf-capwap-objectives-03.txt
<http://www.capwap.org/draft-ietf-capwap-objectives-03.txt> )

Here are the results for CTP:

CAPWAP Evaluation 

CTP

Mandatory

5.1.1 Logical Groups 

C

5.1.2 Traffic Separation 

P

5.1.3 STA Transparency 

C

5.1.4 Config Consistency 

C

5.1.5 Firmware Trigger

P

5.1.6 Monitor System 

P

5.1.7 Resource Control

P

5.1.8 Protocol Security

F

5.1.9 System Security 

F

5.1.10 802.11i Consideration

C

5.1.11 Interoperability 

C

5.1.12 Protocol Specifications

P

5.1.13 Vendor Independence 

C

5.1.14 Vendor Flexibility 

C

5.1.15 NAT Traversal 

C

Desirable

5.2.1 Multiple Authentication

P

5.2.2 Future Wireless 

C

5.2.3 New IEEE Requirements 

C

5.2.4 Interconnection (IPv6) 

C

5.2.5 Access Control 

C

Given the fact that all that we have at our disposal is the presentation of
the evaluation team
(http://www.capwap.org/ietf63/CAPWAP%20Evaluation%20Team-3.pdf
<http://www.capwap.org/ietf63/CAPWAP%20Evaluation%20Team-3.pdf> ), it is
difficult to do a thorough analysis of the results of the evaluation.
Nevertheless, based on the presentation and individual conversations with
the evaluation team, given below is a list of our concerns and requests for
clarification to the evaluation for the categories where we got an "P" or an
"F".  It is understood that many of the answers will be provided with the
evaluation draft itself, but it was deemed prudent (through conversations
with the chairs and evaluation team members) to share this with the list a
priori.

5.1.2 Traffic Separation

For Traffic Separation, the CAPWAP Objectives Draft states: "The CAPWAP
Protocol MUST define transport control messages such that the transport of
control messages is separate from the transport of data messages." 

The CTP protocol specification clearly defines three separate types of
frames:  control, data, and MAC management. Control messages are used to
maintain state between the AC and the WTP. MAC Management messages are used
in the case of Split MAC to relay MAC management frames between the WTP and
the AC. Data messages are clearly used to transport user data when it is
tunneled between the WTP and the AC.

The data frame format includes a network identifier which allows data from
different logical groups to remain separated. This is referred as a
desirable objective in the Objectives Draft description for traffic
separation. 

The CTP capabilities exchange allows the WTP to inform the AC of the number
of logical groups that it supports.

The eval team felt that since we did not specify the OIDs to configure the
WTP to tunnel or not to tunnel, we are partially compliant with this
objective.  In order to be fully compliant we need to fully define the
mechanism and OID that is used to configure the tunneling mechanism. However
there are no CAPWAP objectives that mandate the configuration of data
tunneling.  This was an "implied" objective and it makes sense to some
extent.

5.1.5 Firmware Trigger

            The eval team consistently gave the protocols a P rating if the
state machine did not allow a firmware trigger during normal running state.
They felt that this flexibility was required.  Implementation wise this is
currently supported.  The protocol draft does not explicitly define the
state transitions for going from running state to software update state.
However, in our opinion, the usefulness of this capability is debatable.

CTP defines a trigger which signals and out-of-band mechanism for firmware
upgrade. The trigger mechanism can be used at any time once a secure
connection has been established between the WTP and the AC.  There is
nothing in CTP that prevents the firmware upgrade to be triggered while in
running state. There is nothing in CTP that would prevent an implementation
from continuing to service clients in running while upgrading firmware.

We would request clarification from the evaluation team on CTP was not fully
compliant in this objective. 

5.1.6 Monitor System

               This is the first problematic evaluation.  The Objectives
draft states that the protocol "MUST allow for the exchange of statistics,
congestion and other WLAN state information.".  We don't see how this
objective was not met with the CTP draft.  CTP-Stats-Notify, CTP-Stats-Req
and CTP-Stats-Rsp enable the WTP to send statistics information periodically
on its own, and the other two messages allow the AC to command the WTP to
send statistics upon request.  Section 5.3.10 of the CTP draft specifies
that the statistics information that comes from the WTP is as defined in the
IEEE 802.11 Annex D MIB specification.  
 
               We believe that CTP complies with this objective.
Furthermore, our novel approach of using SNMP pdu and OIDs to define the
configuration and statistics of the radio specific technology makes our
protocol stronger in the compliance of this objective because of its
flexibility to non 802.11 radio technology.  Each non-802.11 radio
technology comes with its corresponding MIB definition and contains the most
appropriate statistics information.  In the case of 802.11 Annex D
(normative) ASN.1 encoding of the MAC and PHY MIB, the dot11CountersEntry
table as well as other tables provide more than sufficient statistics and
counters for a full monitoring of the 802.11 manifestations of a CAPWAP
system.
 
Using SNMP pdu's in CTP allows the CAPWAP working group to directly leverage
new amendments to the IEEE 802 wireless standards without continually having
to revise the CAPWAP protocol. It also significantly simplifies the binding
to other wireless standards besides 802.11. 
 
We would request clarification from the evaluation team on why CTP is
partially compliant in addressing this objective.
 
5.1.7 Resource Control
               As per the presentation of the evaluation team, this
objective was deemed compliant if the protocol provided the ability to
"configure QoS mappings".  While CTP does not define any explicit
configuration messages for QoS this capability is implicitly met by the fact
that we have stated that we would use standard 802.11 MIBs for the
configuration and statistics.  The amendment to 802.11 known as 802.11e
specifies a MIB in which all WLAN QoS parameters are defined both for
configuration as well as statistics.  We believe that no further definition
of this was required.  Furthermore, the CTP data header has a Policy field
which allows for CAPWAP implementations to enforce QoS on the CAPWAP packets
in addition to the MU data.
 
The CAPWAP objective draft clearly states "The CAPWAP protocol MUST map the
IEEE 802.11e QoS priorities to  equivalent QoS priorities across the
switching and wireless medium segments". The CTP protocol uses IEEE 802.11e
SNMP oids to configure the mapping at the AC, which can distribute that
information to the WTP's. Furthermore, Section 5.4 of the CTP specification
states: "Data packet coming into the AC from the wired network is a voice
packet as indicated by the TOS or DSCP markings in the IP header.  This
TOS/DSCP byte will be copied to the outer transport header for  proper
priority handling within the network between the AP and the AC.  However,
for appropriate classification at the AP, the AC sets the Policy field to a
value that allows the AP to prioritize this packet over other data packets
that may have a lower priority.  
Similarly in the reverse direction, the MU may have set the  appropriate
fields in the original IP header, but the AP can interpret those bits and
map them to the Policy field in the CTP-Data header for special dispensation
at the AC.  
               
We would request clarification from the evaluation team on why CTP is
partially compliant in addressing this objective.
 
In contrast, our quick perusal of the SLAPP protocol and SLAPP self
evaluation revealed that the protocol has no explicit provisions for QoS
mapping either for CAPWAP tunnel data or for the Mobile Unit data, it merely
has 802.11e parameters in the 802.11 control protocol.  The most detailed
configuration capability was defined within the LWAPP draft only.
 
5.1.8                Protocol Security
               
The support for asymmetric authentication within the CAPWAP protocol was
deemed mandatory by the evaluation team in order to receive a Compliant
indication.  In the context of the CAPWAP protocol, asymmetric
authentication refers to the presence of a mechanism, within the protocol,
to allow the WTP and the AC to conduct different types of authentication.
For example, the WTP can authenticate the AC by the presence of a duly
signed digital certificate, whereas the AC would authenticate the WTP based
on the presence of a pre-shared key.  This also implies that the
authentication may not necessarily be mutual.  That is, both sides don't
necessarily have to authenticate each other.  
 
               The CTP protocol indeed does not have inherent support for
non-mutual or asymmetric authentication of the WTP and AC.  However, neither
do any of the other protocols other than perhaps SLAPP which uses DTLS (a
datagram version of the TLS protocol).  For example, LWAPP provides for
mutual certificate based authentication OR mutual pre-shared key based
authentication.  It does not provide for the ability for a non-mutual
authentication where one side does not authenticate the other.
 
               Another matter of concern is that the CAPWAP email list had a
long discussion on the need for non-mutual authentication and at most the
conclusion would have been that it is not a "MUST have" but rather a "SHOULD
have".  After reviewing the final objective draft indeed it has some verbage
on this issue which a little confusing: "CAPWAP MUST NOT prevent the use of
asymmetric authentication."  Indeed, we do not support asymmetric
authentication.  But do we prevent its use?  It seems like the evaluation
team took the spirit of the text and interpreted it as asymmetric
authentication MUST be supported.  If it is a SHOULD be supported, then we
should Comply with the requirement.  This is clearly a case disagreement on
the interpretation of the objectives.
 
5.1.9                System Security
 
The objective states very clearly the following: "The design of the CAPWAP
protocol MUST NOT allow for any compromises to the WLAN system by external
entities."  It is not clear based on the table in which we were granted an
"F" for this protocol objective, as well as the two bullets in the
presentation, as to why the evaluation team felt we did not comply with this
objective.  We don't see anything in the protocol, pending a thorough
security review that allows for any compromise to the WLAN system by
external entities.  This is the case where we would be very interested in
understanding what review did the evaluation team do to deem the protocol
insecure.
 
The 802.11i standard uses EAPoL messages between the STA and the WTP for
authentication. These messages are treated as data messages transmitted over
the wireless medium between the STA and the WTP. In the CTP protocol, these
messages are relayed across the switching infrastructure from the WTP to the
AC. If these messages are deemed to be protected across the wireless medium,
why would this compromise security across the wired medium between the WTP
and the AC?
 
We would request clarification from the evaluation team on why CTP failed to
be compliant in addressing this objective.
 
5.1.10             Protocol Specifications
               The evaluation team deemed the CTP protocol specification
draft to be incomplete.  Therefore, we have received partial compliance
within this category.  The only explanation we see for this is that CTP
relies on external MIB definitions for proper and full interoperability.  

In addition to the mandatory objectives stated above, there are a few
Desirable objectives as well.

We would like to state CTP has been implemented and is used in products that
are working in the market today. There may be interpretation and
clarification issues with the specification, but we fail to see why the
protocol is incomplete. There are clarification and interpretations issues
with all protocol drafts under evaluation. For that matter, there are still
interpretation issues on the CAPWAP taxonomy. For instance, working group
has adopted a work item to clarify the interpretation of the definition of
split versus local MAC behavior.

5.2.1 Multiple Authentication

            The evaluation team provided a "P" in this category.  Not only
does CTP allow different authentication mechanisms per logical group, it
also allows different data paths per logical group.  We fail to see the
reasoning behind receiving a "P" in this category.

The objective states: "The CAPWAP protocol MUST support different
authentication mechanisms   in addition to IEEE 802.11i."

The CTP draft allows the WTP to advertise multiple logical wireless networks
in the capabilities exchange with the AC. The AC can then assign different
authentication policies to each logical group on the WTP as if each logical
group corresponded to a separate MAC on the WTP. There is nothing in the
protocol to prevent the AC from configuring different authentication on each
logical segment of the WTP.

We would request clarification from the evaluation team on why CTP is
partially compliant in addressing this objective.

Thanks

---

Inderpreet Singh

Chief Architect

Chantry Networks Inc., A Siemens Company

[email-masked]

Work: 905-363-6412

Mobile: 416-831-3705