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

From: William "Chops" Westfield <[email-masked]>
Date: Fri, 15 Jan 99 14:19:56 PST

> A worry has been expressed to me that this set of drafts describe
    > how to set up a tunnel between a corporate firewall and a NAS box.
    > This would make the NAS box part of the trust boundary of the
    > corporation, and expose the NAS box operator to heavy liability and
    > operational problems

    I have problems with this concern.  RADIUS makes the NAS a trust
    boundary as it is.  What makes this any different?  This sort of
    strengthens the current house of cards, or it's just more of the same.
    What's the real problem here?

I agree completely.  A NAS is by definition part of the "trust boundry" of
a corporation - I don't see how it matters if your incoming users come in
through tunnels, or over POTS lines...

BillW

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 15 Jan 1999 17:11:38 -0500

Mike O'Dell writes:

> so as a manufacturer of NAS equipment, is Bay prepared to
> assume the liability in the ensuing lawsuit (eg, indemnify
> the ISP using your hardware) when SEC-critical financial
> information (being carried because - "it's safe - it's
> encrypted!") from company A is disclosed to company B???
> 
In response, I observe that:

1.) there are many things in life whose use requires judgment and
are not inherently "safe",

2.) any idiot can sue anyone else on any given day, usually with the
complicity of a greedy lawyer; it doesn't mean the case has any merit,

3.) many foolish things have been done and many wise things have
been left undone simply because of sabre-rattling threats of litigation,

4.) by this logic no one would manufacture or sell inherently dangerous,
but useful, items such as automobiles, lawn mowers, snow blowers, 
kitchen knives and security software, and

5.)  yes, many manufacturers do carry product liability insurance.   

Regards,

Dave

David B. Nelson                          Cabletron Systems, Inc.
Software Engineer V                      50 Minuteman Road
(978) 684-1330                           Andover, MA 01810

-

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 15 Jan 1999 13:59:48 -0800

Mike O'Dell <[email-masked]> writes:
>
>it is patently irresponsible to promulgate a protocol feature
>which is known to have *catastrophic* security implications
>
> -mo
>
>

What?

---

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

Mike and Harald seem on target to me.

Ran
[email-masked]

--- Forwarded mail from "Mike O'Dell" <[email-masked]>
Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts
Date: Fri, 15 Jan 1999 16:53:26 -0500
From: "Mike O'Dell" <[email-masked]>

	-mo
---End of forwarded mail from "Mike O'Dell" <[email-masked]>
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 18 Jan 1999 16:46:28 -0800

Mike O'Dell <[email-masked]> writes:

>
>let me try on Stuart's behalf

Thanks!

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

Hmm.  Depending upon ones' point of view, it seems that virtually anything
could fit into that category.  SNMP comes immediately to mind, as does
non-escrowed IPSec.

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

I don't think that this is true.  For example, L2TP can be used to carry
non-IP protocols over the Internet.  Many people think that that's useful.
While it's true that L2TP clients could be written for and installed on
dialup hosts, this would entail considerable user and administrator
involvement, which many people think is bad.

>
>if you do encrypt the tunnel, then the tunnel *must* go all
>the way to the mobile machine and *not* stop at the NAS;

No, _security_ should extend end-to-end.  "Tunnel" and "security" are not
the same thing.  I think that it's likely that many LAC implementations will
use IPSec, but that use will be to protect the control channel and perhaps
the PPP negotiations on the data channels (to avoid some of the problems
involved with passing domain names in the clear, for example).   You seem to
be suggesting (correct me if I'm wrong) that we are somehow trying to
subvert the idea of end-to-end security, which is absolutely not true.

>otherwise the NAS must be the equivalent of "multi-level
>secure" (and with compartments).

In other words, it has to keep the data (and the associated keys) destined
for the various LNS seperate and make sure that the data is delivered to the
correct place.  I suspect that (crypto or no) any LAC that couldn't forward
packets correctly would not be a big seller ;-)

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

This argument may be valid.  If it is, then it certainly applies to backbone
routers and security gateways as well, does it not?

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

That depends upon what is being protected.  If and only if the LAC is
considered as the sole provider of security for the tunneled connections is
the user data at risk.  If the end-to-end principle is applied and the user
data itself is protected, I can't see how there is any danger.

>
> -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: "Beadles, Mark A." <[email-masked]>
Date: Wed, 20 Jan 1999 16:20:53 -0500

From:	Harald Tveit Alvestrand [SMTP:[email-masked]]
>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?

The first case is certainly limited, although that in itself should not be a
reason to halt advancement of the draft, IMHO.  However, you are correct,
the second case is certainly more interesting.  

But LAN access is a much broader scope, and brings up many scenarios that
can be ideally met by compulsory tunneling.  Examples include:
-Remote access over the internet to a non-IP LAN, for example an IPX
network.
-Remote access, using a non-IP intervening network, to an IP network (e.g.
L2TP over ATM tunneling to an IP network).
-The "distributed NAS" scenario, a very interesting one IMHO.  User dials
into one NAS, begins PPP, is L2TP tunneled to a second NAS, which finishes
PPP and provides access to the user's home network, which may not be
otherwise accessible.  The two NAS's can be regarded as two halves of a
distributed NAS which provides access to the home network.  The intervening
L2TP tunnel takes the place of the backplane on a standard NAS.
-Remote access over the internet to a non-public, non-unique IP address
space.

Certainly anyone who is extermely concerned about security will ALSO perform
encryption end-to-end, perform authentication within the end application,
and perform bidirectional authorization at the NAS.  Compulsory tunneling
does not prevent anyone from applying these security measures if they so
desire.   But the functionality provided by compulsory tunneling goes beyond
pure "security". 

Perhaps some of the fear here is that naive users and providers will be
confused by this document into thinking that compulsory tunneling is the
ONLY security that need be applied.  I suppose we could insert some words of
warning into the draft to indicate that is NOT the point.  

However, the flip side of this mode of thinking is that if compulsory
tunneling is involved, then the resulting network is somehow insecure no
matter what other measures are applied.  This is also wrong.  We have many
years of experience here providing remote LAN access over a global public
network using compulsory tunneling (admittedly non-IP), and we have never
experienced the catastrophic failures predicted by others on this list,
because we apply MANY other security measures.  Compulsory tunneling is
simply a mechanism that allows providers to build highly functional, almost
customizable, networks for end users.

+ Mark Anthony Beadles + MCI WorldCom Advanced Networks +
+  [email-masked]   +        http://www.wcom.net     +
+  Voice 614.723.1941  +          Fax 614.723.8407      +

