[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Position statement on IKE development
I stand corrected... well sort of.
KINK doesn't really re-use quick mode since certain things were
dropped like PFS and the whole commit bit stuff. So it's really
quick-mode-lite. And it doesn't use UDP port 500 so it's not really
ISAKMP after all. And I don't even think it uses the ISAKMP header.
It also defines as many (if not more) new payloads as it uses
from ISAKMP.
So all in all, KINK is not really doing quick mode nor is it
using ISAKMP.
Why don't you just define your protocol in full? I don't believe you'll
be sued for cutting-and-pasting payloads from RFC2408.
Dan.
On Sun, 05 Aug 2001 04:49:19 PDT you wrote
> Dan Harkins writes:
> > I discussed this in Minneapolis. The plan is to combine ISAKMP, IKE,
> > and the IPsec DOI into a single draft describing a key management
> > protocol for IPsec.
> >
> > The intent, as well-meaning as it was, was to have a generic language
> > (ISAKMP) in which to describe a key management protocol and there could
> > be many key management protocols with IKE as just one of them. IKE, then,
> > was supposed to be a generic key exchange protocol which could create
> > "SAs" for multiple services, of which IPsec (specified in the DOI) was
> > just one. But IKE is the only thing that used ISAKMP and the other two
> > DOI documents-- OSPF and RIP-- died a quiet death.
>
> Not entirely correct. KINK is using ISAKMP payloads
> (sa, id, nonce, ke, notify, delete, ie quick mode).
> IMO, the logical split here is between authentication
> and IPsec SA establishment. The former is *always*
> a far harder problem than the latter.
>
> Mike
>
Follow-Ups:
References: