Hi, I just want to repeat what I said yesterday at the meeting.
The main motivation for count-based rekey is to limit the amount of data protected with a single key that an attacker can use to mount an attack. Generally the more data is available to attacker, the more chances it has to break the key. If we assume that we are in Dolev-Yao threat model, then an attacker has no access to inside the hosts, but it has an unlimited power on the network. Generally speaking with this model the most sensible thing is to count only the outgoing traffic and not the incoming traffic. Below is described why. The proposal to modify the protocol so that only one side initiates every next rekey may lead to the following situation. Consider we have two hosts A and B, they negotiated that the next rekey will be initiated by B. There are 2 unidirectional ESP SAs between them, but for simplicity we will only consider one of them - from A to B. For this SA host A sends traffic and host B receives it. Both hosts are configured with some threshold, that should trigger the rekey. Host A counts bytes it sends, and host B counts bytes it receives. If the network is lossy, then some packets on the wire will be lost, so that host's A count will usually be greater than host's B count. In this situation what should host A do when it reaches the threshold, but the other side doesn't start a rekey? If it continues to send data, then it will violate its own policy, sending out more data, than the safe limit for a particular algorithm is. If it stops sending data, then the peer will never reach the threshold and never rekey. The things get worse if an attacker makes actions on the path. The attacker can deliberately drops some packets, so if the sending side continues to send data, then the attacker can get much more data for mounting an attack than it would get if the rekey would always be initiated by the side, which sends data and reaches the threshold (whatever sending side reaches it first). Note, that there is little sense in this situation to count the incoming traffic (*), since the receiving side doesn't see dropped packets and thus doesn't know what the real amount of distinct data were protected with the same key and made available to an attacker. Note, that packet replication in the network is not a problem, since replicated packets don't give the attacker any new information (they are identical). But dropped packets usually trigger retransmission mechanism and depending on how it is implemented, it may give additional information to an attacker (if retransmitted packets are different from the dropped ones, e.g. if retransmission is made on application level before encryption and every retransmitted packet is different from previous ones). (*) If we consider side-channel attacks, then it makes sense to count an incoming traffic too, but this is a complex topic and in my understanding is beyond the Dolev-Yao model. Regards, Valery. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
