RE: [Capwap] comment about LWAPP and other wireless = technologies

Hi Dan,
 =
;
Sorry for =
the terse answer, but we will address this in detail in the coming evalua=
tion draft.  We can discuss it after the draft comes out.  Than=
ks for the patience!
 =
;
-Darren
 =
;
[… D=
an Harkins dharkins@trpz.com  wrote …]
Hi,
 =
;
  The=
 evaluation team came up with Ps for SLAPP compliance in two
areas in w=
hich the SLAPP self-evaluation came up with Cs. I'm
curious if=
 the evaluation team could explain how SLAPP did not
fully comp=
ly with:
 =
;
 &nbs=
p;  5.1.7 Resource Control
 &nbs=
p;  5.1.12 Protocol Specification
I think I =
understand why 5.1.5 Firmware Trigger was given a P and=

the SLAPP =
self-evaluation gave it a P as well.
<=
font
size=3D2 face=3D"Courier New"> =
;
  tha=
nks,
 =
;
  Dan=
=2E
4.1.2  Draft Standard
 =
;
 &nbs=
p; A specification from which at least two independent and interoperable<=
o:p>
 &nbs=
p; implementations from different code bases have been developed, and
 &nbs=
p; for which sufficient successful operational experience has been
 &nbs=
p; obtained, may be elevated to the "Draft Standard" level.&nbs=
p; For the
 &nbs=
p; purposes of this section, "interoperable" means to be functi=
onally
 &nbs=
p; equivalent or interchangeable components of the system or process in
 &nbs=
p; which they are used.  If patented or otherwise controlled technol=
ogy
 &nbs=
p; is required for implementation, the separate implementations must=

 &nbs=
p; also have resulted from separate exercise of the licensing process.
 &nbs=
p; Elevation to Draft Standard is a major advance in status, indicating
 &nbs=
p; a strong belief that the specification is mature and will be useful.
 =
;
 &nbs=
p; The requirement for at least two independent and interoperable
 &nbs=
p; implementations applies to all of the options and features of the=

 &nbs=
p; specification.  In cases in which one or more options or features=

 &nbs=
p; have not been demonstrated in at least two interoperable
 &nbs=
p; implementations, the specification may advance to the Draft Standard
 &nbs=
p; level only if those options or features are removed.=

 =
;
 &nbs=
p; The Working Group chair is responsible for documenting the specific
 &nbs=
p; implementations which qualify the specification for Draft or Internet<=
o:p>
 &nbs=
p; Standard status along with documentation about testing of the
 &nbs=
p; interoperation of these implementations.  The documentation must<=
o:p>
 &nbs=
p; include information about the support of each of the individual
 &nbs=
p; options and features.  This documentation should be submitted to =
the
 &nbs=
p; Area Director with the protocol action request. (see Section 6)
 =
;
4.1.2  Draft =
Standard

   A =
specification from which at least two independent and =
interoperable
   =
implementations from different code bases have been developed, =
and
   for which =
sufficient successful operational experience has =
been
   obtained, may be =
elevated to the "Draft Standard" level.  For =
the
   purposes of this =
section, "interoperable" means to be =
functionally
   equivalent or =
interchangeable components of the system or process =
in
   which they are =
used.  If patented or otherwise controlled =
technology
   is required for =
implementation, the separate implementations =
must
   also have resulted =
from separate exercise of the licensing =
process.
   Elevation to Draft =
Standard is a major advance in status, =
indicating
   a strong belief =
that the specification is mature and will be =
useful.

   The =
requirement for at least two independent and =
interoperable
   =
implementations applies to all of the options and features of =
the
   =
specification.  In cases in which one or more options or =
features
   have not been =
demonstrated in at least two =
interoperable
   =
implementations, the specification may advance to the Draft =
Standard
   level only if =
those options or features are =
removed.

   The Working =
Group chair is responsible for documenting the =
specific
   implementations =
which qualify the specification for Draft or =
Internet
   Standard status =
along with documentation about testing of =
the
   interoperation of =
these implementations.  The documentation =
must
   include =
information about the support of each of the =
individual
   options and =
features.  This documentation should be submitted to =
the
   Area Director with =
the protocol action request. (see Section =
6)

       =
;        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.  

  &nb=
sp;            =
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.  =

  &nb=
sp;            =
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.

  &nb=
sp;            =
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        &nbs=
p;       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.  

