[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEv2 (son-of-ike) draft
I read through some of this draft, and mainly I'd say it looks very
good. At least when compared to the current RFCs. Comments follow.
- If, as I understand, there is to be a 'selection' as to what will
be the next IKE, what chance has anybody against a protocol that is
named draft-ietf-ipsec-ikev2-00.txt?
As to the specifics of this protocol, in my view IKEv2 should have
these kinds of requirements:
- IKEv2 must enable all traffic to be protected as well as possible.
If there is no common authentication method, a method to do just
encryption should be provided.
- IKEv2 must be well defined. For example, this draft doesn't state
clearly how the critical bit is to be used (for each payload), notifies
are unclear and should be accompanied by a state machine.
I.e. if a cert payload with critical bit contains a DSS-signature,
is it critical that you know "cert payload", support DSS-signatures, or what?
- I have a strong dislike for the current VID method. It fails to
provide several key requirements:
a) Some problems are best solved by having a new payload in the
first message. Like in ESPUDP IKE negotiation we could have used
such a payload, but it's not possible with VIDs. (The bad thing about
this is that it's not easy to change the protocol structure when
official numbers are assigned.)
b) A VID does not define how the protocol is to be extended, it
just says that after you see this, you can twist IKE as much
as you want.
c) A VID does nothing to prevent conflicts between two drafts that
just happen to allocate the same private use number.
Here's an alternative to VIDs that we could consider:
- A new payload is defined that defines exactly what private use numbers
an implementation uses and what they are used for. In this way the private
use numbers are viewed as variables, i.e.
#define PAYLOAD_TYPE_128 "draft-my-draft-whatever-00.txt:nonce-thingie"
etc., or use an OID instead
- The initiator sends that in the first message, and following that payload
a payload of type 128 may occur in the same message. The responder sends
them in the first reply.
- Responder will map only private use attributes that don't conflict with
the initiator's choices. So a draft will never say "payload number 128",
it will say "private payload that maps to xxxx".
- IKEv2 would be easier to test if a method to authenticate using preshared
secrets was provided. Like, how about hmac-sha-1 signatures?
Ari
Radia Perlman - Boston Center for Networking wrote:
>
> And to answer some of the recent email on the list...this
> protocol does maintain the phase 1/phase 2 notion, but sets up
> both phase 1 and phase 2 in a single 2-round-trip exchange.
> After the initial exchange, additional SAs can be set up,
> or the SA can be rekeyed, with a single round trip. And it
> does identity hiding of both ends.
>
> Most of the work was in rewriting the three documents into
> a single self-contained document, and cleaning up the "networking"
> type issues and overly complex encodings such as
> the SA payload.
>
> Radia
> ------------- Begin Forwarded Message -------------
>
> To: ipsec@lists.tislabs.com
> From: dharkins@tibernian.com
> Subject: IKEv2 (son-of-ike) draft
> MIME-Version: 1.0
> Content-ID: <2377.1006067452.1@SailPix.com>
>
> This draft was submitted but hasn't shown up yet in the repository
> (the I-D editor is, no doubt, swamped) so in the interest of giving
> people more time to look at it prior to Salt Lake here's a link:
>
> http://www.lounge.org/draft-ietf-ipsec-ikev2-00.txt
>
> Please send comments to the list.
>
> Dan.
>
> ------------- End Forwarded Message -------------
--
"They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety." - Benjamin Franklin
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise
Follow-Ups:
References: