Hi Zhen,
On 2012/10/19, at 12:08, Zhen Cao wrote:
> > My question is why local-mac couldn't solve your problem. As far as I
> > know, any local-mac mode AP needs to encapsulate EAP packet into
> > neither CAPWAP-DATA nor CTL
> >
> > as far as i understand, the local-mac mode will encapsulate the CAPWAP
> > message into 802.3 header.
> > +-+wireless frames +-+ 802.3 frames +-+
> > | |----------------| |--------------| |
> > | | | | | |
> > | |----------------| |--------------| |
> > | |wireless PHY/ | | CAPWAP | |
> > | | MAC sublayer | | | |
> > +-+ +-+ +-+
> > STA WTP AC
> >
>
> Thanks, same view on me. The local-mac isn't designed to encapsulate EAP
> packet into CAPWAP-{CTL|DATA} but the split-mac is the mode which CAPWAP-DATA
> deliver the EAP packet.
>
> Not actually. EAP is not exempted from the tunnel by RFC5415.
I think that tunneling EAP packet through AP-AC link in the local-mac mode is
nothing worth. I think that it should be significant to share that there is any
implementation with that, or not. Can you include some results of
implementation survey in the document?
>
>
> >
> > because AP send messages to AAA server as
> > EAP authenticator.
> >
> > This way, when UE handover between different AP, the security session
> > cannot be switched to the new AP.
> >
>
> Well, I understand that what problem you want to solve is keep 802.11i
> security session continuously in UE handover between different APs. If so, I
> may suggest that you can clarify the comparison of solutions in the document
> that local-mac + ERP, which a product of the IETF hokey wg, vs. split-mac +
> EAP encapsulation into CAPWAP-CTL for example.
>
> Thanks for the suggestion. Before that I need to clarify another aspect: now
> that in the non-EAP authentication WLAN, we already have the AP not directly
> interfacing with AAA, for a smooth upgrade, we had better keep this arch.
>
It seems slightly different discussion. EAP is a layer 2 authentication
protocol but non-EAP authentication, whatever web or WISPr, is layer 3 based
authentication. These are in orthogonal.
--satoru
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
