SOI schizophrenia

[Michael Thomas <[e-mail]>]

I admit it. I'm having a real hard time deciding
which design philosophy is actually more
appropriate for SOI. I've vacillated quite a few
times and it doesn't seem like it's about to abate
any time soon. What Paul's document tells me
(which pretty jibes with my own judgement) is that
both protocols are vast improvements over IKE, and
they seem to reach quite similar conclusions on
the basic message exchanges. Both put effort into
DoS, and simplify the on-wire combinatorial
explosion of SA establishment. All in all, they
both seem competent.

While Paul points out some of the differences in
design choices such as quick mode, pre-shared
keys, etc, what it seems to me that makes this so
difficult is that there are two different design
philosophies at work here:

1) Lean, compact public key identity keying (JFK)
2) General purpose (IKEv2)

To a degree I agree about Andrew's observation
about the devil we know, but what I think often
gets lost in this mostly-VPN-centric group is that
IKE -- and I'm afraid IKEv2 as well -- is large,
and difficult to put into cheap, embedded
devices. This isn't usually an issue for the
windoze-VPN-to-corporate-edge, but IKE's size is a
pretty hard sell for little widgets with
constrained memory footprints. I've heard all the
arguments about how the hardware folks are being
unreasonable (and heck, beating up on hardware
folks is just clean fun anyway), but I'm not
overstating the difficulty. 

So from that standpoint, JFK's hardline stand on
limiting complexity and creature feep is
heartening. I've done some experiements writing a
JFK-like protocol (same in spirit, slightly
different wire format) using raw public key
identities and the results are very heartening; if
the memory police balk at its size, they are just
being obstructionist. This is implementable; no
excuses. Thus for simple widgets which operate in
star topologies to a few well known servers where
the traffic needs transport mode IPsec, JFK is
quite attractive. Maybe other uses too.

On the other hand, VPN's do add a lot of
complexity, and I think that JFK understates
that complexity. While some of that complexity is
certainly gratuitous, I think that there's an
unspoken truth here: VPN's are fundamentally more
complicated than point to point transport mode
SA's, and they drag all kinds of crufty legacy
junk into the mix like legacy authentication,
autoconfiguration, and all the rest. Is it needed?
At some level of course it's "needed"; I doubt
many of us are here for the shear fun of making
Frankenprotocols.

So what to do? What to choose? I'm at a loss. We
could flip a coin to decide the pre-shared and QM
debate, but what I don't see is how to preseve the
different design philosophies which appeal
differently to different audiences. Specifically,
I'm having a real hard time seeing how we can have
a single lean unbloated protocol like JFK without
specific bloat-resistant design constraints...
which violates the VPN desire for generality at
the expense of simplicity and footprint.

Time for some more shock therapy, I guess.

	    Mike