Re: Son of IKE: A proposal for moving forward

["Theodore Ts'o" <tytso@mit.edu>]

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.

> > Michael Thomas <mat@cisco.com> writes:
> > >   You get a self-fulfilling prophecy if your idea of
> > >   "practical applicability" == "VPN". Which is
> > >   exactly my point. Nobody's even considering any of
> > >   the other intended applicability of IPsec when
> > >   making decisions about how large the keying
> > >   kitchen sink needs to be.

It is true that there is tension here, but I found it instructive that
Michael's original message both talked about how the ipsec working
group had made life for the remote access folks by considering certain
things out of scope (after all, that's why we have the ipsra working
group), and in the very next paragraph, he was worrying that the
protocol might be including too much so that it's might be too complex
for certain small devices.

One of the things that a public speaker or a teacher quickly learns is
that if half your audience thinks you're going too fast, and half of
your audience thinks that you're going too slow, you probably have
your judge your pace appropriately.  So I'd like to think that we're
at least trying to hold in tension the mutually exclusive goals of not
being too wide or too narrow.

It's also the case that thanks to Moore's law, the amount of processor
and memory in a "small device" continues to become bigger and bigger.
After all, these days, a 386 is sometimes used as an embedded
processor, and design choices which cripped telnet encryption's
security because people were worried about the performance on
Macintoshes running 68000's would today be considered completely
stupid/silly choices.  So I'm not sure whether kitchen sink worry is
really going to turn out to be a real concern, but it's certainly
something which I believe we should continue to ask ourselves as we go
through the SOI requirements debate.

All this being said, it may very well be that if people really want to
use a very specialized key exchange protocol for a very specific use,
it might be possible to make a profile of SOI where certain "MUST"'s
are turned into "MAY"'s.  You couldn't call it IPSEC, which would be
OK, since the missing features would very likely result in
interoperability with other IPSEC implementation.  However, if some
hypotentical telephony or other application protocol really needs to
be implementable in an 8 bit processor with 2k of RAM and 8k of ROM,
then that particular application protocol specification could
reference the SOI specification and describe how it should be stripped
down.  (Heck, if you have an 8-bit processor with 2k of RAM and 8k of
ROM, you probably can't afford much beyond a fixed key passed directly
to ESP/AH, and you might have to dispense with key management
altogether.  :-)

						- Ted