Subject: FW: Re: about draft-pashby-ipv6-network-discovery-00.txt

From: "Pashby, Ronald W CTR NSWCDD-B35" <[email-masked]>
Date: Tue, 2 Aug 2005 15:10:53 -0500

> Greg, et. al,
> 
> You stated:
> >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.
> 
> The mechanism already exists. It is ICMP Echo to an "all hosts multicast" address. My proposal 
> limits the effect by placing a hold-off timer to stop flooding of the network (and the quering device)
> 
> >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.
> 
> I agree that in some circumstances that would be ok. But in other cases, it is extremely important to 
> know what devices are connected to the network and what addresses those devices are using. I have 
> been around "well managed" networks as well as "secure" networks and in both environments this is 
> needed.
> 
> Passive listening to MLD does not yield enough infomation since the group you join is only the low 24 
> bits of the address and you have no idea of the high 108 bits. And depending on your layer 2 technology 
> you might not see the join if the monitor was not turned on when the device is booted. This would require 
> that you reboot all devices (including all the network gear, and the order would be important) after you 
> start you monitoring device. 
> 
> >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.
> 
> I would be in favor of limiting the responses for Inverse Neighbor Discovery and Node Information Queries to onlink requests (i.e. Hop count must = 255).
> 
> Ron
> 
--------------------------------------------------------------------
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 17:02:34 +0930

Hi Ron,

On Tue, 2 Aug 2005 15:10:53 -0500

> > >They are not required to expose global addresses.

Only if they respond to the multicast echo request.

> > been around "well managed" networks as well as "secure" networks and in both environments this is 

Looking at your .mil email address, am I right in assuming that you're
after this capability to be able to attempt to find unauthorised hosts,
rather than using it to get an indication of the number of hosts
attached to the network ?

If you're interested in this for security purposes, I'd think it
wouldn't be all that effective. A knowledgable adversary will just
configure their host not to respond to multicast echo requests.

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

(Just for completeness, I've mentioned this in another, related thread)
They can be vulnerable, if one of the locally attached nodes has running malware
that will act as a relay / proxy for an offlink attacker. This malware
could be delivered via a email payload for example, and then establish
an outgoing connection to the offlink attacker.

Regards,
Mark.