Re: SOI schizophrenia

[Jan Vilhuber <vilhuber@cisco.com>]

On Wed, 15 May 2002, Michael Thomas wrote:

> 
> 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.
> 

They are both competent from a cryptography point of view, but only
one actually allows key management in any sane way. I think that's
where the two part company, and we as a group need to decide which is
more appropriate: A key *agreement* protocol (JFK) which will require
other protocols (ICMP? Right..) to help solve the current deployment
stability, or a key *management* protocol (IKEv2), that let's you
manage the key we agreed on, without requiring other external
management protocols.

The rest of the topics are in my mind really ancillary (You want it
red? You can have it red. You want cipher suites? You can have those?
You want pre-shared keys? We could add that if necessary. You would
prefer it round instead of square? Done.).

So one important question is:

Is
  (simple + n*(extra management protocol)) <
                             (complex + 0*(extra management protocol))
?

Of course another question might be: Do we need key management? Based
on operational experience and fixing lots of customer deployment and
network stability problems, I'd say that's an emphatic YES.

2 phases? Yes.
Key management? Yes.
Simplicity? Only where it doesn't conflict with being able to maintain
an operational network.

jan


> 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
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847