I think Tero's text is somewhat speculative in assuming that this error case
only results from exhaustion of the address pool - I'm sure there can be other
reasons. Otherwise the text is OK.
Thanks,
Yaron
> -----Original Message-----
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Paul Hoffman
> Sent: Thursday, December 10, 2009 21:53
> To: ipsec@ietf.org
> Subject: Re: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to
> continue.
>
> Dan McDonald has agreed to this addition; does anyone else have an
> opinion?
>
> --Paul Hoffman
>
> At 3:24 PM +0200 12/1/09, Tero Kivinen wrote:
> >The section 1.2 says that if we get INTERNAL_ADDRESS_FAILURE then the
> >IKE SA stays up, but the child SA is not created. It does not say
> >anything what should happen on the initiator if it actually did
> >require address by policy.
> >
> >I think we have two options:
> >
> >1) Tear down the IKE SA (by sending DELETE payload inside
> > INFORMATIONAL exchange) and try again after suitable timeout.
> >
> >2) Keep the existing IKE SA up, but retry the configuration payload
> > exchange again after suitable timeout by starting new INFORMATIONAL
> > exchange and putting same configuration payloads in it.
> >
> >I think we might want mention something about this in the section 1.2,
> >or section 3.15.4 Address Assignment Failures.
> >
> >Most likely the section 3.15.4 is better, but we might want to add
> >forward reference from section 1.2 to there.
> >
> >Section 3.15.4 do explain how the responder can behave in different
> >situations, but it does not cover what initiator should do.
> >
> >Perhaps adding following paragraph to the end of 3.15.4 would help:
> >----------------------------------------------------------------------
> > If the initiator does not receive the IP address(es) required by its
> > policy, it MAY keep the IKE SA up and retry the configuration
> > payload (as separate INFORMATIONAL exchange) after suitable timeout,
> > or it MAY also tear down the IKE SA (by sending DELETE payload
> > inside separate INFORMATIONAL exchange) and retry IKE SA from the
> > beginning after some longer timeout. The timeout should not be too
> > short (especially if the IKE SA is started from the beginning), as
> > these error situations will only be fixed when more entries are
> > returned to the address pool of the responder, thus it will not be
> > fixed in seconds, but more likely it takes several minutes.
> >--
> >kivi...@iki.fi
> >_______________________________________________
> >IPsec mailing list
> >IPsec@ietf.org
> >https://www.ietf.org/mailman/listinfo/ipsec
>
> _______________________________________________
> 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
