Subject: Re: [Capwap] Taxonomy doc

From: Shankar Narayanaswamy <[email-masked]>
Date: Wed, 14 Apr 2004 02:55:12 -0700

Lily,

Since the newer version was not distributed before (and the feedback 
deadline was April 12) it is very difficult for someone who is not on 
the design team to contribute: we are chasing a moving target! It would 
be more efficient to freeze the document in between feedback cycles. And 
to change the filename for each draft so we know which one we are 
talking about.

Anyway, my original comment (1) still stands. Section 4.4 (Split MAC) 
states that the reasoning behind the split MAC architecture is scaling. 
But cost reduction in the WTP and security are just as important, if not 
more so. I could even argue the converse: moving functionality away from 
the WTP and centralizing it introduces massive complexity in the AC as 
the system scales, and it is easy to reach a level of complexity in the 
AC that is impractical (from a CPU and I/O processing perspective) with 
just a couple of dozen access points. This would argue for moving 
everything except centralized management into the WTPs.

So my argument is that cost reduction in the WTP and security are the 
real reasons behind the split MAC architecture; their importance 
outweighs the scaling disadvantage.

My original comment (3) also still stands: we have not addressed 
roaming, redundancy and AC/WTP handoff (due to AC failure or 
load-balancing). This is important because it affects the protocol 
between ACs and between AC and WTP. Does anyone else see a need to 
capture this as part of the architecture taxonomy?

Thanks,
Shankar

Yang, Lily L wrote:
> Hi, Shankar --
> 
> It appears that what you are referring to here is an older version of our docemnt. There is a newer version that we are still working on, and this version can be found at 
> http://www.capwap.org/draft-ietf-capwap-arch-01.txt 
> In this newer version, you will see that we do move the encryption/decryption from the real time list to the non-real time list. 
> We also added content to 4.6 security. Please review and if you feel there are more you can add on top of that, please don't hesitate to send to us. We are trying to revise this version by end of tomorrow so that we can provide to IEEE for their review. So early comments would be appreciated.
> 
> Thanks,
> Lily
> 
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On
>>Behalf Of Shankar Narayanaswamy
>>Sent: Monday, April 12, 2004 2:03 AM
>>To: [email-masked]
>>Subject: [Capwap] Taxonomy doc
>>
>>
>>All,
>>
>>Some thoughts:
>>
>>1.  Section 4.2: This section states that the reasoning 
>>behind the Split 
>>MAC architecture is to "offload to the WTP(s) functionality that is 
>>specific and relevant only to the locality of each BSS in 
>>order to allow 
>>the AC to scale to a large number of 'lightweight' WTP devices". The 
>>section also mentions 802.11 encryption/decryption as being a 
>>real-time 
>>service implemented on the WTP.
>>
>>     This is not always true. For example, at Instant802 (and some 
>>others: Symbol, Aruba?) we perform 802.11 
>>encryption/decryption at the 
>>AC rather than the WTP. 802.11 frames in WEP/TKIP/WPA are transported 
>>using a GRE or some other encapsulation between the WTP and the AC.
>>
>>     This is driven by two considerations. The first is cost 
>>reduction 
>>in the WTP. We want it to be as cheap and simple as possible 
>>so taking 
>>out encryption/decryption is useful, especially since this 
>>may otherwise 
>>have to be done twice (decrypt the 802.11 packet, then encrypt the IP 
>>packet to tunnel it to the AC). The second is security. We 
>>want to avoid 
>>any risk from a compromised WTP, and therefore not have user 
>>encryption 
>>keys on the AP at all. Since the entire encrypted 802.11 frame is 
>>carried over the wired LAN between WTP and AC, the user's 
>>security level 
>>(WEP, TKIP, WPA, 802.11i) is preserved.
>>
>>     A side effect of this architecture is that progress in security 
>>protocols and algorithm does not obsolete the WTPs; the ACs implement 
>>the new security schemes instead and the management problem 
>>is therefore 
>>simplified. It can also protect from LAN-side eavesdropping.
>>
>>     This architecture is susceptible to MIM attack in the 
>>sense that a 
>>MIM on the wired LAN could prevent PDUs from getting to their 
>>destinations, but privacy and message integrity are not lost.
>>
>>2.  Section 4.6: This section on security is blank. May I offer the 
>>following prose:
>>
>>    "There are different kinds of traffic passing between the WTP and 
>>the AC, and each one warrants different considerations.
>>
>>    "For user traffic, there are several choices. Some 
>>vendors choose to 
>>encrypt/decrypt user traffic at the WTP and send user data in 
>>the clear 
>>between the WTP and the AC. Other vendors choose to 
>>encrypt/decrypt user 
>>traffic at the WTP and then aggregate this traffic into a single 
>>encrypted tunnel to the AC. Yet others transport the 
>>WEP/TKIP/WPA-encrypted 802.11 MAC PDU between the AC and the WTP, 
>>thereby avoiding user encryption keys being stored at the WTP. The 
>>tradeoffs are between complexity at the AC versus the WTP, 
>>and also in 
>>security versus simplicity in the WTP.
>>
>>    "Most vendors choose to encrypt management traffic 
>>between WTPs and 
>>APs. Most vendors use mutual authentication between WTP and AC to 
>>protect against rogue APs.
>>
>>    "Some vendors support IPSec VPN termination on ACs; this allows 
>>greater security since wireless clients can use an IPSec VPN over the 
>>air and over the wired network, all the way to the AC. Some 
>>vendors use 
>>Access Control Lists (ACLs) at the WTP or the AC to prevent 
>>unauthorized 
>>clients from using the wireless network."
>>
>>3.  I did not see any section on roaming, redundancy, WTP/AC 
>>handoff; do 
>>we need sections on this? If so, I would be happy to write 
>>them. These 
>>are all important issues and some of the taxonomy submissions 
>>do mention 
>>how those vendors approach them.
>>
>>Regards,
>>Shankar
>>-- 
>>Shankar Narayanaswamy, Ph.D.
>>[email-masked]            Mobile: +1 650-387-4593
>>http://www.shankar.org          E-Fax: +1 253-498-8372
>>
>>_______________________________________________
>>Capwap mailing list
>>[email-masked]
>>http://mail.frascone.com/mailman/listinfo/capwap
>>
> 
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap

-- 
Shankar Narayanaswamy, Ph.D.
[email-masked]             Mobile: +1 650-387-4593
http://www.shankar.org          E-Fax: +1 253-498-8372

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 13 Apr 2004 13:41:09 -0700

Hi, Shankar --

Thanks,
Lily