Re: [OPSAWG] Simplified Alternative to CAPWAP

[Björn Smedman <[e-mail]>]

Hi Rajesh,

On Tue, Feb 25, 2014 at 7:29 AM, Rajesh Pazhyannur (rpazhyan)
<[e-mail]> wrote:
> > Yes, if piecewise security is sufficient then there are a multitude of IETF
> > protocols to chose from. But if end-to-end 802.11 encryption all the way
> > from the mobile STA to a trusted location (e.g. a service/access router in
> > the network core) is desired then there is nothing in the IETF playbook
> > except a border case of CAPWAP, which comes with an entangled control and
> > provisioning/management plane.
>
> Okay, I understand the problem statement much better.
> Can you explain the part about “entangled control”.  Is this because in the
> existing CAPWAP model, 802.1X is always handled by the AC (even if the data
> channel is tunneled to another AR) and you want 802.1X to be handled by the
> Tunnel Termination Gateway.

Yes, my thinking is that 802.1X and (other) 802.11 data should ideally
terminate in the same location - essentially because in the case I
care most dearly about the 802.11 data frames are encrypted with the
802.11 key derived as part of the 802.1X authentication. To me it just
makes sense that encryption and authentication terminate in the same
place, so that the entity that gets my clear-text data is the entity
that I have actually authenticated. But there's of course also a
practical issue: if encrypted 802.11 frames end up in the AR but
802.11 key is in the AC... well you get the point.

But what I meant with my comment above was more about how CAPWAP
bundles everything into a single protocol, so if I want to use CAPWAP
for tunneling between WTP and AC/AR/whatever then I also have to
consider what my WTP will do if it receives the CAPWAP firmware update
command... Imagine if IPSEC, L2oGRE and Geneve all came with a
firmware update command and there was no alternative... That's what I
mean with "entangled control and provisioning/management": there's no
clean tunneling protocol for 802.11 that does only that - so we've had
to implement our own [1].

Best regards,

Björn

1. http://anyfi.net/documentation#a_data_plane

> -----Original Message-----
> From: Björn Smedman [mailto:[e-mail]]
> Sent: Monday, February 24, 2014 5:54 PM
> To: Rajesh Pazhyannur (rpazhyan)
> Cc: [e-mail]
> Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP
>
> Hi Rajesh,
>
> On Tue, Feb 25, 2014 at 1:29 AM, Rajesh Pazhyannur (rpazhyan)
> <[e-mail]> wrote:
>>
>> Thanks for the well captured email.  Would like to explore more about
>> what you are suggesting.
>
> Thanks, it's much appreciated.
>
>> 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.
>
> True, in CAPWAP it's a border case that 802.1X key exchange and 802.11
> encryption protects the user data plane all the way from the mobile STA to
> the AC. But I think there are strong reasons to make this the
> default:
>
> * DTLS cannot protect the user data plane inside the WTP. If 802.11
> encryption keys and clear-text user data is available inside the WTP and the
> WTP is not physically protected then (at least from a theoretical
> perspective) the integrity and confidentiality of the data plane cannot be
> trusted.
>
> * DTLS encryption is also wasteful: encrypted 802.11 data frames come in
> over the air, are unencrypted in the WTP and then encrypted again with DTLS.
>
> * DTLS also provides authentication, but to me it makes little sense to
> authenticate an untrusted party. If the WTP can be under the physical
> control of an attacker, then there is no point in authenticating it against
> a digital certificate stored in the WTP.
>
> IMHO encrypting the CAPWAP-Data channel with DTLS and authenticating the WTP
> is borderline "security by obscurity" in that it relies on an attacker not
> being able to gain access to WTP memory. This assumption may have been
> relatively true in the corporate WLAN environment that CAPWAP was designed
> for, but it's less and less true for carrier Wi-Fi deployments.
>
> When on the other hand the 802.11 encryption is relied upon to protect the
> user data plane the WTP is simply excluded from the security
> equation: Even an attacker in complete control of the WTP is no threat to
> the integrity or confidentiality of the user data plane (since they have
> access to nothing more than the encrypted 802.11 frames which are also
> available from the air). That also means there's no real need to
> authenticate the WTP, and the security model is greatly simplified.
>
>> > 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.
>
> Yes, if piecewise security is sufficient then there are a multitude of IETF
> protocols to chose from. But if end-to-end 802.11 encryption all the way
> from the mobile STA to a trusted location (e.g. a service/access router in
> the network core) is desired then there is nothing in the IETF playbook
> except a border case of CAPWAP, which comes with an entangled control and
> provisioning/management plane.
>
> Best regards,
>
> Björn
>
>> -----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]
>> https://www.ietf.org/mailman/listinfo/opsawg
>>
>