Subject: RE: L2TP question on Tunnel Secret

From: Ignacio Goyret <[email-masked]>
Date: Fri, 01 Jun 2001 09:40:10 -0700

How can an LNS reject an ICRQ because the LAC's RADIUS server
was misconfigured? The ICRQ does not contain a Tunnel-Password
or anything derived from it.

This is all a local implementation issue and has little to do
with the protocol itself.

At 08:14 AM 6/1/01 -0700, Vipin Jain wrote: 

I think, rejecting icrq would be the right choice. 

-- vipin 

-----Original Message----- 
From: Kamlesh Agrawal [<mailto:[email-masked]>mailto:[email-masked]] 
Sent: Friday, June 01, 2001 12:19 AM 
To: Bill Baumann; Glen Zorn 
Cc: l2tp 
Subject: RE: L2TP question on Tunnel Secret 

I agree with all the comments that this is a misconfiguration on the part of 
Radius server. My question is "How do we take care of this misconfiguration 
on the LNS side gracefully?" 

Kamlesh. 

-----Original Message----- 
From: Bill Baumann [<mailto:[email-masked]>mailto:[email-masked]] 
Sent: Thursday, May 31, 2001 3:37 PM 
To: Glen Zorn 
Cc: [email-masked]; [email-masked] 
Subject: RE: L2TP question on Tunnel Secret 

RADIUS supports multiple tunnels per LAC/LNS pair.  So it is possible to 
have multiple passwords, they just belong to multiple tunnels. 

A unique RADIUS-specified id comes with the password.  This specifies 
which tunnel to use.  If it passes a different password, the id had better 
be different too, or the RADIUS server is broken.  As Glen says, there's 
only one password per tunnel. 

Regards, 
Bill Baumann 

On Thu, 31 May 2001, Glen Zorn wrote: 

> Kamlesh Agrawal [<mailto:[email-masked]>mailto:[email-masked]] writes: 
> 
> > Hi, 
> > 
> > I had a L2TP question, was wondering if anyone has any 
ideas/suggestions? 
> > 
> > A tunnel is established between a LAC and a LNS and they have a shared 
> > secret. The LAC and the LNS use the same shared secret to 
> > encode(hide) and 
> > decode the hidden AVPs. 
> > 
> > Say user1 comes in with shared secret (Tunnel Password) = "secret" and 
> > Tunnel endpoint = LNS1, Tunnel T1 gets established between LAC1 
> > and LNS1 and 
> > they both use "secret" to encode(hide) and decode the hidden AVPs. 
> > 
> > Now, user2 comes into LAC1 with shared secret (Tunnel Password) = 
> > "secret1" 
> > and Tunnel endpoint = LNS1, LAC1 sees that it has a tunnel T1 to 
> > LNS1, puts 
> > the user in the same tunnel. However, when LNS1 tries to decode the 
hidden 
> > AVPs from user2 which are now encoded using "secret1", it gets garbage. 
> 
> This is not a problem.  From RFC 2661, section 5.1.1: "To participate in 
> tunnel authentication, a single shared secret MUST exist between the LAC 
and 
> LNS. This is the same shared secret used for AVP hiding..." 
> ^^^^^^^^^^^^^^^^^^^^^^^ 
> 
> "Users" (what ever they might be in the context of L2TP) don't share 
secrets 
> with either the LAC or LNS. 
> 
> > 
> > Two workarounds to this: 
> > 
> > 1. LAC1 should reject user2 since the Tunnel Password for user2 is not 
the 
> > same as Tunnel password of T1 (its tunnel to LNS1). 
> > 2. If LAC1 does not reject user2 and allows it to get to LNS1 through 
T1, 
> > LNS1 should somehow magically figure out that the shared secret 
> > for user2 is 
> > wrong and bump out user2. 
> > 
> > Any ideas/suggestions as to how 2nd workaround can be implemented. 
> > 
> > 
> > Any help in this matter will be appreciated. 
> > 
> > Thanks in advance, 
> > 
> > Regards 
> > Kamlesh. 
> > 
> > 
> 
> 
> 

<<<<

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 1 Jun 2001 13:08:21 -0400

Also sprach Ignacio Goyret
>How can an LNS reject an ICRQ because the LAC's RADIUS server was
>misconfigured? The ICRQ does not contain a Tunnel-Password or anything
>derived from it.

>This is all a local implementation issue and has little to do with the
>protocol itself.

Agreed...I would think it would be up to the LAC to realize that the
tunnel password configured on the second user was not the same as the
tunnel password configured on the first and decide whether this should
be set up as a second tunnel or not.

I would think, personally, that a second tunnel would be in order, but I
can see where that might be an implementation issue.

That gives the LNS a chance to accept or reject the second password
independantly of the first.

I don't think necessarily that having different passwords would
necessarily be a RADIUS misconfiguration...I can conceivably see an LNS
accepting both passwords on seperate tunnels...potentially with
different configurations for them and the like (ObCrossThread: DiffServ
maybe?)

Unfortunately, the way the protocol is currently specified, there is,
indeed, no way for the LNS to confirm that the LAC is handling it this
way, so the LNS has no way of knowing if the LAC got the different
password but decided to start the new call on the existing tunnel, which
might end up being a violation of policy in some way...  I don't really
see a good answer to this one other than to specify how this should be
handled by the LAC and depend on the LAC getting it right.  I certainly
don't see a good way of enforcing one behavior or the other at the LNS.

So that leaves us with either deciding whether a new tunnel should be
created or not, and specify that behavior in the standard, or don't
decide it, leave it up to the LAC implementation and just let the LNS
suck it up and deal with whichever way the LAC decides to do it.  Either
way, the LNS really doesn't have any way of knowing what the LAC has
done.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456