Subject: network/all-host discovery and flooding attacks.

From: Greg Daley <[email-masked]>
Date: Wed, 03 Aug 2005 01:48:42 +1000

Hi,

I think there are some interesting discussions going on
in a different thread, but I thought I'd start a new thread
in order to talk about a contentious issue without polluting
the other.

Regarding draft-pashby-ipv6-network-discovery-00.txt,
this provides a mechanism for devices to be made respond
to queries from another device on the IPv6 network.
This is not an existing capability.

I'm concerned that if there is a way to find out all the
nodes on a link, that this information may be used
(by the querier, or another device) to cause remote flooding
attacks onto a network, or to particular otherwise unmodified
hosts.

In IPv4 it is feasible/trivial to try all addresses in a subnet
in order to find targets for attack, but in IPv6 >2^60
combinations may need to be tried.

The anonymity of the present (but quiet) IPv6 node is
probably useful in this case.

There is no system, except MLD which can force response from
unknown nodes in IPv6. With MLD, the reporters can be made to
expose only one of their link-local source addresses.
They are not required to expose global addresses.

At the moment there's no security for MLD, but the risk is
limited to link-local addresses which are not vulnerable to
off-link attacks.

I'm loath to introduce a more generic function like
this which exposes global IPv6 addresses, unless there is
verifiable trust available to the nodes, before they are
forced to respond.

Greg.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Wed, 3 Aug 2005 01:44:25 +0930

Hi Greg,

On Wed, 03 Aug 2005 01:48:42 +1000

> Hi,

<snip>
 
> limited to link-local addresses which are not vulnerable to

Until malware, delivered as an email payload or via a socially
engineered HTTP download, or some other "higher-than-layer-3/4" method
takes advantage of that capability to discover nodes, and then do what
ever it wants to them e.g. DoS them, or "call home" and then act as a
relay betweem the offsite node and these link-local devices etc.

I don't think the "on-link" limitation is all that much of one
unfortunately.

> verifiable trust available to the nodes, before they are

I agree. It does unfortunately rely on only trusted programs using this
trusted request feature - see above (sadly).

Regards,
Mark.

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 2 Aug 2005 18:48:11 +0200 (CEST)

> I don't think the "on-link" limitation is all that much of one

Agree, but we should not destroy this "on-link" limitation...

>> verifiable trust available to the nodes, before they are

Agree.

Regards,
 	Janos Mohacsi

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 02 Aug 2005 09:49:17 -0700

> attacks onto a network, or to particular otherwise unmodified

That is the case if a remote node can do the discovery operation. But if 
the discovery operation is limited to nodes on the link, then we don't 
have the "remote" concern.

I think that might be a reasonable middle ground. It would still make it 
harder than in IPv4 to explore all hosts, yet one can have e.g. SNMP 
access to a local agent on the link that provide this (with appropriate 
SNMP security) to allow remote management.

Elsewhere I've run into the management need to find a particular host 
from knowing only its MAC address. The suggestion to have INVARP would 
help with that subproblem.

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Tue, 02 Aug 2005 18:56:34 +0200

I don't like multicast-based random discovery but about the security
it is why we have scoped multicast...

Regards

[email-masked]

PS: I am in favor of as possible passive mechanisms, and in my IMHO
too active mechanisms won't get better result just because too many
devices will be configured to not answer. Here examples are ND table
dumps via SNMP and multicated echo requests.

---

From: Tim Chown <[email-masked]>
Date: Tue, 2 Aug 2005 18:13:49 +0100

> SNMP security) to allow remote management.

It's important that the solution allows the tool to discover multiple
addresses used by a single node, i.e. the management view should show
a multiaddressed node (e.g. two globals and seven RFC3041 addresses on
one node) and not believe it's viewing multiple separate nodes (which is
a fault that a number of existing tools have, as we witnessed when running
some renumbering scenario tests).   

It's important that multiaddressing is considered normal behaviour for
management of IPv6 nodes.

