Subject: [OPSAWG] Simplified Alternative to CAPWAP

From: Björn Smedman <[email-masked]>
Date: Mon, 24 Feb 2014 23:57:29 +0100

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

---

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Tue, 25 Feb 2014 00:29:04 +0000

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:[email-masked]] On Behalf Of Björn Smedman
Sent: Monday, February 24, 2014 2:57 PM
To: [email-masked]
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

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Björn Smedman <[email-masked]>
Date: Tue, 25 Feb 2014 02:53:45 +0100

Hi Rajesh,

> Thanks for the well captured email.  Would like to explore more about what

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

> 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
> 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.
>
> 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.
>
>
> [email-masked]

---

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Tue, 25 Feb 2014 06:29:35 +0000

Hello Bjorn

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

Regards

Rajesh
-----Original Message-----
From: Björn Smedman [mailto:[email-masked]]
Sent: Monday, February 24, 2014 5:54 PM
To: Rajesh Pazhyannur (rpazhyan)
Cc: [email-masked]
Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP

Hi Rajesh,

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

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

> To: [email-masked]<mailto:[email-masked]>
> conflating everything from firmware updates to configuration of an extra SSID.
>
> (encryption keys end up in a different place than the encrypted data!).
>
> impossible to reason about the security of the system. This is less than ideal IMHO.
>
> encryption all implemented at the tunnel termination point for security reasons.
>
> provisioning/management functionality, instead relying on SNMP, NETCONF/YANG, TR-069 and similar.
>

---

From: "Cao,Zhen" <[email-masked]>
Date: Tue, 25 Feb 2014 16:27:24 +0800

Hello, Bjorn,

Appreciate your analysis.

> STA to the AC. But I think there are strong reasons to make this the

But I do not agree here. The 802.11 key only protect the data from STA
to WTP, NOT the AC, both in local MAC and also one option in the split
model.  http://tools.ietf.org/html/rfc5416#section-2.2.2

-Zhen

---

From: Björn Smedman <[email-masked]>
Date: Tue, 25 Feb 2014 14:22:36 +0100

Hi Zhen,

> Appreciate your analysis.

Thanks, likewise.

> model.  http://tools.ietf.org/html/rfc5416#section-2.2.2

I share your understanding that in the CAPWAP Local MAC mode, and most
implementations of Split MAC, the 802.11 key only protects user data
between STA and WTP. But what I'm saying is that this is unfortunate.

In the corporate WLAN environment for which CAPWAP was originally
designed there is an assumption that WTPs and the Distribution System
(DS) are physically protected, by doors, badges and security
personnel. If somebody gets through those protections and can access
the WTP or DS then there are other things to worry about.

But in a carrier Wi-Fi environment this assumption no-longer holds
true. WTPs are installed in coffee shops, restaurants, stadiums and
even fixed-line subscriber homes (as a "second SSID" on a residential
gateway). There is ample opportunity for an attacker to go to work on
a WTP, perhaps even in the privacy of their own home.

If a single one of those WTPs is compromised (and CAPWAP mode is Local
MAC or Split MAC with encryption in WTP) then there is no-longer any
guarantee of user plane integrity or confidentiality for users of that
WTP. But perhaps more alarmingly there is now also a gaping hole in
the mutual authentication property of IEEE 802.11i, which means that
all users of the wireless network are opened up to possible
man-in-the-middle (MITM) attack [1]. If you combine this fact with
automatic SIM authentication and global roaming the potential impact
is significant.

This is the reason we insist on always implementing both 802.11
encryption and 802.1X authentication at the tunnel termination point
(e.g. an access router) in our SDWN architecture [2]. Unlike the WTP
the tunnel termination point can often be physically protected. This
provides strong guarantees of user data plane integrity and
confidentiality, and also protects the mutual authentication property
of the underlying IEEE 802.11i security mechanism.

Best regards,

Björn

1. This risk of MITM in a "secure" Wi-Fi network may not be entirely
obvious. We explain this risk when an attacker has access to
authentication credentials/interface here:
http://anyfi.net/documentation#i_mutual_authentication. The same
reasoning however holds true if the attacker can forward IEEE 802.11
frames between a targeted device and a CAPWAP AC, and get the 802.11
key from that AC (as in
http://tools.ietf.org/html/rfc5416#section-6.15).

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

---

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Tue, 25 Feb 2014 17:18:17 +0000

This is the reason we insist on always implementing both 802.11 encryption and 802.1X authentication at the tunnel termination point (e.g. an access router) in our SDWN architecture [2]. Unlike the WTP the tunnel termination point can often be physically protected. This provides strong guarantees of user data plane integrity and confidentiality, and also protects the mutual authentication property of the underlying IEEE 802.11i security mechanism.

>  I think I understand the problem even better now :) . It appears that the draft Alternate Tunnel Encapsulation for Data Frames in CAPWAP", http://datatracker.ietf.org/doc/draft-zhang-opsawg-capwap-cds/  would meet the requirement to tunnel data traffic to different tunnel end point. You would set the MAC mode to split mac and tunnel mode to 802.11. The only missing piece would be to specify the that 802.11 frame encryption should happen at the tunnel termination point and not the WTP.  There is no current way to negotiate that. Note that we are solving a similar problem (in the context where AC is the tunnel termination point) http://tools.ietf.org/html/draft-ietf-opsawg-capwap-hybridmac-02.
So potentially a new split MAC profile in the case the tunnel termination is not at the AC.

-----Original Message-----
From: Björn Smedman [mailto:[email-masked]]
Sent: Tuesday, February 25, 2014 5:23 AM
To: Cao,Zhen
Cc: Rajesh Pazhyannur (rpazhyan); [email-masked]
Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP

Hi Zhen,

Thanks, likewise.

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

I share your understanding that in the CAPWAP Local MAC mode, and most implementations of Split MAC, the 802.11 key only protects user data between STA and WTP. But what I'm saying is that this is unfortunate.

In the corporate WLAN environment for which CAPWAP was originally designed there is an assumption that WTPs and the Distribution System
(DS) are physically protected, by doors, badges and security personnel. If somebody gets through those protections and can access the WTP or DS then there are other things to worry about.

But in a carrier Wi-Fi environment this assumption no-longer holds true. WTPs are installed in coffee shops, restaurants, stadiums and even fixed-line subscriber homes (as a "second SSID" on a residential gateway). There is ample opportunity for an attacker to go to work on a WTP, perhaps even in the privacy of their own home.

If a single one of those WTPs is compromised (and CAPWAP mode is Local MAC or Split MAC with encryption in WTP) then there is no-longer any guarantee of user plane integrity or confidentiality for users of that WTP. But perhaps more alarmingly there is now also a gaping hole in the mutual authentication property of IEEE 802.11i, which means that all users of the wireless network are opened up to possible man-in-the-middle (MITM) attack [1]. If you combine this fact with automatic SIM authentication and global roaming the potential impact is significant.

This is the reason we insist on always implementing both 802.11 encryption and 802.1X authentication at the tunnel termination point (e.g. an access router) in our SDWN architecture [2]. Unlike the WTP the tunnel termination point can often be physically protected. This provides strong guarantees of user data plane integrity and confidentiality, and also protects the mutual authentication property of the underlying IEEE 802.11i security mechanism.

Best regards,

Björn

1. This risk of MITM in a "secure" Wi-Fi network may not be entirely obvious. We explain this risk when an attacker has access to authentication credentials/interface here:
http://anyfi.net/documentation#i_mutual_authentication. The same reasoning however holds true if the attacker can forward IEEE 802.11 frames between a targeted device and a CAPWAP AC, and get the 802.11 key from that AC (as in http://tools.ietf.org/html/rfc5416#section-6.15).

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 25 Feb 2014 14:12:45 -0600

Hi Bjorn,

> (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.

> NETCONF/YANG, as well as other established management protocols such
This is good point I think. But TR-069 is not ready for prime time yet.

> for IEEE 802.11 similar to Geneve [3], avoiding the above problems:
Geneve seems to be derived from VXLAN or NVGRE.
Is this correct?

> Software-Defined Networking (SDN) protocols for IEEE 802.11.
Any pointers on this?

Regards,

Behcet

---

From: Björn Smedman <[email-masked]>
Date: Tue, 25 Feb 2014 21:26:08 +0100

Hi Rajesh,

On Tue, Feb 25, 2014 at 7:29 AM, Rajesh Pazhyannur (rpazhyan)
<[email-masked]> 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.
>
> 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

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

---

From: Björn Smedman <[email-masked]>
Date: Wed, 26 Feb 2014 16:12:50 +0100

Hi Behcet,

Thanks for your comments.

On Tue, Feb 25, 2014 at 9:12 PM, Behcet Sarikaya <[email-masked]> wrote:
> On Mon, Feb 24, 2014 at 4:57 PM, Björn Smedman <[email-masked]> wrote:

Our architecture is compliant with the IEEE 802.11 standard as-is, so
we've seen little reason to get involved with the IEEE so far.

The work within 802.16 seems more focused on 802.3 SDN. Ours is an
overlay architecture based on tunneling 802.11 over IP (using our
implementation of the here proposed protocol). Think Contrail meets
the here proposed tunneling protocol and has a baby. ;)

Long term we think the same split that you have for 802.3 SDN would
make sense: IETF standards track for the data plane tunneling protocol
(Geneve equivalent), separate standardization process for the control
plane (OpenFlow / Open Networking Foundation equivalent).

> This is good point I think. But TR-069 is not ready for prime time yet.

With all its shortcomings it's still widely deployed for managing
residential gateways (fixed-line braodband CPE). We come across it a
great deal in the field.

> Geneve seems to be derived from VXLAN or NVGRE.

Yes, they're all essentially tunneling protocols for 802.3. What we're
proposing is an IETF standard tunneling protocol for 802.11.

>> Software-Defined Networking (SDN) protocols for IEEE 802.11.

See Geneve draft section 2.1 Control Plane Independence
(http://tools.ietf.org/html/draft-gross-geneve-00#section-2.1).

There's no explicit mention of "Management Plane Independence", e.g.
for firmware updates and similar, but I'd say it's just an implicit
requirement on a tunneling protocol, taken for granted.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 26 Feb 2014 14:56:01 -0600

Hi Bjorn,

Thanks for your reply, see my comments inline.

> we've seen little reason to get involved with the IEEE so far.
IEEE has SDN BoFs during face to face meetings to bring together all people
interested in SDN, so 802.11 people also attend these meetings.

> residential gateways (fixed-line braodband CPE). We come across it a
Yes it is widely used.

> proposing is an IETF standard tunneling protocol for 802.11.
I checked the Geneve draft. Sorry but I could not see much difference
between Geneve and VXLAN. In Geneve you have Variable Length Options but
that could be added to VXLAN easily.
So I don't understand your argument that Geneve (by the way I like the name
in French :-) ) is for 802.11 and VXLAN is for 802.3?

VXLAN is becoming an RFC, you have all the reasons to use it, rather than
reinventing the wheel.

I am also having trouble in how Geneve will be used? The way I understand
from you is it is going to be used between AP and AC as a tunneling
protocol instead of CAPWAP tunnel.
Then why does an AP need a VNI?
I think you are envisioning a virtualized AP in a VM? Then it makes sense.

> (http://tools.ietf.org/html/draft-gross-geneve-00#section-2.1).
See my comments on Geneve above.

> requirement on a tunneling protocol, taken for granted.
Since Management Plane is different, how do you handle that? I am confused.

 Regards,

Behcet