Subject: [Capwap] Comments on CAPWAP Objectives draft

From: <[email-masked]>
Date: Tue, 15 Feb 2005 15:56:12 -0800

Here are some comments the chairs have on the Objectives draft.  We also provided priority classifications for each objective as described in the charter.  I hope this generates some discussion and more comments.  

Keep in mind that we are looking for a minimal set of requirements needed for an interoperable protocol.   

Regards,
Dorothy

1. (general)  Customer Requirements section should not be a sub-section of each Objective, but rather a separate section for Service Providers to list their requirements.  As the draft's author list includes Operators, this section should list Operator Specific requirements that may be missed by equipment vendors.  

2. (general)  Some of the Objective Section include subsection.  These should be pulled out so we can prioritize them on their own merit.
 Example:  5.2.3.i, ii, iii, 5.2.4.i, ii, iii, 5.2.5.i, ii

3. (general)  We need to clearly state the Requirement in each objective.  I don't believe the title of the objective is enough.  The way its stated now we have to surmise the requirement from the description.  

4. (general)  Section 5.3 needs to be moved into the intro section.

Objective: 5.2.3.i:  Logical Groups, Priority:  Mandatory
Objective 5.2.3.ii:  Should this be Mutual Exclusion of Control and Data?  Priority:  Mandatory
Objective 5.2.3.iii:  Multiple Authentication Mechanisms:  Desirable.  
			- 802.11i should be requirement, not an option.  

Objective 5.2.4.i:  Enable support for future wireless technologies:  Desirable
			- 802.11 first, 802.16 requirements in phase 1 time permitting.  As stated in Charter.
Objective 5.2.4.ii:  Enable support for new IEEE requirements: Desirable
Objective 5.2.4.iii  Access Requirements:  Do you mean transparency here?  This is unclear.  Transparency should be Mandatory

Objective 5.2.5.i:  Configuration Consistency:  Priority:  Mandatory 
			- Is the requirement to update configuration info to AC?  Do you mean to get into Provisioning here?  
			- firmware distribution needs to be its own requirement.  Should this be on control or data plane? 
Objective 5.2.5.ii:  System Wide resource state:  Priority Mandatory
			- Define what statistics are needed.
	
Objective 5.2.6:  Resource Control Objectives:  Priority:  Mandatory
			- Requirement is to maintain the 802.11e mapping.  Can this be expanded to include other 802.11 TG semantics?

Objective 5.2.7 Traffic Separation:  
			Isn't this a duplicate of 5.2.3.ii?

Objective 5.2.8:  STA Admission Control Objectives  	
			- Need to be better defined.  Don't know what you are getting at here.

Objective 5.2.9:  Centralized WTP Management:
			- Isn't this a duplicate of 5.2.5.i?

Objective 5.2.10:  CAPWAP Protocol Security:  Priority:  Mandatory  
			- Is this mutual authentication, should be clarified

Objectives 5.2.11:  System Wide Security	: Priority:  Mandatory

Objectives 5.2.12:  Centralized WTP management:  Priority:  Rejected
			- It sounds like you are requesting the AC not participate in management.  This doesn't seem relevant to establishing a control and provisioning protocol for APs. At the very least it doesn't seem like a high priority requirement for a phase 1 CAPWAP protocol.  

Objectives:  5.2.13:  Security Borderline Control:  Priority:  Desirable 
			- Is this necessary for a phase 1 CAPWAP protocol?

Objective 5.2.14:  Trust Model Definitions
			- Is this a duplicate of mutual authentication in 5.2.10?  

Objectives 5.2.15:   IEEE 802.11i Considerations
			-What is the proposal for key distribution in each case?   Priority Mandatory (for key distribution only)
			-What other considerations?

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

---

From: "Cheng Hong" <[email-masked]>
Date: Fri, 18 Feb 2005 10:42:20 +0800

Hi Dorothy,

Thanks a lot for your detailed comments on the draft. I think those are very
helpful in improving the draft.

As the editor is on his business trip, and has some difficulty in accessing
the e-mail, his reply on those comments may come later.

Here below, please find some of my personal comments to some of the points
inline.

cheers

Cheng Hong

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Wednesday, February 16, 2005 7:56 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Capwap] Comments on CAPWAP Objectives draft
> 
> 
> 
> Here are some comments the chairs have on the Objectives 
> draft.  We also provided priority classifications for each 
> objective as described in the charter.  I hope this generates 
> some discussion and more comments.  
> 
> Keep in mind that we are looking for a minimal set of 
> requirements needed for an interoperable protocol.   
> 
> Regards,
> Dorothy
> 
> 
> 1. (general)  Customer Requirements section should not be a 
> sub-section of each Objective, but rather a separate section 
> for Service Providers to list their requirements.  As the 
> draft's author list includes Operators, this section should 
> list Operator Specific requirements that may be missed by 
> equipment vendors.  
> 
> 2. (general)  Some of the Objective Section include 
> subsection.  These should be pulled out so we can prioritize 
> them on their own merit.
> 3. (general)  We need to clearly state the Requirement in 
> each objective.  I don't believe the title of the objective 
> is enough.  The way its stated now we have to surmise the 
> requirement from the description.  
> 

[Cheng]
Agree
[/Cheng]

> Control and Data?  Priority:  Mandatory 

[Cheng]
That is good suggestion. The titile would be changed.
[/Cheng]

>Objective 5.2.3.iii:  
> Multiple Authentication Mechanisms:  Desirable.  

[Cheng]
Agree. Given the 802.11i is a already part of 11, it has to be supported.
The intention is to require the CAPWAP to support other commonly used
authentication mechanism in current hotspot, without compromising the
support of 11i. This could be clarified with extra text.
[/Cheng]

> 			- 802.11 first, 802.16 requirements in 
> phase 1 time permitting.  As stated in Charter. 

[Cheng]
Agree. 
[/Cheng]

>Objective 
> 5.2.4.ii:  Enable support for new IEEE requirements: 
> Desirable Objective 

>5.2.4.iii  Access Requirements:  Do you 
> mean transparency here?  This is unclear.  Transparency 
> should be Mandatory

[Cheng]
It means that the CAPWAP protocol should not affect the end terminal,
especially over the air interface.

However, it should not precluded that the end terminal could have some
enhanced functions implemented to make use of the new features provided by
CAPWAP. In this sense, the requirement also means legacy end terminal
support.
[/Cheng]

> 			- Is the requirement to update 
> configuration info to AC?  Do you mean to get into 
> Provisioning here?  

[Cheng]
It could be considred as the provisioning. I guess this was also part of the
problem statement of the CAPWAP. 
[/Cheng]

> 			- firmware distribution needs to be its 
> own requirement.  Should this be on control or data plane? 

[Cheng]
It has to be in the control plane, since it affects the operation of the
WTP. Also relates to the Objective 5.2.9 below. (some comments there)
[/Cheng]

> 			- Define what statistics are needed.

[Cheng]
Not sure if the Objective draft is a good place to list out all the
statistics. It could be part of the protocol job. Another alternative is for
the MIB definiton at the later stage.
[/Cheng]

> 			- Requirement is to maintain the 
> 802.11e mapping.  Can this be expanded to include other 
> 802.11 TG semantics?

[Cheng]
So far, 11 only has 11e as the QoS control mechansim. We are also aware tha
there are other TGs that may affect the resource control, e.g. TGk, TGu, and
TGv. But, those drafts are not yet become stable (u & v just started). I
think this other aspects has to be covered in objective 5.2.4
[/Cheng]

> 			Isn't this a duplicate of 5.2.3.ii?

[Cheng]
In deed they overlap a bit here. I guess the 5.2.3.ii could be merged into
this section.
[/Cheng]

> know what you are getting at here.

[Cheng]
This objective is on how the CAPWAP can support the admission control
functions. To make use of the CAPWAP arch, it is expected that the ACU would
most likely be implemented at the AC. In that case, the CAPWAP would need to
provide the support of those SME-MLME SAP functions defined by the 11. (11e
has some informative text regarding the admission control unit
implementation).
[/Cheng]

> 			- Isn't this a duplicate of 5.2.5.i?

[Cheng]
Yes. That part of the 5.2.5.i should be merged into this section. The
section 5.2.5 should concentrate on the montioring aspect, e.g. ways for
centralized controller to be aware of the status/version of the WTP. And
this section on the management aspect, i.e. the provisioning part.
[/Cheng]
 
> 			- Is this mutual authentication, should 

[Cheng]
It requires mutual authentication of the WTP and AC, AND data
confidentiality, integrity, and authentication of the communication between
them.
[/Cheng]

> 			- It sounds like you are requesting the 
> AC not participate in management.  This doesn't seem relevant 
> to establishing a control and provisioning protocol for APs. 
> At the very least it doesn't seem like a high priority 
> requirement for a phase 1 CAPWAP protocol.  
> 
> 			-What is the proposal for key 
> distribution in each case?   Priority Mandatory (for key 
> distribution only)

[Cheng]
This depends on the protocol proposals. If the proposal adapts the arch that
the keys are derived at the AC, it needs to provide a secure and reliable
way to distribute and synchronize the keys with the AC and WTP, and at the
same time keeps the over the air protocol unaffected.
[/Cheng]

> [email-masked] http://mail.frascone.com/mailman/listinfo/capwap
> 
> 
>

---

From: "Cheng Hong" <[email-masked]>
Date: Fri, 18 Feb 2005 10:42:42 +0800

Hi Dorothy,

cheers

Cheng Hong

[Cheng]
Agree
[/Cheng]

[Cheng]

[Cheng]

[Cheng]
Agree. 
[/Cheng]

[Cheng]

[Cheng]

[Cheng]

[Cheng]

[Cheng]

[Cheng]

[Cheng]

[Cheng]

[Cheng]

[Cheng]

---

From: "Saravanan Govindan" <[email-masked]>
Date: Wed, 23 Feb 2005 17:29:48 +0800

Hi Dorothy, Mani

Thank you for your comments and the priority classifications. 

The co-authors and I have followed your suggestion to separate certain
subsections into full objectives. These are being posted as separate threads
for discussion. Also, for reviewing convenience alone, we have included the
changes you have suggested in to another intermediate draft. This link for
this is;

http://www.psl.com.sg/internet-drafts/draft-ietf-capwap-objectives-v00-i1.tx
t 

Additionally, please see inline for responses.

> list Operator Specific requirements that may be missed by 

<SG> 
I see. So, a new section will be included to highlight Operator
requirements. In addition to the operators in the author list, I would like
to request other operators to put forward requirements that they feel are
important for CAPWAP. 
</SG>

>  Example:  5.2.3.i, ii, iii, 5.2.4.i, ii, iii, 5.2.5.i, ii

<SG>
Ok. Please see the new Additions (Additions #9 - #20). These represent the
subsections that have been made into separate objectives. They are also
included in the intermediate draft mentioned above. 
</SG>

> requirement from the description.  

<SG>
Ok. Please see the new Additions (Additions #9 - #20). They include a
specific requirement for each objective.
</SG>

> Objective: 5.2.3.i:  Logical Groups, Priority:  Mandatory Objective

<SG> See Additions #9 - 'Logical Groups' </SG>

> Objective 5.2.3.ii:  Should this be Mutual Exclusion of 
> Control and Data?  Priority:  Mandatory Objective 

<SG> This objective is about mutual exclusion of control and data. Changes
have been made to the "Traffic Separation" objective (5.2.7) See Additions
#10 - 'Support for Traffic Separation' </SG>

> - 802.11i should be requirement, not an option.  

<SG> See Additions #11 - 'Multiple Authentication Mechanisms' </SG>

> phase 1 time permitting.  As stated in Charter.

<SG> Ok. 802.11 will be first. See Additions #12 - 'Future Wireless
Technologies' </SG>

> Objective 5.2.4.ii:  Enable support for new IEEE 
> requirements: Desirable Objective 

<SG> See Additions #13 - 'New IEEE Requirements' </SG>

> Objective 5.2.4.iii  Access 
> Requirements:  Do you mean transparency here?  This is 
> unclear.  Transparency should be Mandatory
> 

<SG> Yes. This objective refers to transparency; End-users should not be
affected by CAPWAP. See Additions #14 - 'End-user Transparency' </SG>

> configuration info to AC?  Do you mean to get into 

<SG> Yes. The CAPWAP protocol is to collect configuration information and
make this aware to the AC. Provisioning will be when the AC makes
configuration decisions based on the information. See Additions #15 -
'Configuration Consistency' </SG>

> own requirement.  Should this be on control or data plane? 

<SG> Firmware distribution should be on the control plane. See Additions #16
- 'Firmware Distribution' </SG>

> - Define what statistics are needed.

<SG> Maybe the objectives can give examples of statistics since the
specifics would depend on the protocol. See Additions #17 - 'Statistics'
</SG>

> 802.11e mapping.  Can this be expanded to include other 

<SG> This objective can be expanded to include other 802.11 TG semantics
that are related to resource control. We will need to point out that some of
the TGs are under progress, so they need to be dealt with appropriately. See
Additions #18 - 'Resource Control' </SG>

> 			Isn't this a duplicate of 5.2.3.ii?

<SG> It is similar 5.2.3ii. See Additions #10 - 'Support for Traffic
Separation' in which 5.2.3ii has been combined with 5.2.7 </SG>

> know what you are getting at here.

<SG> This was one of the original objectives from the individual drafts. The
authors later realized that this needed to be described in a more clear
manner. Additions #4 - 'STA Admission Contro', which was posted to the
mailing list earlier, explains this objective better. Please consider
Additions #4 - 'STA Admission Control' as a proposed change. 
</SG>

> - Isn't this a duplicate of 5.2.5.i?

<SG> This is similar to 5.2.5i. It can be removed now that 5.2.5i has been
made a separate objective. </SG>

> - Is this mutual authentication, should 

<SG> This objective includes both mutual authentication and the subsequent
secure exchanges between AC and WTPs. So it is meant to cover the complete
protocol security between AC and WTPs. This has bee clarified in Addition
#19 - 'CAPWAP Protocol Security'. </SG>

> Objectives 5.2.11:  System Wide Security	: Priority:  Mandatory
OK

> requirement for a phase 1 CAPWAP protocol.  
OK

> - Is this necessary for a phase 1 

<SG> This objective relates to the logical groups (5.2.3i). We will need to
get more information on the details of this objective. </SG>

> authentication in 5.2.10?  

<SG> This objective deals with IEEE 802.11i, so it does not relate directly
to AC-WTP mutual authentication & security in 5.2.10. Additions #8 - 'Trust
Model Definition', posted earlier to the mailing list, details proposed
changes to this objective that the authors considered. Please see Additions
#8 - 'Trust Model Definition'. </SG>

> -What other considerations?

<SG> For key distribution, a proposal is to make CAPWAP aware of IEEE
802.11i exchanges and the locations of the authenticator and encryption
points. This need not be explicit but rather could be an implicit
distinction made during initial configuration of WTPs. This way, the CAPWAP
protocol can be made to include operations for handling key exchanges in the
different cases, i.e. authenticator, encryption at AC or at WTP.
</SG>

Cheers,

Saravanan