[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Racing QM Initiator's
On 14 Oct 99, at 9:24, Scott G. Kelly wrote:
> Valery Smyslov wrote:
>
> <trimmed...>
> > Another curious point - how IKE handles self-connect. Let us assume
> > we have IPsec host A and an attacker injects IKE packet (src_ip = A,
> > dst_ip = A, CKY-I = xxx, CKY-R = 0) into the network. A receives this
> > packet and (naively) begins to act as responder creating state and
> > replying with packet (src_ip = A, dst_ip = A, CKY-I = xxx, CKY-R =
> > yyy). Then it receives this packet back, binds it to that very state
> > and, most likely, rejects it (possibly with some error notification)
> > because it is malformed from his (responder's) point of view. After
> > some time state will die due to timeout. Is this scenario correct? I
> > understand that this situation causes no particular harm and it is
> > very easy to avoid by simple sanity check (compare IP addresses), but
> > still, IKE seem to have no special treatment of it, have it?
>
> Assuming policy is correctly configured (and implemented), this packet
> should never reach the IKE implementation, should it?
Why not? IKE is built atop TCP/IP stack, for the stack it is
perfectly valid packet, IPsec policy usually allows any IKE packet
(UDP/500) to pass through (otherwise you won't be able to communicate
with nomadic peers). So, what prevents this packet from reaching IKE
implementation? It may be dropped inside IKE implementation after
simple sanity check, as I wrote. But the question was (just for
curiosity): whether "self-connect" situation was considered by
protocol designers or not?
> Scott
Regards,
Valera.
Follow-Ups:
References: