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

[Alper Yegin (alper]

>>> But one well versed in 802.11 would quickly understand that this will NOT
>>> work with APs, unless the AR does the 802.11 framing and therefore can
>>> encrypt the
>>> packets.... and then we're talking about LWAPP.
>> 
>> Unless the operator is willing to use IPsec between the host and the access
>> router.
> 
> <prc attempting to inject a little reality> Alper, please point me to one
> service provider that is even considering using IPSec to secure the session in
> a *hot spot environment*. Please show me one operator that is willing to
> assume that IPSec is readily available on all devices, and will build a
> business around this. Frankly, all services providers that I've talked to are
> rather disappointed in the PANA architecture because they were hoping for an
> auth mechanism that did not require any special software on the client (e.g.
> http). 

If the operators want a client-less solution, they can stay with web-based
login hackery (is there any alternative??). Obviously this is not adequately
secure, and they will have to move on. Any reasonable wireless security
requires client support.

As for IPsec and PANA, one more time, PANA does not mandate you to use the
keys with IPsec. You can use them with link-layer ciphering. For example,
you can bootstrap your WEP keys (legacy network) using PANA.

> 
> (FWIW, I think the above would have been a fine problem to solve - see IPass'
> auth protocol for example).
> 
> anyhow, these are discussions for the PANA list, not this one.</prc...>
> 
>> If the operator wants to use L2 ciphering, then yes, 802.11 frames should
>> reach the access router. But note that this is just one of the many things
>> LWAPP does. Doing this does not mean that we must use all other LWAPP
>> features along with that. Please see my earlier message for the problem
>> break-down and possible alternatives...
> 
> Ah - so change the PANA charter to solve the CAPWAP problem?

Why? We are not going to update the charter each time we realize where PANA
can be used.

> If this is the 
> PANA architecture, then it should be clear, because so far, it has not been.

PANA is a protocol, not an architecture. You can use it in any architecture
you like, as long as you follow the protocol design. If you want to see
mention of using keys with L2 ciphers, please read the latest Problem
Statement and Usage Scenarios draft.

> How would you tunnel the frames?

Again, this is not for PANA - obviously. Some tunneling scheme is needed
(OK, this can be CAPWAP modulo where the work should take place)

> How would you coordinate the session keys
> between the devices? etc, etc, etc.

Please explain what keys, what devices, what is the problem ???

Alper