[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IKE must have no Heirs
> Unfortunately the notion that IPsec should simply \"bind
> a key to an IP address\" was rejected repeatedly throughout
> the history of the IPsec WG.
This is why I think we have to stop talking about 'son of IKE'
as if the problem was in the 7 years and 9 months of trying to
implement the requirements and not the 3 months of requirements
capture.
If a WG takes 8 years to come up with a solution it indicates
a broken set of requirements. In the time that we have been waiting
for IPSEC and DNSSEC to deploy we have deployed one generation of
PKIX/X509.v3 based PKI and have started deployment of a second
generation architecture to replace it. We can move quickly when
there is clarity in the requirements.
The first people to complain about the complexity of IKE were
told 'we have been working on this for a year, it is too late
to start again'.
The next lot were told 'we have been working on this for two
years, we can't wait another two'.
The 'we have spent so long digging the well here we will not
try digging elsewhere, even though others have struck water there'
argument is self re-inforcing but does nothing but perpetuate
the original broken assumptions. If the argument for the
status quo is strong today 'it would take 8 years to replace IKE',
just think how strong it will be in 2009 - 'it has taken 16
years to get this far, we will all be retired before your
redesign is complete'.
The DNSSEC group have been making a similar argument for years
concerning the specious 'requirement' for non-repudiable
responses. Despite the fact that non-repudiation is worthless
without infrastructure to archive the messages no client will
ever implement, the DNSSEC spec makes a fetish of it to the
extent that each field in each message has its own signature.
The combination of the non-repudiation requirement and the
backwards compatibility requirement cannot be met except at
unacceptable cost.
The problem is not the demand for additional features, the problem
is that they have to be addressed as 'additional'. IKE/ISAKMP
spent their entire complexity budget on a negotiation framework
for variation in features that are not core, not essential while
ignoring real world problems such as NAT that are core.
>From here there are two routes forward. We could specify a reduced
IKE, eliminating all but 2 of the current 8 modes, simplifying the
negotiation, knife AH... to result in a simpler draft that we can be
confident would get a broad review. I think that would have been an
excellent idea three years ago, I think that it is too late after
the interop tests have been performed. All that would come out
is a description of a profile of the current spec that resulted
in one configuration that was secure. But implementations would
still be constrained by the existing legacy base which would
drag deployments back into the mire of unexamined code paths and
unanticipated interactions.
The second is to burn the current drafts and start from scratch
with a fresh port number. If any change is made that breaks
backwards compatibility then this might as well be what you do.
In short the phrase 'Son of IKE' is part of the problem, not
the solution. IKE must have no heirs, it is time for a new dynasty
to take the throne.
Phill
Phillip
Follow-Ups: