[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Getting focus for son-of-IKE
Many of us are quite excited that Dan Harkins is doing the son-of-IKE
draft. In our excitement, we have started telling him what we want,
and some of it is conflicting information. Now would be a good time
to actually decide what we as a group want son-of-IKE to look like,
so that Dan doesn't do one thing and we all later ask for something
different.
On the list, Dan said:
> The new draft will combine all three of the key management RFCs into
> one. This will give an opportunity to remove lots of the duplication,
> confusion, and conflicts that arose because of the 3 separate documents.
For this, there is probably little disagreement.
> I'm also planning on cutting out quite a bit of the optional things that
> are now referred to as "standards bloat". For instance, one of the
> public key authentication methods will be removed as will Aggressive
> Mode and most of the ISAKMP exchanges defined in RFC2408.
And this is what led to people asking for other things to be removed
and to be added.
It would be useful here for us to say *why* we want things removed.
If we have a clearly-stated goal, we can probably figure out which
parts to remove to meet the goal and let Dan know soon. So far, some
of the things that have been asked for are:
- Adding small features that would probably be really useful
- Removing features that are not commonly used
- Removing features that add only minor security advantages but are confusing
- Removing features whose security isn't as good as other features
- Changing features that have flaws (not just specification issues)
- Replacing some features with better but different ones
- Adding large new features to fix some problems discovered in the market
None of these are, by themselves, goals. They are methods to achieve
the general goals of "better interoperability" and "easier to
implement" and "fix known bugs" and "better functionality".
Unfortunately, some of the proposals go against some of the goals,
and some of the goals conflict.
Given the lack of agreement in the discussions on this list over the
past year about new functionality and clarifications, it seems
unlikely that we are going to be able to universal agreement on
exactly what son-of-IKE should do. But, let's try anyway.
I propose that there will be wide agreement on the following:
- No change should make any part of IKE less secure.
- Some features of IKE have been implemented in only a few products,
and have not been well tested.
- If son-of-IKE changes any of the wire protocol, the major or minor
version number would have to be changed.
- Although a few advanced customers know exactly which IKE features
they want, the vast majority of customers only know the functionality
that they want (but not the features that they need for that
functionality).
- Most of the functionality that is required by the market today is
available in current IKE. The two areas of functionality that we most
often hear is missing are (a) remote access using legacy
authentication and (b) IPsec through NATs.
- If son-of-IKE was made a standard tomorrow, there would be systems
running plain-old-IKE for at least another decade, and there would be
strong market pressure for companies to keep making their new
products interoperate with plain-old-IKE.
Given those as a base, I propose that the primary goals for
son-of-IKE should be "better interoperability" and "easier to
implement" and "fix known bugs", but *not* "better functionality".
Choosing these three goals (but not the fourth) makes it much easier
to choose what parts of IKE should not go into son-of-IKE.
Some of the bugs to be fixed would cause a version number change
(Tero's hash bug comes to mind), which may be a blessing in disguise
for better interoperability. If the first message of an IKE exchange
has the son-of-IKE version number, the responder will know
immediately to use only the smaller set of son-of-IKE features and
that all further messages should use this new version number.
Do people agree that this is a good set of primary goals?
If we want son-of-IKE to come out soon and meet these goals, we must
put off "better functionality" for after son-of-IKE. Yes, yes, we
have all have functionality that we want to add, but making additions
in son-of-IKE will *not* lead to better interoperability or ease of
implementation. Let's strongly consider getting son-of-IKE done
easily and quickly, and then consider adding the new functionality
after that.
--Paul Hoffman, Director
--VPN Consortium
Follow-Ups: