[c-nsp] mpls option A with LAC and LNS

[David Freedman]

If you are really desperate there is "VRF source selection"

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/vrfselec.html

But this is rather insecure as it uses the IP address to decide which
VRF to use, users can spoof IPs and inject traffic into another VRF
unless the access provider is doing uRPF when the users are terminated.

Another solution may be to create a tunnel from the user's CPE to your
kit and drop the tunnel into a VRF at your headend.
You can, for example use Client initiated l2tp + radius
(http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gtvoltun.html)
or just plain old GRE (with appropriate security)

The tunneling solutions will of course reduce your client's payload size
and hence throughput will be affected.

Dave.




Stig Johansen wrote:
> Hi there,
> 
> You should separate the customers in the LAC at your service provider.
> Either in different VRF's or at least in different IP-subnets. The best
> would be if you could get the provider to use *your* RADIUS-server for
> authenticating. They could do a proxy and stripping unwanted
> parameters/adding their internal parameters at their end. This way you
> could control which IP-subnet the different users (your customers) get
> and do some VRF-selection based on source-addresses at your "LNS".
> 
> Since the PPP-connection is terminated in the LAC at the
> service-provider, you won't be able to do any re-negotiating as in a
> LAC/LNS L2TP-setup. The alternative would then be to do a
> user-authentication in a firewall, but I belive this would be a negative
> impact for the users.
> 
> Best regards,
> Stig Meireles Johansen
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Vikas Sharma
> Sent: 28. juli 2008 10:26
> To: Oliver Boehmer (oboehmer)
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] mpls option A with LAC and LNS
> 
> Hi Oli,
> 
> Authentication is required to keep users in their respective VRFs. These
> all
> attributes will come from Radius. We are getting services from other
> operator. User are using their infracture and coming in to my network.
> 
> We provide mpls vpn / internet services to the customer.
> 
> Regards,
> Vikas Sharma
> 
> 
> On 7/28/08, Oliver Boehmer (oboehmer) <oboehmer at cisco.com> wrote:
>> Ah, ok.. may I ask why you would want to authenticate the "users"? And
>> against which user database?
>> Which service(s) do you provide for the other operator? More than just
>> traffic?
>>
>>        oli
>>
>> Vikas Sharma <mailto:vikassharmas at gmail.com> wrote on Monday, July 28,
>> 2008 8:24 AM:
>>
>>> Hi Oli,
>>>
>>> Thanks for the prompt responce. I think I need to slightly modify
>>> this.
>>>
>>> Though I have used the term LAC and LNS, I am not using L2TP to get
>>> the data from the other operator. I am using Inter-AS option A, back
>>> to back vrf. The issue I can see once the data is at my ASBR, it
> will
>>> not have any control plane information (as other operator has
> already
>>> put it in to the respective vrf). In that case I will not be able to
>>> use my radius to authenticate the user. In summary, my radius will
>>> not be used at all.
>>>
>>> Regards,
>>> Vikas Sharma
>>>
>>>
>>> On 7/28/08, Oliver Boehmer (oboehmer) <oboehmer at cisco.com> wrote:
>>>
>>>       Vikas Sharma <> wrote on Monday, July 28, 2008 6:59 AM:
>>>
>>>       > Hi,
>>>       >
>>>       > Need help to resolve the below situation. The scenario of
> LAC
>> / LNS
>>>       > and mpls option A -
>>>       >
>>>       > In case, the customer belong to the ISP dials and latch in
> the
>> same
>>>       > ISP (i.e. using ISP infrastructure), I can authenticate
> (since
>> they
>>>       > will latch on LNS, a radius client), using radius and radius
>> will
>>>       > return certain attribute including vrf / pool name etc. and
>> then
>>>       > customer will go to it's own vrf and to it's own network.
>>>       >
>>>       > But in my case, customers come from other ISP domain
> (dialing
>> and
>>>       > coming on their lac) and we are using back to back vrf to
>> connect
>>>       LAC > and LNS. Now the problem is, how to authenticate the
> users
>> and
>>>       return > vrf and ip pool name from the radius as LNS can not
> act
>> as
>>>       radius > client now. The only option I can see is to forward
> the
>>>       fraffic to > firewall, which can act as radius client and
> query
>> to
>>>       radius server, > radius server can inturn return the vlan
> which
>> can
>>>       be mapped to > respective vrf.
>>>
>>>       you can use vrf-aware Radius to send Radius the radius
> requests
>>>       within the VRF (which, I think, solves your problem, but I'm
> not
>>>       sure I entirely understood your topology):
>>>
>>>       aaa authentication ppp VRFCUST group VRFGROUP
>>>       aaa authorization network VRFCUST group VRFGROUP
>>>       aaa accounting network  VRFCUST group VRFGROUP
>>>       !
>>>       aaa group server radius VRFGROUP
>>>       server-private x.x.x.x key zzzzz
>>>       ip radius source-interface ...
>>>       ip vrf forwarding <vrf-name>
>>>       !
>>>       int virtual-template1
>>>       ppp authentication chap pap VRFCUST
>>>       ppp authorization VRFCUST
>>>       ppp accounting VRFCUST
>>>
>>>       However: The L2TP packets also arrive within a VRF, so you
> need
>> to
>>>       use vrf-aware vpdn as well (specifiy "vpn vrf <name>" in your
>>> vpdn-group).
>>>
>>>       hope this helps..
>>>
>>>              oli
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>