Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-01.txt

[高波 <[e-mail]>]

 

Hi

 

Thank you.

Please see my reply following in blue line.

 

Please allow me try to snip the email a little in order to make it easy to read.

I hope the format is fine for you.

 

Best Regards

 

Bo Gao

 

 

>> [xueli] I appreciated the comments to scenario to offload the authenticator

>function to SGW.

>> There are two reasons, which I clarified the scenario in the document

>version 01 as :

>>    "In EAP framework, SGW could act as the Authenticator instead of AC

>>    because of several reasons.  First of all, a powerful AC that

>>    aggregates the Authenticator function is not a appreciated choice for

>>    some operators. There are large numbers of AC devices in the operators

>>    existing network.  The Authentication Server (AS) will overload the

>communication with large

>>    numbers of AC devices if ACs acts as the Authenticator.

>  

>This is the point where you lost me. Why is it "not appreciated" by operators?

>  

>Sometimes you need to add new functionality to a device; the vendor writes

>code and provides firmware updates for these devices. Deployers apply the

>firmware update. That is a normal part of day-to-day operations in a network.

>  

>I don't understand why you go out of your way to define an entire new

>*protocol* just for the convenience of saving a firmware update in a fleet of

>equipment. (And not even that is true, see below)

>  

>At other places you write that it's difficult to implement in the authenticators

>and more convenient to do it in a central place. My only reply to this: yes, it's

>work and it needs to be done. Get over it. I don't see how the hassle of

>defining a new protocol - which also needs to get implemented, and firmware

>updated to support it - is in any way easier or more useful.

 

[BO]The scenario, we discussed is that there are both AC and SGW deployed in the network, without function converged.

AC is responsible for AP management, and SGW is the gateway for user management, including user management and address assignment, etc.

In this scenario, there could be two solutions for authenticator.

1 AC is the authenticator, SGW must support RADIUS proxy

->The opinions on this point please see the reply following to your second concern.

2  SGW acts as the authenticator, key announcement is needed.

The issue we need to resolve in standard solution.

I must clarify here; we are not saying we cannot support solution 1.

However there are some disadvantages which must be considered if we use solution 1 .

Technology side of view: SGW is on the data path of user traffic. SGW is the gateway for user management and address assignment. So SGW must be Radius proxy to achieve user management, such as charging and address assignment. Otherwise, all the traffic will transparent on SGW. It cannot be accepted.

Management side of view: For operators, there are employees who manage and handle AC device. They are required to have knowledge about AC function. Simple AC will reduce the requirements for employees. Additionally, there are much more ACs than SGW in real network, which means AAA will communicate with much more clients if AC is the authenticator instead of SGW.

We should have another optional solution for the real network, which is solution 2.

They are both possibilities for operators. 

>  On the other

>    hand, SGW MUST support the RADIUS proxy function when AC acts as the

>    Authenticator in EAP framework.  In this scenario, both SGW and AC

>    should be responsible for authentication procedure.

 

I also don't see why the SGW needs to be a RADIUS proxy. If the authenticators are implemented correctly, they implement the RADIUS client side and can be configured to contact any RADIUS server they want. If traffic is administratively *wanted* to flow by the SGW, then yes, the SGW must also implement the RADIUS protocol. If not, the authenticators can talk to the real target, the authentication server, on their own. So this is not a protocol problem, it is just a deployment choice.

[BO] In the scenario defined in the draft, if AC acts as the Authenticator, SGW must support Radius Proxy. It doesn’t account that implementation is correct or not. The motivation is to achieve user management requirement on SGW.

In WLAN network, SGW is the gateway which charges user management and address assignment. Considering the user charging and user traffic forward behavior, SGW must recognize the user information because of following reasons.

For example, SGW must recognize whether the special user is authenticated or not. Then SGW will decide to forward the user traffic or reject it. Otherwise, all the user traffic will be transparent on SGW, even the traffic from Hacker. This cannot be accepted.

You may argue AC can achieve user management and address assignment. If AC and SGW are converged as one device, I agree. However, it is out the scope of the draft. In the scenario, with AC and SGW both deployed, if AC support the user management and address assignment functions, the network architecture will be changed. AC must support router function, because layer 2 network will be terminated on AC. Also, OSPF etc routing protocols are needed on AC. There are many network and device challenges.

For the traditional operators, WLAN network is stacked in the existing broadband network, SGW is responsible for the broadband user management, address assignment, etc. Considering the upgrade work needed if AC is the authenticator, the operators ( I am not sure all the operators, at least some of the operators) are seeking another option to resolve the uniform authentication in WLAN network. If the authenticator can move to the SGW, the network becomes simple, except for the key issue. If authenticator is on the SGW, user management, such as charging and address assignment will be easy to achieve without communication with AC.

So we need to resolve this issue.

I cannot promise which solution the special operator will pick. However, it is the real scenario of the network deployment.

The operators can consider the network status of their own and all the upgrade issues in order to choice the proper solution.

I hope I clarify it clearly.