Subject: L2TP and Radius (RFC2809)

From: Mike Kassam <[email-masked]>
Date: Thu, 26 Apr 2001 12:50:36 -0600

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: Mike Kassam <[email-masked]>
Date: Thu, 26 Apr 2001 15:02:42 -0600

Vipin,

As far as the motive:  This service is on a shared dial architecture
(multiple ISPs using the same NAS) which leverages off of port restrictions.
The port enforcement is done by another server which the Radius server talks
to.  And in short, in order for the port enforcement to work correctly:
authorization, authentication and accounting need to come from the Same
Radius server (or more specifically those 3 Radius packets need to have the
same NAS-IP, NAS-PORT tuple).  That is why I'm looking to have all these
Radius transactions done on the NAS.

The IP addresses are allocated by the LNS.  To clarify here's a simple
description of the call flow:

- User Dials ISPs number, PSTN network routes the call to a LAC
- LAC pre-authenticates and allows call to be answered on port N
- LAC sends authentication & authorization request where Tunneling
information plus authentication information is returned
- LAC creates an L2TP tunnel to LNS and uses "RADIUS reply forwarding" to
give LNS the authentication information (more specifically IP address)
- PPP session terminates on LNS.  Where the LNS advertises the IP of the
session as a part of a summarized network route.

So what I'm looking for is the:

LAC:  To be able to handle the authorization & athentication response from
the Radius server in such a way as it creates the L2TP connection to the LNS
and forwards off the authentication info.  Instead of trying to terminate
the PPP session on itself since it already received a successful
authentication with a framed-ip-address.

and the

LNS:  To receive the forwarded authentication info and use that info to
terminate the PPP session.  

So if anyone has any experience or insight on how I can get all the
authorizaiton (L2TP tunneling info) and auhentication information on the
LAC, instead of authorization on the LAC and authentication on the LNS it
would be greatly appreciatted :)

-Mike

-----Original Message-----
From: Vipin Jain [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 1:08 PM
To: 'Mike Kassam'; [email-masked]'
Subject: RE: L2TP and Radius (RFC2809)

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,

regards,
---------

Mike Kassam
Service Solutions

---

From: Mike Kassam <[email-masked]>
Date: Thu, 26 Apr 2001 15:02:42 -0600

Vipin,

and the

-Mike

-----Original Message-----
From: Vipin Jain [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 1:08 PM
To: 'Mike Kassam'; [email-masked]'
Subject: RE: L2TP and Radius (RFC2809)

Mike,

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,

regards,
---------

Mike Kassam
Service Solutions

---

From: Vipin Jain <[email-masked]>
Date: Thu, 26 Apr 2001 15:05:01 -0700

James, Mike,

Actually I wanted to say:
"Isn't typically the IP address allocated by LNS, and in that case LAC (who
happens to be radius tunneling) will have no idea of the address pools used
by LNS that does IPCP".

I agree, from what Mike and James mention, there might be advantages to
using one radius dialogue. I am curious on:
Is there an AVP LAC would use to pass on "Radius reply forwarding"
information to LNS?
Is there a document/draft that covers passing on radius information to LNS?
Has anybody analyzed the implications of LAC allocating IP address, and
other layer 3 parameters?

thanks,
Vipin Jain
Nortel Networks.

-----Original Message-----
From: James Carlson [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 2:07 PM
To: Vipin Jain
Cc: 'Mike Kassam'; [email-masked]'
Subject: RE: L2TP and Radius (RFC2809)

> 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

---

From: Klausberger Walter <[email-masked]>
Date: Fri, 27 Apr 2001 10:26:02 +0200

Hi,

I always had a different interpretation of section 4.1.2 in RFC 2809.

In my opinion only proxy authentication is supported at the moment. This may
include things like CHAP challenge from RADIUS. Anyway I always had a
problem with this section.

First, I do not know any AVP that allows forwarding of a RADIUS reply.

Second, I always thought that only the LNS finalizes the authentication
process and thus things that are done during IPCP negotiation.

Anyway it seems a bit tricky to me to get the IP address from the LAC,
because this needs coordination with the LNS routing tables and networks and
a high trust level between LAC and LNS. I would not trust my LAC!

I would also be interested in different interpretation and realization of
section 4.1.2.

- regards, Walter