[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)
Hi Jan,
Jan Vilhuber wrote:
>
> On Wed, 17 May 2000, Scott G. Kelly wrote:
> > The point has been made that some sort of aaa infrastructure has been
> > deployed for dial-up users, and that customers should not be asked to
> > discard this. Please clarify what components would be discarded if we do
> > not use l2tp. For example, I know of several ipsec vendors who implement
> > some sort of radius interaction without using either ppp or l2tp, so it
> > seems that radius investments are not necessarily in jeopardy here.
> > Please address this.
> >
> That's exactly my point though: There's certainly people that have
> implemented this, but what they had to do was essentially *re-implement* the
> radius interaction (if not define it from scratch), whereas PPP has hashed
> all this out over the years, and there would not have to be any re-inventing
> and/or re-implementing.
While I see some merit in this, I think it ignores that fact that this
"reimplementing" may be as simple as cutting and pasting code, and
adding calls to it from the appropriate place. It also seems to ignore
the large amount of additional functionality (and complexity) the 2
additional protocol layers (or is it 3 once you encap l2tp in udp?)
bring to the table compared to this cutting and pasting.
> Example: Config-mode does address-assignment, dns and wins assignment, and so
> forth. PPP already does all this. PPP also does more (look at some fairly
> complex radius profile for PPP; I can't find any in my radius directory
> off-hand), which you'd have to define and implement in config-mode (or some
> other mechanism). Why bother? it's been done. it's solved. Let's use it.
Yes, but dhcp also provides all of this config functionality, and it did
so before such functionality was replicated in ppp (and config-mode).
Also, there is dhcp functionality which ppp _does not_ provide, and so
you would still have to implement dhcp either way (or lose the
functionality). That being the case, I don't think ppp adds anything
useful in this regard.
> Another example: xauth and all the different authentication types. While
> radius isn't a stellar example in this case (tacacs+ handles things like EAP
> better, I think; but let's please not get into a flame-war about which is
> better.. it's an example), do you really want to reinvent all the different
> authentication type (token card, next pin mode, chap, PAP, EAP, skey, etc
> etc) in xauth when it's already been done in PPP? The code exists, is
> well-seasoned and well-tested.
An earlier draft on this topic pointed out that eap could be encap'd in
udp to fulfill this functionality. Since eap ostensibly encompasses all
of the other mechanisms named, this mechanism would be far simpler than
l2tp. No matter what, the sgw at the headend has to have some sort of
authentication server application running if you intend to support these
legacy mechanisms. If you run ppp/l2tp, your ppp code will somehow call
into this code, which will interact with the backend
{radius,tacacs,what-have-you} server. If you run eap-in-udp over ipsec
you get the legacy auth mechanism, but you've jettisoned all of the
encapsulation contortions required by the l2tp/ppp solution in favor of
something much simpler, I think.
> L2tp gives you all those for free via PPP. I see no reason to reinvent them
> in IKE/IPSEC and clutter the rfc's and the already complex code.
Free? It seems like implementing ppp and l2tp, and then encapsulating
transit traffic in this, and then encapsulating all that in udp prior to
encapsulating *that* in ipsec is far from free.
Scott
Follow-Ups:
References: