Re: [OPSAWG] Simplified Alternative to CAPWAP

["Rajesh Pazhyannur (rpazhyan)" <[e-mail]>]

Hello Bjorn

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

Thanks for the well captured email.  Would like to explore more about what you are suggesting.
I have not read the details provided in your link.

In the meanwhile,

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

>        Technically speaking, 802.1X protects the 802.11 frames and does not have anything to do CAPWAP Data channel. The Data channel is protected using DTLS. It is conceivable that 1) the tunnel mode is encapsulating 802.11 frames (instead of 802.3 frames) and 2) CAPWAP-Data is not encrypted and 3) 802.11 encryption is happening at the AC instead of AP. When all three conditions hold,  what you are saying is true: 802.1X is indeed protecting the data plane.

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.

>  Yes, it is true, that wireless binding (RFC 5416) of CAPWAP are dependent on 802.11 and needs updates with 11n, 11ac and so on. But in some sense it appears that the problem does not go away. You are simply pushing the problem to SNMP or TR-69 or something like that.  We can debate whether those are better than CAPWAP in configuring a WI-FI AP.

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.

>       By this I am assuming that you want encryption at the Tunnel termination point rather than the AP.  What is motivating this, given that all APs (that I know of) implement 802.11 encryption and if security is needed between AP and Tunnel termination point then one could use IPSEC or DTLS.

Regards

Rajesh

-----Original Message-----
From: OPSAWG [mailto:[e-mail]] On Behalf Of Björn Smedman
Sent: Monday, February 24, 2014 2:57 PM
To: [e-mail]
Subject: [OPSAWG] Simplified Alternative to CAPWAP

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]:

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.

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:

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.

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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/opsawg