[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE v2 Requirements and backwards compatability
>>>>> "Tylor" == Tylor Allison <allison@securecomputing.com> writes:
Tylor> Well, one has to ask the question, what should a
Tylor> "correctly-implemented" IKEv1 responder do? Unfortunately the
Tylor> RFC is not explicit...
>> From rfc.2408, section 5.2 ISAKMP Header Processing:
Tylor> " 3. Check the Major and Minor Version fields to confirm they
Tylor> are correct (see section 3.1). If the Version field
Tylor> validation fails, the message is discarded and the following
Tylor> actions are taken:
Tylor> (a) The event, INVALID ISAKMP VERSION, MAY be logged in the
Tylor> appropriate system audit file.
Tylor> (b) An Informational Exchange with a Notification payload
Tylor> containing the INVALID-MAJOR-VERSION or INVALID-MINOR- VERSION
Tylor> message type MAY be sent to the transmitting entity. This
Tylor> action is dictated by a system security policy."
That's explicit enough. Unfortunately, it's also the not the answer
you'd want to see.
In order to deal with IKEv1 vs. IKEv2 "without undue delay" as I
suggested should be the requirement, you need a timely way to
recognize a V1-only implementation. If the "invalid version number"
message were mandatory, this could be done (modulo the issue of lack
of authentication).
Given that the message is optional, the version number field has no
value.
It sounds like we're stuck with timeout as the mechanism for detecting
V1-only implementations. Yuck. If that's right, then there is no
reason to stick with the old port number.
paul
Follow-Ups:
References: