> o Spoof DNS and make you connect to the wrong site > (DNS is not secure)
Hard to do w/o penetrating one of the endpoint hosts or inserting another host into the emulated lan (difficult to do in LPAR mode w/hipersockects where that takes a IO gen change, or at least a lpar config change). Under VM, you'd have to circumvent a closed gLAN definition (unless you're a compleat moron and do this over a public GLAN) or connect to a real hipersocket, which implies access to real storage or to highly privileged VM commands. Not easy to do. If you've poisoned the DNS from the outside (ie, both hosts consult an corrupted outside DNS), then encrypting the data isn't any real defense either -- you need connection authentication; whether the data is encrypted or not isn't the issue, it's whether you recognize your peer that counts. Not really the same problem, although linked. If you have a OSA acting as a router between two guests or LPARs, you'd have to change the config there -- also not easy to do or hide. You'd also have to have the necessary privileges to attach a spare set of OSA devices, which is again a privileged command (it's certainly not class G, and if you're running your Linuxen with more than class G, you already know the consequences of your actions, I would hope). > o USe ARP faking or ICMP to redirect traffic See above. You'd need to be on the segment first. > o Join in OSPF/RIP/etc routing protocols to > nominate myself as the router you want. Since the original question was passing data on a internal LAN segment, there probably isn't a router present, and the hosts certainly don't need a routing daemon listening on that interface to communicate between two hosts on the same LAN segment. I'd venture to say that hosts in this scenario are unlikely to be the ones running routing daemons. > Your bigger risk is not people tapping the data (I'd hope!) but people > persuading your data to go elsewhere, or even misrouting it > by accident. > Encryption is good - there are cases where the CPU cycles matter or > where the crypto is expensive for some boxes and you have to make hard > choices sure.. Ordinarily, I'd agree that misdirection is more likely, but here it's so difficult or so obvious to get access to perform most of the attacks you're mentioning that I made the comment that you can build a case to omit encryption in this environment. I don't deny that encryption is *good*. The question was whether it is *necessary* in an environment where most of the common attacks you mention are difficult or impossible to perform if the administrator is even moderately alert. >
