Subject: [Capwap] Consensus check for Issue 138: encryption/decryption at WTP/AC

From: <[email-masked]>
Date: Fri, 23 Feb 2007 16:46:05 -0600

Dear CAPWAP WG,
During the CAPWAP Interim meeting in San Jose last month, we discussed
issue 138: Wireless Encryption/Decryption at the WTP/AC, but did not
achieve clear consensus. This issue has been discussed at length since
IETF 67 in San Diego and on the list over the past few months. 
The chairs would like to close this issue  with WG consensus on one of
the following proposals that have the most WG support:
1) To provide system component interoperability, the WTP MUST support
802.11 encryption/decryption at the WTP, and the WTP MUST support 802.11
encryption/decryption at the AC. The AC MUST support either 802.11
encryption/decryption at the WTP or 802.11 encryption/decryption at the
AC.
The AC MAY support both 802.11 encryption/decryption at the WTP and
802.11 encryption/decryption at the AC.
-OR-
2) To provide system component interoperability, the WTP and AC must
support 802.11 encryption/decryption at the WTP. The WTP and AC MAY
support 802.11 encryption/decryption at the AC. 
Note the 2 proposals differ with support of 802.11 encryption/decryption
at the AC.
As there has been no objections to the optional use of DTLS in the Data
Plane, this portion of issue 138 is closed. 
Please submit your choice and opinions on this topic to the WG list by
March 1st for a final consensus call on this feature.   This is a short
consensus call since the last date to submit drafts for IETF 68 is March
5th.   If we cannot agree to come to consensus in the next week, this
issue will remain unresolved in the draft targeted for review in IEEE.  
Best Regards,
Dorothy, Mani and Margaret.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 27 Feb 2007 08:48:52 -0800

As we discussed during the interim meeting, I do not like option 1
because it places the interoperability burden on the WTP. It requires
that the WTP support both modes of operation, as opposed to simply
making one mandatory and the other optional (which is what option 2
does). Therefore, I prefer option 2 for the following reasons:
- Guaranteed 802.11 chipset compatibility. The first proposal assumes
that the WTP will receive frames from the WTP that failed decryption.
This is because in the first proposal, it does require that the frame be
encrypted over the air, but that the WTP not have the keys required to
decrypt the frame. It is possible, and even likely, that some chipsets
out there simply drop packets that fail decryption, whil the proposal
does require the chip to pass the packet to the CPU. I am concerned that
by selecting option 1, we will rule out vendors that happen to have
chosen the wrong chipset in their WTP.
- Does not impact 802.11 protocol. There are features in 802.11e and
802.11n that will be significantly impacted because of this protocol.
The areas of impact are mostly from a performance standpoint. For
instance, the first proposal requires that packets be encrypted on the
AC, but 802.11n's A-MSDU (packet aggregation feature) requires that
encryption occurs after aggregation. Clearly, buffering packets on the
AC for extended periods of time in order to perform the aggregation
function will increase jitter/latency. The best place to do aggregation
is on the WTP as it is a natural place for buffering to occur due to its
slow link (radio). Packet aggregation is an area that will significant
increase link throughput, and the promise of 802.11n. This is further
complicated by the fact that any performance problems will result in the
custmer calling the WTP vendor, which has no way to resolve this
problem.
- Simplest to implement on WTP. I think that it is in our best interest
to limit the complexity on the WTP, and option 2 certainly does so.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Friday, February 23, 2007 2:46 PM
	To: [email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: [Capwap] Consensus check for Issue 138:
encryption/decryption atWTP/AC

	Dear CAPWAP WG, 
	During the CAPWAP Interim meeting in San Jose last month, we
discussed issue 138: Wireless Encryption/Decryption at the WTP/AC, but
did not achieve clear consensus. This issue has been discussed at length
since IETF 67 in San Diego and on the list over the past few months. 

	The chairs would like to close this issue  with WG consensus on
one of the following proposals that have the most WG support:

	1) To provide system component interoperability, the WTP MUST
support 802.11 encryption/decryption at the WTP, and the WTP MUST
support 802.11 encryption/decryption at the AC. The AC MUST support
either 802.11 encryption/decryption at the WTP or 802.11
encryption/decryption at the AC.

	The AC MAY support both 802.11 encryption/decryption at the WTP
and 802.11 encryption/decryption at the AC. 
	-OR- 
	2) To provide system component interoperability, the WTP and AC
must support 802.11 encryption/decryption at the WTP. The WTP and AC MAY
support 802.11 encryption/decryption at the AC. 

	Note the 2 proposals differ with support of 802.11
encryption/decryption at the AC. 
	As there has been no objections to the optional use of DTLS in
the Data Plane, this portion of issue 138 is closed. 
	Please submit your choice and opinions on this topic to the WG
list by March 1st for a final consensus call on this feature.   This is
a short consensus call since the last date to submit drafts for IETF 68
is March 5th.   If we cannot agree to come to consensus in the next
week, this issue will remain unresolved in the draft targeted for review
in IEEE.  

	Best Regards,