Subject: [OPSAWG] Request for comments on CAPWAP related draft

From: Hui Deng <[email-masked]>
Date: Thu, 18 Oct 2012 16:36:47 +0800

Hello OPS

Quite recently, there are large carrier grade wifi deployment because of
mobile Internet data congestion in the air interface. And there become more
strong demand about the successful usage of CAPWAP protocl which is
invented by IETF. It will help operator to deploy more than couple of
millions of Wifi APs, in this case, we have writen drafts about further
work on capwap extension, Hope you could kindly help to review and comment
them,

PS:
https://datatracker.ietf.org/doc/draft-shao-capwap-plus-ps/

EAP extension

http://www.ietf.org/internet-drafts/draft-cao-capwap-eap-00.txt
Thanks a lot for your kind review.
Best regards,

-Hui

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 18 Oct 2012 18:41:14 +0900

Hello Hui,

Looks interesting. My first impression for these drafts is that the local-mac, another capwap model, has also supported EAP. Why do you need split-mac for EAP particularly?

BTW, the right place in the IETF to discuss them would be capwap but it has already closed. Does the IETF work work CAPWAP stuff again?

cheers,
--satoru

> 
> Hello OPS
>  
> Quite recently, there are large carrier grade wifi deployment because of mobile Internet data congestion in the air interface. And there become more strong demand about the successful usage of CAPWAP protocl which is invented by IETF. It will help operator to deploy more than couple of millions of Wifi APs, in this case, we have writen drafts about further work on capwap extension, Hope you could kindly help to review and comment them,
>  
> PS:

---

From: Hui Deng <[email-masked]>
Date: Thu, 18 Oct 2012 22:21:07 +0800

Hello Satoru,

Thanks a lot for your comments,

I guess it is not clear in our document, because chapter says.
3. Supporting EAP authencation in Wifi network . . . . . . . . . . 3
3.1. Scenario Description . . . . . . . . . . . . . . . . . . . 3
4. The scope of definition of split MAC mode . . . . . . . . . . . 4
Section 4 could lead people think that we are only working on the split
MAC, actually the local MAC don't need define the scope,

we specify both split and local MAC.

Thanks again for your kind review.
Best regards,

-Hui

2012/10/18 Satoru Matsushima <[email-masked]>

> Hello Hui,
>
> Looks interesting. My first impression for these drafts is that the
> local-mac, another capwap model, has also supported EAP. Why do you need
> split-mac for EAP particularly?
>
> BTW, the right place in the IETF to discuss them would be capwap but it
> has already closed. Does the IETF work work CAPWAP stuff again?
>
> cheers,
> --satoru
>
> >
> > Hello OPS
> >

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 19 Oct 2012 00:47:50 +0900

Hui,

On Thu, Oct 18, 2012 at 11:21 PM, Hui Deng <[email-masked]> wrote:
> Section 4 could lead people think that we are only working on the split MAC,
> actually the local MAC don't need define the scope,
>

Thanks your clarification. In addition, split-mac mode is also assumed
in section 3.

> we specify both split and local MAC.

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 because AP send messages to AAA server as
EAP authenticator.

cheers,
--satoru

---

From: Zhen Cao <[email-masked]>
Date: Fri, 19 Oct 2012 10:16:46 +0800

Hi Satoru,

Inline please.

On Thu, Oct 18, 2012 at 11:47 PM, Satoru Matsushima <
[email-masked]> wrote:

> MAC,

> 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

> 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.

--cz

>
> cheers,
> --satoru
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 19 Oct 2012 11:45:30 +0900

Hi Zhen,

On 2012/10/19, at 11:16, Zhen Cao wrote:

> as far as i understand, the local-mac mode will encapsulate the CAPWAP message into 802.3 header.

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.

> 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.

cheers,
--satoru

---

From: Zhen Cao <[email-masked]>
Date: Fri, 19 Oct 2012 11:08:47 +0800

On Fri, Oct 19, 2012 at 10:45 AM, Satoru Matsushima <
[email-masked]> wrote:

> 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.

> 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.

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 19 Oct 2012 12:59:58 +0900

Hi Zhen,

> 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?

> 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

---

From: Zhen Cao <[email-masked]>
Date: Fri, 19 Oct 2012 16:42:42 +0800

Hi Satoru,

Thank you for the suggestion, and my comments inline.

On Fri, Oct 19, 2012 at 11:59 AM, Satoru Matsushima <
[email-masked]> wrote:

> 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?

Very good point and suggestion.  We are glad to include such survey.  Could
you help conduct the survey?

> 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.
>

Anyway the problem we have is that the Thin-AP does not have the interface
with AAA or not enabled at all.

-cz