Hi, Eric, Thanks so much fr your feedback! Please find my responses in-line...
On 06/20/2014 12:13 PM, Eric Vyncke (evyncke) wrote: > 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) Agreed. Will do. > - 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? FWIW, the reason for which this part is included is that they key to doing host scanning in IPv6 is reducing the search space. -- that's why we essentially describe each of the algorithms that are commonly employed to generate the addresses, and then compute the approximate search space.... > - 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) Good point. Will do. > - 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. Good point, will add. > My default Mac OS/X configuration also prevents replying to any ICMP echo > request... Wasn't aware about Mac OS... I expected them to follow FreeBSD in this respect. BTW, what version of Mac OS are you using? 8to check if this was changed for recent versions, or has been the case for a while now). > - section 3.4 not sure whether an inventory of existing scanning tools is > valuable and this is an every changing world IMHO, pointers to tools can be useful for folks willing to play/asses their networks -- particularly when many of the popular tools have little to no IPv6 support. > - 3.5 about mitigations, IPFIX can also help a lot with regard to > detecting a scan Anything better than "IPFIX [RFC7011] could also be of help to detect host scanning attacks"? > - 3.5 I do not like the idea that error messages should not be generated > when destination is a multicast... That's in the specs already (RFC4443) -- the only thing that I had proposed to change at the time was the response to unsupported options of type 10xxxxxx. > We need at least packet too big as well > as parameter problem if we still dream about mcasted IPv6 video streaming That would go against RFC4443. > - 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 3.5 is a subsection of the "address scanning" section (section 3). It's true that the other sections do not have a mitigations subsections -- mostly becaus they boils down to "'It's impossible' or 'stop using that application'". Three options: 1) Leave as is 2) Have a top-level Section called "Mitigations", which would include the contents of Section 3.5, and also note that for the other vectors there's not much that you can do other than "stop using the orresponing protocol" (which, of course, in virtually all cases is not applicable). 3) Add a "Mitigations" subsection to each of the top-level sections... However, this would mess a bit with the index.. and many of such sections would have not much text. Thoughts? Me, I'd opt for 1 or 3 above. > - 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? I had checked this before, and apparently "it was not possible". But please let me re-check again. > - section 8 (ND cache), it is not only by 'login' but also available > through SNMP (see also section 5 of draft-ietf-opsec-v6) Myabe we should ahve said "auth required" instead of "login"? -- The point was that if yu're an attacker, you might need credentials to access the aforementioned info. > - 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) We might tweak the text noting that it might be of help for learning subnets rather than IIDs... > - appendix A, not sure whether it brings value FWIW, goal here was to provide some guidance for folks working n e.g. en-testing frameworks. - Most of the popular famewroks are rather clueless regarding how to learn the v6 addresses of potential targets (of couse, for v4 they do brute-forcing). > 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. Duble-checking: This would be for *legitimate* audits of *active* nodes, right? > 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. Will do. > You may also want to add simple traceroutes as they discover the IP > addresses of routers. Good pint. > 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) Let's drop the can, but in a separate document. ;-)) (That aside, for scanning purposes, a diode-firewall would mostly do). Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
