[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
Follow-Ups:
References: