Re: [OPSAWG] Simplified Alternative to CAPWAP

Hi Bjorn,

On Mon, Feb 24, 2014 at 4:57 PM, Björn Smedman <
bjorn.smedman@anyfinetworks.com> 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
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>