[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Merging IKEv2 and JFKr?




>>	From: Michael Thomas <mat@cisco.com>
		
>>	So I wasn't at the last meeting, but it's seemed
>>	fairly obvious to me that there's been consensus
>>	around IKEv2 (fwiw, I've never been anti-IKEv2).
>>	What is to be gained by trying to merge these two
>>	other than a sort of Medieval peace by marrying
>>	different bloodlines? JFK's big appeal, IMO, was
>>	its simplicity. The WG has clearly decided that
>>	wasn't compelling enough argument.
	
>>			  Mike

I don't think that thinking about it as "merging two specs" makes
much sense. That would be like interspersing words or something,
and certainly nobody is proposing that. What's really being "merged"
is the author names, and that's certainly a win.

The important question is what actual modifications are being made? The
main two things are:
  a) changing from a la carte negotiation to suites (which incidentally
     wasn't part of either spec, but all contributers thought it would
     be a simpler, better protocol with suites)
  b) changing to an "always 4 message" protocol where Bob is stateless
     until receipt of message 3.
     
Indeed, both of these changes sounded easier when first proposed, than
when actually worked out. For instance, although I still prefer
suites, I'm not exactly sure how the ESP/AH
extended sequence numbers are supposed to work, now that we're not
individually negotiating features. I guess it will be defined as part
of the suite (not only what cryptographic algorithms are used, but
whether ESP/AH extended sequence numbers will be used).

The 4-message thing is certainly more complicated to understand, and
there were some thorny issues. I advocated for this change, but
had somewhat of a change of heart after seeing the implications.
But it's doable, and I believe we have worked out all the details,
and it would be good for implementers to think about it once
they can see it fully worked out. It's hard to compare
until a concrete proposal is made, all written down. Hopefully the
spec will be distributed to the ipsec list real soon now, and then people
can argue with more information about whether these changes are a net
plus or a net minus, or not significant enough either way to worry about.

And although it's moot in this case, in general it would be good
for people to get in the habit of saying something like "A is simpler than B
because it leaves out feature X" rather than "A's advantage over B
is simplicity", because often when people are saying this
sort of thing, A isn't actually simpler than B, but people
just say so and it gets repeated,
or it appears simpler because of not having worked out some details,
or it's simpler because of leaving out features that people wouldn't be
happy leaving out.

Radia