Subject: [IPsec] returning INVALID_MAJOR_VERSION as a result of policy

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Apr 2016 15:24:00 -0400

Assume a responder which currently *implements* IKEv1 and IKEv2.

Consider the cases:
A) it has a global policy set to reject all IKEv1 connections.
B) it has a global policy set to reject all IKEv2 connections.
C) a specific policy (for a specific peer, identified by IP address) has a
   policy to use IKEv1 only.
D) a specific policy (for a specific peer, identified by IP address) has a
   policy to use IKEv2 only.
E) a specific policy (for a generic peer, identified by ID) has a
   policy to use IKEv1 only.
F) a specific policy (for a generic peer, identified by ID) has a
   policy to use IKEv2 only.

Perhaps cases B,D and F seem silly today, but assume "IKEv3" came along,
except that likely we would retain the packet format, so it would be less weird.
(Or perhaps the people who worry about Quantum Cryptography are suddenly
 proven right, and IKEv1's perverted main-mode with PSK *is* stronger)

I think that there is a significant tension between providing some useful
diagnostics to the other end vs telling too much about our policy.

I also consider that given code is already present, that it may be better
to proceed to parent SA established, and send a private message about wrong
version number.

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"}

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.

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.

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?

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?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: <[email-masked]>
Date: Fri, 15 Apr 2016 19:36:45 +0000

> On Apr 15, 2016, at 3:24 PM, Michael Richardson <[email-masked]> wrote:
> 
> ...

One approach would be: say nothing meaningful in the reply, but log information locally.  Then, if the other end is legitimate, the local end admin can examine the log and find what went wrong.  On the other hand, if the remote end is not legitimate, it learns nothing.

	paul

---

From: [email-masked]
Date: Fri, 15 Apr 2016 16:51:58 -0400 (EDT)

>    implementation would respond with, but which an IKEv1 initiator would

I dont see the problem? There is no incompatibility with the IKE haeder
between v1 and v2? And INVALID_MAJOR_VERSION has the same number (5) in
IKEv1 and IKEv2.

Anyy IKE daemon (v1, v2 or both) receiving an IKEv2 reply with
INVALID_MAJOR_VERSION should be able to read/log the error and understand
it means "invalid ike version, abort". The same is true if the reply
came as an IKEv1 message. Perhaps you need to ignore msgid, but that's
about it. The IKEv2 RFC states:

    If an endpoint receives a message with a higher major version number,
    it MUST drop the message and SHOULD send an unauthenticated
    notification message containing the highest version number it
    supports.

So yes, your IKEv2 packet might receive a reply from a MAJOR ikev1
packet. But your initiator SPI should allow you to look this packet up
regardless of major ike version.

>   IKEv2, so reply in IKEv2, saying... INVALID_MAJOR_VERSION?  Or NO_PROPOSOL_CHOSEN?

    If it receives a message with a major version that it supports, it MUST respond with
    that version number.

So NO_PROPOSOL_CHOSEN.

>   And then INVALID-MAJOR-VERSION? We may well be able to authenticate the

Same.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 Apr 2016 13:36:43 +0300

>     to say, "I do not speak IKEv1"
        ^^^^^^^^^^^^^^^^^^^^ En puhu suomea.

>     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. 

>    do we respond with A1 or A2?  For other IP addresses we may well support

Same here.

>    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.

>    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.
-- 
[email-masked]