RE: SOI schizophrenia

[Michael Thomas <mat@cisco.com>]

Andrew Krywaniuk writes:
 > 
 > > 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,
 > 
 > My comment about the devil we know is not just a general purpose aphorism.
 > IKE is a widely deployed protocol with a number of well-known use cases. It
 > is true that IKE was mostly developed by VPN vendors, but then again, they
 > did their best to accomodate the host to host case. When someone proposes an
 > alternative that doesn't address the use cases we already have (not to
 > mention the ones we can foresee), but punts them off to some unspecified
 > future protocol, it is not much of an alternative.

Andrew,

"Alternate" also involves things whose keying
solution is currently the null set. As currently
instantiated, it will almost certainly remain the
null set for a long time to come for many cheap
devices unless we do something about the heft of
IKE. What is their alternative?

That's why I think the generally JFK proposition
of keeping things simple has merit; it can be
aimed at a class of problem that _doesn't_ have a
viable alternative. To date, IKEv2's focus has
been fixing many problems, but its general
direction has also been to add new features too.
I don't have an issue with that, fwiw, so long as
the problems have been generalized, but it flies
pretty much in the face of the desire for
simplicity.

 > JFK says that "[X and Y and Z] should be accomplished by protocols defined
 > for that purpose. By excluding these protocols for JFK, we can exclude them
 > from our security analysis." This strikes me as a bit disingenuous. 

It could be disingenuous if it just postpones a
necessary requirement for _any_ protocol for which
there isn't a ready answer elsewhere. I don't
really see this as going on here: if you want
public key based IPsec SA establishment, JFK or
something very close to JFK is sufficient and does
not require external protocols. True, it's not a
forklift replacement for the current IKE, but then
again, I didn't sense that that was the authors
intent.

Which is why I brought this all up: is there 
really two different problem spaces here?

 > My point is that the determination of what features impact what other
 > features cannot be divorced from common sense. Separating every feature into
 > its own protocol doesn't necessarily make the analysis simpler, nor does it
 > necessarily make your code size smaller. 

Of course we don't want balkanized standards here,
but that doesn't mean we need a *single* standard
either, especially when that single standard isn't
a viable choice for a potentially large user base.

 > IMHO, the easiest way to simplify your analysis is to refer to an
 > unspecified protocol TBD. You can call this my golden rule of protocol
 > analysis. Any protocol that doesn't currently exist is always simpler than
 > all existing alternatives. (Also, redesigning this software module from
 > scratch will be easier than fixing it, and if we redesign our "process" then
 > our projects will be completed on time, etc)

FWIW, I've actually written something that really
keys real SA's using something that looks a great
deal like JFK. It works. It's really small. As in
no excuses small. So, I don't think this is quite
as much vaporware as your letting on here.

 > To return to my original thread, IKE has been widely deployed in remote
 > access scenarios, mostly using the pseudo-standard Config Mode protocol. JFK
 > was specifically designed to rule out any heretic vendor extensions such as
 > these. 

Uh, it's using TLV's. Naughtiness is just an
unassigned TLV type away.

 > But even if one uses the IESG-sanctioned DHCPv4 Configuration of
 > IPsec Tunnel Mode (which was no doubt excluded from the analysis), it is not
 > clear how to proceed. I imagine you do one JFK exchange with IP=0.0.0.0 then
 > another JFK exchange with your DHCP-assigned address, and then a third JFK
 > exchange to delete the SA to 0.0.0.0. (Either that, or there will be a new
 > protocol TBD for secure DHCP address assignment.)

This assumes that JFK has to be The substitute for
remote access. What if we just say it isn't? Heck,
what if we say it's just for transport only! My
entire point was that maybe bifurcation of the
problem space is warrented, essentially split down
the lines of "remote access/security gateways" and
"host-host SA's."

			Mike