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

Comments on IKEv2

Dan, Charlie, Radia,

Thanks for taking the effort of putting this together.  Here are a few
comments and
(hopefully) constructive criticisms.  My comments focus mainly on management
issues.

1 - I'm not a big fan of merging of the three documents.  I guess I've grown
accustomed to the way it was.  I suspect those who wanted to define new DOIs
will probably strongly object.  Myself, I just find the new doc to be too
cluttered with info.  No reply necessary on this point.  I understand why it
was done.  I'm just voicing my opinion on this one.

2 - Many nice new features were added (Stateless Cookies, IKE rekey, removal
of modes / methods, removal of commit bit, Tero's HASH fix, SA payload
negotiation, Continuous Channel Mode, fixing K1, K2, K3 calculation,
Critical Bit, many
more....)  Good Job !

3- It would have been nice to have Legacy Auth built into IKEv2.  Dan had a
good proposal with CRACK.  I understand the political motivation for leaving
this out though.

4 - Section 2.2 (sequence numbers).
- What is the expected behavior if a peer receives a sequence number which
is out of whack.
- It will be possible to receive CREATE-CHILD-SA out of order if several
requests are sent simult.  What do you do in this case.
- If the point of seq numbers is to identify retransmits, then I would guess
we would need to keep a window, rather than just a "current" Message ID.
- What is the expected behavior if / when MID reaches 2^32.  OK it'll never
happen, but we still have to write code for it.  I expect if this is used
for DPD (Dead Peer Detection), then an IKE rekey would be necessary at this
point.  This should be documented.

5 - Section 2.3.
- What is the point of the window size.  I figure if Bob can't handle all
the requests, he can just drop them, and Alice will retransmit.  This seems
a little bit simpler than negotiating / managing a window.

6 - Section 2.4
"If a cryptographically protected message has been
   received from the other side recently, unprotected notifications MAY
   be ignored. Implementations MUST limit the rate at which they
   generate responses to unprotected messages."
IMO, if you're doing CC mode AND you have DPD (IKEv2's null-query equiv),
unprotected notifications MUST ALWAYS be ignored.  If the peer can't respond
to a null-query, then he is dead.  Kill him !  Hopefully (in a good
implementation) a peer sending traffic into a black hole will notice that
you're not responding to packets, initiate his own null-query, and figure
out that the peers are out of sync.  See the DPD draft for more discussion
on this.

7 - Section 2.8 - Rekeying
last sentence "The node that initiated the rekeying SHOULD delete the older
SA
   after the new one is established."
I believe the following sentence needs to be added for completeness
"The node that is the responder SHOULD NOT delete the older SA until it
receives traffic on the new SA".  along with a little bit more text talking
about the timing issues (i.e. responder's keys are ready before the
initiators keys)
This timing problem is discussed in detail in Tim Jenkin's expired rekey
draft.

8 - Missing AUTH in CREATE-CHILD-SA.
I notice that there is no HASH payload in the CREATE-CHILD-SA exchange.
This allows an attacker to replay the message and force a DH.  Or am I
missing something?

9 - Missing AUTH is Notify message.
- This is needed, especially if you're sending the null-query for DPD.
Else, an attacker could just keep transmitting null-query messages with a
different seq number in the header.

10 - INITIAL-CONTACT
 - We should specify exactly in which messages this should be specified.  I
would guess that it could be put in message 3 and 4, and it's presence added
into the AUTH calculation.

11- Deletes for IKE SAs.
- Why can't we specify the COOKIES to identify an IKE SA for deletion?  If
you get into a situation where a peer (which you have a valid IKE SA with)
is sending you data using unknown COOKIES then you could send an IKE delete
authenticated by the valid IKE SA to delete the unknown IKE SA.

12- VID payload.
- might want to rename this Feature ID payload, since that's what it's
become.

13- Nat traversal.
I think everyone (vendors at least) agree this is a problem.  Any chance of
integrating some of the drafts in here?

Thanks.
Stephane.
------
Stephane Beaulieu
S/W Engineer
Cisco Systems.
email: stephane@cisco.com
phone: (613) 254-3678