-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


First, let me say that the decision for a 1 hour IKE
lifetime was made
for convenience more than anything else.  

The 8 hour IPsec lifetime came from the specification, true.
KLIPS supports byte and packet based expiry, but pluto never
actually
uses those.  (We have KLIPS test cases for it even...) 

In general, you want to rekey your IPsec SAs when they get
"chewed" up. (1Gb is considered enough data for a
~128bit key. I don't
know the math behind that)

Second, *swan doesn't care about lifetimes. IKEv2
acknowledges what
Henry and DHR observed --- a peer that wants a shorter
lifetime than the
peer can just rekey earlier. In IKEv2, lifetimes are just
notifications.

pluto will accept any lifetime the other end proposes.
Other vendors aren't so clueful.  You should file bugs with
the vendors
on this topic. It's a serious interoperability issue, and
you can point
out that RFC4306 makes it clear that IKEv1 got this wrong.

>>>>> "Tuomo" == Tuomo Soini
<tisfoobar.fi> writes:
    Tuomo> Another issue is short IKE SA lifetime. It
seems to be common
    Tuomo> interoperability issue that responder has
shorter IKE
    Tuomo> lifetime than initiator.

  Many systems do this so that the initiator will remain the
initiator.

    Tuomo> I attach patch to address that for known
windows
    Tuomo> connections. Same patch removes things for
type=transport and
    Tuomo> rightsubnet which should be fixed for 2.4.5 so
it can be
    Tuomo> defined.

  Your patches to the examples seem sane.
  Are you using git yet? (git-format-patch output against
our #public
would be great)

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.       
   |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON
   |net architect[
] mcrxelerance.com      http://www.san
delman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel
hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBQ8/GMoCLcPvd0N1lAQKYMQf/YYhiTha2IXRgvGUR3VHF0cwE+M1C
9yEL
SI5fniHSM0Sw555TNVSw9B7GfLNd5uIOfrGiQfkNeRnypcfIqizTQlHpBAj/
cbkB
7ZmnRqp2XJt+o3U2YCRkt0Yvx7Wd5u5cfVn/uPiQR5K+HQ6s1XZguRxlIbMh
HyeW
KnihilOxFsi3s3kdNlSNyB9L6jEu/bNhOxN0D+hg58fiCBkiLC793IBQweoc
2qZN
4/1IbBewWqsIjhS2H8Dk3OQ1QjH+Gtna3oUBG14BNU9cH7DKR1V7TjYJAaSH
Zjlh
E2ac813mrgS93KMGxq6Hn/LjU0H0pnuwz9mWuc6BKTfRpmFwOO4HKg==
=Er2A
-----END PGP SIGNATURE-----
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev