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

From: "Beadles, Mark A." <[email-masked]>
Date: Fri, 15 Jan 1999 13:52:29 -0500

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

If the NAS box operator is not willing to accept this liability and
operational
issues, then the NAS box operator should not offer this type of service.
That
is a business question, not a protocol question.  

On the other hand, there are service providers who are willing to accept the
liability and operational issues, and customers who are willing to accept
the
redrawing of trust boundaries in order to receive the functionality desired.

We cannot let protocols dictate business models.  We must make our protocols
flexible enough to accommodate any reasonable business model.
Traditionally,
a strict demarcation has been seen between the customer's network and the
service provider's network, and neither party has trusted the other.  This 
model is changing, there are now service providers willing to take on the 
greater operational burden, and customers willing to expose themselves to 
greater calculated risk.

The functionality described in these drafts is absolutely needed, and yes,
one
of the areas of application WILL be tunneling between a corporate firewall 
and a NAS box.  I agree that this should only be undertaken when both
parties
are fully aware of the risks inherent in this.

I would be happy with wording that stated, basically, that creating a tunnel
between a NAS box and a customer gateway can result in a connection that 
crosses trust boundaries, and as such, should only be done when a thorough
security analysis has been performed.

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

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 15 Jan 1999 23:13:15 +0100

>flexible enough to accommodate any reasonable business model.

Agreed. I care about quality of documentation and "fair warning", not about
saving the world from itself.

IF (the security section of?) this draft set discusses the diverse models
for deployment and the dangers they incur to the point where I can see at
once what I had to have pointed out to me, I have no real problem with
shipping it; sort of "This is a gun. That is your foot. If you put your
finger here and pull, your foot will not be terribly useful."

Or to use another metaphor: I don't want to lower the temperature of
McDonald's coffee (it's bad enough as it is), I want to make sure people
know it's hot.

If possible.

                  Harald A

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

-

---

From: Stuart A Barkley <[email-masked]>
Date: Fri, 15 Jan 1999 17:46:46 -0500 (EST)

On Fri, 15 Jan 1999, Beadles, Mark A. wrote:

> operational issues, then the NAS box operator should not offer this
> type of service.  That is a business question, not a protocol
> question. 

However the NAS operator may not understand the implications until it
is too late.  People often mistake the fact that something is
published in a RFC as a statement that it is good and useful.  They
often don't understand the different statuses of RFCs and will seek
RFC buzzword compatibility with everything published. 

> On the other hand, there are service providers who are willing to
> accept the liability and operational issues, and customers who are
> willing to accept the redrawing of trust boundaries in order to
> receive the functionality desired. 

Where does this liability end?  Can we (IETF or individual
contributers) be considered liable because we make a (perceived)
recommendation that this is acceptable behavior?

> We cannot let protocols dictate business models.  We must make our
> protocols flexible enough to accommodate any reasonable business
> model.  Traditionally, a strict demarcation has been seen between
> the customer's network and the service provider's network, and
> neither party has trusted the other.  This model is changing, there
> are now service providers willing to take on the greater operational
> burden, and customers willing to expose themselves to greater
> calculated risk. 

As I see it, it isn't a necessary protocol.  A client can do the
tunneling themselves if that is necessary, there are existing
protocols for this.  A service provider can apply ip filtering to the
NAS data if the customer wants to restrict access to only a single
firewall entrance point (Compulsory Tunneling apparently being the
only documented use of this functionality). 

> The functionality described in these drafts is absolutely needed,
> and yes, one of the areas of application WILL be tunneling between a
> corporate firewall and a NAS box.  I agree that this should only be
> undertaken when both parties are fully aware of the risks inherent
> in this. 

It may be that I don't understand what the needs are for these
protocols (L2TP, PPTP, L2F) as implemented at the NAS level.  If
tunneling is required can not the other end of the link do the
necessary setup and thus be insured it is working to its own
satisfaction?  Can someone explain where such things are really
necessary in a NAS environment? 

> I would be happy with wording that stated, basically, that creating
> a tunnel between a NAS box and a customer gateway can result in a
> connection that crosses trust boundaries, and as such, should only
> be done when a thorough security analysis has been performed. 

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.
-- 
Stuart A Barkley                        email: [email-masked]

-

---

From: Stuart A Barkley <[email-masked]>
Date: Tue, 19 Jan 1999 19:16:14 -0500 (EST)

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

-

---

From: Aydin Edguer <[email-masked]>
Date: Tue, 19 Jan 1999 19:48:33 -0500 (EST)

>  - having a meaningful purpose

FACT: The tunneling protocols exist
FACT: The tunneling protocols are in active use
FACT: There must be a method to configure equipment for said protocols

Therefore, as long as said tunneling protocols are still being used,
there is a meaningful purpose for supporting RADIUS configuration of
tunneling.

Your arguments have little bearing upon the RADIUS-WG, since they are
directed at trying to say the tunneling protcols are not needed, not
to the sole purpose of the RADIUS-WG which is the authentication and
authorization of Services for Dial in Users.   If you care to argue
about why the RADIUS drafts are insufficient to configure the services,
your points have validity to this WG.  Otherwise you are in the wrong
forum.

>  - size, implementation time, debug time and support of the extensions

Since most of the tunneling protocols are *already* implemented by one
or more of the NAS vendors and since one or more of the NAS vendors are 
already supporting the RADIUS drafts for tunneling attributes, this
is moot point.

> routers exist and the other problems are general internet issues.

Yes, multiprotocol routers exist and L2TP depends upon the LNS to
be a multiprotocol router in order to accept the PPP NCP negotiations
for the non-IP protocols.

Yes, there are other non-L2TP tunneling solutions to transporting
non-IP protocols over the Internet.  But the use of tunneling for
providing transport is clearly necessary over the IP-based Internet.
The use of client-side (voluntary) versus NAS-side (compulsory)
tunneling is one that is best left to the service provider and end-user.
And there has been considerable service provider *demands* for the
support of compulsory tunneling.

L2TP is the only way I know to permit Multilink Protocol sessions
to be split across more than vendor's NAS.  All the other "stacking"
methods I am aware of are proprietary.  For a service provider who
uses only one vendor's equipment, that may not be an issue.  If you
know of an alternative, please be more explicit.  But to be honest,
it is a matter of curiosity only, it really does *NOT* matter to *THIS*
working group.  As long as we need to configure L2TP on a NAS for
a Dial in User, we need the current RADIUS tunnel drafts.

-

---

From: Stuart A Barkley <[email-masked]>
Date: Tue, 19 Jan 1999 20:52:22 -0500 (EST)

> FACT: There must be a method to configure equipment for said protocols

Actually the one in question doesn't exist yet.  Its existence is yet
to be determined (although I expect that it will eventually happen
despite my misgivings). 

> there is a meaningful purpose for supporting RADIUS configuration of

Not if the protocols serve no purpose.  What I am requesting is some
understandable new useful purpose, not just "its good" or "it already
exists".

> your points have validity to this WG.  Otherwise you are in the wrong

Understood and mentioned in my earlier statement. 

I would like to get out some more meaningful comments about the
specifics of the L2TP RADIUS drafts, but my immediate work schedule
may not allow for that.  I will be trying to limit future comments to
this more productive nature. 

> already supporting the RADIUS drafts for tunneling attributes, this

So we have something large implemented by the current vendor base
without a known reason for existence?  The "existing implementation"
is what will be documented (sort of like radius was) and we really
can't supply any meaningful comments which impact these existing
implementations.

These are not implemented on tomorrows NASes and are a wonderful way
for the current vendors to build up a huge development base which a
new vendor must over come to get all the boxes checked off on their
product regardless of whether anyone uses them or not.  Likewise the
existing vendors will continue to be bloated down with this code when
the leaner trimmer implementations don't require such things.  This
can also impact vendors when attempting to merge two similar but
distinct product lines. 

> for the non-IP protocols.

I was more thinking of some of the routers we use.  They will handle
multiple non-IP protocols, but that is mostly historic code base which
we don't use and don't expect other vendors to provide.

> support of compulsory tunneling.

As a service provider I don't see a purpose for this compulsory
tunneling.  I am still looking for the proponents to explain what this
is useful for. 

As an ISP user I want my data packets to take the shortest internet
route to their destination.  I don't need packets bouncing across the
country to get to somewhere down the street.

As the operator of a corporate firewall I want the tunnel to extend to
the remote equipment so that I can ensure that my perimeter is really
secure. 

> working group.

Okay.  This might be a situation where tunneling helps, but then I
need to force all multilink users into tunneling.  Perhaps the
multilink protocol needs work under its working group (existing
solutions are proprietary and we are interested in multivendor
support).  This is the closest I've seen to a valid reason for
compulsory tunneling and it seems like a long stretch. 

