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

From: "Pat Calhoun" <[email-masked]>
Date: Thu, 16 Jun 2005 16:01:43 -0700

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
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> 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
> 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-recommenda
> tion-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: Chris Hinsz <[email-masked]>
Date: Thu, 16 Jun 2005 16:38:05 -0700

Pat,
> in the WTP or the AC, but the latter cannot work w/ HCCA.
First thing that confuses me, if the encryption is at the WTP, then
it's not centralized, this statement seems to imply that it is. 
Second, you note that encryption at the AC won't work with HCCA.  I
was not aware of this limitation.  I freely admit that I am not a TGe
expert, the access mechanism seems like it would be orthogonal to
encryption.  What is it about HCCA that effects the location of
encryption?
   CSH

---

From: Dan Harkins <[email-masked]>
Date: Thu, 16 Jun 2005 16:47:08 -0700

On Thu, 16 Jun 2005 16:01:43 PDT you wrote
> in the WTP or the AC, but the latter cannot work w/ HCCA.

  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.

  Dan.

---

From: "Pat Calhoun" <[email-masked]>
Date: Fri, 17 Jun 2005 05:45:57 -0700

Chris,

Taken from
http://www.ietf.org/internet-drafts/draft-calhoun-capwap-taxonomy-recommenda
tion-00.txt:

   o  Fragmentation/Defragmentation.  Requiring this function to exist
      in the AC will cause issues with support for 802.11e.  In the
      802.11e specification, and more importantly the HCCA mechanism
      defined, an AP may need to fragment frames in order to fill a
      scheduled service period; thus 802.11e defines this function to be
      realtime for some instance.  Moving this function to the AC is not
      possible since access to the air is required in order to be able
      to react to instantaneous changes in bandwidth, either as a result
      of noise or co-channel interference from adjacent APs or STAs.
      Placing this function in the AC would preclude an implementer from
      using the feature of 802.11e.  In addition, this function is often
      used as part of the retransmission strategy, the control of which
      is in the WTP.

   o  Privacy.  There are two components to Privacy; 802.11 data privacy
      and secure session establishment (802.1X/EAP).  It is agreed that
      the 802.1X/EAP function should reside in the AC.  However, while
      encryption/decryption services could be performed in the WTP in
      most of today's circumstances, this becomes very problematic when
      used in conjunction with HCCA.  As previously noted, HCCA will
      cause frames to be fragmented in order to fill a service period,
      and fragmentation occurs prior to encryption in 802.11.  Requiring
      encryption services in the AC is not possible, again, else it
      preclude an implementer from utilizing these 802.11e features.

Hope this helps,

Pat Calhoun

> [mailto:[email-masked]] On Behalf Of Chris Hinsz
> Sent: Thursday, June 16, 2005 4:38 PM
> To: [email-masked]
> Subject: Re: [Capwap] Taxonomy Recommendations: encrypt/decrypt
> 
> Pat,
> > 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.
> First thing that confuses me, if the encryption is at the 
> WTP, then it's not centralized, this statement seems to imply 
> that it is. 
> Second, you note that encryption at the AC won't work with 
> HCCA.  I was not aware of this limitation.  I freely admit 
> that I am not a TGe expert, the access mechanism seems like 
> it would be orthogonal to encryption.  What is it about HCCA 
> that effects the location of encryption?
>    CSH
> 
> > 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.
> > 
> > recommendations document, or the chairs can find another medium on 
> > which to document this. Either way works for me.
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> > 
> > 
> > 
> > > 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
> > > 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.
> > >
> > > 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.
> > >
> transpire to 
> > > provide only clarifying interpretations of functions - 
> not delineate 
> > > or standardize splits.
> > >
> > > -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:
> Split MAC 
> > > are
> > >    MAC, while the WTP may terminate all 802.11 frames 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.
> 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:
> > >    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."
> > >
> > > 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.
> > >
> 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.
> > >
> > > [mailto:[email-masked]] On Behalf Of Mani, Mahalingam 
> > > (Mahalingam)
> 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.
> > >
> > > 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 
> 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
> > > ======
> taxonomy 
> > > recommendation draft that Bob O'Hara Inderpreet Singh and I have 
> > > been working on. It can be found at 
> > >    In order for CAPWAP to be successful, it is crucial for the 
> > > protocol
> > >    We conclude in this document that the architectures are very 
> > > similar
> > > CTO, Wireless Networking Business Unit Cisco Systems
> > >

---

From: "Pat Calhoun" <[email-masked]>
Date: Fri, 17 Jun 2005 05:57:34 -0700

>   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: Chris Hinsz <[email-masked]>
Date: Fri, 17 Jun 2005 06:39:50 -0700

Pat,
   Thanks for directing me to those sections.  I can now certainly see
the issue you're referring to.  Given this information I agree that
CAPWAP should address this.
   CSH

---

From: Dan Harkins <[email-masked]>
Date: Fri, 17 Jun 2005 09:25:58 -0700

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

---

From: "Pat Calhoun" <[email-masked]>
Date: Fri, 17 Jun 2005 15:38:53 -0700

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]
> 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.
> 
> > >   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.
> > > 
> objection is 
> > > not defensive or political. I just don't think it has any 
> place in 
> > > CAPWAP.
> > 
> > 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