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

From: Abhijit Choudhury <[email-masked]>
Date: Thu, 1 Mar 2007 17:58:55 -0800 (PST)

Please see my comments in-line.
   
  Thanks,
  Abhijit

  From: Dorothy Stanley [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 12:36 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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) <[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.

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

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

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