[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)

> Sorry, but this 'why reinvent' call seems too late - it's been done
> and plenty of vendors have implemented it.

The call went out a long time ago, but was ignored.

>
> Keeping faith with installed Remote Access tools is common practice
> for IPSEC-only remote access products using a combination of the new
> tunnel RADIUS attributes (sometimes), and most of the old ones (except
> stuff like 'call-back').
>
> I know of at least 6 shipping IPSEC client/server products that do
> just this, and I would not be surprised to find the actual number is
> much higher.

How many of those actually interoperate (outside of bake-offs)?

>
> So, is the path of least resistance really to implement IPSEC/L2TP/PPP
> as well?
>
> Steve.
>
>
>
>
> -----Original Message-----
> From: Jan Vilhuber [mailto:vilhuber@cisco.com]
> Sent: Wednesday, May 17, 2000 11:57 PM
> To: Scott G. Kelly
> Cc: W. Mark Townsley; Ari Huttunen; Stephen Kent; CHINNA N.R. PELLACURU;
> ipsec@lists.tislabs.com
> Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router
> interoperability)
>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> jan
>
> > Secondly, in response to overhead concerns, the point has been made that
> > there are various header compression schemes available in ppp/l2tp which
> > mitigate this. While this response addresses the on-the-wire overhead to
> > some extent, it ignores the additional packet processing overhead and
> > complexity that wrapping the packets in 2 more protocols (all the while
> > doing header compression) entails. Please address this.
> >
> > Finally, in response to the security issues raised by obscuring the
> > transit selectors from the ipsec machinery, the argument has been made
> > that ppp provides all the necessary protections. However, this is not
> > all that reassuring, and conjures up images of the left hand not knowing
> > what the right hand is doing. Please elaborate a bit on how this
> > mechanism provides comparable assurance to one where ipsec is employed
> > alone.
> >
> > Scott
> >
>
>  --
> Jan Vilhuber                                            vilhuber@cisco.com
> Cisco Systems, San Jose                                     (408) 527-0847
>
>
References: