On the contrary, there is a specification that addresses this. RFC 2409 section 5 contains the following paragraph about phase 1 (security association) exchanges: During security association negotiation, initiators present offers for potential security associations to responders. Responders MUST NOT modify attributes of any offer, attribute encoding excepted (see Appendix A). If the initiator of an exchange notices that attribute values have changed or attributes have been added or deleted from an offer made, that response MUST be rejected. Since lifetime is one of the attributes, modifying it from the initiator's request is forbidden, and the initiator is required to reject it even if it is done. This indeed happens with the Win2k/2k3/XP implementation. I don't know about other vendors' implementations. -nh > From: YAMASHITA Yutaka <yutapon@tera.ics.keio.ac.jp> > Reply-To: <racoon@kame.net> > Date: Thu, 21 Oct 2004 22:32:04 +0900 > To: Yves-Emmanuel Jutard <ye.jutard@gmail.com> > Cc: <racoon@kame.net> > Subject: (racoon 821) Re: Phase 1 lifetime control > > On Wed, 13 Oct 2004 17:44:24 +0200 > Yves-Emmanuel Jutard <ye.jutard@gmail.com> wrote: >> >> 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 ? > > Hi, > > There is no specification/draft about phase 1 lifetime treatment. > So, such implementation depends on each vendor. > Some vendors' implementation are different from other vendors'. > Racoon always take its own lifetime as the ISAKMP SA lifetime > because many other vendors' implementations do so. > > thanks > -- > ----------------------------- > - YAMASHITA Yutaka - > Keio Univ. ICS. Teraoka Lab > yutapon@tera.ics.keio.ac.jp > -----------------------------
Attachment:
smime.p7s
Description: S/MIME cryptographic signature