Re: Racing QM Initiator's

["Valery Smyslov" <[e-mail]>]

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.