The idea behind this kind of vulnerability is that per RFC 2328 Section 3.1:
Two different instances of an LSA are considered identical if they have the same:
• Sequence number
• Checksum
• Age (+/- 15 minutes)
Problem: The body of the LSA is not checked.
In fact, two LSAs are considered identical even if their Age fields differ by up to 15 minutes (and the Sequence Number and Checksum fields are the same). The key point is that the spec considers these two LSAs to be the same even if the actual advertised links in the LSAsdiffer.
A naive exploitation of this feature is to advertise an LSA with false links on behalf of a victim router while having the same values of the above three fields as the valid LSA advertised by the victim3. We call this false LSA a disguised LSA. When the victim receives the disguised LSA it will not fight back since it will consider it to be an identical copy of the last instance it advertised. Unfortunately, all other routers on the AS will also consider the disguised LSA as a duplicate and will not install it in their LSA database.
A better approach for the attacker is to advertise a disguised LSA that matches a recently generated LSA that has yet to be installed by all routers on the AS. On the one hand, the victim will consider the disguised LSA a duplicate of the fresh instance it just generated and will not activate the “fight-back” mechanism. On the other hand, other routers who have not yet received the new valid LSA will treat the disguised LSA as a new valid instance and install it in their databases. Once they re- ceive the true valid LSA they will reject it as a duplicate.
One implementation of this approach is for the attacker to wait for a new valid instance advertised by the victim router. Once the LSA is received the attacker will flood the disguised LSA to its neighbors (rather then the valid LSA). This implementation enables the attacker to poison routers, i.e. make them install the disguised LSA, on the part of the AS that is farther from the victim router.
