TL;DR: The mentioned attack only works against plaintext connections.
Alice and Bob share a key.
If this is the case, you shouldn't roll your own protocol. Just rely on the power of TLS and its PSK ciphersuites - preferably the ones which offer forward secrecy by also using an (EC)DHE exchange.
If and only if both parties share the same key, the TLS handshake will suceed and anything identified with either party has to be encrypted and authenticated with that party's session keys. So if Trudy sends some message using Alice's source address (but not with Alice's session keys) the MAC verification will fail and the connection will be aborted as an attack has been registered.
How are such problems dealt with?
If you really deploy a custom authentication protocol, you should always run them over TLS (either server-authenticated or opportunistic). This allows you to associate a given party (Alice) with a given other end of a specific TLS connection. If anything "from that party" comes in that doesn't use the right keys, the MAC verification will fail and the connection will be dropped.
I was curious about nature of the attack I described
The attack works by spoofing the source adress. If there are no counter measures in place and the attacker gets the source (IP) adress of Alice he can send arbitrary requests as Alice if Alice is only recognized by her source adress (and not ownage of keys or even cookies). However the answers to these requests will still be sent to the real Alice (unless tha attacker attacks the authentication protocol in a clever way by acting as a man-in-the-middle) but they can do harm nonetheless.