Re: [OPSAWG] Simplified Alternative to CAPWAP

Björn Smedman <bjorn.smedman@anyfinetworks.com> Wed, 26 February 2014 15:12 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 0AC731A042B for <opsawg@ietfa.amsl.com>; Wed, 26 Feb 2014 07:12:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.221
X-Spam-Level:
X-Spam-Status: No, score=0.221 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 NyDUTLRoN-M6 for <opsawg@ietfa.amsl.com>; Wed, 26 Feb 2014 07:12:51 -0800 (PST)
Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 985361A00DB for <opsawg@ietf.org>; Wed, 26 Feb 2014 07:12:51 -0800 (PST)
Received: by mail-oa0-f45.google.com with SMTP id i11so952969oag.18 for <opsawg@ietf.org>; Wed, 26 Feb 2014 07:12:50 -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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MbTM1eWzwKbge0RRDeup0NZTXwk9fCFEBe6wGsxl7Zo=; b=YV9aTAFQJGO6ctRUZ0Xe04GCzax1a2GOhzjhMsRuxajvyBe+3aPLxvVjPdJokpbQtH 6JjdaWNgnzv6Z983io/zm39QabbpcJNKAwA+mtv/LUXWvu7/IBOvMA11smWEXvhVjH2X kNm0f9mH/+cHz8+ktHitTlQGGvOQhpD+n35GhI+LpuhKPmahbLlhgwuqGh46oRUMcURM sPi6cT3MVjyxZy4aCANNiVMJi2mS3FNnM0tpEpfZg9uzGVs4xCBGjymyjmnkfhSyz75+ e7MJoRXSS9NXN94cIw6ITNXJ5fPUiv9qXFrhyd0rSffVoGyLIFStbLHBoQ+1Ga6oUSii +/dA==
X-Gm-Message-State: ALoCoQm/HEpI7TdB//M2Bt7m1NVRPtQ3kGqEwBsLf/+dojh6ccojVNJHIxGLgtBiKJ7cqZ2UCy58
MIME-Version: 1.0
X-Received: by 10.60.165.72 with SMTP id yw8mr1170150oeb.71.1393427570206; Wed, 26 Feb 2014 07:12:50 -0800 (PST)
Received: by 10.182.191.9 with HTTP; Wed, 26 Feb 2014 07:12:50 -0800 (PST)
X-Originating-IP: [82.99.7.230]
In-Reply-To: <CAC8QAcdVfZCPC613rbYe=Y3rky_wSMvh_hEgrEpdQbgZ-ipTjg@mail.gmail.com>
References: <CAO_acptCXNzu09qH1sxig+qbjJXX0KMUmbA35LOo6KoRrG8vPg@mail.gmail.com> <CAC8QAcdVfZCPC613rbYe=Y3rky_wSMvh_hEgrEpdQbgZ-ipTjg@mail.gmail.com>
Date: Wed, 26 Feb 2014 16:12:50 +0100
Message-ID: <CAO_acpuRUad=qp4cBpk+FfOZfa8C73u9VPnnsomHHmXbcC2uCQ@mail.gmail.com>
From: =?UTF-8?Q?Bj=C3=B6rn_Smedman?= <bjorn.smedman@anyfinetworks.com>
To: sarikaya@ieee.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/pZYGa036NhAeqMdt9aYK6d0KSyI
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [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: Wed, 26 Feb 2014 15:12:53 -0000

Hi Behcet,

Thanks for your comments.

On Tue, Feb 25, 2014 at 9:12 PM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
> On Mon, Feb 24, 2014 at 4:57 PM, Björn Smedman <bjorn.smedman@anyfinetworks.com> 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.

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.

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

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

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.

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