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

Re: Network World article on IPSec

Maybe Bob would like to address your email as well, since he says he was badly
misquoted/misrepresented in that article.  I avoid interviews like the plague
for precisely this reason.  Perhaps there are still lessons to be learned all
around...

In my opinion, the article was editorially irresponsible.  Either the author
set out to write a negative article or else the author never bothered to check
her facts with anyone who's actually fielded an implementation of IKE/IPSEC.

>1. "The harder IPSec change will be standardizing on an IPSec remote 
>   client.  The goal of the IETF meeting is to define a client that
>   can support IP address changes automatically."
>
>   [Anne] To what extent is this a barrier to deployment of the
>   existing IPSec?  Only in NAT environments?

You're right, it's not.  NAT is a known issue.  For more information on NAT,
see Steve Bellovin's many lucid posting on this issue in this archive.  It's
on the agenda for IPsecond.

>2. "Another difficult item on this week's agenda will be redefining
>   the core IKE protocol.  Security experts recently uncovered a
>   flaw related to the improper exposure of information."
>
>   [Anne] Is this referring the discussion about exposure of
>   identities during IKE negotiation in Pre-Shared-Key-Auth Main
>   Mode?  Is this really a barrier to deployment?

Yes, that would be a difficult issue, had it been true.  

No one I spoke with seemed to know which "flaw" we're talking about.  The
general consensus was that the author incorrectly linked the PKCS encoding
problem (i.e. the recent "SSL/RSA" bug) with IPSEC.  As written however, that
statement is completely unjustifiable and irresponsible.

>3. "And IKE, as it now exists, handles time-expiration of session
>   keys in a way that could cause one gateway not to understand
>   another."
>
>   [Anne] Is this referring to the use of kbytes-based lifetime
>   payloads versus seconds-based lifetime payloads?  To what extent
>   is this a barrier to deployment?  Does it just cause a delay, or
>   is it a Big Problem?

Again, utter crap.  There are some incomplete implementations which do not
currently include support for the mandatory lifetime attributes.  As a result,
certain other gateways will refuse to negotiate with them because of security
policy which says that lifetime negotiation is required.  This is hardly a
problem with the protocol.

It is true that from an implementation perspective, getting rekey right is
somewhat complicated in this architecture.  There is work underway in IPsecond
to write some guidelines about how to do rekey correctly.  However, as someone
who has written code, it certainly can be done interoperably.

Derrell
References: