Subject: RE: L2TP question on Tunnel Secret

From: "Kamlesh Agrawal" <[email-masked]>
Date: Fri, 1 Jun 2001 00:18:45 -0700

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]]
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]] 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: "Vipin Jain" <[email-masked]>
Date: Fri, 1 Jun 2001 08:14:12 -0700

I think, rejecting icrq would be the right choice.

-- vipin

-----Original Message-----
From: Kamlesh Agrawal [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

Kamlesh.

-----Original Message-----
From: Bill Baumann [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

Regards,
Bill Baumann

ideas/suggestions?
hidden
and
secrets
the
T1,

---

From: "Vipin Jain" <[email-masked]>
Date: Fri, 1 Jun 2001 10:08:59 -0700

Ignacio,

Of course this is a local issue at LAC and LNS action will not solve the
problem;
But say , LNS receives some hidden AVPs in ICRQ that were hided with a
different tunnel password what should LNS do? To answer that, I mentioned if
LNS finds some params that are not appropriate (i.e. seem garbage) then it
welcome to reject ICRQ.

-- vipin
nortel networks

-----Original Message-----
From: Ignacio Goyret [mailto:[email-masked]]
Sent: Friday, June 01, 2001 9:40 AM
To: Jain, Vipin [SC9:T337-A:EXCH]
Cc: 'kamlesh'; Bill Baumann; Glen Zorn; l2tp
Subject: RE: L2TP question on Tunnel Secret

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: 

-- 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 

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 

Regards, 
Bill Baumann 

On Thu, 31 May 2001, Glen Zorn wrote: 

> Kamlesh Agrawal
[<mailto:[email-masked]>mailto:[email-masked]]
ideas/suggestions? 
hidden 
and 
secrets 
the 
T1, 
> > Any help in this matter will be appreciated. 

<<<<

---

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

If a LAC is using different passwords to hide AVPs for different sessions
within the _same_ tunnel, I'd say that the LAC has a faulty software.
The tunnel password is for the tunnel not for a particular session.
If the ICRQ has any hidden AVPs, they MUST be hidden using the password
used when negotiating the tunnel. Tunnel passwords are not session attributes.

Now, whether the LAC should or should not even attempt to send an ICRQ
on a tunnel that has different tunnel-passwords but otherwise matching
parameters, is very much a LAC implementation issue.

I can see some benefits from doing it either way: rejecting the call
(I guess someone could make a security claim although it will be a pain
for any reasonably big service providers if they need to change TPs on
the fly) or accepting the call and ignoring the new differing TP (although
it may open a small security risk but remember that the LNS still has
to authenticate the call anyway).

Opening a new tunnel will most likely fail because the LNS will use the
Hostname AVP to search for the shared secret. Unless that string changes
as well (with a Tunnel-Client-Auth-ID), the SCCRQ/SCCRP/SCCN exchange
will certainly fail. Of course, if the Tunnel-Client-Auth-ID is different,
then the tunnel parameters do not match which should trigger a new tunnel
anyway.

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

Ignacio, 

Of course this is a local issue at LAC and LNS action will not solve the problem; 
But say , LNS receives some hidden AVPs in ICRQ that were hided with a different tunnel password what should LNS do? To answer that, I mentioned if LNS finds some params that are not appropriate (i.e. seem garbage) then it welcome to reject ICRQ.

-- vipin 
nortel networks 

-----Original Message----- 
From: Ignacio Goyret [<mailto:[email-masked]>mailto:[email-masked]] 
Sent: Friday, June 01, 2001 9:40 AM 
To: Jain, Vipin [SC9:T337-A:EXCH] 
Cc: 'kamlesh'; Bill Baumann; Glen Zorn; l2tp 
Subject: RE: L2TP question on Tunnel Secret 

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

-- vipin  

-----Original Message-----  
From: Kamlesh Agrawal [<<mailto:[email-masked]>mailto:[email-masked]><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  

Kamlesh.  

-----Original Message-----  
From: Bill Baumann [<<mailto:[email-masked]>mailto:[email-masked]><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  

Regards,  
Bill Baumann  

On Thu, 31 May 2001, Glen Zorn wrote:  

> Kamlesh Agrawal [<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>mailto:[email-masked]] writes:  
>  
> > Hi,  
> >  
ideas/suggestions?  
hidden  
and  
secrets  
the  
T1,  

<<<< 

<<<<

---

From: "Hari Kishan" <[email-masked]>
Date: Fri, 1 Jun 2001 11:01:58 -0700

As ICRQ has no mandatory hidden AVPs, it may not be possible
to reject the session looking only at ICRQ.

It may be possible for the LNS to detect this case
after the user session got established. Suppose
LAC encrypted a plain AVP "X" with a wrong password
and obtained the hidden AVP "Y" and has sent it to LNS.

LNS will decrypt "Y" with the (right)tunnel password and
obtains a plain AVP "Z".

Obviously "X" will not be equal to "Z". "Z" may contain
some garbage values. If LNS can look into "Z" and find
that one of the attributes has invalid value ( like
unknown VendorId field, or length of the packet does not
really indicate actual length received or unknown attribute
codes), it can detect that something wrong is going on
in that session. If this scenario arises several times on
the session(when several such decrypted AVPs are encountered
on the session), LNS can decide to drop the session.

This could be one way !!

--kishan

> From: [email-masked]
> [mailto:[email-masked]]On Behalf
> Of Jeff Mcadams
> Sent: Friday, June 01, 2001 10:08 AM
> To: Ignacio Goyret
> Cc: Vipin Jain; 'kamlesh'; Bill Baumann; Glen Zorn; l2tp
> Subject: Re: L2TP question on Tunnel Secret
>
>
> 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