Capwap Mailing List: Re: Certificates, Discovery Request/Reply, and validation.

[Alper Yegin (alper]

>>> So how does the AP know that 802.1x will be required for a
>>> given mobile?
>> 
>> Why does the AP need to know this? The AP needs to be capable
>> of authenticating a station irrespective of whether it is
>> 802.1x capable or not (HTTP redirect).
> 
> well, clearly a policy needs to be satisfied before the user is granted
> access. Further, if 802.1x is required, then the AP needs to know because the
> beacons over the air must indicate that encryption will be required (here I am
> assuming 802.11 because the AP MUST be involved in encryption in the PANA
> architecture, so there is a message required from the AR to the AP with the
> specific keys, which of course needs to be secured).

PANA protocol does not state that AP MUST be the encryption end point. PANA
can be used in architectures where AR is the encryption end-point.

Other things you are talking about above is related to configuring APs. Yes,
PANA does not do that. If you remember my earlier e-mails, I was asking why
not do this using SNMP.

> 
> So if you have two SSIDs (one for 802.1x and one for HTTP redirect), you need
> two SSIDs (or one SSID advertised in two different ways), probably with
> different BSSIDs in order to really interoperate with today's clients.
> 
>>> How does the AP get the 802.1x keys that it
>>> must use with the mobile? How does the AR handle load
>>> balancing? How does the AR handle 802.11e and 802.11i, or
>>> should the AP do it? What about 802.11h? What about 802.11k?
>> 
>> Hmmm... At least PANA does not have any goals or objectives of
>> dealing with all these issues.
> 
> correct. hence the biggest difference between PANA and LWAPP/CAPWAP.
> 
>>> 
>>> You see, the PANA architecture really only touches the tip of
>>> the iceberg. Moving towards a LWAPP architecture solves these
>>> issues, and significantly reduces the amount of protocol work
>>> required between the AP and the AR (because 802.11 terminates
>>> in the AR, so 802.11 *is* the protocol).
>>> 
>>> We seem to be focused on EAP only, but again, I think the
>>> problem is much greater in scope - hence CAPWAP.
>> 
>> I missed the CAPWAP BOF at IETF57. Is there an issue w.r.t the
>> scope of PANA and CAPWAP? The thread seems to indicate that to be
>> the case.
> 
> yes, a point raised numerous times by Alper.
> 
>> The CAPWAP objective may be to solve a greater set of
>> problems for 802.* networks. PANA is not a solution that is specific
>> to 802.* networks. There may be overlap in functionality but
>> I dont think that is necessarily a problem.
> 
> ok
> 

Alper