JINMEI Tatuya / 神明達哉 writes: > (Intentionally separating the thread since this is irrelevant to the > main focus of completing 2462bis)
Agreed; and changed the subject line as well. > At Tue, 10 Jul 2007 07:43:34 -0400, > James Carlson <[EMAIL PROTECTED]> wrote: > > > > On the other hand, I'd point out the same argument could apply to the > > > "two-hour" rule adopted in RFC2462 and kept in 2462bis. The consensus > > > at that time (IIRC) was that even though we knew it's an on-link only > > > attack the forced shut-down of an available global addresses was > > > serious enough to mitigate within the protocol specification. And > > > since an unsolicited NA is a very rare event, I'd suspect it's more > > > likely an attack than an actual duplicate that happens to have been > > > undetected. > > > > The two-hour rule has always struck me as more of a robustness issue > > than anything else. > > I'm not sure if you are indicating by "robustness" that it's not an > issue of DoS, but the fact is that the two-hour rule was indeed > introduced as a counter-measure of a DoS attack (I guess you knew > that, but just in case...). Understood; I just don't agree that effective DoS protection against even a modestly determined attacker is possible, hence my reference to "robustness" (being able to withstand transient and unintentional errors) rather than "security" (defending against intentional interference, such as denial of service). > > The point I was making was that a denial of service attack against NDP > > is not just feasible, but trivial, and that bringing up DoS as a > > reason to ignore assumed-incorrect advertisements doesn't seem like a > > productive way to frame the argument. > > I admit whether discarding the NA may be a debatable behavior (with or > without logging the event), but I don't think discussing this in the > context of DoS, referring to the two-hour rule, is unproductive. An > attacker can easily make the Solaris node shut down an address by > sending two attacking NAs. Absolutely true, but I believe the claim to be irrelevant. It's irrelevant because no matter *what* Solaris does it cannot stop other nodes on the network from receiving and processing the incorrect information offered by the attacker, and cannot prevent the attacker from sending well-formed but incorrect messages in the first place. Each time there's a solicitation, the attacker can generate an incorrect advertisement. If someone wants to attack NDP -- again, regardless of what Solaris or any implementation chooses to do -- then he can in fact do so. Such an attack can and will cause disruption by poisoning neighbor cache entries of peer systems. Keeping the local address "up" even though all of the neighbors are confused about the L2-to-L3 mapping does not thwart the attack or help recover from it. It just leaves the network in an inconsistent (and potentially unusuable) state. Thus, I claim that it's not productive to talk about the problem as an issue of DoS, because DoS is just inherent in the protocol, so long as there's no message authentication. That leaves the issue of network stability. For network stability, it's best if there is _at most_ just one node that responds to solicitations for any given IPv6 address. If there's more than one, then peers will inevitably end up with inconsistent entries, leading to erratic and unpredictable behavior. This is the reason that Solaris tears down interfaces that have persistent conflicts. There's nothing else useful, as best I can see, that can be done. > The attacker can also mount the same > attack on any other nodes in the link by first pinging them to collect > the addresses and then performing the attack with the forged NAs. Sure. > We could still argue that such an attack is "trivial" and discussion > based on the "trivial" attack is not productive. But if so, we should > also revisit the two hour rule, too. As long as we keep that rule, it > makes more sense to me to consider a counter measure for the same > level of security threats. As long as it leaves peer cache entries unaddressed, I don't think the counter measure proposed here (simply ignoring the messages and leaving the local IPv6 address "active") solves any problem related to denial of service. If anything, it actually makes the problem worse when there are persistent conflicts, because instead of one node making progress (and the others backing off and sulking), you end up with nobody being able to use the address in any reliable way at all. > To avoid wasting our time further, however..., I personally think this > particular case isn't worth further debates. As I repeatedly noted, > we don't see unsolicited NAs very often in the first place, whether it > would indicate a duplicate address or an attack. We can safely leave > it to implementations without a fear of disruption in practice. So, > I'll stop here on this matter until, someday, we need to discuss how > to address undetected duplicates in general. OK. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
