Subject: [IPsec] response to Informational Messages outside of an IKE_SA

From: <[email-masked]>
Date: Thu, 10 Apr 2008 20:46:32 +0900

Hi all,

I am Hiroki ENDO, a member of TAHI project.
I am describing IKEv2 conformance test specfication and developping test tools.

I'd like to confirm what is "respond" in RFC 4306 Section 1.5.

RFC 4306 says:
------------------------------------------------------------------------
1.5.  Informational Messages outside of an IKE_SA
   ...
                                                                  If it
   does not have such an IKE_SA, it MAY send an Informational message
   without cryptographic protection to the source IP address.  Such a
   message is not part of an informational exchange, and the receiving
   node MUST NOT respond to it.  Doing so could cause a message loop.
                 ^^^^^^^
------------------------------------------------------------------------

Currently I think that "respond" is to send a response to an Informational message without cryptographic protection or to retransmita message which raises the Informational messsage without cryptographic protection.
Because such action can cause a message loop.

Though it may be not common case, the current test sequence and check point are as follows:

(Initiator)  (Responder)
    NUT        Tester
     |           |
     |---------->| IKE_SA_INIT request  (HDR, SAi1, KEi, Ni)
     |           |  (Judgment #1)
     |<----------| IKE_SA_INIT response (HDR, SAi1, KEi, Ni)
     |           |
     |---------->| IKE_AUTH request  (HDR, SK{IDi, UATH, SAi2, TSi, TSr})
     |           |  (Judgment #2)
     |<----------| IKE_AUTH response (HDR, N(INVALID_IKE_SPI))
     |           |
     |-----X     | no IKE message
     |           |   or
     |---------->| IKE_SA_INIT request  (HDR, SAi1, KEi, Ni)
     |           |  (Judgment #3)
     |           |
     V           V

Judgment #1
    NUT sends IKE_SA_INIT request.
Judgment #2
    NUT sends IKE_AUTH request.
Judgment #3
    NUT can send no IKEv2 messages to give up negotiation or send
    IKE_SA_INIT request to initiate negotiation again.

Is what I wrote correct?
How do you think the test sequence?

Thanks,
--
Hiroki ENDO
Yokogawa Electric Corporation
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 10 Apr 2008 16:14:00 +0300

> I'd like to confirm what is "respond" in RFC 4306 Section 1.5.

Respond in that case means that the responder do not send specific
reply to that informational message. It does NOT mean that the
initiator cannot still continue sending the original message (that is
not a response to the information message, that is simply
retranmission of packet which have not received reply yet). 

> Currently I think that "respond" is to send a response to an
> Informational message without cryptographic protection or to
> retransmita message which raises the Informational messsage without
> cryptographic protection.

Retransmission is allowed, and in most of the case actually desired.
I.e. as the informational message is not cryptographically protected,
the initiator will not necessarely act on it directly, but will keep
normal retransmissions for the previous message. It might use that
message as hint that there is something wrong, i.e. it might for
example limit the number of packets it is sending out. It should NOT
shorten the retranmission periods based on that. 

> Because such action can cause a message loop.

Loop will only be caused if the responder sends unauthenticated error
notify, and the initiator sees that unauthenticated error notify and
sends unauthenticated error notify because it received unauthenticated
notify, and then responder gets unauthenticated error notify and sends
again unauthenticated error notify about that etc...

>      |<----------| IKE_AUTH response (HDR, N(INVALID_IKE_SPI))

Here the initiator will most likely continue retransmission of the
IKE_AUTH as the N(INVALID_IKE_SPI) notify is unauthenticated. It might
use the unauthenticated N(INVALID_IKE_SPI) notify as hint that the
other end might have rebooted, so it might for example time the
exchange out after retransmitting its IKE_AUTH request only 2 or 3
times, instead of the normal 10 or so...

After it times the exchange out, it will most likely start the
exchange again after next packet that triggers SA creation is seen.
Note, that it might also act differently on the error cases which
cannot be fixed without adminstrator changing policy.

For example the the N(INVALID_IKE_SPI) usually just means that
responder rebooted between the IKE_SA_INIT and IKE_AUTH, so it should
try again immediately when the previous exchange times out, but for
example AUTHENTICATION_FAILED will not usually disappear until policy
is fixed in one of the ends, so in those cases it might for example
wait for few minutes before retrying (just to limit the number of
Diffie-Hellmans to be done by misconfiguration). 

-- 
[email-masked]

---

From: <[email-masked]>
Date: Wed, 16 Apr 2008 10:38:45 +0900

Hi Tero,

Thanks for your reply.
It is helpful for me.
I realized that it was difficult to test this case.

Thanks again,

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Thursday, April 10, 2008 10:14 PM
> To: Endou, Hiroki ([email-masked])
> Cc: [email-masked]
> Subject: [IPsec] response to Informational Messages outside
> of an IKE_SA
>
> ----------------------------------------------------------------------
> > -- 1.5.  Informational Messages outside of an IKE_SA
> >    ...
> >
>       If it
> Respond in that case means that the responder do not send
> specific reply to that informational message. It does NOT
> mean that the initiator cannot still continue sending the
> original message (that is not a response to the information
> message, that is simply retranmission of packet which have
> not received reply yet).
>
> I.e. as the informational message is not cryptographically
> protected, the initiator will not necessarely act on it
> directly, but will keep normal retransmissions for the
> previous message. It might use that message as hint that
> there is something wrong, i.e. it might for example limit the
> number of packets it is sending out. It should NOT shorten
> the retranmission periods based on that.
>
> Loop will only be caused if the responder sends
> unauthenticated error notify, and the initiator sees that
> unauthenticated error notify and sends unauthenticated error
> notify because it received unauthenticated notify, and then
> responder gets unauthenticated error notify and sends again
> unauthenticated error notify about that etc...
>
> > Though it may be not common case, the current test sequence
> and check
> > point are as follows:
> >
> > (Initiator)  (Responder)
> >     NUT        Tester
> >      |           |
> Here the initiator will most likely continue retransmission
> of the IKE_AUTH as the N(INVALID_IKE_SPI) notify is
> unauthenticated. It might use the unauthenticated
> N(INVALID_IKE_SPI) notify as hint that the other end might
> have rebooted, so it might for example time the exchange out
> after retransmitting its IKE_AUTH request only 2 or 3 times,
> instead of the normal 10 or so...
>
> After it times the exchange out, it will most likely start
> the exchange again after next packet that triggers SA
> creation is seen.
> Note, that it might also act differently on the error cases
> which cannot be fixed without adminstrator changing policy.
>
> For example the the N(INVALID_IKE_SPI) usually just means
> that responder rebooted between the IKE_SA_INIT and IKE_AUTH,
> so it should try again immediately when the previous exchange
> times out, but for example AUTHENTICATION_FAILED will not
> usually disappear until policy is fixed in one of the ends,
> so in those cases it might for example wait for few minutes
> before retrying (just to limit the number of Diffie-Hellmans
> to be done by misconfiguration).
>
> >      |           |
> >      |-----X     | no IKE message
> >      |           |   or