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

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

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-masked]]
Sent: Wednesday, September 21, 2005 13:02
To: Pashby, Ronald W CTR NSWCDD-B35
Cc: [email-masked]
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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

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

>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…
Presumably all you'd need to do is to look at all packets that have
protocol = icmpv6 (despite whether they are addressed to you or not).
You might filter further based on the type of message, but I think
we'd already be in the neighborhood of feasible implementation.
And the actual intelligence might be either in a central node or
in the switches themselves.

In fact, a quick search reveals that e.g. that Cisco supports
a switch feature called Dynamic ARP Inspection (DAI), which
does this for IPv4 ARP. I'm not sure I see a reason to develop
backwards incompatible changes to IPv6 if vendors have
already shown that they can solve the issue in other ways.

--Jari

---

From: Pekka Savola <[email-masked]>
Date: Fri, 23 Sep 2005 11:43:53 +0300 (EEST)

> in the switches themselves.

Uhh, on a switch which is supposed to be forward, line-rate, dozens of 
gigabytes of traffic per second this is really NOT all that simple. 
But the problem already exists to some degree..

But nonetheless, the draft is not sufficiently convincing on why 
exactly we should bother with non-backwards-compatible changes.  Such 
changes are really major, and would give a strong indication that the 
problem should be changed in some other way.  If you intend to 
continue seeking a solution to this problem, I'd put a lot more 
emphasis on the definition of the problem and evaluation of the 
current tools (and why those are not sufficient).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings