Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt

From: "Clint Chaplin" <[email-masked]>
Date: Thu, 16 Jun 2005 15:48:16 -0700

There is one issue in how to split the "split architecture" that will be somewhat contentious in generating a standard for CAPWAP.  That issue is: who handles the 802.11i encryption decryption?  There is already in the market from major vendors equipment that falls on both sides of this division.  If the CAPWAP standard is to be inclusive with existing architectural decisions, this one is going to have to be thrashed out.  In my opinion, the correct answer should be: both are supported.

Clint (JOATMON) Chaplin
Wireless Security Advisor
Wireless Standards Manager

>>> "Mani, Mahalingam (Mahalingam)" <[email-masked]> 6/16/05 07:13:18 >>>
I have no objections to this 'bug-fix' if it can happen in time and has
no author/WG objections. We can request the RFC Ed. to hold off.

As for the other issue on split-MAC interpretation:
The split-discussion is long overdue; and is worth having - to help
evaluation as well. I think resolution of the discussion is important to
arrive at the best approach to CAPWAP protocol accommodating/not split
variants.

History:
We had clearly noted not to make any recommendations on what a split
characteristic must be in the taxonomy. This has perhaps been argued
many times in (taxonomy) design team and in IETF58-62 as well. There was
no scope for us in the then charter to venture that way.

When APF AHC initially started its work - the hope was it would offer
enough information for CAPWAP to draw conclusions for future work; there
were no expectations on what they would recommend the split ought to be
once they were chartered (there were hopes much prior to that). Inasmuch
as IEEE 802.11 endorsed and acknowledged the documented splits caused no
standards departure/breakage in implementation or behavior - by its
review of the taxonomy draft - we had validated all architectures from
IEEE 802.11 perspective.

It was clear when APF AHC group was formed that it will transpire to
provide only clarifying interpretations of functions - not delineate or
standardize splits.

-mani
======
-----Original Message-----
From: Yang, Lily L [mailto:[email-masked]] 
Sent: Wednesday, June 15, 2005 1:19 PM
To: Mani, Mahalingam (Mahalingam); Pat Calhoun
Cc: [email-masked] 
Subject: RE: [Capwap] Taxonomy Recommendations

Hi, Pat and Mani --

I have not read through the entire Taxonomy Recommendations document
yet, but just reading through the first few pages, I believe the authors
are correct in pointing out one of the "inconsistency" (error) in the
taxonomy draft. There was a paragraph in the taxonomy draft Section 5.6:
" The commonalities and differences between Local MAC and Split MAC are
   most clearly seen by comparing Figure 7 to Figure 10.  The
   commonality is that 802.11 control frames are terminated at WTPs in
   both cases.  The main difference between Local MAC and Split MAC is
   that the WTP terminates only the 802.11 control frames in the Split
   MAC, while the WTP may terminate all 802.11 frames in the Local MAC.
   An interesting consequence of this difference is that the Integration
   Service, which essentially refers to bridging between 802.11 and
   802.3 frames, is implemented by the AC in the Split MAC, but can be
   part of either the AC or WTP in the Local MAC."
The last sentence, as pointed out by Pat, Bob and Inderpreet's document,
was incorrect. According to Figure 9, Integration Service, for all the
parties classified as Local MAC, is implemented by WTP. 
Given that we still have about 3 hours remaining in the authors' 48 hour
window, I would like to send a note to RFC Editor suggesting the
following sentence to replace the last sentence in the paragraph:
"An interesting consequence of this difference is that the Integration
   Service, which essentially refers to bridging between 802.11 and
   802.3 frames, is implemented by the AC in the Split MAC and by the
WTP in the Local MAC, as shown in Figure 9 and Figure 12."

Glaring as it is, I believe this error does not carry any far reaching
implication to the entire document and hence it is bug we can fix right
now.

Regarding the comment from the authors that taxonomy draft lacks
conclusion and recommendation and hence the motivation to take it
further to clearly define what Local and Split MAC really mean in terms
of functional split -- I think that is a fair comment -- Personally I
was tempted to take that step in the taxonomy draft with the intention
to help the WG moving forward, but as the editor of the draft, I
received clear instruction from the chairs and the WG that a taxonomy
only goes so far to "document" the reality of the market, not to
"define" any architectures. So the draft deliberately didn't go far into
making any specific functional split recommendation.

As I advocated in both July and Nov IETF meeting last year, I believe
there is indeed a gap between taxonomy draft and objective draft -- the
WG needs a clear definition of the functional split for Local,
especially Split MAC, but that is not the charter of either taxonomy
draft or Objective draft. Some people have the illusion that IEEE 802.11
(specifically the APF ad hoc group) will provide such definition. The
clear answer there is NO, IEEE would not do that. It is up to us in this
group to agree on the split and move on. So if indeed this Taxonomy
Recommendation draft fulfills this purpose, I personally believe it is a
very necessary step to take in order to move forward. However, as I
said, I have not reviewed the entire document yet and so I would reserve
until then to offer any further comments.

But I do want to fix the error in Section 5.6 in Taxonomy draft NOW. 

Lily
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mani, Mahalingam (Mahalingam)
Sent: Wednesday, June 15, 2005 11:14 AM
To: Pat Calhoun; [email-masked] 
Subject: RE: [Capwap] Taxonomy Recommendations

Thanks for the joint effort (by authors of two candidate protocols for
eval. as I see it) in making a case for clarification of terminology.

If the changes and clarifications proposed are extensive - comments in
form of I-D is useful to place-hold them.

The WG should (especially the original taxonomy team authors) comment on
these comments (draft): WG has approved the -06 version of the taxonomy
draft. Two of the authors are in this as well :)

It is also important to understand the implications, if any, (on
Objectives draft) if WG agrees to any of the proposed clarifications. It
may turn out to be transparent to the Objectives draft. This needs to
happen soon for Objectives to freeze and let the evaluation team use a
baselined version.

[BTW: the taxonomy draft is in RFC editor's queue - actually just
completed AUTH48].

-mani
======
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pat Calhoun
Sent: Thursday, June 09, 2005 2:28 PM
To: [email-masked] 
Subject: [Capwap] Taxonomy Recommendations

All,
 
I wanted to announce the early availability of the CAPWAP taxonomy
recommendation draft that Bob O'Hara Inderpreet Singh and I have been
working on. It can be found at
http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommendation-00.tx 
t.

Abstract

   The IETF's CAPWAP working group has documented various product
   architectures and has categorized the Centralized WLAN Architectures
   into two main buckets: Split and Local MAC.  While the document
   contains very relevant and useful information, what it does is list
   the architectural variants of these two buckets, but does not
   unambiguously define either the Split MAC or Local MAC architectures.
   In order for CAPWAP to be successful, it is crucial for the protocol
   evaluation team, and the working group, to agree on unambiguous
   terminology to describe these architectures.

   This document proposes terminology to unambiguously describe the
   relevant architectures found in the taxonomy document, for the
   purpose of initiating a discussion within the working group and to
   allow the protocol evaluation work to come to a fruitful conclusion.
   We conclude in this document that the architectures are very similar
   and could be supported via a single protocol.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

_______________________________________________
Capwap mailing list
[email-masked] 
http://mail.frascone.com/mailman/listinfo/capwap 

_______________________________________________
Capwap mailing list
[email-masked] 
http://mail.frascone.com/mailman/listinfo/capwap 

_______________________________________________
Capwap mailing list
[email-masked] 
http://mail.frascone.com/mailman/listinfo/capwap 

________________________________________________________________________
This email has been scanned for computer viruses.
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 17 Jun 2005 10:56:53 -0400

Pat,

The three comments made so far against your draft with regard to the
Split MAC arch - Bridging at WTP, HCCA and encryption/decryption - show
a pattern: in term of labor division the Split MAC arch is not
homogenous.
It may be constructive to consider "splitting" the Split arch or allow
for several functions to run at the AC or WTP.

Regards,
Emek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pat Calhoun
Sent: Friday, June 17, 2005 2:02 AM
To: 'Clint Chaplin'; Mani, Mahalingam (Mahalingam);
[email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt

Clint, while I am OK with the proposed approach you are stating as long
as CAPWAP's statement is clear that centralized encryption can be done
either in the WTP or the AC, but the latter cannot work w/ HCCA.

From a procedural standpoint, I can make changes to the taxonomy
recommendations document, or the chairs can find another medium on which
to document this. Either way works for me.

Pat Calhoun

> From: Clint Chaplin [mailto:[email-masked]]
> Sent: Thursday, June 16, 2005 3:48 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt
> 
> There is one issue in how to split the "split architecture" 
> that will be somewhat contentious in generating a standard for CAPWAP.

> That issue is: who handles the 802.11i encryption decryption?  There 
> is already in the market from major vendors equipment that falls on 
> both sides of this division.  If the CAPWAP standard is to be 
> inclusive with existing architectural decisions, this one is going to 
> have to be thrashed out.  In my opinion, the correct answer should
> be: both are supported.
> 
> Clint (JOATMON) Chaplin
> >>> "Mani, Mahalingam (Mahalingam)" <[email-masked]> 6/16/05
> 07:13:18
> >>> >>>
> I have no objections to this 'bug-fix' if it can happen in time and 
> has no author/WG objections. We can request the RFC Ed. to hold off.
> 
> evaluation as well. I think resolution of the discussion is important 
> to arrive at the best approach to CAPWAP protocol accommodating/not 
> split variants.
> 
> History:
> many times in (taxonomy) design team and in IETF58-62 as well. There 
> was no scope for us in the then charter to venture that way.
> 
> enough information for CAPWAP to draw conclusions for future work; 
> there were no expectations on what they would recommend the split 
> ought to be once they were chartered (there were hopes much prior to 
> that). Inasmuch as IEEE 802.11 endorsed and acknowledged the 
> documented splits caused no standards departure/breakage in 
> implementation or behavior - by its review of the taxonomy draft - we 
> had validated all architectures from IEEE 802.11 perspective.
> 
> provide only clarifying interpretations of functions - not delineate 
> or standardize splits.
> 
> -mani
> ======
> yet, but just reading through the first few pages, I believe the 
> authors are correct in pointing out one of the "inconsistency" (error)

> in the taxonomy draft. There was a paragraph in the taxonomy draft 
> Section 5.6:
> The last sentence, as pointed out by Pat, Bob and Inderpreet's 
> document, was incorrect. According to Figure 9, Integration Service, 
> for all the parties classified as Local MAC, is implemented by WTP.
> Given that we still have about 3 hours remaining in the authors' 48 
> hour window, I would like to send a note to RFC Editor suggesting the 

> implication to the entire document and hence it is bug we can fix 
> right now.
> 
> further to clearly define what Local and Split MAC really mean in 
> terms of functional split -- I think that is a fair comment -- 
> Personally I was tempted to take that step in the taxonomy draft with 
> the intention to help the WG moving forward, but as the editor of the 
> draft, I received clear instruction from the chairs and the WG that a 
> taxonomy only goes so far to "document" the reality of the market, not

> to "define" any architectures. So the draft deliberately didn't go far

> into making any specific functional split recommendation.
> 
> there is indeed a gap between taxonomy draft and objective draft -- 
> the WG needs a clear definition of the functional split for Local, 
> draft or Objective draft.
> Some people have the illusion that IEEE 802.11 (specifically the APF 
> ad hoc group) will provide such definition. The clear answer there is 
> NO, IEEE would not do that. It is up to us in this group to agree on 
> the split and move on. So if indeed this Taxonomy Recommendation draft

> fulfills this purpose, I personally believe it is a very necessary 
> step to take in order to move forward. However, as I said, I have not 
> reviewed the entire document yet and so I would reserve until then to 
> offer any further comments.
> 
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Mani, Mahalingam 
> (Mahalingam)

> The WG should (especially the original taxonomy team authors) comment 
> on these comments (draft): WG has approved the -06 version of the 
> taxonomy draft. Two of the authors are in this as well :)
> 
> Objectives draft) if WG agrees to any of the proposed clarifications. 
> It may turn out to be transparent to the Objectives draft. This needs 
> to happen soon for Objectives to freeze and let the evaluation team 
> use a baselined version.
> 
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Pat Calhoun
> CTO, Wireless Networking Business Unit Cisco Systems
>

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Sat, 18 Jun 2005 10:30:37 -0400

Pat,

If you agree with Dan's point then please educate the group how it
differs from allowing bridging function to run at the WTP in Split Mac
arch. Philosophically they are the same, practically there are two
notable distinction in favor of bridging: a) bridging in WTP doesn't
break interoperability with an 802.11 feature and b) offers merits to
the customer.

Regards,
Emek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pat Calhoun
Sent: Saturday, June 18, 2005 1:39 AM
To: 'Dan Harkins'
Cc: 'Clint Chaplin'; Mani, Mahalingam (Mahalingam);
[email-masked]; [email-masked]
Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt 

I agree with you Dan, except that if we agree to allow a specific
permutation of an architecture which breaks interoperability with an
802.11 feature, then it is our responsibility to make sure it isn't
brushed under the rug. In the end, the market will decide.

Pat Calhoun

> [mailto:[email-masked]] On Behalf Of Dan Harkins
> Sent: Friday, June 17, 2005 9:26 AM
> To: Pat Calhoun
> Cc: 'Clint Chaplin'; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [Capwap] Taxonomy Recommendations: encrypt/decrypt
> 
>   The specific technical reason is a reason not to put 
> encryption/decryption in the AC. And it is a very good reason.
> As I mentioned, I agree with it. There are very valid technical 
> reasons not to come up with a split MAC architecture in which 
> encryption/decryption is done at the AC. What I don't agree with is 
> that explaining this has any place in a CAPWAP document.
> 
>   As the taxonomy memo shows people have come up with different 
> approaches. I don't necessarily agree with the rationale behind them 
> but reasonable people can disagree and if someone wants to come up 
> with an architecture that is problematic for use with 802.11e then 
> that's their problem.
> 
>   CAPWAP just has to support the different architectures, it doesn't 
> have to lecture people about how what they did is wrong or how a 
> different approach would've been better. They did it that way. CAPWAP 
> just needs to be able to support them.
> 
>   Let me point out again, since I don't think it sank in:
> this problematic architecture is not mine; you split the MAC the same 
> way we did (and probably for similar reasons). My opposition to this 
> text is that a protocol document is not the place for explaining why 
> one supported architecture is bad as compared to another supported 
> architecture.
> 
>   Dan.
> 
> On Fri, 17 Jun 2005 05:57:34 PDT you wrote
> > >   The fact that it would be problematic with HCCA is not anything 
> > > that needs to be mentioned in any CAPWAP statement.
> > > It's useful to bring up during a product design phase
> when deciding
> > > where to do bulk data encryption in a particular split
> MAC but such
> > > architectures exist and all CAPWAP has to do is support
> it not say
> > > why one particular approach is better or worse than another.
> > > 
> > >   Note that you split the MAC the same way we did so my
> objection is
> > > not defensive or political. I just don't think it has any
> place in
> > > CAPWAP.
> > 
> > I disagree - and for very specific technical reasons.
> > 
> > This is the one area where splitting the MAC has significant 
> > implications. See my previous e-mail response to Chris
> Hinsz, but to
> > summarize, in HCCA the fragmentation must occur prior to
> encryption in
> > order to meet the service period negotiated within HCCA. One cannot 
> > centralize the encryption function (hence fragment) without direct 
> > access to the RF in real-time in order to gain access to
> interference
> > and co-channel information.
> > 
> > Pat Calhoun

---

From: "Randy Chou" <[email-masked]>
Date: Sat, 18 Jun 2005 12:12:58 -0700

I'm glad you agreed.  Just because a vendor can't figure out how another
may solve a perceived problem doesn't mean it can't be done nor is it
relevant to Capwap.

Another example would be the amount of key distribution and key
management required by each architecture.  Virtually every cryptography
expert will tell you the security advantages of minimizing key
distribution and shear complexity of managing keys.  Encrypting at the
AC versus at the WTP clearly minizes key distribution and hence is much
more secure.  Are we going to spell that out in the security
considerations section then?

Let the market decide.

Regards,

--
Randy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pat Calhoun
Sent: Friday, June 17, 2005 3:39 PM
To: 'Dan Harkins'
Cc: 'Clint Chaplin'; Avaya - Mani Mahalingam; [email-masked];
[email-masked]
Subject: RE: [Capwap] Taxonomy Recommendations: encrypt/decrypt 

Pat Calhoun

> As I mentioned, I agree with it. There are very valid 
> technical reasons not to come up with a split MAC 
> architecture in which encryption/decryption is done at the 
> AC. What I don't agree with is that explaining this has any 
> place in a CAPWAP document. 
> 
>   As the taxonomy memo shows people have come up with
> different approaches. I don't necessarily agree with the 
> rationale behind them but reasonable people can disagree and 
> if someone wants to come up with an architecture that is 
> problematic for use with 802.11e then that's their problem.
> 
>   CAPWAP just has to support the different architectures, it
> doesn't have to lecture people about how what they did is 
> wrong or how a different approach would've been better. They 
> did it that way. CAPWAP just needs to be able to support them.
> 
>   Let me point out again, since I don't think it sank in: this 
> problematic architecture is not mine; you split the MAC the same way 
> we did (and probably for similar reasons). My opposition to this text 
> is that a protocol document is not the place for explaining why one 
> supported architecture is bad as compared to another supported 
> architecture.
> 
>   Dan.
> 
> [email-masked] http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked] http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap