1 Answer
1

Actually, the attack is on CBC mode (which IPSec uses). In the attack, it modifies the encrypted packets, and uses the IPSec decryptor as a decryption Oracle.

How it works is based on how CBC-mode decryption works:

Note that any particular plaintext block depends only on the corresponding ciphertext block, and the one immediately before it (and the key); as long as those two ciphertext blocks are correct, the corresponding plaintext block will result.

What the attacker does is take the encrypted packet, and replace its payload contents with the message he wants to decrypt (aligned about the cipherblock boundaries).

He then forwards the modified message to the decryptor, which will proceed to decrypt the message. Now, consider how this decryption will happen for the parts of the message that he has replaced; if we ignore the very first block he replaced, then both the current ciphertext block and the previous one corresponds to the message he is attacking; hence the resulting plaintext will be the plaintext he is attacker.

That is, the resulting decrypted packet will have the plaintext of the message he is attacking embedded in it.

Then, if the security gateway forwards the message, it'll be forwarding a message containing the information the attacker is interested in.

As for your questions:

Why does the attacker need to firstly send some arbitrary UDP packet?

He needs to send a message that:

Contains an IP header that will eventually get somewhere where he can look at it. That's why we assume the attacker can't modify a random IP packet; the attacker can't assume he'll see that modified packet. Instead, he sends a message that's targeted at a confederate; as long as he's careful not to overwrite the inner IP header, that packet will get to somewhere he (actually, his confederate) can see.

Won't be checked to see if any checksums are correct. UDP can have checksums disabled; that's why Bellovin suggested it. Actually, it doesn't have to be UDP; any protocol that doesn't checksum its payload would work.

How can the attacker break the privacy between A and B?

Suppose the attacker sees a message going between A and B that he wants to read. What he does is generate a packet that'll go through the tunnel between A and B, and is targetted at his confederate. Once the packet has been encrypted and is traversing between A and B, he grabs the packet, and replaces the payload contents with the message he wants to decrypt (being careful not to disturb the inner IP header and the trailing ESP padding); he lets the modified packet go to B, which decrypts it, and forwards the decrypted packet to the confederate. The confederate then looks at the internal payload data and see the decryption of the original packet; he wins.