Subject: [IPsec] IKEv2: Behavior when IKE_SA_INIT Message 1 has an unacceptable DH group

From: "Matthew Cini Sarreo" <[email-masked]>
Date: Mon, 8 Dec 2008 17:36:58 +0100

Hello,

Let's consider the following scenario:
Two IKEv2 peers, A and B want to initiate an IKE_SA (this is the first SA),
and A (Initiator), who is configured to request just one, specific DH Group,
not a group of groups, guesses an unacceptable DH Group (say, it is
configured to use MODP_2048 but B only supports MODP_1024).

The first message is sent, using a KE payload with MODP_2048 as DH group.
When B parses the proposal for MODP_2048, it realizes that it does not
support that group. What does B do? The options (atleast, that come to my
mind) are:
1) Disregard the group and use the highest possible group (i.e MODP_1024).
To me, this does not seem plausible.
2) Wait until A resends a proposal with the correct DH Group. This would
probabbly cause a deadlock, as A will assume that the peer is dead after DPD
runs out.
3) Send somekind of reply to tell A that the Group was inacepptable, and to
use another one. Preferibly, this other group would also be included. To my
understanding, an Informational Message with INVALID_KE_PAYLOAD would be the
the correct way to follow this point (3) and the correct way to behave in
this scenario. I got this understanding from Par 7 in Section 2.7 of
draft-ietf-ipsecme-ikev2bis-01, which reads:

Since the initiator sends its Diffie-Hellman value in the
> IKE_SA_INIT, it must guess the Diffie-Hellman group that the
> responder will select from its list of supported groups. If the
> initiator guesses wrong, the responder will respond with a Notify
> payload of type INVALID_KE_PAYLOAD indicating the selected group.
>

This seems to make it clear that at this point, the IKE_SA has not yet been
established due to an error in the IKE_SA_INIT exchange. But, section 1.5
states that:

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

> {{ Clarif-7.7 }} There are two cases when such a one-way notification
>    is sent: INVALID_IKE_SPI and INVALID_SPI.  These notifications are
>    sent outside of an IKE SA.  Note that such notifications are
>    explicitly not Informational exchanges; these are one-way messages
>    that must not be responded to.
>
>
The confusion lies here: does a one way Informational Message exist only in
the case when a known Peer sends a message with an invalid SPI to a peer
that it already had an SPI with (say, a crash caused a state loss), or
whenever any IKE_SA is not available, these are the only two possible things
to do? Logically, I would say that if Informational Messages CAN happen
before the IKE_SA is established, but this does not seem to be clearly
stated.

I am sorry if this question has an obvious answer, this is my first
experience with something similar to IKE.

Regards,
Matthew
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Dec 2008 20:10:03 +0200

> configured to use MODP_2048 but B only supports MODP_1024).

If both ends are configured that way, then there is no way they can
ever get any IKE SAs up, thus it does not really matter that much how
you fail it. 

> To me, this does not seem plausible.

The responder cannot select any group that is not proposed by the
initiator, and if initiator only offered 2048 bit group, then he do
not have options. He either selects that or fails the exchange. 

> probabbly cause a deadlock, as A will assume that the peer is dead after DPD

If A is configured to use only 2048 bit group, it will not ever change
to any other group unless someone manually fixes the policy. 

> use another one.

The correct solution is to send NO_PROPOSAL_CHOSEN, as none of the
proposals sent by the initiator is acceptable for B. The use of
INVALID_KE_PAYLOAD is only possible if the A proposed something that
would be acceptable for the B, but just selected wrong group for the
KE payload. I.e. the INVALID_KE_PAYLOAD will indicate the selected
group B selected from the offer given by A. If none of the offers were
acceptable then NO_PROPOSAL_CHOSEN is the sent instead.

> >    that must not be responded to.

That clarification talks about ONE-WAY notifications.
NO_PROPOSAL_CHOSEN or INVALID_KE_PAYLOAD are not one-way
notifications, they are error notifications replies that are part of
the normal IKE_SA_INIT exchange.

> before the IKE_SA is established, but this does not seem to be clearly

INFORMATIONAL exchanges are not used in the case you explained, it is
using normal reply to the IKE_SA_INIT exchange but the contents will
be the error notification. 

If you check out the section 2.4 of the RFC4718 that has some diagrams
explaining the situation more. All the messages shown there do have
IKE_SA_INIT in their exchange type field, and all sent by initiator
will have R(esponse) bit set to 0, and all sent by responder will have
the R(esponse) bit set to 1 in the flags of the header. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec