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

RE: ISAKMP_RESPONDER_LIFETIME (Could it be removed?)



> From 2409, Section 5.
>
> 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.
>
>
> I don't necessarily agree with it, but if you want
> interoperability, I would
> use the RESPONDER-LIFETIME notify instead.


I believe this constraint is required in order to allow stateless operation.
In other words, it's an artifact, just like cookies.

Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephane Beaulieu
> Sent: Friday, November 17, 2000 11:20 AM
> To: antonio.barrera@nokia.com; ipsec@lists.tislabs.com
> Subject: Re: ISAKMP_RESPONDER_LIFETIME (Could it be removed?)
>
>
> From 2409, Section 5.
>
> 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.
>
>
> I don't necessarily agree with it, but if you want
> interoperability, I would
> use the RESPONDER-LIFETIME notify instead.
>
> Stephane.
>
>
> ----- Original Message -----
> From: <antonio.barrera@nokia.com>
> To: <ipsec@lists.tislabs.com>
> Sent: Friday, November 17, 2000 9:15 AM
> Subject: RE: ISAKMP_RESPONDER_LIFETIME (Could it be removed?)
>
>
> > I noticed that some implementations actually allow a reply with an
> > SA with different lifetimes so if the reply contains a
> smaller lifetime
> > means that
> > the other peer is using a smaller lifetime. In these cases
> > RESPONDER_LIFETIME is actually useless.
> > Is it mandatory that the SA in the reply has exactly the same
> > lifetime or it can be smaller?
> > I think taht would be a good solution for a further version
> of IKE to get
> > rid of the RESPONDER_LIFETIME. Anyway it doesn't appear to
> be used too
> much.
> > Any coments?
> >
> > Toni
> >
> > -----Original Message-----
> > From: EXT Tero Kivinen [mailto:kivinen@ssh.fi]
> > Sent: 16. November 2000 22:12
> > To: antonio.barrera@nokia.com
> > Cc: ipsec@lists.tislabs.com
> > Subject: ISAKMP_RESPONDER_LIFETIME
> >
> >
> > antonio.barrera@nokia.com writes:
> > > IPSEC DOI question:
> > >
> > > Is the ISAKMP_RESPONDER_LIFETIME notification payload supposed to
> > > send only the lifetime (seconds) or also the lifesize (KBytes)?
> >
> > Yes, I think both are allowed.
> >
> > > And if both can be send, should they both be send
> together in the same
> > > ISAKMP Notification payload (Of course same SA) or in 2
> different ones?
> >
> > I would say that they must be only one notification,
> containing both.
> > --
> > kivinen@ssh.fi                               Work : +358 303 9870
> > SSH Communications Security                  http://www.ssh.fi/
> > SSH IPSEC Toolkit
> http://www.ssh.fi/ipsec/
>
>



References: