Hi Bjorn,
On Mon, Feb 24, 2014 at 4:57 PM, Björn Smedman < [email protected]> wrote: > Dear all, > > I've been following the recent CAPWAP activity on this list and > thought I should share some general thoughts on the protocol, and see > if there's interest in a broader approach. > > The CAPWAP shortcomings discussed are similar to the problems > preventing us [1] from using it in our Software-Defined Networking > (SDN) architecture for IEEE 802.11 [2]: > > Where in IEEE 802.11 is this happening? Your link [2] is pointing to your company's evaluation system. As far as I know, in IEEE 802, SDN work is being pursued in 802.16. > 1. CAPWAP was specified before separation of data, control and > management planes became the norm in networking architecture. > Unsurprisingly it provides very little separation of concern, > conflating everything from firmware updates to configuration of an > extra SSID. > > 2. CAPWAP attempts to provide provisioning/management functionality > that overlaps with other IETF standards track protocols, e.g. SNMP and > NETCONF/YANG, as well as other established management protocols such > as TR-069. > > This is good point I think. But TR-069 is not ready for prime time yet. > 3. The separation of data and control planes that CAPWAP does provide > is IMHO incorrect: 802.1X key exchange is considered part of the > control plane but the derived encryption keys protect the data plane. > This doesn't matter when both control and data plane terminate in the > same location (the AC), but becomes a problem when they are separated > (encryption keys end up in a different place than the encrypted > data!). > > 4. CAPWAP leaves many options open to the implementer and is therefore > less interoperable than desired. To some extent this can be solved > with run-time negotiation, but such negotiation of security critical > aspects (such as where encryption keys are derived and kept) makes it > impossible to reason about the security of the system. This is less > than ideal IMHO. > > 5. CAPWAP (partly due to 1 and 2 above) depends excessively on details > in the IEEE 802.11 standard, with each amendment threatening to impact > the protocol. > > > We would be interested in specifying a simplified tunneling protocol > for IEEE 802.11 similar to Geneve [3], avoiding the above problems: > > Geneve seems to be derived from VXLAN or NVGRE. Is this correct? > A. The protocol should mandate a single well-defined partitioning of > the IEEE 802.11 stack, with 802.1X authentication, key management and > encryption all implemented at the tunnel termination point for > security reasons. > > B. The protocol should mandate a single well-defined frame format > relying only on a PHY-independent stable subset of IEEE 802.11, > ensuring compatibility with 11n/ac and (most likely) beyond. > > C. Like Geneve the protocol should not provide any > provisioning/management functionality, instead relying on SNMP, > NETCONF/YANG, TR-069 and similar. > > D. Like Geneve the protocol should not provide any control plane > functionality, instead remaining compatible with several > Software-Defined Networking (SDN) protocols for IEEE 802.11. > > Any pointers on this? Regards, Behcet > E. Each virtual access point in a multi-BSSID (and/or multi-radio) > access point should be treated as a separate entity associated with a > separate tunnel. > > > We see strong benefits to such a protocol from an extensibility [4], > flexibility [5] and security [6] perspective. If there is interest in > exploring this further please let me know. > > Best regards, > > Björn Smedman > > 1. http://www.anyfinetworks.com > > 2. http://anyfi.net and http://www.anyfinetworks.com/products > > 3. http://tools.ietf.org/html/draft-gross-geneve-00 > > 4. http://anyfi.net/documentation#architecture > > 5. http://anyfi.net/documentation#a_how_it_all_fits_together > > 6. http://anyfi.net/documentation#i_security_model > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
