[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bellovin's and Ashar's attacks
Amir:
>> In the case of the shared host, we need to ensure that the protocol
>> conveys information necessary to prevent leakage when the enemies
>> serially reuse the same resource, a port in the recent examples.
>> discading the key when the port is closed sounds great. Better yet,
>> Discard the key and tell the other key management daemon that you did
>> it.
>
> This is fine when the host is running IP-SEC. The problem persists if
> the host is unmodified and IP-SEC is done at a firewall/encrypting
> router. In this case, the firewall would not know that the port was
> closed.
>
> The only solutions so far are fast re-key and counters; both are, as
> pointed out on the list, imperfect as they still allow an attacker to
> re-play packets within the timeout period (both methods must allow
> time-out period of at least the maximal allowable round trip delay). For
> manual attackers this may be OK, but, as was pointed out, one could run a
> program that constantly looks for closed ports and immediately tries to
> replay traffic.
You are discussing a case with shared comms and a shared host here. I
understand the attack. I just do not think that it is an attack that we
should worry about. If the IPSEC is implemented in a firewall/encrypting
router, then the commuications is vulnerable to interception on the network
between the unmodified host and the firewall/encrypting router. I do not
think that we should spend a lot of time and energy trying to prevent a
socket reuse attack when the sniffer attack is not prevented. Either you
trust the communications environment between the host and the
firewall/encrypting router. If you don't trust it, then put IPSEC at the
host.
Russ