[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE v2 Requirements and backwards compatability
On Tue, 18 Dec 2001, Henry Spencer wrote:
> On Tue, 18 Dec 2001, Bill Sommerfeld wrote:
> > > (b) An IKE1-only responder must reliably reject attempts to use IKE2
> > > to it.
> >
> > Retroactive specification is such fun.
> > Do you mean:
> > a *correctly-implemented* IKE1-only responder
> > or
> > "all commonly-used IKE1 implementations"
> > ?
>
> I would say that the former is essential and the latter is highly desirable.
> You're right, there is a difference...
>
> Henry Spencer
> henry@spsystems.net
Well, one has to ask the question, what should a "correctly-implemented"
IKEv1 responder do? Unfortunately the RFC is not explicit...
>From rfc.2408, section 5.2 ISAKMP Header Processing:
" 3. Check the Major and Minor Version fields to confirm they are
correct (see section 3.1). If the Version field validation
fails, the message is discarded and the following actions are
taken:
(a) The event, INVALID ISAKMP VERSION, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-MAJOR-VERSION or INVALID-MINOR-
VERSION message type MAY be sent to the transmitting entity.
This action is dictated by a system security policy."
What complicates the matter more is that even if the responder sends back a
notify with the proper INVALID-MAJOR-REVISION set... this notify cannot be
authenticated, and is not guaranteed to be delivered. This does not
constitute a "reliable rejection" by the responder... atleast not a
rejection that can be determined by the initiator.
My point: IKEv1 does not adequately specify what must be done in error
conditions during each step of the negotiation. Should this be a
requirement for SOI? I believe that it should. Think of all the states
the IKE/SOI engine can enter during a negotiation, and how one would go
about aborting the negotiation in each of these states. Some examples:
1) the example above, where the responder rejects the first packet
from the initiator and no state exists between peers.
2) when the initiator instantiates the SKEYID and sends an outbound
packet, but the peer (responder) rejects inbound packet.
3) Initiator sends first round of Quick Mode and responder rejects
proposal.
These are just a few examples...
Bottom line: Error handling in current IKE implementations is erratic and
very vendor-specific. To our user community, this is very frustrating when
VPNs fail to establish without a clear indication of what went wrong.
=====================================================================
= Tylor Allison Secure Computing Corporation =========
= phone: 651.628.1554 e-mail: allison@securecomputing.com =========
=====================================================================
Follow-Ups:
References: