Subject: [IPsec] New issue: INTERNAL_ADDRESS_FAILURE error and how to continue.

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Dec 2009 15:24:18 +0200

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.
-- 
[email-masked]

---

From: Dan McDonald <[email-masked]>
Date: Tue, 1 Dec 2009 09:40:08 -0500

> require address by policy.

Interactions like these show the hazards in integrating address configuration
into a key exchange protocol.  But since we've already thrown in with this
since the days of MODE-CFG in IKEv1...

> Perhaps adding following paragraph to the end of 3.15.4 would help:

This is definitely the right idea.  And the responder should already be able
to react to either initiator choice (try with existing IKE SA, or deal with
new IKE SA).

Dan

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Dec 2009 11:53:09 -0800

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:
>_______________________________________________
>IPsec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 10 Dec 2009 23:22:18 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Hoffman
> Sent: Thursday, December 10, 2009 21:53
> To: [email-masked]
> Subject: Re: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to
> continue.
> 
> Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Dec 2009 14:00:32 -0800

>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.

Good point.

Current:
>  The timeout should not be too

Proposed:
>  The timeout should not be too
>  short (especially if the IKE SA is started from the beginning)
>  In many cases, the cause of the errors is that the address pool of
>  the responder is depleted, and this can
>  only be fixed when more entries are
>  returned to the address pool of the responder. This is likely
>  to take several minutes.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 11 Dec 2009 15:45:02 +0200

Yaron Sheffer writes:
> 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.

Can you give me example what other error causes can cause this error
notification? Do you think they require any other type of handling
than what is listed in my text?

Anyway we can change the text to be following if that is better:

  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 are not fixed quickly, thus timeout should
  likely be several minutes. For example address shortage problem will
  only be fixed when more entries are returned to the address pool of
  the responder when other clients disconnect or when responder is
  reconfigured with larger address pool.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 11 Dec 2009 16:24:27 +0200

No, I don't have a good example. But the error code is not reserved specifically for this situation, so I wouldn't want to imply that it is.

Anyway, I'm OK with your text and also with the text that Paul proposed earlier.

Thanks,
	Yaron

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Friday, December 11, 2009 15:45
> To: Yaron Sheffer
> Cc: Paul Hoffman; [email-masked]