See my earlier mail exchange with Tero. That section is descriptive, not
prescriptive, and we should describe why the (new) message sequence works fine
with older clients, even though they obviously don't support the new
notification. What you say below may be sufficient: there's stale state lying
around, but both sides still agree on the correct IKE SA to use.
Thanks,
Yaron
> -----Original Message-----
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Yoav Nir
> Sent: Thursday, January 21, 2010 8:11
> To: Paul Hoffman
> Cc: IPsecme WG
> Subject: Re: [IPsec] Issue #150: What happens if the peer receives
> TEMPORARY_FAILURE and does not understand it
>
> We can't really prescribe actions for (presumably older)
> implementations that don't support this spec.
>
> Such implementations will do what it says in RFC 4306 and the
> clarifications document: TEMPORARY_FAILURE is an error notification, so
> therefore the exchange failed. In that case the old SA remains until
> this or the other end deletes it. If the other side has rekeyed, we're
> fine.
>
> On Jan 20, 2010, at 11:03 PM, Paul Hoffman wrote:
>
> > 2.8.2: we should add a sentence on what happens if the peer receives
> TEMPORARY_FAILURE and does not understand it (because it's new to this
> spec).
> >
> > --Paul Hoffman, Director
> > --VPN Consortium
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> > Scanned by Check Point Total Security Gateway.
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
