[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Retransmits in traffic count?
Andrew Krywaniuk writes:
> 2. Let's face it: it's probably not that much work for an attacker to guess
> which Isakmp packets are which. Unless you are clouding your network with
> lots of fake Isakmp traffic, it doesn't take a lot of brains for an attacker
> to guess that the first message in an exchange is QM1 and the next is QM2
> and if you see the same message twice in a row then it's a retransmit.
Attacker does not have to guess. He can see it immediately. The
generic ISAKMP header is NOT encrypted which means that attacker can
immediately see that this packet is first QM packet (exchange type qm,
new message id), second QM packet (exchange type qm, same message id
already sent by other end), or third QM packet (exchange type qm, same
message id than older QM packet). It can also detect all
retransmissions by just comparing the packets.
> So what difference does counting the retransmits against the SA make to most
> of us? Not much. But it's theoretically incorrect and it will degrade
> implementations that send multiple copies of the same packet.
I think the most important difference is that parties sent/received
counts get out of sync very quickly. If sender retransmits a packet
which didn't reach its destionation its sent counter is immediately out
of sync from the other ends receive counter. If we do not count
retransmissions then the only way to get counters out of sync is that
the negotiation times out (sender sends packets several times, and
none of them reaches the destination).
I think we should not be counting retrasmitted packets.
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
References: