Capwap Mailing List: Re: Consensus check for Issue 138: encryption/decryptionatWTP/AC

[Abhijit Choudhury (abhijit10425]

Please see my comments in-line.

 

Thanks,

Abhijit

 

 

From: Dorothy Stanley [mailto:dstanley1389 [at] gmail.com]
Sent: Thursday, March 01, 2007 12:36 AM
To: Dorothy.Gellert [at] nokia.com
Cc: margaret [at] thingmagic.com; capwap [at] frascone.com
Subject: Re: [Capwap] Consensus check for Issue 138: encryption/decryptionatWTP/AC

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.

[Abhijit] Option 2 will also allow interoperability as central

          encryption mode will be supported at the WTP as an

          optional mode. 

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

[Abhijit] I'm sorry I did not understand this point. If a WTP

          is 802.11i compliant, it will support all 802.11 security

          guarantees. If the issue is one of secure transport, that

          is why DTLS was proposed for the data channel.

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

[Abhijit]  I think it would be nice to have chip-set vendors

           chime in here. It's not clear that this can be 

           easily supported. And if it can, then WTP vendors

           will anyway support the optional mode (centralized encryption),

           so there should be no issue.  We should not be including

           requirements that essentially eliminate a section of the AP

           vendors from being CAPWAP compliant.

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

[Abhijit] Encryption at the AC is restrictive in the sense that

          it prevents deployments from fragmenting and encrypting

          at the WTP which may be needed for some 802.11e modes.

          It also makes it impossible to do aggregation at the WTP

          for 802.11n. Now some AC vendors may choose this mode,

          but forcing ALL WTP vendors to support this seems unnecessary.

          Option 2 allows vendors who want to support this mode, to

          support it as an option. 

Dorothy Stanley

On 2/27/07, Pat Calhoun (pacalhou) <pcalhoun [at] cisco.com> 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: Dorothy.Gellert [at] nokia.com
[mailto:Dorothy.Gellert [at] nokia.com ]
        Sent: Friday, February 23, 2007 2:46 PM
        To: capwap [at] frascone.com
        Cc: margaret [at] thingmagic.com; Dorothy.Gellert [at] nokia.com
        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.

---

Looking for earth-friendly autos? 
 Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.