Example 1 and Example 2 show individual key exchange rules. A complete key exchange policy contains any number of key exchange rules. Key exchange rules in a key exchange policy are searched in the order listed. In the process of an IKE negotiation, Policy Agent searches the list of active key exchange rules to locate a best match. It is possible for more than one key exchange rule to match a pending IKE negotiation. For this reason, the list of key exchange rules in the key exchange policy should be ordered from most specific to least specific in much the same way as the IP filter rules. If the key exchange policy contains key exchange rules with both unique and wildcard security endpoints, the most specific definitions should be placed higher in the list than the wildcard definitions.
For instance, there might be one key exchange rule governing a connection from an internal administrative machine, and another key exchange rule governing all other hosts on the internal network, as follows:
KeyExchangeRule Admin_KeyExRule1
{
LocalSecurityEndpointRef Internal_IKED
RemoteSecurityEndpointRef Admin_IKED
KeyExchangeActionRef Bronze-PSK
SharedKey Ascii TheEagleHasLanded
}
KeyExchangeRule ZoneA_KeyExRule1
{
LocalSecurityEndpointRef Internal_IKED
RemoteSecurityEndpointRef ZoneA_IKED
KeyExchangeActionRef Silver-RSA
}
In this case, because the remote IKE peer that is defined by the remote security endpoint Admin_IKED matches both the Admin_KeyExRule1 and ZoneA_KeyExRule1 rules, the Admin_KeyExRule1 rule should be placed ahead of the ZoneA_KeyExRule1 rule in the key exchange policy as follows:
KeyExchangePolicy
{
KeyExchangeRuleRef Admin_KeyExRule1
KeyExchangeRuleRef ZoneA_KeyExRule1
KeyExchangeRuleRef ZoneB_KeyExRule1
KeyExchangeRuleRef ZoneC_KeyExRule1
}