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

From: "Glen Zorn" <[email-masked]>
Date: Sat, 16 Jan 1999 11:46:50 -0800

Stuart A Barkley <[email-masked]> writes:

>I would be happier without any words at all.  Then I don't need to
>keep explaining why it is bad and unneeded to people who only see that
>a new RFC has been published and feel the need to jump on the
>implementation bandwagon.  On the other hand, if there is really some
>useful benefit I would like to understand what that is.

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

>--
>Stuart A Barkley                        email: [email-masked]
>
>-
>To unsubscribe, email [email-masked]' with
>'unsubscribe ietf-radius' in the body of the message.
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 17 Jan 1999 00:00:28 +0100

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

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]

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

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

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

What have I missed?

                      Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

-

---

From: "Mike O'Dell" <[email-masked]>
Date: Sat, 16 Jan 1999 18:20:58 -0500

let me try on Stuart's behalf

we believe it is *highly* irresponsible to standardize
something which is extremely dangerous.

there is no reason to do tunneling if you don't intend to
encrypt the tunnel. otherwise, the tunnel accomplishes
nothing that cannot be done as easily with other mechanisms
like route or packet filters.

if you do encrypt the tunnel, then the tunnel *must* go all
the way to the mobile machine and *not* stop at the NAS;
otherwise the NAS must be the equivalent of "multi-level
secure" (and with compartments).  if the tunnels stop at
the NAS then you have an element in the protection
boundaries (note the plural) which is shared between
mutually-antagonistic parties and that is just madness.

it is profoundly naive, not to mention irresponsible, for
the WG to just say "the NAS implementation has gotta be
good enough to use this feature". there are some features
for which that warning is arguably sufficient.  however, having
a NAS a shared element in multiple protection boundaries
is a threat of a completely different magnitude and 
is simply indefensible.

	-mo

========================
Mike O'Dell
VP, Chief Scientist
UUNET - the MCI/Worldcom Internet Company

3060 Williams Drive
Fairfax, VA 22031
Voice: 703-206-5890
Fax:   703-206-5601
Email: [email-masked]
-

---

From: [email-masked] (Ran Atkinson)
Date: Sat, 16 Jan 1999 15:51:06 -0800

To clarify my position a bit:

	- I think that the current draft is indefensible because
	  it doesn't document the issues thoroughly.  Glen Zorn
	  appears to be working on resolving this.

	- If the draft is revised appropriately and documents clearly
	  the issues and concerns being raised, I won't object at
	  Last Call.  However, the revised text needs to be bold
	  and clear, not timid and diplomatic IMHO.

	- Generally speaking, RADIUS does NOT have good security
	  properties and (like many other protocols) is being
	  extended beyond its appropriate use.  IMHO this is why
	  the IESG chartered RADIUS WG so narrowly and more generally
	  why narrow IETF WG charters are strongly desirable.

Ran
[email-masked]
-

---

From: Aydin Edguer <[email-masked]>
Date: Sat, 16 Jan 1999 21:41:41 -0500 (EST)

> like route or packet filters.

False.  L2TP allow the transport of non-IP protocols over an IP network.
This cannot be accomplished with route or packet filters.

False.  L2TP allows the transport of IP and other protocols back to a
centrol location while hiding the intervening topology and thus avoiding
increases in hop count and permitting the use of private address space
across the public Internet.  This cannot easily be accomplished with
route or packet filters.

However, this does not raise questions for the RADIUS-WG - your questions
are better directed to the working groups that created L2TP or the customers
that want to use L2TP, L2F, PPTP, GRE, and ATMP and offer them as value
added services.

The RADIUS-WG is trying provide guidelines for using the current protocol
used to configure services, such as SLIP and PPP for dial-up clients to
configure the tunneling services for dial-up clients.

-

---

From: "Mike O'Dell" <[email-masked]>
Date: Sat, 16 Jan 1999 21:47:17 -0500

ok, the list of Bad Ideas is even longer.

	-mo
-

---

From: Dave Mitton <[email-masked]>
Date: Mon, 18 Jan 1999 18:20:47 -0500

>something which is extremely dangerous.

	I yet to figure out what is "dangerous" here.

>like route or packet filters.

	I think this is your opinion.  Tunnel technology is deployed and has been
in use by multiple vendors for several years now.  Shiva, Cisco(L2F),
USR/3Com (VTP), Bay (DVS), Ascend (ATMP)
	Someone must think it's useful for something.
>mutually-antagonistic parties and that is just madness.

	The typical setup does not terminate a tunnel, but initiates a tunnel from
the NAS to the designated server, under the provisioning and control of the
service provider.  Hence the term "mandatory" tunnelling.
	The provisioning of the service is from the service provider's NAS to the
mutually-cooperative tunnel server (usually governed by the form of a
service contract).  This cooperation forms the trust basis, and
compartmentalization between the parties.

	The data stream actually carried over the tunnel is only presumed to IP
packets which COULD be encrypted via any means agreed upon between the
source and the sink.  However that is not part of the service being
discussed here, nor for layering purposes should it be.

>is a threat of a completely different magnitude and 
	Sorry, still don't get what you mean.  While I don't intend to be
irresponsible, I don't see how I/we am/are.

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