ISAKMP Policy Negotiation

[stephan.l.martin1]

Greetings,

As I am currently working my way through the SVPN course I have a question which continues to peek my interest. My question is this:

HOW is the policy negotiation determined between two devices during the ISAKMP parameter negotiation. Within the negotiation process is it the first proposed and acceptable policy or does it prefer the more secure of the two options for matching policies between two peers. I understand that all parameters except the lifetime must match. If there is an RFC or Cisco document that outlines the negotiation process of the policies when there are 2 policies that match but in different order I would really like to review it for my own sanity.

Thank you in advance for any assistance you can offer!

[Rob Ingram · Accepted solution]

Hi,

It's the highest isakmp policy of the initiator of the tunnel which matches with the peer (responder) that determines which policy to use.

HTH

[stephan.l.martin1]

Thank you, Rob, for the quick response. I was able to review the RFC for the relevant information that I was looking for. My next question would be how is the initiator determined. The question itself may be pointless as if you use best practice it should result in the most optimal and secure policy being selected but I'm more of a definitive type person and like to understand specifically how a device arrives at the decision and what process is taken to determine who is in control of the establishment (like OSPF priority in DR election). If the process is of no consequence and the initiator is determined by who asks first so be it. 

Thank you again!

[stephan.l.martin1]

In my quest I think I have found the answer to my question thanks to you Rob. As I now understand it based on the context within this document: https://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ikevpn/configuration/15-2mt/sec-ike-respond-only.html the initiator is based specifically on the initiation of interesting traffic that matches the crypto ACL as it is defined when the lack of an SA is present. As it seems, limiting this function is not ideal for standard use cases and as such should be left as is. 

edit- I see that you responded well before I ventured upon this. Thank you again for your help.

[Rob Ingram · Accepted solution]

When using a Policy Based VPN (crypto map) the initiator is the the peer that generated interesting traffic, which matched the crypto ACL kicking off the ISAKMP process. Both peers could be configured to initiate or repond only.

With a Routed Based VPN it depends. If a static VTI (point-to-point) then it's pot luck, which ever virutal interface was up first would be the initiator, unless you manually configure one peer to be the initiator and the other to repond only. If DVTI or DMVPN, then only the spoke would initiate the traffic.

Hope that makes sense.