Re: [OPSAWG] Simplified Alternative to CAPWAP

Behcet Sarikaya <sarikaya2012@gmail.com> Wed, 26 February 2014 20:56 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 00E6E1A06BC for <opsawg@ietfa.amsl.com>; Wed, 26 Feb 2014 12:56:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.45
X-Spam-Level:
X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 olLFwXIEkT9T for <opsawg@ietfa.amsl.com>; Wed, 26 Feb 2014 12:56:05 -0800 (PST)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 512661A0184 for <opsawg@ietf.org>; Wed, 26 Feb 2014 12:56:03 -0800 (PST)
Received: by mail-lb0-f173.google.com with SMTP id p9so1048197lbv.32 for <opsawg@ietf.org>; Wed, 26 Feb 2014 12:56:01 -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=AMR0CJ0qVgg2JKcJPn0jV9KTWAAHAzj4HW6tVlF6wmw=; b=H3gXqK8wKnzc/21KqU6m+dZp2LDHtkcN6JgkB14d1IQWgumkm/f1VFLdS6IXYDqWBR CCwlTH24Bwzf8DjebzTo58PcVIjK9ubEehdN2Nbeb95sRbIrfCZtP/UiwhJs7a6vtJ/J chZ5HY6suCKzWpSbdTPKChllYotWKTUU6VHY9AbowtlSB5lFT3RCFKnXYJlWSLhEdkon 2sUqEppdfaRhViWfavQ0tf3YFbFQmF2AU+L657wnA6ocFVlu75lUQYG0vbLkTbNK9suz txXzK3QyZTA0O6cPHlF+XyrP1N3moawzd1XtUER4MpiQmkLQotMbLDT344ixM+b4Cg/0 eXfg==
MIME-Version: 1.0
X-Received: by 10.152.23.169 with SMTP id n9mr3105570laf.45.1393448161212; Wed, 26 Feb 2014 12:56:01 -0800 (PST)
Received: by 10.114.176.234 with HTTP; Wed, 26 Feb 2014 12:56:01 -0800 (PST)
In-Reply-To: <CAO_acpuRUad=qp4cBpk+FfOZfa8C73u9VPnnsomHHmXbcC2uCQ@mail.gmail.com>
References: <CAO_acptCXNzu09qH1sxig+qbjJXX0KMUmbA35LOo6KoRrG8vPg@mail.gmail.com> <CAC8QAcdVfZCPC613rbYe=Y3rky_wSMvh_hEgrEpdQbgZ-ipTjg@mail.gmail.com> <CAO_acpuRUad=qp4cBpk+FfOZfa8C73u9VPnnsomHHmXbcC2uCQ@mail.gmail.com>
Date: Wed, 26 Feb 2014 14:56:01 -0600
Message-ID: <CAC8QAcd=p6-+i9P93EYiM-w0_cWTcj0ZGo0rnQhZ2wABC+0Djg@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=089e0160b99aa97ca704f3556e90
Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/ly_F1lcMdqSPkQXg308IeWaR7zI
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
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: Wed, 26 Feb 2014 20:56:08 -0000

Hi Bjorn,

Thanks for your reply, see my comments inline.



On Wed, Feb 26, 2014 at 9:12 AM, Björn Smedman <
bjorn.smedman@anyfinetworks.com> wrote:

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