Re: Son of IKE: A proposal for moving forward

[Cheryl Madson <cmadson@cisco.com>]

At 02:06 PM 6/12/2002, Theodore Ts'o wrote:
>On Wed, Jun 12, 2002 at 12:16:48PM -0700, Jan Vilhuber wrote:
> > Cheryl tried to put together a requirements/scenario document. You can
> > find it here.
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.txt
> >
> > It tries to list all scenarios we could think of. Some of the are
> > mutually exclusive, but there for completeness. Feel free to provide
> > feedback and comments on any scenarios there or add some if we missed
> > any.
>
>Absolutely.  This document has been available for quite some time, and
>it is indeed designed to be a way in which the working group is
>supposed to judge SOI proposals.  To that end, it's hard for me to
>credit the claims that the entire working group is VPN-centric, given
>that the document analyzes several scenarios, of which VPN is only one.


Something that the WG is *supposed* to be doing is looking through the
scenarios and deciding which ones are important enough to be covered by SOI
(in other words, if we don't properly accommodate some core set of
scenarios, we have not succeeded).

It's obvious to all of us that we can't support everything. But we aren't
even willing to discuss what we *should* support.  [It's been 6 months since
the initial draft, and three months since the more comprehensive draft, and
the number of folks willing to think about/talk about it is depressingly
small. [Apart from my reviewers, the only direct substantive comment
came after the first draft, something along the lines of "why didn't you
include scenario <foo>?".]

What scenarios are still needed? What scenarios are we willing to exclude
(and why)?  [IMO, VPN+remote access *aren't* enough.] And are the pieces I
call out as "important" in each scenario a reasonable representation of the
problem space (in other words, do we understand the problem space enough to
figure out what it is that we need to solve)?

It's much easier to weigh the relative priorities of the various requirements
once we agree to the scope of the problem we want to solve with SOI. But we
can't even seem to take the first step, which to me seems much easier to
tackle than the priority weighting exercise (unless you punt almost
everything, of course).  You can't optimize (I'm talking in an abstract
sense here) a protocol for everything, but ideally that protocol should be
optimized for the important things.

Yes, this is hard.  But it's very hard to design a good protocol without
doing such an exercise.  To be blunt, the lack of such scoping is one of the
big reasons we got into this mess in the first place (we shouldn't have had
to shoehorn in remote access into a preexisting protocol, but most people
weren't willing to think about that problem space at all -- much less grasp
the problems it would introduce -- soon enough).

I realize it's much easier to talk about point features/capabilities. Heck,
it's more fun. But if we haven't agreed as to the problems we need to solve,
it's somewhat of an academic exercise.  And we're beyond trying to build a
toy protocol here; there are lots of people dependent upon these things
being real and useful.



There is another consideration, which is actually more of a design issue
(and is actually talked about in more depth in the earlier draft -- which
has since expired -- I got a little too "simplification-happy ;-)" with the
second draft):

    + If a protocol is designed with a reasonable amount of modularity, it 
should
       be possible to provide building blocks for other key management 
protocols
       to use. In other words, we don't have to solve the world's problems, 
but if
       with the building blocks we aren't forcing other groups to invent new KM
       protocols from scratch. [One example: if we have a good key agreement
       mechanism, it might be usable by lots of different protocols. Another
       example in this space is KINK, which used some of the pieces from IKE
       while replacing the key agreement mechanism.]

    + We need to weigh modularity against the complexity of having to manage
        lots of separate pieces. This is especially true if the separate 
pieces are
        actually separate protocols.

     The point here is that hopefully we can choose some happy medium on the
     modularity continuum, we can provide useful mechanisms for others to use.


thx - C


====================================
Cheryl Madson
Core IP Engineering; Security and Services
Cisco Systems, Inc.
cmadson@cisco.com