Re: Choosing between IKEv2 and JFK

["Angelos D. Keromytis" <angelos@cs.columbia.edu>]

In message <Pine.LNX.4.33.0203071154360.27873-100000@janpc-home.cisco.com>, Jan
  Vilhuber writes:
 >
 >That's what I meant.

That's one signature per exchange. Numbers show this is easy to deal with,
even for large numbers of exchanges and no hardware acceleration.

 >Actually, no. Some maybe. Some won't be. Also, the speed of the
 >processor doesn't really matter, does it? If the speed of the
 >processor increases, the numberof tunnels per processor will likely go
 >up to, and customers generally want as many as possible.

You need more than 1000 tunnels/second set up, on your palmpilot ? I wonder
how realistic these assumptions are --- do you have any usage statistics ?

 >Is there anyone that disagrees that for reasons of the replay
 >counter/window, you need multiple SA's per peer (for the same user!)
 >for QoS?  If so, let's discuss that, since that's more or less my
 >premise.

How is QoS related to the replay counter (I'm assuming you mean the ESP/AH
header replay counter) ?

 >Maybe. I still don't think rsa operations are cheap enough that we can
 >throw them around like candy and ignore the costs completely. If I can
 >cut the number of public key (rsa) operations down by half or down by
 >a factor of 3, I'm all for that. No need to be wasteful. No doubt'
 >it's one of those engineering trade-offs Radia talked about in an
 >email a few months ago.

They're not very cheap, but they're not prohibitively expensive either. Web
servers do the inverse operation (which is a lot more expensive) all the time.
Of course, cutting down on any cost is always a good thing; however, if it's at
the cost of complexity (*) -- and for this particular cost, and given your
assumptions as I understand them --- my choice is on the side of a few more
pubkey operations if needed (no big surprise there :-)

(*) The distinction between Phase 1 and Phase 2 really is ugly for
implementors: there are all kinds of "secret" policy checks when determining
whether an existing Phase 1 SA can be used to establish a new Phase 2 SA,
because of the different parameters that may be relevant when establishing a
new Phase 2 SA (initiator/responder credentials, IDs, source/destination
addresses, Phase 2 parameters, etc.) I've implemented IKEv1 twice so far, and
it wasn't particularly pleasant dealing with all the dependencies hidden in the
protocol.

 >Why not amortize that cost, while at the same time getting a "tunnel
 >management tunnel" for free, i.e. a phase 2, as long as it doesn't
 >overcomplicate the protocol? I'm willing to pay some complexity if it
 >buys me a better protocol (I realize that sentence has a lot of
 >subjective words in it, like 'complexity', 'better', and
 >'overcomplicate' ;), i.e. one with built-in keepalives/DPD,
 >informational exchanges, etc.

We clearly have different definitions of "better" :-)

You would find many people arguing for a clear separation of protocol
functionality --- huge, monolithic protocols are not pleasant to specify,
analyze, implement, or debug. On a slightly more philosophical vein, they
promote both bloat (see IKEv1) and bad APIs (another source of trouble and
embarassments).

As for informational exchanges, surely you jest :-) I have yet to see an
IKE implementation that (a) does anything meaningful on receipt of an
informational message, or (b) depends on information exchanges for its
correct operation.
-Angelos