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
