Subject: RE: L2TP and Radius (RFC2809)

From: Vipin Jain <[email-masked]>
Date: Thu, 26 Apr 2001 13:07:36 -0700

Mike,

May I ask the motive: Is it just to avoid getting interaction with radius
server twice?

Isn't typically the IP address allocated by LAC (who happens to do the
radius tunneling) have no idea of address pools used by LNS where the PPP
sessions actually terminate?

Vipin Jain
Nortel Networks.

-----Original Message-----
From: Mike Kassam [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 11:51 AM
To: [email-masked]'
Subject: L2TP and Radius (RFC2809)

Hi,

I have a question in regards to creating a tunnel from a LAC (NAS) to an LNS
using Radius.  What I want to do is have the LAC query the Radius server not
only for the L2TP authorization (tunneling information , i.e.
Tunnel-Endpoint, Tunnel-Password etc..),  but to also acquire the
authentication information (i.e. Framed-IP-Address, User Auth etc..) and
pass this information to the LNS.  This way the LNS does not have to
authenticate the User with RADIUS but can use the forwarded information
instead.

In RFC 2809 (Implementation of L2TP Cumpulsory Tunneling via RADIUS) there
is a section addressing this exact situation  4.1.2 "NAS authentication with
RADIUS reply forwarding".  Here's a little exerpt of that section:

"With this approach, authentication and authorizatin occurs once at the NAS
and the RADIUS reply is forwarded to the tunnel server."

So my question is, has anyone ever implemented this?  and if so what NAS
(LAC) vendor and what Tunnel Server/Router (LNS) vendor supports this RADIUS
reply forwarding feature?

Any help that could be provided would be greatly appreciated

regards,
---------

Mike Kassam
Service Solutions
TELUS Communications Inc.
[email-masked]

---

From: James Carlson <[email-masked]>
Date: Thu, 26 Apr 2001 17:06:53 -0400 (EDT)

> sessions actually terminate?

If the LAC isn't terminating IPCP, why on earth would it be allocating
IP addresses for the peer?

I think what you're saying might be this: since the RADIUS server is
sometimes used to allocate IP addresses, it seems like a good idea to
have the RADIUS server that is within the LNS's administrative domain
choose those addresses rather than one that is in the LAC's (possibly
separate) domain.

That seems perfectly reasonable to me, and is one argument to do the
RADIUS authentication twice (once at LAC to determine tunnel endpoint,
again at LNS to actually validate user and assign addresses, filters,
and such) in this type of deployment.  There are of course other
reasons to do it this way -- if the RADIUS answer seen by the LAC is
forwarded to the LNS, then there's a pretty high level of trust
between that RADIUS administrator and the LNS owner.  That could be
operationally infeasible for some users.  (Read: "I'd *never* buy
that!")

Plus, it's obviously simpler and doesn't involve additional new
extensions to support everywhere.  The LAC's RADIUS server, for
instance, could be extremely simple -- if name is of form m/.*@.*/,
then tell the LAC to contact DNS address "lns.$2".  Otherwise,
validate locally as non-L2TP user.  :-/

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677