Michael Richardson writes: > A1) Upon receipt of an IKEv1 message, such a peer should reply with an > IKEv1 format notify INVALID-MAJOR-VERSION. Seems perverse to use IKEv1 > to say, "I do not speak IKEv1" > {"En puhuto sumalainen"} ^^^^^^^^^^^^^^^^^^^^ En puhu suomea.
> A2) Upon receipt of an IKEv1 message, such a peer should reply with an > IKEv2 format notify INVALID_MAJOR_VERSION (n=m=2). This is what a pure > IKEv2 > implementation would respond with, but which an IKEv1 initiator would > not understand. > > B1) Upon receipt of an IKEv2 message, such a peer should reply with an > IKEv2 format notify INVALID-MAJOR-VERSION (n=m=1). > > B2) Upon receipt of an IKEv2 message, such a peer should reply with an > IKEv1 format notify INVALID-MAJOR-VERSION. This is what a pure IKEv1 > implementation would respond with. In all of these cases I think it is best to sent a INVALID-MAJOR-VERSION notify back with same level than the incoming packet was. If the implementation really supports both versions this is what will most likely happen, as when you receive the packet you will parse it as IKEv1 or IKEv2 message depending on the version number in the packet, and the code sending error message back is IKEv1 or IKEv2 specific. I.e., if the packet is for IKEv1 then you process it using IKEv1 library and send errors based on that. If the packet is for IKEv2 you use your IKEv2 library etc... On the other hand as other end will ignore the message as it is unauthenticated, this will simply act as debugging help. Other option is simply silently drop the message and log the reason to the log. > C) since we can identify the policy by IP address, we can respond, but > do we respond with A1 or A2? For other IP addresses we may well support > the requested version. > > D) ditto for C. Same here. > E) upon receipt of IKEv2 message, we have to proceed until we can > process the ID in the I1. Having done, we notice the PAD says not to do > IKEv2, so reply in IKEv2, saying... INVALID_MAJOR_VERSION? Or > NO_PROPOSOL_CHOSEN? In that case you need to reply with AUTHENTICATION_FAILED not NO_PROPOSOL_CHOSEN. NO_PROPOSOL_CHOSEN in to the IKE_AUTH would mean that the Child SA exchange failed, and the IKEv2 SA would still be created. Returning AUTHENTICATION_FAILED means that the whole IKEv2 exchange failed, and IKEv2 SA is removed also. I.e., the authentication failed because the ID did not allow using IKEv2, thus no proper credentials was found for the IKEv2 SA to authenticate it. Using INVALID_MAJOR_VERSION is wrong, as you do know how to process the packet, your policy simply do not allow you to accept the incoming connection using that combination of protocol version, ID and algorithms. > F1) upon receipt of an IKEv1 MAIN MODE message, we have to proceed until we > can see the ID, which means getting the I3 message. > And then INVALID-MAJOR-VERSION? We may well be able to authenticate the > peer! > > F2) upon receipt of an IKEv1 AGGRESSIVE MODE message, we process until we > can see the ID, and then INVALID-MAJOR-VERSION? In IKEv1 returning NO_PROPOSOL_CHOSEN is most likely proper answer. On the other hand, the other end will most likely ignore it and simply time out after some time. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec