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
--------------------------------------------------------------------
