(racoon 805) Phase 1 lifetime control

[Yves-Emmanuel Jutard <ye.jutard@gmail.com>]

Hello,

I've not found evidences that racoon do any control over phase 1
lifetime when responding, which frighten me a bit.

I have looked in sourcecode, especially in ipsec_doi.c (v1.169
2004/03/27 03:27:45), function "get_ph1approvalx(...)" where lies this
code :

#if 0
      /* XXX to be considered */
      if (tsap->lifetime > s->lifetime) ;
      if (tsap->lifebyte > s->lifebyte) ;
#endif

Which is not like in function "get_ph2approvalx(...)" where extensive
checks over phase 2 lifetime are made.

And when I enable debug traces, I see :

*** LOG (7) : DEBUG: (t = 23665.455 s)
ipsec_doi.c:343:get_ph1approvalx(): Compared: DB:Peer
*** LOG (7) : DEBUG: (t = 23665.455 s)
ipsec_doi.c:344:get_ph1approvalx(): (lifetime = 420:600)
*** LOG (7) : DEBUG: (t = 23665.455 s)
ipsec_doi.c:346:get_ph1approvalx(): (lifebyte = 0:0)
*** LOG (7) : DEBUG: (t = 23665.488 s)
ipsec_doi.c:348:get_ph1approvalx(): enctype = 3DES-CBC:3DES-CBC
*** LOG (7) : DEBUG: (t = 23665.488 s)
ipsec_doi.c:353:get_ph1approvalx(): (encklen = 0:0)
*** LOG (7) : DEBUG: (t = 23665.488 s)
ipsec_doi.c:355:get_ph1approvalx(): hashtype = SHA:SHA
*** LOG (7) : DEBUG: (t = 23665.488 s)
ipsec_doi.c:360:get_ph1approvalx(): authmethod = pre-shared
key:pre-shared key
*** LOG (7) : DEBUG: (t = 23665.521 s)
ipsec_doi.c:365:get_ph1approvalx(): dh_group = 1024-bit MODP
group:1024-bit MODP group
*** LOG (7) : DEBUG: (t = 23665.521 s)
ipsec_doi.c:253:get_ph1approval(): an acceptable proposal found.

Is this really acceptable ? It also seems that racoon always take his
own lifetime as the IKE SA lifetime, thus ignoring peer lifetime.

So here are my questions :

- do racoon make any control over phase 1 lifetime ? (or do I mistake ?)
- do racoon properly handle phase 1 lifetime ?
- if not, is it dangerous ? Or is it acceptable ?

Best regards,

Yves-Emmanuel.