Subject: Re: [Capwap] Consensus check for Issue 138: encryption/decryption atWTP/AC

From: "Dorothy Stanley" <[email-masked]>
Date: Thu, 1 Mar 2007 00:36:16 -0800

All,

As discussed at the interim meeting, option 2 does not provide
interoperability between WTPs and all CAPWAP AC implementations.
A CAPWAP compliant local-encryption only WTP will not work
in a CAPWAP compliant deployment using central encryption.
I prefer option 1, for the following reasons:

- Option 1 supports encryption differentiation at the AC, consistent with
current
implementations, and guarrantees that all CAPWAP compliant WTPs work in any
CAPWAP deployment. This is analagous to, for example, dual-mode cellphones,
which
interoperate with multiple network (AC encryption) types.

- Option 1 WTPs support all 802.11 security guarrantees,
and provide end to end station-to-AC security. Option 2 WTPs do not
support all 802.11 security guarrantees.

- The "cost" of supporting central  encryption in 802.11 chipsets is
extremely minimal and is provided today by many major enterprise AP (WTP)
802.11 chipset manufacturers. To require that the CAPWAP binding protocol be
backwards compatible with every 802.11 chipset ever manufactured, including
those targeted for and
included in station devices only is not reasonable.

- Required 802.11 feature support.  Option 1 enables all required 802.11
features to be supported in a deployment as needed.

Dorothy Stanley

On 2/27/07, Pat Calhoun (pacalhou) <[email-masked]> wrote:
>
> 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,
>         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
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: <[email-masked]>
Date: Thu, 1 Mar 2007 13:33:48 -0600

Dear CAPWAP WG-

We've had only 2 comments on the consensus call for issue 138, and the
consensus check will end today.  This is not enough response to claim
consesus and close the issue before the upcomning draft deadline of
March 5th.  

Is there some confusion on this issue that the group doesn't want to
weigh in on consensus?  Should 138 be removed from the issue DB due to
lack of interest?

This issue will have to remain open and will not be included in the next
draft that is targeted for IEEE review.

Best Regards,

> _____________________________________________ 
> From: 	Gellert Dorothy (Nokia-SIR/MtView)  
> Cc:	ext Mani, Mahalingam (Mani); [email-masked]; Gellert
> Dorothy (Nokia-SIR/MtView)
> Subject:	Consensus check for Issue 138: encryption/decryption at
> WTP/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
> 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
> 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
> week, this issue will remain unresolved in the draft targeted for
> review in IEEE.  
> Best Regards,

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 1 Mar 2007 16:00:46 -0800

I suspect the issue may be that folks don't completely understand the
two options, so let me try to deconstruct the two options.
 
Background: There are two modes of encryption supported in 802.11;
encryption at the WTP (a) and encryption at the AC (b).
 
Option 1:
In this option, the AC MAY support either modes of encryption. The WTP
MUST support support both (a) and (b). In this mode, AC vendors are free
to implement whichever method they prefer, but WTP vendors are forced to
support both.
 
Option 2:
In this option, the WTP and the AC MUST support encryption at the WTP
(a). The WTP and AC MAY support encryption at the AC (b). In this mode,
the WTP and AC vendors can choose to add more options if they feel that
(b) is important to them.
 
I personally believe that option 2 guarantees interoperability, and
minimizes the number of options forced to implement of vendors. In
option 1, a customer could have two ACs side by side, from two
manufacturers, that would work differently (a) and (b). In option 2, the
customer can choose (b) if he deems it important for his deployment
scenario.

Pat Calhoun

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Thursday, March 01, 2007 11:34 AM
	To: [email-masked]; [email-masked]
	Cc: [email-masked]; [email-masked]; Pat Calhoun
(pacalhou); [email-masked]; [email-masked]
	Subject: RE: Consensus check for Issue 138:
encryption/decryption at WTP/AC

	Dear CAPWAP WG- 

	We've had only 2 comments on the consensus call for issue 138,
