[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE transport (was INITIAL-CONTACT issues)
> Dan> for IKE. You'll never get past the 3-way handshake if you have
> Dan> a malicious eavesdropper.
>
> You're talking about an active attack here, not an eavesdropper
> (passive attacker). And this is a denial of service attack.
When I used the word malicious, there was an implicit "active" in that word.
Sorry for not being clear.
> Sure, you can prevent the TCP connection from establishing. Likewise, I
> believe, you can prevent an IKE handshake from completing by inserting
> suitable packets, or deleting others.
You don't need to ability to delete packets to thwart TCP, only the ability
to inject. As for IKE, perhaps one can inject IKE-over-UDP packets to thwart
IKE, but adding TCP vulnerabilities complicates the problem.
> I wouldn't think that anyone claims IKE to be resistant to denial of
> service attacks. Are you saying it is?
No. I am saying that we're in the risk reduction business, so why bother
with TCP and its vulnerabilities when UDP works equally well. Using TCP
introduces new forms of attack.
Finally, from an end-to-end point of view, the request-reply nature of IKE
doesn't lend itself well to a reliable streaming protocol. Even though HTTP
works pretty well, many would argue that a scalable request/reply (or RPC
w/congestion avoidance) datagram protocol would've served better.
Dan
Follow-Ups:
References: