Re: [OPSAWG] Simplified Alternative to CAPWAP

Behcet Sarikaya <sarikaya2012@gmail.com> Tue, 25 February 2014 20:12 UTC

Return-Path: <sarikaya2012@gmail.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 30D9D1A082A for <opsawg@ietfa.amsl.com>; Tue, 25 Feb 2014 12:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level:
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 DNB1-p03g9RO for <opsawg@ietfa.amsl.com>; Tue, 25 Feb 2014 12:12:48 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 854BC1A082D for <opsawg@ietf.org>; Tue, 25 Feb 2014 12:12:47 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id l4so3605120lbv.24 for <opsawg@ietf.org>; Tue, 25 Feb 2014 12:12:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lNNRrVgXR58damVRHgi4uvrhTQ3O1hoth6u4lTY6r6k=; b=O2prDes1Wzh610cbm7/h7CF/K5BaHfXIsIO3CeAaSgbXlWFswfdVFfpXWKUt3cszhx LV/5oFNrSuKJvtR0XTGObJYVyXQtPS9n5yJHQ1KHaDKROWEFOORZ4mQPOo+42y5GDB+J wYtQ2BJ9M9wfrRhbCxWF3oM2+W/3vw/SbKIptQi0yhV/wATvH5GHkM25jxAlchkk+Agh Ku3Lcvg4BLOewiaEWVl3V0XyaBnhGfsYV0J5+t2ZZ2lxnVVC4bYFtlZvKW8AVRPoXEdE 2PMS4vHDMgMZzItRYKdmIzwfrXO/2hFubU9PuqR56vw1tjWalG7E50p+HR61YhpXdYYt cfPg==
MIME-Version: 1.0
X-Received: by 10.112.63.193 with SMTP id i1mr895925lbs.54.1393359165748; Tue, 25 Feb 2014 12:12:45 -0800 (PST)
Received: by 10.114.176.234 with HTTP; Tue, 25 Feb 2014 12:12:45 -0800 (PST)
In-Reply-To: <CAO_acptCXNzu09qH1sxig+qbjJXX0KMUmbA35LOo6KoRrG8vPg@mail.gmail.com>
References: <CAO_acptCXNzu09qH1sxig+qbjJXX0KMUmbA35LOo6KoRrG8vPg@mail.gmail.com>
Date: Tue, 25 Feb 2014 14:12:45 -0600
Message-ID: <CAC8QAcdVfZCPC613rbYe=Y3rky_wSMvh_hEgrEpdQbgZ-ipTjg@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: =?ISO-8859-1?Q?Bj=F6rn_Smedman?= <bjorn.smedman@anyfinetworks.com>
Content-Type: multipart/alternative; boundary=001a11c3fd101e9e3904f340b6e0
Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/X4tSyeKP_pO4Qz6fpynLBGVX4_o
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] Simplified Alternative to CAPWAP
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: sarikaya@ieee.org
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: Tue, 25 Feb 2014 20:12:51 -0000

Hi Bjorn,




On Mon, Feb 24, 2014 at 4:57 PM, Björn Smedman <
bjorn.smedman@anyfinetworks.com> wrote:

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



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



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



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

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
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>