Fernando and Tim [Adding V6OPS in cc], Just re-read your I-D, here are some comments: - in the intro, 'van dijk' scanning via reverse DNS is no more 'recent' IMHO (update also section 4.4) - section 3.1.1 is yet another explanation of SLAAC & Co, I usually prefer avoiding repetition because they may introduce discrepancy or incoherencies => remove those parts from the I-D? What about only talking about EUI-64 for example? - section 3.1.2 about DHCP, probably worth to say that some DHCP servers change the leased address(es) every few hours/days while others keep the same address(es) for years (even if the DHCP client went away for months) - section 3.3 about local mcast probe, a lot of networks (think large wifi) prevent direct WiFi client to WiFi client communication, or isolate hosts to communication to each others (hosting providers for example), so, this method of scanning is not always efficient. My default Mac OS/X configuration also prevents replying to any ICMP echo request... - section 3.4 not sure whether an inventory of existing scanning tools is valuable and this is an every changing world - 3.5 about mitigations, IPFIX can also help a lot with regard to detecting a scan - 3.5 I do not like the idea that error messages should not be generated when destination is a multicast... We need at least packet too big as well as parameter problem if we still dream about mcasted IPv6 video streaming - section 3.5 mitigations is in the middle of scanning techniques? Move it apart? Or build a mitigation section in all other scanning techniques? - section 4.4, should there be a recommendation to optionally change the reply code of reverse DNS servers? More work to be done in DNSEXT? Or DNSOP? - section 8 (ND cache), it is not only by 'login' but also available through SNMP (see also section 5 of draft-ietf-opsec-v6) - section 10 (routing protocols), not sure whether it can really help to scan except by providing the prefixes and in some case some router interface addresses (but trace route is there anyway) - appendix A, not sure whether it brings value
May I suggest to add also IPFIX as it can aggregate the flows by source addresses, hence, getting a list of all addresses. See also section 2.5.1.2 of draft-ietf-opsec-v6. While at the beginning the I-D rightfully discusses about the two purposes of scanning (bad guys and good guys doing inventory), the main focus of the document appears to be on mitigation techniques (i.e. Prevent scanning) while very few on helping the good guys to build an inventory. May I also suggest that SAVI RFC 6620 also builds a cache of MAC/IPv6 without actively participating in the NDP exchange, so, it is also another source of information. You may also want to add simple traceroutes as they discover the IP addresses of routers. Lastly, and not sure about that point, should we drop a can full of worms in the document? Telling readers that using ULA and NAT is perhaps worse than the benefit? ;-) (it is Friday after all) -éric On 15/06/14 01:54, "[email protected]" <[email protected]> wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Operational Security Capabilities for >IP Network Infrastructure Working Group of the IETF. > > Title : Network Reconnaissance in IPv6 Networks > Authors : Fernando Gont > Tim Chown > Filename : draft-ietf-opsec-ipv6-host-scanning-04.txt > Pages : 31 > Date : 2014-06-14 > >Abstract: > IPv6 offers a much larger address space than that of its IPv4 > counterpart. An IPv6 subnet of size /64 can (in theory) accommodate > approximately 1.844 * 10^19 hosts, thus resulting in a much lower > host density (#hosts/#addresses) than is typical in IPv4 networks, > where a site typically has 65,000 or less unique addresses. As a > result, it is widely assumed that it would take a tremendous effort > to perform address scanning attacks against IPv6 networks, and > therefore brute-force IPv6 address scanning attacks have been > considered unfeasible. This document updates RFC 5157, which first > discussed this assumption, by providing further analysis on how > traditional address scanning techniques apply to IPv6 networks, and > exploring some additional techniques that can be employed for IPv6 > network reconnaissance. In doing so, this document formally > obsoletes RFC 5157. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-host-scanning-04 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >OPSEC mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
