Subject: Solicit comments on draft-pashby-ipv6-detecting-spoofing-00.txt

From: "Pashby, Ronald W CTR NSWCDD-B35" <[email-masked]>
Date: Wed, 21 Sep 2005 09:12:12 -0500

This draft was presented in Paris, but did not have time for discussion. We would appreciate any comments.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Sep 2005 20:01:32 +0300

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Sep 2005 10:49:03 +0200

In your previous mail you wrote:

   (about SEND support)
   
=> in fact there is no real reason for DHCP and static configuration
to be incompatible with SEND: the only constraint is to give a
not-random Interface ID, and this is only a matter of configuration
(BTW DHCPv6 is not dynamic :-).

My key term here is (still) "backward incompatible changes"...

Regards

[email-masked]

PS: if you believe it is stupid to give through DHCPv6 the same address
than the stateless autoconf would get:
 - many guys who use DHCPv4 to manage their networks want to keep the
   same tool (this is a not-technical issue then it is (too) hard to solve)
 - DHCPv6 itself can provide extra features like DNS registration