Adding authentication needs to break compatibility with older versions to be safe, or else an attacker could simply masquerade as an older client and perform an effective downgrade attack. As in what's happening with DNSSEC implementations.
When talking about breaking compatibility in Bitcoin you should recognize two district classes of compatibility.
1. Consensus compatibility i.e. that a node running the new software and a node running the old software will, when given the same blockchain, will always agree on which blocks are valid and which blocks are invalid.
2. Everything else.
Breaking consensus compatibility is viewed as very risky and should only happen under extreme circumstances or under extreme agreement. Breaking backwards compatibility at the network level should be carefully thought through but it is much more likely to happen.
>an attacker could simply masquerade as an older client and perform an effective downgrade attack
BIP-151 is only designed to defeat a passive attacker since it does not include a way of attaching a long term identity to a node. Thus, even without a downgrade attack you can just MITM a connection and substitute your own keys. As BIP-151 says:
"The encryption does not include an identity authentication scheme. This BIP does not cover a proposal to avoid MITM attacks during the encryption initialization."
BIP-150 is the identity mechanism for BIP-151 however establishing the pubkey to node mapping requires out of band communication.
"The identity-public-key(s) can be shared over a different channel with other node-operators (or non-validating clients) to grant authorized access."
