The issue came to my attention, after reading cisco article on IKEv2:
Under the proposal section it states:
> “Manually configured IKEv2 proposals must be linked with an IKEv2 policy; otherwise, the proposals are not used in the negotiation”
consequently when a proposal is manually configured, this must be called/linked to a policy for example:
> *> Crypto IKEv2 proposal nwlesson_Proposal*
> *> {Encryption Algorithm} e.g aes-cbc256 etc*
> *> {Integrity Algorithm} any hash of your choice e.g SHA etc *
> *> {Pseudo-Random function (PRF)} The PRF algorithm is the same as integrity algorithm, subesquently this does not to separately configured*
> {Diffie-Hellman(DH) Group}
> >
I discovered yesterday in the lab, **if** you want this proposal to be utilised in the IKEv2 negotiation it MUST be called/linked by a policy for example:
> *Crypto IKEv2 Policy nwlesson_Policy*
> *proposal nwlesson_Proposal (our proposal we configured above)*
During a friday night dinner out with the family. I kept thinking, what happens if we don’t link the proposal to a policy?
Subsequently from 10pm untill 1am in the lab, I tested this theory. The configured proposal(encryption, Integrity, PRF algorithm and DH group) is not utilised in the SA_INIT exchange of the IKEv2 negotiation, if there isn’t a policy!
subsequently the question becomes, what proposal is being utilised if the one we configured isn’t being used in the exchange?
The answer: the default proposal!(remember smart defaults?)
You will notice there is no policy that links the proposal, just a authorization policy which technically is completely different. Subsequently we are not using those proposal declared in the tutorial for the negotiation we are simply using **default** values provided by IOS:
in order to utilise the proposa(IKEV2_PROPOSAL)l that was declared in the lesson we must include the following in the tutorial guide:
> *Crypto IKEv2 Policy nwlesson_Policy*
> *proposal IKEV2_PROPOSAL*