On Fri, 15 Apr 2016, Michael Richardson wrote:
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.
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.
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?
If it receives a message with a major version that it supports, it MUST
respond with
that version number.
So 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!
Same.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
