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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
