Capwap Mailing List: Re: CONSENSUS CONFIRMATION: #138, #217, #247, #248, #249, #250, #251 & #252

[Abhijit Choudhury (abhijit10425]

I completely agree with Margaret. In fact, that was exactly

what I had argued in Prague.

 

The only mandatory mode in CAPWAP is the local mode. Local mode

requires support for 802.11i encryption at the WTP.

Since split-MAC mode itself is optional, it makes very little

sense to make something that is required by split-MAC to be

mandatory.

 

Any vendor who implements the split-MAC mode will select the

the options that go with it. And if customers demand either

centralized encryption or encryption at the WTP or both,

the equipment vendors will implement it.

Ultimately, customer demand will drive this.

 

Regards,

Abhijit

 

----Original Message-----
From: Margaret Wasserman [mailto:margaret [at] thingmagic.com]
Sent: Tuesday, April 03, 2007 5:50 PM
To: Merwyn Andrade
Cc: capwap [at] frascone.com; Dorothy.Gellert [at] nokia.com
Subject: Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248,
#249,#250, #251 & #252


Hi Merv,

<chair hat=off>

Here is the message where I am responding as an individual to the
technical portions of your message.  The above notation is pseudo-XML
shorthand for the chair taking his/her hat off, which means that I am
now speaking as an individual.

On Apr 3, 2007, at 7:27 PM, Merwyn Andrade wrote:

> As I have argued on the list the functionality and security properties

> between centralized encryption WTP implementations v/s distributed are

> clearly different as evidenced when I referred you all to the DoD
> 8100.2
> policy around end-to-end and supported by comments from Charles. These

> have also documented in drafts by our security advisors Scott and
> Charles. Making centralized encryption optional from the baseline
> mandatory-to-implement will prevent my DoD customers from mix and
> matching COTS (commercial off the shelf gear - what they are looking
> for) gear and makes "baseline" CAPWAP useless for them.

I've heard this argument before, but  I don't really understand it.    
Regardless of what decision we make about Issue #138, a "baseline"  
CAPWAP implementation does not have to support centralized encryption,
because a "baseline" CAPWAP implementation does not have to support
split-MAC mode at all.  Any customer who wants to use centralized
encryption would already have to specify one option (split-MAC), so I
don't understand why it would be a problem for them specify two options.

I understand that the U.S. DoD may end-up requiring the centralized
encryption option if/when they decide to use CAPWAP.  If they do specify
centralized encryption, then vendors who want to sell to the DoD will
provide equipment that implements it.  I don't think that the U.S. DoD
is any less likely to specify (or purchase) equipment that supports
their preferred security model, just because that model is listed as
optional in the IETF's CAPWAP specification.  Do you?

Let me share some of my reasoning about why I personally think it makes
sense for the distributed model to be mandatory in both modes, and for
the centralized encryption model to be optional.

In local-MAC mode, the only available security model is the "distributed
model" where the 802.11 encryption terminates at the WTP.  There was
strong agreement in Prague that it also made sense to make this model
mandatory on both ends in split-MAC mode, since both ends will already
have the software and hardware to support this model in local-MAC mode.

In the past, we reached strong agreement that we would not mandate
centralized encryption on the AC side, as many current ACs do not have
hardware support for encryption, and we do not want to add that hardware
requirement to all future ACs.  So, there will be CAPWAP- compliant
hardware that does not support centralized encryption.  I don't see why
it makes sense to require all WTPs to support centralized encryption,
when many of them may be controlled by ACs that are incapable of
supporting that mode.  So, I think it makes sense to for the centralized
encryption model to be optional on both ends.

> I can understand why my competitors would like to prevent me from
> proving that centralized encryption is better by claiming they didn't
> support it in their WTPs since it wasn't part of the baseline to keep
> a lock on their WTPs for their customers but let's remember the
> customers we are building this "interoperable mix-and-match protocol"
> for as opposed to parochial vendor interests.

IMO, it is not a goal of the IETF to mandate a technology so that the
proponents of that technology can prove that it is better...

I think it should be our goal to write a specification that will
interoperate and that contains a minimal base set of features that will
serve a fairly large percentage of the target end-users.  We may also
choose to include additional options, so that the protocol can serve a
wider group of end-users, with the hope that it can be more  
widely deployed.   I personally think that a specification that  
mandates support for the distributed security model in both local-MAC
and split-MAC modes and allows the centralized encryption model as an
option for split-MAC mode meets those goals.

In my experience, a technology never becomes successful because it is
mandated by the IETF.  A technology becomes successful because it solves
the customer's problems better than other available technologies.  If it
is true that centralized encryption is a better solution than
distributed encryption for the majority of end-users, I believe that
end-users will demand that the it is supported in the products they
purchase, whether we mandate support for the centralized encryption
model or not.  And frankly, if vendors do not see customer demand for a
specific feature, they won't implement it, even if we do try to mandate
it.

</chair>

Margaret

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.