Subject: RE: [Capwap] Radius

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 21 Feb 2006 13:06:36 -0800

I believe that having CAPWAP focus on creating what we essentially have
today, via autonomous or standalone APs, is not necessarily a worthwhile
exercise.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Behcet Sarikaya [mailto:[email-masked]] 
	Sent: Sunday, February 19, 2006 2:35 PM
	To: Pat Calhoun (pacalhou)
	Cc: David T. Perkins; [email-masked];
[email-masked]
	Subject: Re: [Capwap] Radius

	I am confused, are you saying that local MAC WTPs (with a Radius
client) are not governed by CAPWAP work?
	
	Behcet
	
	Pat Calhoun (pacalhou) wrote: 

		I concur with David, and therefore having RADIUS in the
AP implies that
		it is a standalone AP, and therefore not governed by the
CAPWAP work.
		
		Pat Calhoun
		CTO, Wireless Networking Business Unit
		Cisco Systems

			-----Original Message-----
			From: David T. Perkins
[mailto:[email-masked]] 
			Sent: Tuesday, February 07, 2006 10:19 AM
			To: [email-masked]
			Cc: [email-masked]
			Subject: Re: [Capwap] Radius
			
			HI,
			
			Where do you draw the line between:
			1) a collection of stand-alone APs that have a
management
			   application apply a consistent configuration
			2) a collection an AC and connected WTPs that
			   act together as a system.
			
			I believe that this is an important issue,
because #1 does 
			not need the CAPWAP protocol. It can use the
existing 
			mangement interfaces (be they CLI, SNMP, or
proprietary) 
			found on standalone APs. And these interfaces
can be different.
			That is, AP #1 could be managed via scripted CLI
commands, 
			and AP #2 could be managed via SNMP operations.
			
			Regards,
			/david t. perkins
			
			On Tue, 7 Feb 2006 [email-masked]
wrote: 

				My reading of the draft indicates there
are 2 modes of operation.
				
				a) Combined MAC (where the AP does
everything)
				b) Split MAC (where the AC does most of
the work)
				
				in case b) it is clear that the AC must
act as the radius relay.
				
				in case a) where the AC is just
configuring the WTP, it is 

			not clear 

				WHY the AC has to 'proxy' as the radius
server.  I think the 
				restriction on REQUIRING that the AC act
as the radius 

			server (in base

				a) is too strong.
				
				Philip
				
				Quoting Charles Clancy
<[email-masked]> <mailto:[email-masked]> :

				Are you suggesting the WTPs communicate
directly with the AAA 
				server, and the AC configures the WTPs
with the appropriate 
				connection information?  Two thoughts:
				
				1. AAA traffic is trivial compared to
everything else the 

			AC will be 

				doing, so the performance increase would
be minimal.
				
				2. You've broken the keying/trust
hierarchy.  Now compromise of a 
				single WTP would allow an attacker the
ability to compromise all 
				networks that AAA server manages.  You
can't contain 

			attacks anymore.

				[ t. charles clancy ]--[ [email-masked]
]--[ 

			www.cs.umd.edu/~clancy ] [ 

				computer science ]-----[ university of
maryland | college park ]
				
				[email-masked] wrote:

				I was wondering if it really makes sense
in the NON 

			split MAC case 

				to require the AC handle radius
requests.  It seems this is over 
				burdening the AC.  The LWAPP protocol
should allow the AC to 
				configure the radius server.
				
				regards,
				
				Philip

_________________________________________________________________
				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

	
_________________________________________________________________
				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

_________________________________________________________________
		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: Behcet Sarikaya <[email-masked]>
Date: Tue, 21 Feb 2006 16:06:20 -0600

If others agree, I also agree but reducing the scope to Split MAC only, 
this is a big change!

Pat Calhoun (pacalhou) wrote:

> I believe that having CAPWAP focus on creating what we essentially 
> have today, via autonomous or standalone APs, is not necessarily a 
> worthwhile exercise.
>
> Pat Calhoun
>     ------------------------------------------------------------------------
>     Cc: David T. Perkins; [email-masked]; [email-masked]
>>I concur with David, and therefore having RADIUS in the AP implies that
>>it is a standalone AP, and therefore not governed by the CAPWAP work.
>>
>>Pat Calhoun
>>>From: David T. Perkins [mailto:[email-masked]] 
>>>1) a collection of stand-alone APs that have a management
>>>I believe that this is an important issue, because #1 does 
>>>not need the CAPWAP protocol. It can use the existing 
>>>mangement interfaces (be they CLI, SNMP, or proprietary) 
>>>found on standalone APs. And these interfaces can be different.
>>>That is, AP #1 could be managed via scripted CLI commands, 
>>>On Tue, 7 Feb 2006 [email-masked] wrote: 
>>>    
>>>
>>>>My reading of the draft indicates there are 2 modes of operation.
>>>>
>>>>a) Combined MAC (where the AP does everything)
>>>>b) Split MAC (where the AC does most of the work)
>>>>
>>>>in case b) it is clear that the AC must act as the radius relay.
>>>>
>>>>in case a) where the AC is just configuring the WTP, it is 
>>>>      
>>>>
>>>not clear 
>>>    
>>>
>>>>WHY the AC has to 'proxy' as the radius server.  I think the 
>>>>restriction on REQUIRING that the AC act as the radius 
>>>>      
>>>>
>>>server (in base
>>>    
>>>
>>>>a) is too strong.
>>>>
>>>>Philip
>>>>
>>>>Quoting Charles Clancy <[email-masked]>:
>>>>
>>>>      
>>>>
>>>>>Are you suggesting the WTPs communicate directly with the AAA 
>>>>>server, and the AC configures the WTPs with the appropriate 
>>>>>1. AAA traffic is trivial compared to everything else the 
>>>>>        
>>>>>
>>>AC will be 
>>>    
>>>
>>>>>doing, so the performance increase would be minimal.
>>>>>
>>>>>2. You've broken the keying/trust hierarchy.  Now compromise of a 
>>>>>single WTP would allow an attacker the ability to compromise all 
>>>>>networks that AAA server manages.  You can't contain 
>>>>>        
>>>>>
>>>attacks anymore.
>>>    
>>>
>>>>>[ t. charles clancy ]--[ [email-masked] ]--[ 
>>>>>        
>>>>>
>>>>>computer science ]-----[ university of maryland | college park ]
>>>>>
>>>>>>I was wondering if it really makes sense in the NON 
>>>>>>          
>>>>>>
>>>split MAC case 
>>>    
>>>
>>>>>>to require the AC handle radius requests.  It seems this is over 
>>>>>>burdening the AC.  The LWAPP protocol should allow the AC to

---

From: Charles Clancy <[email-masked]>
Date: Tue, 21 Feb 2006 19:46:55 -0500

I don't think Pat's comments imply having only a split MAC.  For 
example, local MAC with RADIUS client on the AC gives the added 
functionality of fast handoff between WTPs.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

Behcet Sarikaya wrote:
>>     *From:* Behcet Sarikaya [mailto:[email-masked]]
>>     *Sent:* Sunday, February 19, 2006 2:35 PM
>>     *To:* Pat Calhoun (pacalhou)
>>     *Cc:* David T. Perkins; [email-masked];
>>     [email-masked]
>>     *Subject:* Re: [Capwap] Radius
>>