In a reply to the previous episode, Matthias pointed out that while the ramond is a useful tool, it is little if any use against a malicious attacker. Right, but if you let an attacker into a subnet with potential targets, you are in some very serious trouble anyway.
Table of Contents
00:00:44 Is a student dorm network really a worst case scenario?
00:02:30 Subnet security, or, dealing with the threat at its root
00:04:20 When subnet securiy is infeasible
00:05:30 The inherent limitations of SEND (Secure Neighbor Discovery)
00:07:03 Fixing Neighbor Discovery to be secure in hostile networks
00:10:30 Attacking below the network layer
00:13:50 Don’t forget to compare ND security issues with their IPv4 equivalents
Generally speaking, there are literally infinitely many ways to perform a DoS attack (bandwidth exhaustion is almost always possible). Cryptography can certainly be used to amplify a DoS attack, but cryptography is worth this risk in a lot of cases and there often more ways to perform a DoS attack even without cryptography. DoS defence company make a living out of developing mitigation techniques against particular DoS attacks while having low false positives. As a single person or small team you play in a different league. So I don’t worry so much about DoS attacks and prevent only the easily preventable attacks.
SEND seems interesting, but I think it would take years until every operating system vendor would offer it even if there would be demand for it.
You mentioned that you don’t recommend large networks. Perhaps you can say what you think about TRILL and 802.1aq in some of your next videos.
In the previous episode you said that one should separate network layers and that switches shouldn’t touch the Internet layer. However, higher priced switches support ICMP and MLD snooping in hardware to avoid flooding the network with multicast traffic. Perhaps you can address the following in some future video: What would you recommend if your network has significant multicast traffic (e.g. Windows Deployment Services, TV over IP etc.), you want to switch your multicast software to IPv6 and your switches don’t do MLD snooping? If I remember correctly, there is some standard for Ethernet (I think IEEE 802.1ak) to alter port attributes, among them the multicast MAC addresses you want to receive traffic from. Have you heard of this and if so, have seen this deployed or would you like to see this deployed (Linux didn’t support it last time I checked)?
Hi again,
well, there are ways to mitigate DoS attacks, but yes, that can be quite a can of worms as well as a significant expense. Looks like that’s worth another episode, but there’s some other interesting stuff in the queue, so it’ll take some time. Anyway, I’ve put it on the list, together with TRILL and 802.1aq (and actually, old-fashioned spanning tree protocol as well).
As far as IGMP and MLD snooping is concerned: That’s pretty much an issue around the historic evolution of the TCP/IP/Ethernet stack. Yes, it’s butt ugly, but it can’t really be helped at this point. 802.1ak might have been an option if it hadn’t been about 15 years too late. At this point I’d rather not touch it simply because it adds another constraint to the equipment alternatives available to you; I’m personally not much of a fan of climbing in a golden Cisco cage, locking myself in and throwing the key to the next Cisco sales representative…
BTW, next week there’s the Heise/DE-CIX IPv6-Kongress here in Frankfurt. I’ll do two talks, one on ICMPv6 packet filtering and another on multicast routing. These two are also in the queue for a re-run here on the blog.
Cheers,
Benedikt