[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)
I had brought this up before: Isn't securing EAP within an IKE exchange,
considered to be an overhead?
chinna
On Wed, 17 May 2000, Scott G. Kelly wrote:
> 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
>
chinna narasimha reddy pellacuru
s/w engineer
Follow-Ups:
References: