Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts

From: "Glen Zorn" <[email-masked]>
Date: Mon, 18 Jan 1999 18:48:13 -0800

Harald Tveit Alvestrand <[email-masked]> writes:
>At 11:46 16.01.99 -0800, Glen Zorn wrote:
>>
>>I think that it would be more useful if you could explain to _us_ (since
we
>>obviously don't get it!) why the entire concept of compulsory tunneling is
>>"bad and unneded".  Preferably this explanation would take the form of
>>clear, English sentences without references to either cryptography or
>>metaphorical "fluids".  Hint: "I don't like it" is _not_ helpful; neither
is
>>"If it becomes a standard, UUNET will have to do it and we don't want to".
>
>play it again, sam.....
>
>Let us see if I can understand what this thing actually does.
>NOTE: I *still* don't feel that I understand it, so feel free to correct
me.
>
>When an end system connects to a NAS, and gets Internet connectivity,
>the end system is free to set up tunnels to anywhere it wants to, using any
>mechanism the service it connects to allows.
>For a PPP connection, it can use IP-in-IP tunnels, for instance.

Yes, that's true; it may be irrelevant, however, since the end system will
never see any RADIUS packets - these attributes are designed to support
_only_ tunnels that originate at the NAS.

>
>The list of tunnel technologies mentioned in -auth is:
>
>       1      Point-to-Point Tunneling Protocol (PPTP) [1]
>       2      Layer Two Forwarding (L2F) [2]
>       3      Layer Two Tunneling Protocol (L2TP) [3]
>       4      Ascend Tunnel Management Protocol (ATMP) [4]
>       5      Virtual Tunneling Protocol (VTP) [5]
>       6      IP Authentication Header in the Tunnel-mode (AH) [6]
>       7      IP-in-IP Encapsulation (IP-IP) [7]
>       8      Minimal IP-in-IP Encapsulation (MIN-IP-IP) [8]
>       9      IP Encapsulating Security Payload in the Tunnel-mode (ESP)
[9]
>       10     Generic Route Encapsulation (GRE) [10]
>       11     Bay Dial Virtual Services (DVS)
>       12     IP-in-IP Tunneling [11]
>

Several of those (especially the IPSec ones) don't seem very useful to me.
I believe I had originally included just the first four; the rest were added
later (many at the request/suggestion of Ran Atkinson).

>(BTW, this reminds me: Any such list means that it will get longer in
>the future. There is no IANA considerations section in this document,
>and I can't find any other mechanism whereby new identifiers are
>allocated. This must be fixed - see "IANA considerations" RFC)

Good point.

>
>>From the way L2TP is described, it seems to be intended for the
>scenario where all traffic from an end-system is going into the tunnel;
>L2TP is also strongly biased towads "not modifying the PPP-using end
system",
>which means that L2TP tunnels will terminate at the NAS, not the end host.

Yes.

>For the other technologies, both approaches may be possible.
>
>The scenario described where mandatory tunnelling is useful:
>
>"These are
>all services which, without compulsory tunneling, would probably be pro-
>vided  using  dedicated  networks  or  at least dedicated network access
>servers (NAS), since they are characterized by the need  to  limit  user
>access to specific hosts."
>
>Now, let's play this scenario:
>
>  Someone dials into a NAS box.
>  He presents an identifier, and authenticates, in order to use general
>  Internet access (or corporate LAN access, or whatever).

Maybe, maybe not.  It's quite possible that (s)he might have been handed a
canned object designed just to connect to a certain host or network on the
Internet.

>  He then fires up his home banking application, installs software, or
>  does something else that invokes one of these "dedicated" services.
>
>  He's now supposed to DISCONNECT FROM THE INTERNET in order to use
>  these "dedicated" services, which are provided over the SAME
NETWORK??????
>
>(note - I regularly keep chat sessions, extra Web browser windows and so on
>open and active while doing Web-based banking - my bank is just SLOW.....)

Here's a different example (which doesn't assume the sophisctication of you
or I ;-): I have a neighbor who is Internet illiterate and has no desire to
get an account with an ISP.  Nevertheless, he has a modem and would love to
have the convenience of on-line banking.  The bank, OTOH, has no desire to
install and maintain a bank of modems so that people like my neighbor can
dial in directly.  With compulsory tunneling, the bank can easily outsource
the access service and supply my neighbor with a floppy disk with a
self-contained object on it that will dial a selected number and have the
connection automatically tunneled to its server across the Internet.
End-to-end security might be supplied by TLS, or Kerberos, whatever.  The
bank likes this because it can ensure that no (more knowledgeable) customer
can use the disk to start a connection, then spend hours downloading porn on
it's dime and because it doesn't have to be locked into a single ISP's
architecture (unlike the alternative of address filtering on the NAS).  My
neighbor likes it because he gets to do the what he wants w/o having to
learn a bunch of stuff about something he doesn't care about.  It's true
that this particular scenario could be implemented using RADIUS and NAS-side
address filters; the problem with this (from the bank's point of view) is
that this approach seriously reduces the bank's flexibility in choosing a
service provider, because address filters in RADIUS are quite
vendor-specific.

>
>This means that the usefulness of mandatory tunneling is limited to two
>cases (IMHO, of course):
>
> - The case where what is sent through the tunnel is the only thing the
>   person CAN be doing at the moment (such as boot-time registration)

Actually, I'm inclined to think that that is the only case.

> - The case where what is sent through the tunnel is the only thing the
>   person WANTS to be doing at the moment (such as secured corporate
>   LAN access).
>
>The first one seems a very limited scope.

Actually, the scope is huge.

>The second one seems to be what this spec is aimed at, but I can't tell
>what situation is suited to both this and NAS termination of tunnels.

Suppose that
1) my employer supplies me w/an ISP account, so that he can reduce costs by
outsourcing remote access
2) he would much prefer that I spend the time he is paying for doing
actually accessing the corporate network, as opposed to surfing
3) effective use of my corporate network requires that I use an IP address
_on_ that network (instead of the ISP's network)

This _could_ all be accomplished through the use of voluntary tunneling and
IP address filters, but it is _much_ simpler for everyone involved to use a
compulsory tunnel.

>
>What have I missed?
>
>                      Harald A
>
>
>
>
>
>
>
>--
>Harald Tveit Alvestrand, Maxware, Norway
>[email-masked]
>
>-
>To unsubscribe, email [email-masked]' with
>'unsubscribe ietf-radius' in the body of the message.
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 20 Jan 1999 05:51:49 +0100

I think we're converging towards an agreement:

- Tunnelling (of the type we're talking about here) isn't useful for
  security. It's useful for making connections for things that
  otherwise wouldn't run across the open Internet.
- At least with L2TP, tunnels are between the NAS and the site
  being connected to. There is no definition for anything else at
  the moment.
- If the customer wants security, he should supply it end-to-end;
  the NAS should be treated with no less distrust (and no more) than
  any other ISP device.

I don't think it's a terribly useful service:

At 18:48 18.01.99 -0800, Glen Zorn wrote:
>dial in directly.

well.....he may not understand much about the Internet, but he does
understand "the football game stops showing when I access my bank".

I think using the PC for one thing at a time is a paradigm that
won't last for long.

But my disbelief in the model won't make me stop shipping documents,
if the document, to my mind, gives a correct representation of what
it's good for.

                     Harald A

-

---

From: Chip Sharp <[email-masked]>
Date: Thu, 21 Jan 1999 09:23:13 -0500

>  being connected to. There is no definition for anything else at

Actually, the current specifications allow an IP client to set up a L2TP
tunnel to the LNS.  This is sometimes called "voluntary" tunneling as
opposed to the "compulsory" tunneling when the NAS initiates the tunnel to
the LNS.

>  the NAS should be treated with no less distrust (and no more) than

There are many levels and types of security.  End-to-end (e.g.,
client-to-client, application-to-application) authentication, authorization
and encryption is certainly more secure than relying on an L2TP tunnel.  Of
course, it doesn't matter what kind of alarm system you have on your Benz
if someone steals your keys. :-)

...snip...

--------------------------------------------------
Chip Sharp                 voice: +1 (919) 851-2085 
Cisco Systems              Consulting Eng. - Telco   
Reality - Love it or Leave it.			
--------------------------------------------------
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Dave Mitton <[email-masked]>
Date: Thu, 21 Jan 1999 10:53:59 -0500

>opposed to the "compulsory" tunneling when the NAS initiates the tunnel to

	Which specifications?  Can you point me at the citation?  Thanks.

These drafts discuss how to use RADIUS to setup a tunnel.  For the most
part a compulsory tunnel (even in the title...).  I'm not really aware of
voluntary implementations, so they're not discussed much.

But more to the point, RADIUS is only engaged during an authentication or
service initiation.  You mention an "IP client", but once someone becomes
an IP (PPP) client of the network, they have already passed through the PPP
authentication phase, and they have no interface to RADIUS, or for that
matter no really defined way to engage the services of the NAS further.
They have the service intended by their provider.

If they wish to start a tunnel from their own client, that is an end-to-end
decision, and they must know the appropriate access information to proceed.

The typical way someone may interface to NAS to initiate voluntary
tunneling, would be via an async terminal style connection.  Then they can
type a command to start a tunnel, (I believe Shiva supports this?) This
would initiate a new RADIUS authentication cycle and the attributes as
provisioned in the NAS'es RADIUS server will  come into play.

It's been stated by others in this discussion that somehow these
specifications allow callers to terminate or initiate tunnels to anywhere.
This is false.

These specifications provide a standard communication path between the NAS
and the RADIUS server to provision a service.  The user has no control or
visibility into this process.  For an IP client, he is not even let out of
the PPP authentication phase until the service is completely setup. This
means authentication by the remote gateway/LNS and likely a remote domain
authentication server.

>if someone steals your keys. :-)
---------------------------------------------------------------
David Mitton					978-670-8888 Main
Consulting Engineer, Nortel	Networks	978-916-4570 Direct
Carrier Packet Networks, I&SP Group	978-916-4789 FAX
Billerica, MA 01821				[email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Jan 1999 17:25:29 +0100

>specifications allow callers to terminate or initiate tunnels to anywhere.
The hint that led me to believe that it might be possible is that the
specification includes attributes for the addresses of BOTH ends of the
tunnel. But these attributes are only sent to the NAS, who has no standard
way of telling anyone else about them, so....

It was only when I re-read the "tunnel-imp" draft that I came to the
conclusion that endsystem termination wasn't supported.

                   Harald

-

---

From: Chip Sharp <[email-masked]>
Date: Thu, 21 Jan 1999 11:37:29 -0500

>	Which specifications?  Can you point me at the citation?  Thanks.
..snip...
Mea Culpa. Sorry folks. With all the discussion of whether L2TP is a valid
protocol or not, I forgot what mail list I was on or what
documents/protocols were being discussed. :-\
I was wrong.  As far as I know there are no specifications anywhere for
RADIUS to set up a client-initiated L2TP tunnel.  Nor do I hope ever to see
one (let's see, we define a new RADIUS attribute and a new LCP parameter to
tell the PPP client to initiate a L2TP tunnel to the defined LNS. ;-) ;-)
;-) ).

Chip