[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