and the consensus check will end today.  This is not enough response to
claim consesus and close the issue before the upcomning draft deadline
of March 5th.  

	Is there some confusion on this issue that the group doesn't
want to weigh in on consensus?  Should 138 be removed from the issue DB
due to lack of interest?

	This issue will have to remain open and will not be included in
the next draft that is targeted for IEEE review. 

	Best Regards, 

		_____________________________________________ 
		From:   Gellert Dorothy (Nokia-SIR/MtView)  
		Sent:   Friday, February 23, 2007 2:46 PM 
		To:     [email-masked] 
		Cc:     ext Mani, Mahalingam (Mani);
[email-masked]; Gellert Dorothy (Nokia-SIR/MtView) 
		Subject:        Consensus check for Issue 138:
encryption/decryption at WTP/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,

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 1 Mar 2007 17:21:46 -0800

I support option 2.  It is sufficient for interoperability of all ACs
and WTPs.  It also minimizes the additional work required of WTP
vendors, where they are required to implement only one method of
supporting 802.11 encryption, rather than both.

 -Bob

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, 

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.

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,

---

From: "Merwyn Andrade" <[email-masked]>
Date: Thu, 1 Mar 2007 19:11:18 -0800

I support Option 1 for all the reasons Dorothy Stanley already covered. One additional, but very important point. Option 1 (via preservation of centralized encryption support on WTPs) clearly and cost-effectively meets the end-to-end assured channel requirements within the Federal market (as specified in 8100.2) and reduces the burden to FIPS certify existing WTPs and modify them. More details on the directive and what it means to Federal customers below. 

The updated and long awaited DoD 8100.2 directive released June 02, 2006 which opened the floodgate for implementation of COTS (Commercial Off The Shelf) 802.11i technology for use in the Federal market, states
"encryption for unclassified data in transit via WLAN-enabled devices, systems, and technologies must be implemented end-to-end over an assured channel and be validated by NIST as meeting requirements per FIPS 140-2 Overall Level 1 at a minimum. If WLAN infrastructure devices which store keying information are used in public unprotected environments, then those products must meet FIPS 140-2 Overall Level 2".

It is quite clear to budget constrained Federal customers that 802.11i FIPS validated WTPs, that do not handle the un-encrypted tunnel behind the WTP-to-AC do not meet the end-to-end directives. Why you may ask does end-to-end extend to an AC? Prior to WPA2/802.11i, first generation deployment of WLANs entailed deployment of L3 VPNs over untrusted wireless and created a compliance environment where assured-channel encryption traversed from FIPS approved VPN clients all the way to the VPN concentrator (the policy boundary). The wireless and wired network was clearly untrusted. Having to pursue waivers to already granted approvals to their existing policy boundaries by requesting that they be moved down to individual WTPs (for distributed encryption) is an even more painful and expensive endeavor and a non-starter. 

In centralized encryption one end of the end-to-end assured channel is the FIPS 140-2 approved 802.11i client station and the other end of the policy boundary is where the 802.1X/11i key management/authorization functions are carried out. The end-to-end assured channel is the link between the 802.11i station and the AC. This easy replacement of a VPN concentrator with centralized 802.11i encryption gear to meet current mandates and policy boundaries for "end-to-end assured channel" represent the cleanest way of not having to redo one's compliance.

It has been argued that with DTLS support for the data-channel it should be possible to encrypt behind the AP (in distributed encryption modes), and meet the end-to-end assured channel. While possible in theory, this ignores the fact that today's WTPs do not have crypto assist to bulk re-encrypt 802.11i into a DTLS data channel and with 11n bandwidths this is only getting worse. Centralized encryption provides a fighting chance for these WTPs to perform only control-channel encryption and leave data-channel security to the AC while not needing them to be FIPS certified. A double advantage.

Mandating DTLS crypto assist support (to meet the bulk-encryption needs to compete in Federal), both hurts the chances of current generation CAPWAP WTPs as candidates in the Federal market, and increases prices on WTPs via the need for a FIPS-140-2 Level 2 (v/s 1) certification. This is because as per 8100.2 above "If WLAN infrastructure devices which store keying information are used in public unprotected environments, then those products must meet FIPS 140-2 Overall Level 2" (WTPs/APs are typically in hostile user space and not locked in a closet). 

I am not against the distributed encryption model but believe both modes should be available for customers to make an informed choice based on the level of security and the markets they want to pursue.
 
This (need to FIPS certify WTPs, as well as the need to add crypto assist for DTLS to meet assured channel needs), v/s offloading 802.11i encryption to the AC/controller is the better of two burdens to WTP vendors to preserve their ability to mate with CAWPAP compliant centralized encryption vendors and pursue federal markets. In these times of tight war budgets this is an important and far superior security option that we need to preserve for federal customers to allow them to take advantage of COTS gear as we proceed towards an interoperable WTP-AC CAPWAP protocol.

Merv

Merwyn (Merv) Andrade
CTO, Aruba Networks
[email-masked]
________________________________________
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,
Dorothy, Mani and Margaret. 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

From: "Rohit Suri (rsuri)" <[email-masked]>
Date: Fri, 2 Mar 2007 12:09:00 +0530

I support option 2, as it is the simplest path for WTP interoperability.
Currently all WTP chipsets support option 2, while support for option 1
is not clear.
 
Regards
Rohit

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 11:34 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Capwap] Consensus check for Issue 138:
encryption/decryptionat WTP/AC

Dear CAPWAP WG- 

Best Regards, 

	_____________________________________________ 
	From:   Gellert Dorothy (Nokia-SIR/MtView)  
	Sent:   Friday, February 23, 2007 2:46 PM 
	To:     [email-masked] 
	Cc:     ext Mani, Mahalingam (Mani); [email-masked];
Gellert Dorothy (Nokia-SIR/MtView) 
	Subject:        Consensus check for Issue 138:
encryption/decryption at WTP/AC 

	Dear CAPWAP WG, 

	Best Regards,

---

From: Bo Kvarnström (LI/EAB) <[email-masked]>
Date: Fri, 2 Mar 2007 10:49:29 +0100

I support option 1. 
The design impact on the WTP seems feasible and I do believe that this is the only way to ensure full interoperability between WTPs and ACs. 
 
Best Regards
Bo Kvarnstrom

From: [email-masked] [mailto:[email-masked]] 
Sent: den 23 februari 2007 23:46
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Capwap] Consensus check for Issue 138: encryption/decryption atWTP/AC

Dear CAPWAP WG, 

Best Regards,

---

From: "Partha Narasimhan" <[email-masked]>
Date: Fri, 2 Mar 2007 07:35:41 -0800

Option 1 provides a richer solution set and is my choice for what we should go with. 

Having implemented support for both crypto models at a WTP, I can say that the complexity differences between these two options at the WTP are marginal. 

Thanks
partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thu 3/1/2007 11:33 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Dorothy Stanley
Subject: Re: [Capwap] Consensus check for Issue 138: encryption/decryptionat WTP/AC
 
Dear CAPWAP WG- 

We've had only 2 comments on the consensus call for issue 138, and the consensus check will end today.  This is not enough response to claim consesus and close the issue before the upcomning draft deadline of March 5th.  

Is there some confusion on this issue that the group doesn't want to weigh in on consensus?  Should 138 be removed from the issue DB due to lack of interest?

This issue will have to remain open and will not be included in the next draft that is targeted for IEEE review. 

Best Regards, 

	_____________________________________________ 
	From:   Gellert Dorothy (Nokia-SIR/MtView)  
	Sent:   Friday, February 23, 2007 2:46 PM 
	To:     [email-masked] 
	Cc:     ext Mani, Mahalingam (Mani); [email-masked]; Gellert Dorothy (Nokia-SIR/MtView) 
	Subject:        Consensus check for Issue 138: encryption/decryption at WTP/AC 

	Dear CAPWAP WG, 

	Best Regards,