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

Re: Getting the features chart going

<trimmed here and there...>

Will Price wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> [[ Not sure who wrote the double quoted text here, maybe Glen???  The
> attribution was removed and some messages were left off the main
> list.]]
> > > there may be others.  The major benefits of L2TP over hacking
> > > IKE are pretty
> > > obvious, I think
> 
> Terms like "obvious" and "clearly" are an emotional response that
> seems unclear given that a large number of vendors have in fact
> chosen to use the route this poster thinks is "obvious"ly wrong.
> 

>From the sounds of it, only a handful of vendors have actually
implemented this so far. The fact is that it has not been fully debated
in terms of security risks and other areas of concern as of yet, and
that is one of the tasks that could lead to an ipsec remote access
(ipsra) working group. Charging ahead full steam prior to this debate
could be reckless...

> > > the use of
> > > well-understood protocols for both authentication and remote node
> > > configuration.
> 
> IKE is a well understood protocol to everyone here.

I'm not so sure about this, especially given some of the cryptographic
subtleties. That's not to say the there aren't people reading this who
understand it very well, but... everyone here? 

Read
http://www.ietf.org/internet-drafts/draft-simpson-danger-isakmp-01.txt,
if you haven't already.

>  ISAKMP-cfg is so
> simple I can't imagine anyone saying it isn't well understood.
> Trying to bring L2TP, PPP, IKE, and IPSEC together all at once is far
> more likely to introduce these interoperability and not well
> understood issues that you raise.

Perhaps this second statement (interop issues, etc) is true, but on the
other hand, DHCP provides all the functionality required for
configuration, and relies only on the security of the underlying ipsec
framework, with no risk of compromising IKE by adding additional states
and opportunities for attack. The only meaningful drawback I've heard of
so far pertains to the additional overhead required for the extra SA,
and this is really more of an optimization issue than anything else.
It's not clear that isakmp-cfg is simple, and it's also not at all clear
that the additional challenges it presents in terms of analyzability,
reliability, etc. with respect to security are worth the overhead gains
over the dhcp approach.

> 
> > > A more interesting question is why anyone
> > > would favor the
> > > invention of novel extensions to a protocol that is already
> > > far too complex
> > > over the use of widely-deployed, proven techniques.
> 
> It must be a conspiracy.
> 
> Seriously, while IKE may be complex, it has the significant advantage
> that everyone here already understands it quite well, has already
> implemented it, and IMHO didn't find it to be far too complex. 

As I said above, I don't think everyone here understands it all that
well. Protocols take time to analyze.

I think we need to split this discussion. Isamkp-cfg vs. dhcp is one
issue, and xauth vs (???) is another. 

Scott
Follow-Ups: References: