Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC

From: "Saravanan Govindan" <[email-masked]>
Date: Mon, 4 Sep 2006 10:01:17 +0800

Pat,

This is not a new functionality, but one that is mandatory by the
Objectives. 

Also, I do not think this is an issue of where the EAPoL-Key is
generated, but rather "how" EAPoL messages are exchanged in local-MAC
and split-MAC architectures. 

I have made a number of proposals with both text and figures that direct
address the mandatory objective. 

I am not comfortable with a protocol that does not support explicitly
stated objectives. 

Saravanan

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Friday, September 01, 2006 7:32 AM
To: [email-masked]
Subject: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC

This issue was opened to add a new mode of operation to the CAPWAP
protocol, allowing the WTP to generate the EAPOL messages. I do not
agree with this request, and would like to see this one rejected. We
really need to focus on getting a protocol completed, and I just don't
see a burning need to add this new functionality. 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

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

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

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Mon, 4 Sep 2006 10:51:13 -0700

Saranavan,

The current protocol, as it is specified in -02, does meet the stated
objectives.  It supports both local MAC and split MAC architectures, as
those architectures are described in the taxonomy document.  

There is no requirement in the objectives that the protocol support any
other arbitrary split of functionality between the AC and WTP.
Otherwise, we would have to negotiate EVERY possible frame that might be
exchanged between a mobile node and the 802.11 access point, to
determine if it is generated in the AC or the WTP.  For example, do the
objectives require that the protocol must support the Association
Request being processed in the AC and the Association Response being
generated in the WTP for a split MAC architecture?

 -Bob
 
-----Original Message-----
From: Saravanan Govindan [mailto:[email-masked]] 
Sent: Sunday, September 03, 2006 7:01 PM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or
AC

Pat,

Saravanan

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Friday, September 01, 2006 7:32 AM
To: [email-masked]
Subject: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC

Pat Calhoun

---

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 5 Sep 2006 14:02:28 +0800

Bob,

The objective for this issue addresses designs where the 802.11i
authenticator is located at the AC and cryptographic functions are on
the WTP. This is made very clear in the requirement. 

What the protocol currently needs is a way to specify prevailing KeyRSC
information (maintained by the WTP) to EAPoL messages (generated by the
AC). The proposal so far is to let the AC send EAPoL messages (with
unassigned KeyRSC field) to the WTP. Then the WTP assigns the prevailing
KeyRSC and forwards to the wireless station. 

The objective and corresponding proposal are very clear. 

Saravanan

-----Original Message-----
From: Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Tuesday, September 05, 2006 1:51 AM
To: [email-masked]
Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or
AC

Saranavan,

 -Bob
 
-----Original Message-----
From: Saravanan Govindan [mailto:[email-masked]] 
Sent: Sunday, September 03, 2006 7:01 PM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation at WTP or
AC

Pat,

Saravanan

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Friday, September 01, 2006 7:32 AM
To: [email-masked]
Subject: [Capwap] Issue 199: EAPoL-Key message generation at WTP or AC

Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 5 Sep 2006 08:28:21 -0700

Saravanan,

What exactly in the protocol prevents 802.11i from being used? As far as
I can tell, from my own implementation of a derivative of CAPWAP, the
protocol runs fine with both Split and Local MAC.

Pat Calhoun

> Sent: Monday, September 04, 2006 11:02 PM
> To: Bob O'Hara (boohara); [email-masked]
> Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation 
> at WTP or AC
> 
> Bob,
> 
> The objective for this issue addresses designs where the 
> 802.11i authenticator is located at the AC and cryptographic 
> functions are on the WTP. This is made very clear in the requirement. 
> 
> What the protocol currently needs is a way to specify 
> prevailing KeyRSC information (maintained by the WTP) to 
> EAPoL messages (generated by the AC). The proposal so far is 
> to let the AC send EAPoL messages (with unassigned KeyRSC 
> field) to the WTP. Then the WTP assigns the prevailing KeyRSC 
> and forwards to the wireless station. 
> 
> Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation 
> at WTP or AC
> 
> Saranavan,
> 
> The current protocol, as it is specified in -02, does meet 
> the stated objectives.  It supports both local MAC and split 
> MAC architectures, as those architectures are described in 
> the taxonomy document.  
> 
> There is no requirement in the objectives that the protocol 
> support any other arbitrary split of functionality between 
> the AC and WTP.
> Otherwise, we would have to negotiate EVERY possible frame 
> that might be exchanged between a mobile node and the 802.11 
> access point, to determine if it is generated in the AC or 
> the WTP.  For example, do the objectives require that the 
> protocol must support the Association Request being processed 
> in the AC and the Association Response being generated in the 
> WTP for a split MAC architecture?
> 
>  -Bob
>  
> Subject: Re: [Capwap] Issue 199: EAPoL-Key message generation 
> at WTP or AC
> 
> Pat,
> 
> This is not a new functionality, but one that is mandatory by 
> the Objectives. 
> 
> Also, I do not think this is an issue of where the EAPoL-Key 
> is generated, but rather "how" EAPoL messages are exchanged 
> in local-MAC and split-MAC architectures. 
> 
> I have made a number of proposals with both text and figures 
> that direct address the mandatory objective. 
> 
> I am not comfortable with a protocol that does not support 
> explicitly stated objectives. 
> 
> Saravanan
> 
> 
> 
> 
> This issue was opened to add a new mode of operation to the 
> CAPWAP protocol, allowing the WTP to generate the EAPOL 
> messages. I do not agree with this request, and would like to 
> see this one rejected. We really need to focus on getting a 
> protocol completed, and I just don't see a burning need to 
> add this new functionality. 
>  
> 
> Pat Calhoun