Re: SOI schizophrenia

[Jan Vilhuber <vilhuber@cisco.com>]

On Thu, 16 May 2002, Michael Thomas wrote:

> Jan Vilhuber writes:
>  > On Wed, 15 May 2002, Michael Thomas wrote:
>  >
>  > >
>  > > 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.
>  > >
>  >
>  > They are both competent from a cryptography point of view, but only
>  > one actually allows key management in any sane way. I think that's
>  > where the two part company, and we as a group need to decide which is
>  > more appropriate: A key *agreement* protocol (JFK) which will require
>  > other protocols (ICMP? Right..) to help solve the current deployment
>  > stability, or a key *management* protocol (IKEv2), that let's you
>  > manage the key we agreed on, without requiring other external
>  > management protocols.
>
>    I don't understand what you mean by "management"
>    in this context. JFK can add and delete SA, and
>    assigns lifetimes to them. It seems light on a
>    DPD scheme, but that seems like a negotiable
>    item. Two phases is just an optmization.
>
>    What am I missing?
>

In order to delete an SA, the ESP_BYPASS and AH_BYPASS was added to
JFK (although I'd probably call this a kludge.. your mileage may
vary). Note that "When a negotiated SA expires (or shortly before it
does), the JFK protocol is run again." This holds true for deletion as
well. Meaning one rsa operation (at each end) each time. Yes, having a
phase 1 SA is in this respect an optimization, but in my opinion a
critical one. Is doing an RSA sign operation each time you want to
send a tunnel-management message OK? Not in my opinion.

Also, don't forget that you may want to negotiate multiple SA's
between two endpoints (in fact it's quite likely). Doing rsa
signatures every time (for every SA) seems unreasonable. Again, a
phase 1 SA under which to do the add's and delete's is ever so much
cheaper.

As you point out, keepalives or DPD is lacking in JFK as well
(pointing to ICMP pings is an interesting idea, but hardly worthy of a
protocol spec and interoperability; This ICMP section in JFK
constitutes the second punt of key management in the spec; Also, pings
don't scale well. DPD was developped because something like an IKE
ping won't scale).

Second, if you believe that management messages are few and well
defined, building them into your protocol from the start may be OK, I
suppose. If, on the other hand, you believe that you'll need to
address customer and deployment issues as they arise (i.e. if you
believe a protocol is a living, breathing entity that needs to adapt
to changing times and situations), you need a bit more flexibility and
extensibility (and I strongly believe in a vendor-extension mechanism,
which has proven critical in many protocols over the years to test out
new features before proposing them). JFK implicitely (or explicitely?)
slams the door on vendor-extensibility.

Again, a management channel via which I can add different management
messages as I decide I need them is a wonderful idea.

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