The problem with promiscuous monitoring in a switched network is that, if is more than one switch you would need monitors on each switch, because traffic that is between two ports on the same switch does not get forwarded to the other switch. Another problem with promiscuous monitoring is the amount of "good" traffic that you must sift through to find the "bad" stuff. There is also may be a bandwidth issue going to the promiscuous monitor.
You are correct that in some cases a false positive might be detected, but this is always the case with security monitoring. The key is detecting the issue without too many false positives. -----Original Message----- From: Jari Arkko [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 21, 2005 13:02 To: Pashby, Ronald W CTR NSWCDD-B35 Cc: ipv6@ietf.org Subject: Re: Solicit comments on draft-pashby-ipv6-detecting-spoofing-00.txt Another set of quick comments: > There are two well documented vulnerabilities in the basic IPv6 > architecture: Neighbor Discover spoofing and Host Redirection. > There is the SeND RFC [send] that addresses authenticating these > interactions. Certain networks may choose not to uses (or cannot > use) SeND, for instance, networks that use DHCP or statically > assigned addresses. There's some work that attempts to extend SEND to cover more cases, e.g. proxy situations (see draft-kempf-mobopts-ringsig-02.txt). Support for DHCP would probably be possible too, if there was demand for this. Is there? > 3.3 Require Host Redirection messages to be sent to the destination > node's SNA. By the way, there's no technical reason why SEND router security (e.g. redirects) couldn't be applied even if the ND part would be currently inapplicable due to the use of DHCP. > 3.2 Require that a node shall silently discard Neighbor Advertisements > received that are not addressed to the node's SNA. This requirement > may administratively be disabled to allow for interoperability with > non-conforming node. The default configuration shall be to provide > this requirement. This is quite problematic, IMHO. Perhaps there'd be a way to provide interoperability and new functionality in some less drastic manner. Some protocols are capable of downgrading themselves to old behaviour in a graceful manner. In any case, I'm not convinced that the use of solicited node multicast addresses (or multicast to begin with) is the right solution to this particular problem. It would seem that, e.g., promiscuous reception mode and access to the network infrastructure (e.g. switches) would enable an intrusion detection system to operate without any IPv6 protocol changes. Also, the mere reception of multicast packets by a monitoring entity is by no means a guarantee that we'd be able to find the offending nodes. A node that switches interfaces but keeps the same IP address, node that is plugged to a new Ethernet slot etc would potentially show up as anomaly even if this behaviour is perfectly normal. More importantly, as nodes would typically be able to spoof L2 information, it would seem to be more important to track events directly at the switch ports rather than attempt to reconstruct what happened indirectly via multicast packets. One way to address these issues would be to re-issue the draft as a guideline on how network infrastructure can be used to detect such attacks (or alternatively as an explanation of why other methods do not work and why new work is needed). --Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
