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

Re: Simplifying IKE (was RE: Reliable delete notifies)



Hello Valery,

It is true that you can attempt to isolate ISAKMP code from IKE,
but imho you will never reach anything as clean as HTTP over TCP.

>Well, code sharing is not the only (and probably not the most
>important) issue here. My point here is that IKE is far from ideal
>now but it is stalled in this state due to sole political reasons. In
>this situation one could try to define another KE protocol inside
>ISAKMP framework, reusing its constructions (payloads, messages,
>attributes etc.). How much of ISAKMP code will be reused depends,
>again, on implementation design, but at least at the protocol
>definition level a lot of stuff will be. Combining everithing into
>one document will (ok, may) effectively eliminate this possibility.

I agree in some ways.  If ISAKMP is to remain a separate spec, we
(or rather, "someone") should define a new non-ipsec key management
protocol using it to ensure that it is reasonably separate from IKE.
The current state does not make sense, it should be either-or.

If ISAKMP is to be kept separate, I think a lot of stuff should be
removed from it.  The message format (header, payloads, etc) are
worth keeping, and so is the UDP transport mechanism (which should
be described more completely, esp. wrt completion of an exchange).

But eg the exchanges defined in the ISAKMP spec (apart from
Informational). I don't see any point in ISAKMP defining 'example'
exchanges (and even defining numbers for them) for two reasons.
First, the key exchange and authentication mechanism will (and has)
severely affected the actual payloads in the messages, and how the
messages should be processed (consider the RSA encryption
authentication modes).  Second, the code handling the exchanges
will almost certainly have to be tailored for the particular
exchange too, because of eg security and performance reasons.

Any two key management protocols taking the ISAKMP identity
protection exchange will probably have to re-define it to meet
the actual protocol's needs.  Again, consider IKE's revised RSA
encryption authentication mode (in main mode), and compare the
messages to ISAKMP identity protection exchange.

Of course it is useful to have sketches of how to design new
exchange types, but they should hardly be a part of the spec.

Sami
--
Sami Vaarala         /  Pygmy Projects - We make it small!
www.iki.fi/~silvere /
                   /  No matter where you go, there you are.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.