Subject: RE: [Capwap] Radius

From: "Saravanan Govindan" <[email-masked]>
Date: Wed, 22 Feb 2006 08:56:22 +0800

Hi Behcet,

I am not sure that the CAPWAP scope doesn't include local-MAC. CAPWAP
will cover both local-MAC and split-MAC WTPs that require central
control and management. I think the previous comment deals particularly
with RADIUS and does not imply all control and management.

Saravanan

 

________________________________

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2006 6:06 AM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] Radius

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
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 <http://www.cs.umd.edu/%7Eclancy>
] [ 

				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