Subject: RE: L2TP question on Tunnel Secret

From: "Hari Kishan" <[email-masked]>
Date: Fri, 1 Jun 2001 11:09:47 -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

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

---------------------------------
Hari Kishan Desineni,
Ericsson Inc,
Data Backbone & Optical Division,
Santabarbara,
California - 93117
Office:(805) 562 6419
Home:(805) 968 1894

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 01 Jun 2001 13:15:55 -0700

>to reject the session looking only at ICRQ.

That's right: there are no AVPs that require hiding. Hiding
is always optional.

>and obtained the hidden AVP "Y" and has sent it to LNS.

If the LAC uses the wrong password to hide an AVP, it means
that the LAC is broken.

The LNS may or may not be able to figure out that the AVP was
hidden with the wrong password. If it can, it is within its
right to drop the call.

---

From: "Hari Kishan" <[email-masked]>
Date: Fri, 1 Jun 2001 18:03:44 -0700

I agree that the LAC is broken. I was explaining
a method to handle a session initiated by a broken LAC.

Do you think that my solution will work for a LNS
to detect such sessions initiated by some broken LAC
implementations??

--kishan

==================================
Hari Kishan Desineni,
Ericsson Inc,
Data Backbone & Optical Division,
Santabarbara,
California - 93117
Office:(805) 562 6419
Home:(805) 968 1894 

> Of Ignacio Goyret
> Sent: Friday, June 01, 2001 1:16 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: L2TP question on Tunnel Secret
> 
>

---

From: "Hari Kishan" <[email-masked]>
Date: Fri, 1 Jun 2001 13:56:03 -0700

--kishan

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 02 Aug 2001 07:04:57 -0600

> to detect such sessions initiated by some broken LAC

Did you try turning on tunnel authentication? The LAC and LNS MUST use
the same secret for hidden AVPs as it does for Tunnel Authentication. Of
course, this doesn't work if your LAC is broken in this regard as well.

Note that in the latest l2tp-bis draft there is a MUST that tunnel auth
be performed if any avps are hidden (thereby disallowing hidden avps in
the SCCRQ and SCCRP). This was not so clear in RFC2661.

- Mark