VPDN & Calling Line ID

VPDN & Calling Line ID

Post by Mark Edward » Tue, 01 Jul 1997 04:00:00



We are setting up a PPP/IP VPDN service to a SITA Home Gateway. The SITA
Home Gateway is to be made available to selected customers.

Customers call a NAS (PSTN or ISDN) where the callers destination domain
(Home Gateway) is authenticated using CHAP and CiscoSecure. When
authenticated, the NAS establishes an L2F tunnel
the SITA managed Home Gateway.

The Home Gateway has to establish if the remote caller is a legitimate
customer or not.
We want to do this by having the Home Gateway check the customers Calling
Line Id validated (CLID) with that ofa known user/CLID on the security server.

The problem we have is that the CLID is  not passed on to the Home Gateway.

The NAS does see the CLID when the ISDN call comes in. The NAS picks up the
CLID and assigns it to the 'rem_addr' field. After the subsequent CPE CHAP
challenge/NAS authentication exchange with the server, the sucessfull call
has the rem_addr field updated with an IP addresses used in tunnel creation.
The rem_addr field is not sent to the Home Gateway, it seems to just tell
the NAS where te establish the tunnel.

Is the failure of the NAS to send the CLID to the Home Gateway is a bug or
not ? In this situation, the CLID enables us (SITA) to associate a call with
a known customer and location.

Alternatively, if we (SITA), were providing a VPDN service for specific
private customer Home Gateway, and that customer wanted to do his own
CHAP/CLID authentication, he would not be able to do so as the CLID
information is not passed on. This is a likely scenario for us.

Having the NAS verify the CLID may be possible, but is much more
restrictive. It restricts us to a single database, and in the case above
(VPDN for a private customer) would force us to be involved/responsible for
their authentication process. If the CLID info was passed on, the customer
could maintain his own database.

I can send configs if necessary....

Regards,

Mark Edwards.

 
 
 

VPDN & Calling Line ID

Post by Robert Kiesslin » Wed, 02 Jul 1997 04:00:00


Mark,

This is not possible as L2F does not have a method to transmit the
CLID. There has once been a ddts opened for this (CSCdi66409), but
it has been junked due to this fact.

Perhaps this will be possible with L2TP.

Robert


> We are setting up a PPP/IP VPDN service to a SITA Home Gateway. The SITA
> Home Gateway is to be made available to selected customers.

> Customers call a NAS (PSTN or ISDN) where the callers destination domain
> (Home Gateway) is authenticated using CHAP and CiscoSecure. When
> authenticated, the NAS establishes an L2F tunnel
> the SITA managed Home Gateway.

> The Home Gateway has to establish if the remote caller is a legitimate
> customer or not.
> We want to do this by having the Home Gateway check the customers Calling
> Line Id validated (CLID) with that ofa known user/CLID on the security server.

> The problem we have is that the CLID is  not passed on to the Home Gateway.

> The NAS does see the CLID when the ISDN call comes in. The NAS picks up the
> CLID and assigns it to the 'rem_addr' field. After the subsequent CPE CHAP
> challenge/NAS authentication exchange with the server, the sucessfull call
> has the rem_addr field updated with an IP addresses used in tunnel creation.
> The rem_addr field is not sent to the Home Gateway, it seems to just tell
> the NAS where te establish the tunnel.

> Is the failure of the NAS to send the CLID to the Home Gateway is a bug or
> not ? In this situation, the CLID enables us (SITA) to associate a call with
> a known customer and location.

> Alternatively, if we (SITA), were providing a VPDN service for specific
> private customer Home Gateway, and that customer wanted to do his own
> CHAP/CLID authentication, he would not be able to do so as the CLID
> information is not passed on. This is a likely scenario for us.

> Having the NAS verify the CLID may be possible, but is much more
> restrictive. It restricts us to a single database, and in the case above
> (VPDN for a private customer) would force us to be involved/responsible for
> their authentication process. If the CLID info was passed on, the customer
> could maintain his own database.

> I can send configs if necessary....


 
 
 

VPDN & Calling Line ID

Post by Gary L. Christofferso » Thu, 03 Jul 1997 04:00:00


Greetings,

In our implementation of the same, CLID is not used for end user
authentication at the home gateway or security server behind the home
gateway.  The end user is authenticated using "normal" login methods.  This
could involve PAP or CHAP on an end to end basis and is independent of the
authentication done initially at the NAS. In our case, we use Dialed Number
Identification System(DNIS) in combination with a TACACS+ server for the
initial NAS authentication.  If the dialed number is recognized, then the
home gateway(s) target IP address(es) is/are passed to the NAS for
tunnel/call setup and the user is passed through to the home gateway
transparently(L2F).  This may not directly address your situation, but
hopefully it provides some additional perspective.

Regards,

Gary Christofferson


Quote:

>We are setting up a PPP/IP VPDN service to a SITA Home Gateway. The SITA
>Home Gateway is to be made available to selected customers.

>Customers call a NAS (PSTN or ISDN) where the callers destination domain
>(Home Gateway) is authenticated using CHAP and CiscoSecure. When
>authenticated, the NAS establishes an L2F tunnel
>the SITA managed Home Gateway.

>The Home Gateway has to establish if the remote caller is a legitimate
>customer or not.
>We want to do this by having the Home Gateway check the customers Calling
>Line Id validated (CLID) with that ofa known user/CLID on the security
server.

>The problem we have is that the CLID is  not passed on to the Home Gateway.

>The NAS does see the CLID when the ISDN call comes in. The NAS picks up the
>CLID and assigns it to the 'rem_addr' field. After the subsequent CPE CHAP
>challenge/NAS authentication exchange with the server, the sucessfull call
>has the rem_addr field updated with an IP addresses used in tunnel creation.
>The rem_addr field is not sent to the Home Gateway, it seems to just tell
>the NAS where te establish the tunnel.

>Is the failure of the NAS to send the CLID to the Home Gateway is a bug or
>not ? In this situation, the CLID enables us (SITA) to associate a call with
>a known customer and location.

>Alternatively, if we (SITA), were providing a VPDN service for specific
>private customer Home Gateway, and that customer wanted to do his own
>CHAP/CLID authentication, he would not be able to do so as the CLID
>information is not passed on. This is a likely scenario for us.

>Having the NAS verify the CLID may be possible, but is much more
>restrictive. It restricts us to a single database, and in the case above
>(VPDN for a private customer) would force us to be involved/responsible for
>their authentication process. If the CLID info was passed on, the customer
>could maintain his own database.

>I can send configs if necessary....

>Regards,

>Mark Edwards.

******************************************
*  Gary L. Christofferson                       *
*  Data Communications Systems Engineer *
*  Pacific Bell Network Data Products   *

*  Voice: (916) 977-7414                        *
*  Fax: (916) 485-1435                  *
*                                               *
******************************************
 
 
 

1. VPDN and Calling-Station-Id

Hi,
I have a VPDN (L2TP between Cisco NASes managed by an operator and my
Cisco Tunnel Server) in a "dial-in" configuration (users dial into the
NASes and are tunneled to my Tunnel Server).
My Tunnel Server makes all of the AAA :
- ppp authentication via Radius
- network authorization via Radius
- network accounting (start-stop and update) via Radius

My current trouble is that accounting Radius packets sent by my Tunnel
Server don't include the Calling-Station-Id Radius field (n31). My
operator couldn't help...

Is there a way to have the NASes inform my Tunnel Server of the
caller's phone number (my operator confirmed the NASes know it), and my
Tunnel Server use it in its Accounting Radius packets ?

Thanks,

Gian-Paolo Zanini
NetWork Admin

Sent via Deja.com
http://www.deja.com/

2. Where can I get dvips?

3. GTE of Calif. & Calling-Line ID

4. hints for spectrum games wanted - hacker

5. Help;Call-id box &Ring-id

6. Wanted: Apple IIe or IIe extended

7. Adventure Design Team

8. Caller ID and Called ID in a diverted/forward call...

9. Call-in & call-out on the same line

10. Call waiting with call id - still don't get the Call waiting signal!

11. USA Calling Line ID