RE: Son of IKE: A proposal for moving forward

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

Michael, to reply to this message and some of your earlier comments:

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

The vaporware is not JFK. The vaporware is all the anciliary protocols that
we already have for IKEv1, from remote access to NAT traversal.


> As I've said, I've
> done some experimenting and I can fit a usable
> keying + crypto solution into about 30-40kb of
> code including the crypto and modular arithmetic
> libraries. This is down about an order of
> magnitude from a typical IPsec/IKE stack.

But you're doing something unfair. You are comparing your own prototype KMP,
which has been specifically optimized for size, with a "typical" IPsec/IKE
stack (which doesn't make sense... are you comparing IKE+IPsec to
SPUNK+IPsec or just SPUNK?). I think we all have the ability to build scaled
down versions of our products if we want (strip out 90% of the crypto, etc).
About the only fundamental difference is the 1 vs 2 phase issue, and that
can hardly account for a factor of 10 increase in size.


> The one thing I don't see here is any
> consideration of the very basic question of
> whether there are in fact two different problem
> spaces. The slant of this working group is very
> VPN-centric, much to the burden of things which
> aren't especially interested in remote access,
> amortization of authentication expense, etc, etc.

In a sense, I agree with you. I think that everybody here knows there is a
rift in the working group, as there has been for as long as I can remember.
Perhaps the reason that people are reluctant to make constructive comments
on this list, particularly in reference to the requirements document, is
that there is very little chance of achieving consensus (I admit to being
guilty in this regard).

If the goal is simply to provide a specialized KMP for widgets, then I
wonder why the JFK team didn't merely start an alternate WG like KINK did.
(Speaking of which, I wonder why you are so interested in SOI; are you
unhappy with the way KINK turned out?) But clearly JFK was not really aimed
at widgets; it was aimed at PCs and servers. The VPN vendors popularized
IPsec, and secure remote access is not going away anytime soon (as it turns
out, I'm using it to send this message). With IPsec now standard in most
computer OSs, it doesn't make sense for SOI to not support a popular and
legitimate usage scenario.


> A third way to deal
> with this is to potentially legitimize "profiles"
> where we have a very slim inner protocol which can
> and should be implemented by *everything* where
> you have additional functionality layered on
> through, say, different standard's track RFC's,
> or whatever.

I agree with the concept of profiles. I think it is completely valid for a
community with a specific requirement to define a subset of the standard for
one specific purpose. There are a few very vocal WG members who say that if
it doesn't do all the MUSTs then it's not IPsec (and you can't even call it
IPsec-lite or Ipsec-foo). If the IWC defines one profile and the ILC defines
a different one, then my IPsec-enabled wristwatch may not be able to talk to
my IPsec-enabled lawnmower, but as long as they can both talk to my home PC
I'll be happy. If, in the future, someone wants to develop a standardized
protocol for wristwatches to talk directly to lawnmowers then I imagine that
coordinating the KMP will be the least of their problems.

Speaking of widgets, can you explain to me how a widget where "the profit
margin is pennies" is going to do group 5 with 2048 bit RSA keys? The point
is that any deployment involving widgets is going to require a specialized
IPsec policy, anyway. If the widget wants to talk to a server, you can't
expect the server to automatically think "oh, well since I'm talking to a
widget then I guess group 1 with 512 bit RSA is okay".

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.