Re: [OPSAWG] Simplified Alternative to CAPWAP

[Behcet Sarikaya <[e-mail]>]

Hi Bjorn,

Thanks for your reply, see my comments inline.



On Wed, Feb 26, 2014 at 9:12 AM, Björn Smedman <
[e-mail]> wrote:

> Hi Behcet,
>
> Thanks for your comments.
>
> On Tue, Feb 25, 2014 at 9:12 PM, Behcet Sarikaya <[e-mail]>
> wrote:
> > On Mon, Feb 24, 2014 at 4:57 PM, Björn Smedman <
> [e-mail]> wrote:
> >> 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.
>
> 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.
>
>
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.


> 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).
>
> >> 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.
>
> 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.
>
>
Yes it is widely used.


> >> 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?
>
> Yes, they're all essentially tunneling protocols for 802.3. What we're
> 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.



> >> 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?
>
> See Geneve draft section 2.1 Control Plane Independence
> (http://tools.ietf.org/html/draft-gross-geneve-00#section-2.1).
>
>
See my comments on Geneve above.


> 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.
>
>
Since Management Plane is different, how do you handle that? I am confused.

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