Lack of error descriptions for Phase 1 in IKEv2

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

IKEv2 is still very thin on describing what should be done during 
Phase 1 in case of some pretty typical errors. This means that there 
will be little interoperability in common situations.

If message 1 contains cert-requests and the responder knows that his 
certs won't chain to any of the stated roots, he should send an 
INVALID_CERT_AUTHORITY notification in message 2. What else should be 
in message 2? Section 2.5 says that the payloads must be in the 
stated order, but it makes no sense to send anything in message 2 
other than the error notification payload.

If message 2 contains cert-requests and the initiator knows that his 
certs won't chain to any of the stated roots, he should send an 
INVALID_CERT_AUTHORITY notification in message 3. What else should be 
in message 3? According to Appendix B, message 3 should be encrypted 
and integrity protected; does that seem right for a fatal error such 
as this?

Same two questions for message 1 and 2, except about getting an IKE 
version number that is higher than what you support.

If message 3 has an error such as malformed payload or a 
cert-chaining failure, what should be in message 4? According to 
Appendix B, message 4 should be encrypted and integrity protected; 
does that seem right for a fatal error such as this?

If message 4 has an error such as malformed payload or a 
cert-chaining failure, what should the responder do?
- Send a "message 5" (and if so, should it be encrypted?)
- Start a Phase 2 so the responder can start an informational exchange,
   followed by a delete of both the Phase 2 and Phase 1?

Same two questions for message 3 and 4, except about getting an IKE 
version number that is higher than what you support. Section 2.5 says 
that the notification should be unauthenticated, but Appendix B says 
it MUST be authenticated.

--Paul Hoffman, Director
--VPN Consortium