> -----Original Message-----
> From:	Harald Tveit Alvestrand [SMTP:[email-masked]]
> Sent:	Saturday, January 16, 1999 6:02 PM
> To:	[email-masked]; Stuart A Barkley; Glen Zorn
> Sender: [email-masked]
> Received: from bast.livingston.com (bast.livingston.com [149.198.247.2])
> 	by hil-img-6.compuserve.com (8.8.6/8.8.6/2.17) with ESMTP id
> SAA21478
> 	for <[email-masked]>; Sat, 16 Jan 1999 18:02:15 -0500
> (EST)
> Received: from server.livingston.com (server.livingston.com
> [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id
> OAA00613; Sat, 16 Jan 1999 14:58:48 -0800 (PST)
> Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9)
> id OAA15760 for ietf-radius-outgoing; Sat, 16 Jan 1999 14:59:03 -0800
> (PST)
> Message-Id: <[email-masked]>
> X-Sender: [email-masked]
> X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
> Date: Sun, 17 Jan 1999 00:00:28 +0100
> To: "Glen Zorn" <[email-masked]>, "Stuart A Barkley"
> <[email-masked]>,
>         <[email-masked]>
> From: Harald Tveit Alvestrand <[email-masked]>
> In-Reply-To: <[email-masked]>
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> Sender: [email-masked]
> Precedence: bulk
> Reply-To: Harald Tveit Alvestrand <[email-masked]>
> 
> 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.
> 
> 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: "Beadles, Mark A." <[email-masked]>
Date: Wed, 20 Jan 1999 16:33:34 -0500

From:	Beadles, Mark A. [SMTP:[email-masked]]
>Please do not confuse Mr. Barkley's opinions with the opinions or products
>of MCI WorldCom.  

Before everybody jumps all over me....Please do not confuse MY opinions with
those of MCI WorldCom, either. They are my own.

-

---

From: "Beadles, Mark A." <[email-masked]>
Date: Wed, 20 Jan 1999 16:42:04 -0500

>Failing to find a purpose for these protocols, I need to also question
>the size of the effort to implement these.  I find 274 pages of L2TP
>internet drafts plus 43 pages of radius L2TP internet drafts.  This
>represents a very large code base for vendors to develop, properly
>debug and support.  We have many other things which we need our
>current and future vendors to work on for us. 
>
>Within the L2TP protocol specifications themselves I find a number of
>things which appear to reimplement existing functionality.  L2TP
>appears to reimplement much of both TCP and IP which is something
>else which seems to need clear reason.  

If you find that the L2TP protocol ITSELF is deficient or unnecessary,
please take it to the L2TP list.  (I would recommend you do it quickly, too,
BTW, since it's currently in draft 12 and is basically functionally "done").

But this is the RADIUS list, and we are discussing the draft in question,
not the applicability or size of the entire L2TP protocol.

> From:	Stuart A Barkley [SMTP:[email-masked]]
> Sent:	Tuesday, January 19, 1999 7:26 PM
> To:	[email-masked]
> Subject:	RE: (radius) WG LAST CALL on L2TP RADIUS Drafts
> 
> 	by hpamgaaa.compuserve.com (8.8.8/8.8.8/HP-1.0) with ESMTP id
> TAA02332
> 	for <[email-masked]>; Tue, 19 Jan 1999 19:25:13 -0500
> (EST)
> QAA13948; Tue, 19 Jan 1999 16:15:08 -0800 (PST)
> id QAA11704 for ietf-radius-outgoing; Tue, 19 Jan 1999 16:16:33 -0800
> (PST)
> Date: Tue, 19 Jan 1999 19:16:14 -0500 (EST)
> From: Stuart A Barkley <[email-masked]>
> To: [email-masked]
> Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts
> In-Reply-To: <[email-masked]>
> Message-ID: <[email-masked]>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Reply-To: Stuart A Barkley <[email-masked]>
> 
> First, let me repeat that I haven't given the L2TP RADIUS drafts as
> much attention as they deserve.  I have also not given L2TP itself
> strong attention in the past, but I did give earlier drafts a quick
> once over orientation pass.  I expect to have more time to pay
> attention to and be involved with various IETF activities in the not
> too distant future. 
> 
> Now that this work has progressed into an area I'm currently directly
> monitoring and am concerned with, I need to raise issues that I see.
> Certainly a number of these issues are more directly related to pppext
> or other working groups.  However, since I don't have the history in
> those groups and others on the radius mailing list may have similar
> lack of background I will keep this discussion here for now. 
> 
> My arguments against this set of extensions consist of 2 major areas:
> 
>  - having a meaningful purpose
>  - size, implementation time, debug time and support of the extensions
> by NAS vendors
> 
> The L2TP radius protocol drafts refer to three examples for using L2TP
> (in draft-ietf-radius-tunnel-imp-04.txt section 6): 
> 
>  - Internet software upgrade servers
>  - Software registration servers
>  - Banking services
> 
> I don't see how any of these examples pose any problem with existing
> technology.  These can be solved with routing filters applied when
> dedicated service is desired and can be solved with either generic IP
> connectivity support or dedicated client based tunneling otherwise. 
> There are some areas for roamops/radius to standardize functionality
> for better interoperablity among multiple NAS vendors and ISPs.
> 
> Section 6.1 of draft-ietf-radius-tunnel-imp-04.txt goes on to describe
> "Advantanges of RADIUS-based compulsory tunneling".  This describes
> why user based radius attributes are advantageous over static or realm
> based attributes, but fails to provide any further insight on why
> compulsory tunneling is desired.
> 
> Some other purposes for L2TP which have been proposed on this list and
> elsewhere include:
> 
>  - Non IP protocols
>  - hop count/TTL reduction
>  - private/unregistered IP address space
>  - multilink PPP
> 
> These don't seem to be reasons for L2TP either.  Multi protocol
> routers exist and the other problems are general internet issues.
> 
> The following reasons appear to be valid issues with running client
> tunneling protocols.  Perhaps we need some extended ppp options to
> transfer needed information to the client: 
> 
>  - Administrative issues on client
>  - Client tunnel configuration by remote service
> 
> So overall I have yet to see what I consider a sufficient reason for
> spending any time working with these protocols.  If there are any
> other reasons someone would want to run compulsory tunneling I would
> like to understand the reasons.  Given the large amount of time which
> has already been spent on this and the number of people working on
> these protocols I assume there must be some real reasons for these
> somewhere. 
> 
> Failing to find a purpose for these protocols, I need to also question
> the size of the effort to implement these.  I find 274 pages of L2TP
> internet drafts plus 43 pages of radius L2TP internet drafts.  This
> represents a very large code base for vendors to develop, properly
> debug and support.  We have many other things which we need our
> current and future vendors to work on for us. 
> 
> Within the L2TP protocol specifications themselves I find a number of
> things which appear to reimplement existing functionality.  L2TP
> appears to reimplement much of both TCP and IP which is something
> else which seems to need clear reason.  In order to give L2TP itself
> the necessary time to understand its full implications I would also
> still be needing some understanding of what it claims to offer.
> Without that its hard to determine if it actually meets its design
> goals.
> 
> Stuart
> -- 
> Stuart A Barkley                        email: [email-masked]
> 
> -
-

---

From: "Beadles, Mark A." <[email-masked]>
Date: Wed, 20 Jan 1999 17:41:08 -0500

From:	Mike O'Dell [SMTP:[email-masked]]
>ah yes - it happens in the best of families....
>
>please do not confuse WANS opinions with those of UUNET,
>where we do not offer tunneling and don't intend to start

Mr. Odell brings up an excellent point here.  It will be up to each
individual service provider whether they wish to offer services enabled by
the draft in question.  And it will be up to each individual NAS vendor
whether they wish to sell NAS's that adhere to this draft.  And this is
obviously a controversial draft, given that there are such strong opinions
on both sides, even within a "single" organization.

However, I don't believe we are trying to mandate service offerings or NAS
feature lists here.  What we seem to be trying to do is bring
standardization to a very fragmented functional set that is already offered
by most NAS vendors.  Many, but not all, service providers would like to
offer services based on this draft.  Many NAS vendors appear willing to
conform to this functionality.

If we can come to agreement on some wording strongly admonishing users and
providers not to bet the farm on compulsory tunneling, is there anyone who
would still oppose adoption of the draft?  Is anyone working on such
wording, or have suggestions?

-

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 27 Jan 1999 02:29:20 -0800

>Bernard, these two paragraphs form a completely adequate (to me)
>security section for the tunnel-impl draft!
>(Of course, this depends on L2TP always using PPP inside; is this
>always true?)

Yes, L2TP always tunnels PPP.

>Glenn, Bernard, is it OK to take this text and put it there

Yes, it is ok to add the text below to the "Security considerations"
section.

>Absolutely.
>That is *exactly* what a security section is supposed to be.
>Or rather, for the tunnel-auth draft: The list of questions that each
>mode of operation raises, which each tunnelling protocol has to answer.

Such an analysis is supplied for L2TP in the L2TP security draft.
Interestingly, while the draft was placed on the standards track by
PPPEXT, it has been unclear to me what the IESG wanted to do
with it. It was decided not to include it in the L2TP draft proper
so as to allow its expedited advancement. Given the questions,
I'd suggest that an L2TP security analysis is necessary and
needs to be on the standards track.

>
>>Such an analysis belongs in the relevant protocol drafts, not in
>>this set of documents.
>
>The answers, yes. The questions, no.

From the above discussion, I think we can come up with an
abreviated list of questions and brief answers relating to
compulsory tunneling.

>Failures of others.....the L2TP documents have been yelled at,
>objected to, commented and asked for revisions of on so many other
>points (including the need to document numerous security problems)
>that the particular issues that pertain to operating a NAS box that
>is not implicitly in the same trust domain as the tunnel endpoint
>have not been raised.
>It does not excuse us; WE are the ones responsible for the multi-domain
>situation.
>

I'm available to assist in preparing any material relating
to L2TP security that the IESG may request. My experience
with this is that the issues can be somewhat intricate so that they
are worth explaining in detail. These can include subjects as
arcane as why L2TP/IPSEC is not compatible with NAT (answer
has to do with IKE; if UDP checksumming is turned off and
IPSEC ESP is used, L2TP/IPSEC packets should pass
the NAT.)

-