-- 
Tim/::1

---

From: Mark Smith <[email-masked]>
Date: Wed, 3 Aug 2005 12:11:04 +0930

Hi Mohacsi, Greg,

On Tue, 2 Aug 2005 18:48:11 +0200 (CEST)

> Agree, but we should not destroy this "on-link" limitation...

I also agree with that.

One thing I've realised overnight is that most "entities" (animals,
miltary, etc.) that use hiding as a security method don't have it as
their only security method. They usually use it as a first line of
defence, albeit not a very strong one. It might work, and if it does,
that's all well and good. If it doesn't, they have at least one or more
much more secondary security methods e.g. being able to run away
very quickly.

Learning from that example, it probably means that while the hiding
property of IPv6 addressing is useful, it isn't all that strong a
security mechanism, and in particular, shouldn't be the only one relied
on. Therefore, while I certainly think we should try to preserve it in Ipv6, we
shouldn't necessarily blindly think that if it is somewhat easily
overcome (e.g., my example from above), we have a serious problem. Other
techniques, such as host based firewalling for example, need to be in
place if the hiding measures are overcome.

Regards,
Mark.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 03 Aug 2005 09:21:42 +0200

In your previous mail you wrote:

=> my default passive tool (ND table dump on routers via MIB/SNMP) gives
all in use addresses of hosts and all addresses of routers. Explicit
queries of hosts by SNMP or ICMP name lookups should give more (even
too much :-).

=> I fully agree.

PS: for hosts the question is about direct or indirect management: direct
gives more but needs tools (agents) on each host and raises security/privacy
issues. Indirect is more standard but works only for "active" hosts, usually
it is enough because "inactive"/invisible nodes are less sources of troubles.

---

From: "Eric Klein" <[email-masked]>
Date: Wed, 3 Aug 2005 10:36:21 +0300

> help with that subproblem.

I agree that the security issues here are great, and that there is a need in
the Management world for this feature. If you could limit this to an SNMP v3
secure function and not a IPv6 function then maybe we could work this out
within the security concerns of all involved. But that is a different WG (I
think that the SNMP v3 WG was closed down last year) so I would be real
careful in how we proceed.

Eric

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 3 Aug 2005 11:05:16 +0200

<below>
Tom Petch
----- Original Message -----
From: "Eric Klein" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 03, 2005 9:36 AM
Subject: Re: network/all-host discovery and flooding attacks.

> careful in how we proceed.

SNMPv3 WG did indeed shut down, work accomplished.  MIBs continue to appear, of
course, and there is an isms WG which seeks to integrate the security of SNMPv3
with the security systems already in place in organisations.  The current
security model does include an element of discovery, it won't work without it,
but by itself it is insecure.  It is unclear what a future security model would
have but currently discovery does not look possible with it.

My personal experience is of seeing very little IPv6 SNMP.  Yes there are
address families to allow for the different formats but outside that, SNMP seems
a very IPv4 world.

Tom Petch

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 03 Aug 2005 03:22:40 -0700

> careful in how we proceed.

Even with a SNMP approach for *remote* access, one would need to define 
how the local SNMP agent would discover the nodes attached to the 
*local* link.

    Erik

---

From: "Eric Klein" <[email-masked]>
Date: Wed, 3 Aug 2005 13:32:43 +0300

> have but currently discovery does not look possible with it.

Maybe we should bring in the security people to this issue.

> address families to allow for the different formats but outside that, SNMP
seems

As we move into an IPv4/v6 or all IPv6 world these will become more of an
issue, as element managers and OSS/BSS systems will need this functionality.
Eric

---

From: "Eric Klein" <[email-masked]>
Date: Wed, 3 Aug 2005 13:34:28 +0300

> how the local SNMP agent would discover the nodes attached to the

Agreed. In the local network this will be a crucial requirement for network
management, in the external one it would be dangerous as it could be used to
map a network or for DOS attacks.

Eric