> As long as we need to configure L2TP on a NAS for

In C:

if (need_L2TP) {
    do_lots_of_work();
}

If the tested condition is false then you don't need to evaluate the
body of the statement.  Some of the most effective coding is the
removal of code. 

Stuart

-

---

From: Paul Krumviede <[email-masked]>
Date: Tue, 19 Jan 1999 18:16:24 -0800

> > FACT: There must be a method to configure equipment for said protocols

FACT: cleartext passwords exist. They are in active use.

Now try convincing the IESG and/or the IAB that you should be able to
advance something on the standards track that requires use of them.

I don't mean to imply that the tunneling questions, and the desire to
support configuration for them, falls into the same category, but
proof by assertion isn't always convincing.

> understandable new useful purpose, not just "its good" or "it already

In at least some environments, I have potential customers asking for the
ability to support internal (private, unregistered or registered to
somebody else) IP address spaces for VPNs. For this I need some form
of encapsulation. In some cases, such potential customers are also 
interested in my carrying PPP packets back to an edge device of theirs
so they can do the final PPP authentication (and maybe periodic CHAP,
or something else) without me, as a service provider, having to be
involved. L2TP is one way of satisfying these.

That isn't to say that we would offer such a service, but there seems
to be at least some market demand for this kind of thing.

-paul
-

---

From: Aydin Edguer <[email-masked]>
Date: Tue, 19 Jan 1999 21:25:55 -0500 (EST)

