Subject: Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248, #249, #250, #251 & #252

From: Abhijit Choudhury <[email-masked]>
Date: Wed, 4 Apr 2007 11:30:06 +1000 (EST)

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:[email-masked]] 
Sent: Tuesday, April 03, 2007 5:50 PM
To: Merwyn Andrade
Cc: [email-masked]; [email-masked]
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

____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail 

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 4 Apr 2007 18:32:09 -0700

For the record, I am sill satisfied with Split-MAC being optional and hope we will not re-open issues that have been both discussed and closed. 

I also still believe that a single mode of encryption being a MUST provides guaranteed interoperability and flexibility for vendors that feel they need to implement specific options to satisfy their customer demands.

PatC

 -----Original Message-----
From: 	Merwyn Andrade [mailto:[email-masked]]
Sent:	Wednesday, April 04, 2007 05:33 PM Pacific Standard Time
To:	Margaret Wasserman
Cc:	capwap; Dorothy Gellert
Subject:	Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248, #249,#250, #251 & #252

Margaret 

Sorry just got back from travel and couldn't get to this sooner. Thanks
for your comments, your last two posts clarified your position and what
transpired at Prague. 

I missed the split-MAC being optional piece. That is indeed very
unfortunate for the baseline CAPWAP standard since the majority of the
switch architectures out there (accounting for > 90% of market-share)
employ exactly that model. 

To your point about
<Margaret> " If you strongly disagree with the decision to make WTP
support for centralized encryption optional (which isn't entirely clear
from your  message), you should send a message to the list expressing
your disagreement with that decision.  It would be ideal if you could
also state why you disagree with the decision and what you think we
should do instead."

I strongly disagree with the decision and reasons are as follows: 

Today the market has migrated to a model where folks pick a system AC
and WTP from the same vendor.
In any of these WLAN switch architecture based systems, the WTP follows
the lead of the AC.
With my comment above about the majority of vendors doing split-MAC it
stands to reason that the only way customers would maintain flexibility
in choosing their ACs (centralized or dist encryption supporting) and
leverage a open-standards based CAPWAP would be to have WTPs that
support both (centralized and distributed encryption support). See
further data to prove this below.

To your point about
<Margaret> "This was a difficult situation for the WG, because both
choices are technically viable, and there are very few (if any) strong
technical criteria that we could use to decide which should be mandatory
and which should be optional on each end." 

IMHO this is the wrong question. This is not about technical criteria
but about the group ensuring that the baseline CAPWAP standard measures
up to some sensible least-common-denominator high-bar of market reality.
If we don't do this no one adopts it, or the vendors who want to do
bake-offs with a claim to adopt/support it are really doing so only for
the RFP checkoffs and are not really interested in their WTPs being
interoperable and being managed by other SM-based-ACs out there. Is this
what you want as chairs of this WG ?

Pick your favorite market share report ..I list one as informational
(just to make my point)
http://www.infonetics.com/resources/purple.shtml?ms07.wl.4q06.nr.shtml 
The Top 5 vendors with switch market share (you can read through the
technical docs to figure out where encryption is performed ..this is not
a secret) C-Centralized Enc AC, D-Dist Enc AC, CD -Centralized or
Distributed AC, SM-Split MAC, F - Legacy or Standalone Fat APs

Cisco-SM-D,F
Aruba/Alcatel-SM-CD,
Symbol/Motorola-SM-C,F
Trapeze/Nortel/3COM-SM-D,F
Meru/Foundry SM-D 

Independent of C/D/CD support they all have one thing in common .. Split
MAC (SM).

Hopefully you can see why I maintain my position given the market
reality. 

If I were in Prague my argument to the group would have been : 
a) For this effort to be successful and given the time we've spent on
this we need to see a high enough bar for a baseline CAPWAP spec. This
means we need to have WTPs that support C and D mandatory for the Split
MAC based ACs out there.
b) This is not about a strong technical decision but about allowing
CAPWAP capable WTPs in the real (SM based) world the chance to follow
what a distributed encryption AC, or a centralized encryption AC tells
them to do. Hence their need for mandatory support both schemes.
b) It is unfortunate that our mistake in leaving "SM optional" is now
the tail wagging the "WTPs mandatory to support distributed only" dog. 

I encourage folks to consider reopening that decision given the market
reality details above.

Hope this clarifies my position.

Regards
Merv 

Merwyn (Merv) Andrade
CTO, Aruba Networks
[email-masked]

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 8:24 AM
To: Merwyn Andrade
Cc: Scott G Kelly; capwap; Dorothy Gellert
Subject: Re: [Capwap] CONSENSUS CONFIRMATION: #138, #217, #247, #248,
#249, #250, #251 & #252

Hi Merv,

I hope that my response to Scott made it clear what process we are  
trying to follow...

There was a long discussion of issue #138 in the WG meeting.  At the  
end, we did not make the decision by having one choice win out over  
the other due to technical merits.  Both choices will work from a  
technical standpoint, so it was more a matter of preferences.

We had very strong consensus that the WTP encryption mode should be  
mandatory on both ends, so we agreed that either way, we would want  
to mandate support for WG encryption on both the AC and the WTP.  The  
discussion basically came down to a question of whether to mandate  
WTP support for centralized encryption or not.

There were some people who supported making WTP support for  
centralized encryption mandatory, and a larger number of people who  
preferred to make it optional, but no clear consensus between those  
choices.  In the end, we ended-up taking a poll regarding how many of  
the WG members could accept a specification where WTP support for  
centralized encryption was optional and how many could accept a  
specification where WTP support for centralized encryption was  
mandatory.  The large majority of the group could accept a  
specification where WTP support for centralized encryption was  
optional, while only a small number could accept a specification  
where WTP support for centralized encryption was mandatory.

This was a difficult situation for the WG, because both choices are  
technically viable, and there are very few (if any) strong technical  
criteria that we could use to decide which should be mandatory and  
which should be optional on each end.  However, this is something  
that we have to decide in order to publish the document, so we  
declared consensus to proceed with the choice that was acceptable to  
the largest majority of the group.

If you are concerned about the process that is being used, please  
read the message I just sent to Scott and let us know if it addresses  
your concerns.  If not, please express your remaining concerns, and  
we will try to address them.

If you strongly disagree with the decision to make WTP support for  
centralized encryption optional (which isn't entirely clear from your  
message), you should send a message to the list expressing your  
disagreement with that decision.  It would be ideal if you could also  
state why you disagree with the decision and what you think we should  
do instead.

Your message alone won't be enough to overturn the consensus of those  
who attended the Prague meeting, but if there are several people who  
didn't attend the meeting who also disagree with the decision, the  
consensus from the meeting will not hold, and we will have to reopen  
discussion of this issue, which will likely delay publication of the  
document.

Thanks,
Margaret