4.1.2  Draft =
Standard

   A specification from which at =
least two independent and interoperable
   implementations from different =
code bases have been developed, and
   for which sufficient successful =
operational experience has been
   obtained, may be elevated to the =
"Draft Standard" level.  For the
   purposes of this section, =
"interoperable" means to be =
functionally
   equivalent or interchangeable =
components of the system or process in
   which they are used.  If =
patented or otherwise controlled technology
   is required for implementation, =
the separate implementations must
   also have resulted from separate =
exercise of the licensing process.
   Elevation to Draft Standard is a =
major advance in status, indicating
   a strong belief that the =
specification is mature and will be useful.

   The requirement for at least two =
independent and interoperable
   implementations applies to all =
of the options and features of the
   specification.  In cases in =
which one or more options or features
   have not been demonstrated in at =
least two interoperable
   implementations, the =
specification may advance to the Draft Standard
   level only if those options or =
features are removed.

   The Working Group chair is =
responsible for documenting the specific
   implementations which qualify =
the specification for Draft or Internet
   Standard status along with =
documentation about testing of the
   interoperation of these =
implementations.  The documentation must
   include information about the =
support of each of the individual
   options and features.  This =
documentation should be submitted to the
   Area Director with the protocol =
action request. (see Section 6)

4.1.2  Draft Standard

   A specification from which at lea=
st two independent and interoperable
   implementations from different co=
de bases have been developed, and
   for which sufficient successful o=
perational experience has been
   obtained, may be elevated to the =
"Draft Standard" level.  For the<=
/pre>   purposes of this section, "i=
nteroperable" means to be functionally   equivalent or interchangeable com=
ponents of the system or process in
   which they are used.  If pat=
ented or otherwise controlled technology
   is required for implementation, t=
he separate implementations must
   also have resulted from separate =
exercise of the licensing process.
   Elevation to Draft Standard is a =
major advance in status, indicating
   a strong belief that the specific=
ation is mature and will be useful.

   The requirement for at least two =
independent and interoperable
   implementations applies to all of=
 the options and features of the
   specification.  In cases in =
which one or more options or features
   have not been demonstrated in at =
least two interoperable
   implementations, the specificatio=
n may advance to the Draft Standard
   level only if those options or fe=
atures are removed.

   The Working Group chair is respon=
sible for documenting the specific
   implementations which qualify the=
 specification for Draft or Internet
   Standard status along with docume=
ntation about testing of the
   interoperation of these implement=
ations.  The documentation must
   include information about the sup=
port of each of the individual
   options and features.  This =
documentation should be submitted to the
   Area Director with the protocol a=
ction request. (see Section 6)

Darren,

Thanks =
for the info. Just took a quick look at the Airespace's Statement about =
IPR and found a statement below: =

“Airespace hereby covenants that it =
will not assert any patent
claims =
contained in any of the above-identified pending =
patent
applications (if and when issued as a Patent) =
against any party that
makes, =
uses, sells, imports, or offers for sale, an implementation =
of
the LWAPP =
protocol as specified in the Specification, assuming it =
is
adopted.”
4.1.2  Draft =
Standard

   A specification from which at =
least two independent and =
interoperable
   implementations from different =
code bases have been developed, and
   for which sufficient successful =
operational experience has been
   obtained, may be elevated to the =
"Draft Standard" level.  For =
the
   purposes of this section, =
"interoperable" means to be =
functionally
   equivalent or interchangeable =
components of the system or process =
in
   which they are used.  If =
patented or otherwise controlled =
technology
   is required for implementation, =
the separate implementations must
   also have resulted from separate =
exercise of the licensing process.
   Elevation to Draft Standard is a =
major advance in status, indicating
   a strong belief that the =
specification is mature and will be =
useful.

   The requirement for at least two =
independent and interoperable
   implementations applies to all =
of the options and features of the
   specification.  In cases in =
which one or more options or features
   have not been demonstrated in at =
least two interoperable
   implementations, the =
specification may advance to the Draft =
Standard
   level only if those options or =
features are removed.

   The Working Group chair is =
responsible for documenting the =
specific
   implementations which qualify =
the specification for Draft or =
Internet
   Standard status along with =
documentation about testing of the
   interoperation of these =
implementations.  The documentation =
must
   include information about the =
support of each of the individual
   options and features.  This =
documentation should be submitted to =
the
   Area Director with the protocol =
action request. (see Section 6)

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<= /font>