> to be determined (although I expect that it will eventually happen

While most of our discussions have been about L2TP, since that is the
most recent work, when I said "tunneling protocols exist", I really
did mean *exist* in already approved IETF informational documents and
*existing* products.

Please see:
  RFC 1701 "Generic Routing Encapsulation (GRE)"
  RFC 2107 "Ascend Tunnel Management Protocol - ATMP"
  RFC 1853 "IP in IP Tunneling",
  RFC 2341 "Layer Two Forwarding (L2F)"

I also did mean *exist* in vendor implementations -
  Point-to-Point Tunneling Protocol (PPTP)
  Bay Dial Virtual Services (DVS)

These are all *existing* protocols that are in use and that can be
configured on different vendor NASes.  I know that more than one NAS
vendor was providing means to support compulsory tunneling using these
protocols.  But until the RADIUS tunnel drafts, the configuration was
done in different proprietary ways.  Therefore, these drafts serve
a useful purpose by allowing vendor interoperability of *existing*
functionality, even assuming that L2TP is not approved as a standard.

Furthermore, due to the large number of vendors with interoperable L2TP
implementations, as evidenced by the interoperability workshops, even
if the IETF refuses to approve the L2TP draft as a standards track
document, it *will* be released to customers, and will probably be made
an informational document.

> understandable new useful purpose, not just "its good" or "it already

It is not my purpose to supply a reason - it is the service providers
who provide multi-million dollar orders to vendors that supply the
reason.  Since most service providers are not part of this mailing
list, asking here is not very useful.  Especially when, as members
of this list give *existing* uses by service providers, you say that
they are not sufficient reasons.  They may not be sufficient reasons
for you, but they are for the current users and those are the people
who will be using the work.

We have service providers who are offering to outsource network access
to corporations.  These corporations are using multiple protocols on
the LAN.  They use local equipment on their network to provide the same
support to dial-in clients.  They therefore require that the service
provider provide matching functionality.

This is done using tunneling protocols.

Similarly, these corporations are using private addresses on their LAN.
They use local equipment on their network to provide the same support to
dial-in clients.  They therefore require that the service provider
provide matching functionality.

This is done using tunneling protocols.

UUnet/Worldcom/MCI may not be offering these services.  UUnet/Worldcom/MCI
may not need to use tunneling protocols to offer these services.  But
there are already other service providers who are and do.

The fact that RADIUS-WG is chartered to try to work on functionality that
already exists is a good reason for the RADIUS-WG to consider "it already
exists" to be sufficient for us to try to put it down on paper in a
vendor-independent way.

> > a Dial in User, we need the current RADIUS tunnel drafts.

if (need_L2TP || need_L2F || need_PPTP || need_GRE || need_IP-IP) {
    configure_existing_implementation_in_a_standard_way();
}

-

---

From: "Mike O'Dell" <[email-masked]>
Date: Tue, 19 Jan 1999 21:39:59 -0500

one of the major responsibilities of the IETF is
to say NO to Bad Ideas, no matter how much people
wish to do The Wrong Thing.  

saying "yes, for the right price" is a different,
though ancient, occupation.

	-mo
-

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 19 Jan 1999 19:24:37 -0800

> wish to do The Wrong Thing.

Silly me, I thought that the IETF ran on "rough consensus and running code"!
The fact that both are apparently present in this case is apparently
irrelevant.

-

---

From: "Mike O'Dell" <[email-masked]>
Date: Tue, 19 Jan 1999 22:56:09 -0500

you understand the basic notion correctly, but i think you are
applying it incompletely

after you decide to do something, THEN the IETF Credo
guides the efforts. (code is the tie-breaker and sometimes
the insight giver)

what i'm talking about is being wise enough to decide to
not do something even when you have running code. in fact,
it is sometimes only then when you actually understand you
didn't want it to do something

so these are not inconsistent

you implication taken in extremis leads to "mob rule via C
compiler" and that is certainly NOT the Right Answer

The answer to many problems is often LESS but RIGHT
functionality, not more.

	cheers,
	-mo
-

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 20 Jan 1999 05:38:47 -0800

>can also impact vendors when attempting to merge two similar but

Ah, now I see a real-world reason for UUnet to object to L2TP. The above is
a valid reason for UUnet to be concerned. UUnet has been a leader in the
ISP business since forever and they have a very large and growing network.
UUnet understandably pushes vendors to build better products for their
network. Anything that might get in the way of product development is a bad
thing for them. Totally understandable.

I also understand Mike O'Dell's arguments that L2TP can be a "bad thing"
for the Internet and customers. I understand how lay people, trade
magazines, and unscrupulous salespeople may misuse and misrepresent L2TP as
a secure way to access an intranet. We all know this happens. I understand
that assuming a multi-user third party NAS as a trust boundary is a bad
thing. I know that service providers understand this. They are not stupid.

UUnet's operation is very large and I don't claim to understand its overall
architecture. But I'll take their word for it that they do not have any
need for L2TP. But I do understand other service provider architectures and
I understand corporate networks and I understand the driving forces behind
their architectures. Those driving forces push for a solution. They are
like a raging river looking for an outlet. We have a delta of outlets
available and L2TP is one of them. For some, it is the best available
choice. For others, there are other choices. 

Choices are one of the great things about the Internet. We wouldn't be here
without them. The fact that there are choices are available means that each
choice is a good idea for some and a bad idea for others. Mike claims that
L2TP is a bad idea. Others claim it is a good idea. So we have a choice.

While I can understand UUnet's worries over product development, I would
say that supporting L2TP is undeniably part of the business. It has been
implemented on everything from large NAS's to small cable/adsl CPE devices
to PC's. Although the L2TP RFC has taken a very long time to show itself,
the industry has not waited. When the next solution comes down the pike, it
will not wait for standards approval either. The industry is way too
dynamic to wait for standards these days. I think the IESG is painfully
aware of this.

Also as the ISP business grows, NAS and router applications grow with it.
It's an undeniable fact that NAS's have to grow their hardware and software
to meet the increasing requirements of ISP's. Yet even that doesn't stop
smaller, lighter NAS architectures from being built. Witness the new
architectures that we have developed for the MEGACO WG and ETSI TIPHON. 

When I see people trying to stop standards development, I often wonder if
they are trying to stifle competition. I know of several cases in the past
where this has been true. I truly don't believe UUnet is trying to stifle
competition. But I think that if L2TP were somehow stopped, that would be
the lasting effect.

Sorry for the long ramble and I'm sorry that this is taking place on the
Radius list. 

Matt Holdrege		http://www.ascend.com	[email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 21 Jan 1999 11:50:11 -0800

> you understand the basic notion correctly, but i think you are

I was going to let this pass, but since assent generally is taken as
agreement, I can't.

> guides the efforts.

This statement begs the question "To whom does the term "you" refer in the
above statement?"  Apparently not the consensus of the WG, since it is only
relevant _after_ the decision is made.  Apparently not the implementers, a
'mob with C compilers' who will gladly 'say yes' to anything 'for the right
price'.  Obviously not customers, since they aren't smart enough to know
what's good for them.  So who is it that decides to do something?

-