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

Re: Choosing between IKEv2 and JFK



On Thu, 7 Mar 2002, Angelos D. Keromytis wrote:

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

What does a palm pilot have to do with anything? I'm talking about
aggregators where the order of magnitude of negotiations is MUCH
higher.

If you tell me that a palm pilot can handle 1 tunnel with JFK and 3
tunnels with IKEv2, I'll choose IKEv2. But again: You're looking at it
from the end-station point of view, where 1 or 60 doesn't REALLY
matter all that much. I'm looking at it from the aggregator point of
view where it clearly DOES matter. If you tell me that an aggregator
with a gazillion GHz Foo processor can handle X tunnel creations per
second with JFK and 3*X with IKEv2, which do you think people will
want? So processor is irrelevant (it's not a variable. It's a
constant).


> 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) ?
>

Yes. Think about it: If you have load and high priority traffic on the
same SA, and there are not only reordering (and prioritization) of
packets as they leave the box, but also when they enter (and are
processed by) the receiver AND there is prioritization and reordering
happening IN THE NETWORK (assuming QoS ever becomes more prevalent),
then chances are the receiver will see a LOT of the higher priority
packets before he sees any low priority packets.

hence each high priority packet will advance the replay window, until
finally some low priority packet comes in which is rejected, since the
replay window has moved too far forward due to the high priority
packets.

Hence: Separate SA's and replay counters.


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

Yes, and note that there's strong demand for off-load servers to
handle all those operations.


> 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" :-)
>

I realize that :) That's what this is all about...


> You would find many people arguing for a clear separation of protocol
> functionality

And you'll find many people who prefer two phases due to amortization
of the public key operations and management tunnel. The question is,
who's in the majority. I expect we'll find out in Minneapolis :)


> --- huge, monolithic protocols are not pleasant to specify,
> analyze, implement, or debug. On a slightly more philosophical vein, they
> promote both bloat

What kind of bloat are we talking about?

> (see IKEv1) and bad APIs (another source of trouble and
> embarassments).
>

Underspecification in a protocol definition leads to bad API's, not a
comprehensive protocol...


> As for informational exchanges, surely you jest :-)

Nope.

> I have yet to see an
> IKE implementation that (a) does anything meaningful on receipt of an
> informational message,

IOS does, I believe. Not an unprotected notify, of course.

> or (b) depends on information exchanges for its
> correct operation.

That's because so far there's been much confusion surrounding these
exchanges. If they were clearly spelled out in their use and semantics
(note: well defined protocol specification), this wouldn't be nearly
as confusing. We're finding that it's becoming very important to have
these informational exchanges and are starting to use them more and
more.

jan


> -Angelos
>
>
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847