[OPSAWG] Simplified Alternative to CAPWAP

Björn Smedman <bjorn.smedman@anyfinetworks.com> Mon, 24 February 2014 22:57 UTC

Return-Path: <bjorn.smedman@anyfinetworks.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1401A0320 for <opsawg@ietfa.amsl.com>; Mon, 24 Feb 2014 14:57:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.022
X-Spam-Level: *
X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfkoa24uxKm9 for <opsawg@ietfa.amsl.com>; Mon, 24 Feb 2014 14:57:30 -0800 (PST)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 64D401A0313 for <opsawg@ietf.org>; Mon, 24 Feb 2014 14:57:30 -0800 (PST)
Received: by mail-oa0-f44.google.com with SMTP id m1so2028940oag.17 for <opsawg@ietf.org>; Mon, 24 Feb 2014 14:57:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=0ddcq5A2+jJWqnaNSpo1Jez+01ZjZ/PVdy0P3/JOwGo=; b=VRln3RhckF+ldcPlFeSEjAwS6PdM7kxPfke8hodAya70/UFSrhA1EjTMEGuwaQJFRy awdq1OHsCt6TQLTnYSP4r925SbIulKEBRSxjqjhb4zs1dfNyRwEfe7vrPcp2Z+xcex+j O3SgRrT0JbeyQvdQHIBdvv4w2+juoKJ7SzkYxAA0LrhrquaKdxxcBwrUJT91gLynVnnr HX22h0GZbsGoE3rDmP+7ZfS7ddU/6mYFd8VA6g5im4KmmDbX4R1ykTgTMYzilmOSC1bF kMIeTDio9J+XvnCQndW3FctYagltpBlr8zEeBBCL4qlOtEhtIvblDF27ZL9cgJ6DnSbW T3ug==
X-Gm-Message-State: ALoCoQnZnhicrA+CA1sibapwGsHiYF3NPERh4hTcKPw4PUnkl6feNy7eAAGcRS06IF/eqQUKvMUH
MIME-Version: 1.0
X-Received: by 10.182.28.7 with SMTP id x7mr19831191obg.43.1393282649550; Mon, 24 Feb 2014 14:57:29 -0800 (PST)
Received: by 10.182.191.9 with HTTP; Mon, 24 Feb 2014 14:57:29 -0800 (PST)
X-Originating-IP: [82.99.7.230]
Date: Mon, 24 Feb 2014 23:57:29 +0100
Message-ID: <CAO_acptCXNzu09qH1sxig+qbjJXX0KMUmbA35LOo6KoRrG8vPg@mail.gmail.com>
From: =?UTF-8?Q?Bj=C3=B6rn_Smedman?= <bjorn.smedman@anyfinetworks.com>
To: opsawg@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/h84_wkfBluC719zf_vyrP3sq2-w
Subject: [OPSAWG] Simplified Alternative to CAPWAP
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 22:57:32 -0000

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