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 <mcr+i...@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to