[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SOI schizophrenia
> 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.
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. In
practice, I can choose to exclude whatever features I want from my security
analysis. I could state that "Authentication should be accomplished by a
protocol defined for that purpose. By excluding authentication from our key
agreement protocol, we can exclude it from our analysis." To an untrained
eye, that text doesn't look any less reasonable than the quoted text from
[JFK].
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. (I recall hearing comments at the
last MSec meeting about the decision to separate GDOI from rekeying being a
mistake.) We have to rely on human judgement to assess whether features X
and Y interact, and this will usually be independent of whether they are
implemented together or as separate protocols.
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)
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. 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.)
I find it ironic that one of the driving factors behind the development of
JFK was to reduce the number of round trips, and yet if you compare today's
deployed remote access clients to a proposed solution doing PIC + (3 x JFK),
you find that the number of roundtrips has actually increased dramatically.
Is this we call progress?
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Thomas
> Sent: Wednesday, May 15, 2002 7:51 PM
> To: ipsec@lists.tislabs.com
> Subject: SOI schizophrenia
>
>
>
> 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
>