the issue is originated by the fact that in iBGP sessions the AS path attribute is not modified when propagating an advertisement to another iBGP peer. Actually when sending the advertisement to an eBGP peer the AS number of the BGP speaker is added to the AS path attribute.
This behavior has the potential for loops in the propagation of the advertisement that can travel among several iBGP peers and could be sent back to the original node that injected the route in the AS.
The real problem arises if the originator node withdraws the BGP advertisement, in absence of control mechanisms the node could be fooled by a copy of the advertisement received by another node and re-advertise the just withdrawn IP prefix.
As a result in the AS, there would still be present an advertisement for a prefix that is not existing anymore.
For this reason, an iBGP speaker cannot propagate advertisements received by an iBGP peer RX to any other iBGP peer.
This mechanism is built-in BGP and cannot be disabled for the reasons explained above.
The most important consequence is the requirement for a full mesh of iBGP sessions that leads to scalability problems, because given N iBGP nodes
N*(N-1)/2
When a BGP speaker receives an UPDATE message from an internal peer, the receiving BGP speaker shall not re-distribute the routing information contained in that UPDATE message to other internal peers. This is split horizon rule use within AS to prevent loops