|
|
This appendix details remote access to MPLS VPN integration AAA and Radius requirements for authorization, authentication, accounting, and address management. Direct and proxy authentication are discussed.
The Dial L2TP solution (see Provisioning Dial-In Access) is used in this Radius AAA example, but the requirements apply to all RA to MPLS VPN solution environments.
The following steps are indicative of a AAA and Radius centric call flow.
Step 2 The NAS uses the SP Radius server to determine the address of the VHG/PE the session should be tunneled toward. The SP Radius server determines the appropriate VHG based on the remote user's domain name or the DNIS.
Step 3 The NAS creates an L2TP tunnel to VHG. The NAS and the VHG authenticate each other.
Step 4 The remote users PPP session is tunneled to the VHG.
Step 5 The VHG uses the SP Radius server to authenticate the incoming PPP session.
Step 6 The SP Radius server:
Step 7 Call setup is complete where packets can flow in both directions.
Step 8 The VHG sends accounting records to the SP Radius servers. The SP Radius server saves a copy of the accounting records, and also proxies the record to the relevant VPN Radius server.
For a scalable solution with multiple VHG/PEs in a POP, the NAS can not be configured with VPDN information to each PE. It has to retrieve information from the SP Radius Server.
When a remote user calls in, the NAS sends an Access-Request to the SP Radius server that includes the following attributes:
The SP Radius server must be configured with the following record. Assume the remote user's domain name is being used to associate it for retrieving the appropriate VHG to tunnel to:
All communication between the NAS and the SP Radius server should be carried over the management VPN, if the NAS and the SP Radius server do not reside in the same POP.
Based on the NAS's IP address and/or Identifier, the SP Radius Server recognizes the POP in which this NAS is located. The SP returns the address of a VHG/PE router which is located in that POP, and has a VRF pre-enabled for the cisco.com VPN.
There are multiple VHG/PEs in the POP that have cisco.com VRF enabled. The SP Radius server load balances amongst them. Random load balancing is acceptable, however, if the SP Radius server monitors the utilization of the various VHG/PEs via accounting records, it can load balance more intelligently.
The NAS also load balances among multiple VHGs as well as failover if one VHG is not available. In this case, the Radius server returns a list of VHG addresses to the NAS and the NAS load balances among these VHGs.
The Tunnel-Assignment-ID and Tunnel-Password are the local name and the local password used by the NAS for L2TP tunnel setup. If these commands are left out, the NAS uses its hostname and default password. The attributes that must be returned are the tunnel type (l2tp) and the IP address of VHG/PE.
When establishing an L2TP tunnel, the LAC (NAS) and the LNS (VHG) first authenticate each other. This is optional and can be disabled. For L2TP tunnel authentication, the LAC and LNS must use the same password. Currently tunnel authentication is possible via local authentication, not via Radius.
The VHG sends an Access-Request to the SP Radius server. The request includes the following information:
The SP Radius server strips of the user-name, and looks up a record for the domain name to associate it with the appropriate VRF on the VHG/PE. The domain name's record could be, for example:
These cisco-avpairs include VPN specific information and configs, but nothing user specific. The last command in the "lcp:interface-config" specifies the local pool. It may change when the "overlapping address pools" feature is implemented. Or the SP Radius server may not include this command, and include an IP address itself in the Framed-IP-Address attribute.
Based on the domain name or DNIS, the SP Radius server, associates the user with a VPN and proxies the Access-Request to that VPN's Radius server.
The VPN Radius server authenticates the remote user, and returns an Access-Accept or Access-Reject message to the SP Radius server. The Access-Accept message includes user specific information and configs. The SP Radius server merges this user-specific information with the VPN specific information in the Access-Accept message it returns to the VHG/PE.
 |
Note An alternative to this proxy authentication mechanism is for the SP Radius server to do both the authorization and remote user authentication itself. The customer must provide the SP with complete, up-to-date records for all users with remote access privileges. |
The SP provider needs to keep distinct records for the same domain name: one to respond to the NAS's request in Step 2 and the other one to respond to the VHG's request in Step 6. The AR can do this. In large networks, there can be a local Radius server in each POP and other Radius servers in the core of the network. The local Radius servers is configured with tunneling information specific to that POP, addresses of VHGs, etc. The NASs query the local Radius server to obtain tunneling information. The Radius server(s) in the core respond to queries from the VHGs for authorization, authentication, address management, and accounting.
If the SP Radius server is responsible for address assignment it maintains a separate address pools per (VHG,VPN) pair to prevent address fragmentation. The other requirement is for the Radius server to maintain overlapping address pools. The AR can fulfill both requirements. The AR can reclaim unused addresses by monitoring the accounting messages sent for each remote user.
Posted: Fri Mar 28 16:09:34 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.