Hi, Eric, [Looks like this was in my "Drafts" folder and never got sent. - shame on me]
Some additional notes... On 06/20/2014 12:13 PM, Eric Vyncke (evyncke) wrote: > - 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) So even when the client suggests an address, the server(s) force some other address t be configured? Do you have any references for this behavior? > - section 3.3 about local mcast probe, a lot of networks (think large > wifi) prevent direct WiFi client to WiFi client communication, So there's no way to do e.g. P2P among them?? Is there anything we could reference here? > or isolate > hosts to communication to each others (hosting providers for example), so, Not sure what you mean... > - 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? Last time I checked with DNS folks, I seem to recall them saying that this wasn't possible -- although I wasn't convinced about it. Will poll other folks and re-check mysef (this one left in the TODO queue). > - section 8 (ND cache), it is not only by 'login' but also available > through SNMP (see also section 5 of draft-ietf-opsec-v6) I've tweaked the text and also added a reference to draft-ietf-opsec-v6. However, the relevant section seems to be Section 2.5.1.4 rather than Section 5, right? > - 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) Agreed. Although with traceroute you need a destination address in the first place (to traceroute to). > 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. Yep, added. Thanks! > 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. I'd say that most of the techniques that require some sort of credentials are only of use to the good guys... > 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. Yep. Added to the same section discussing "ND Cache inspecion". Thanks! > You may also want to add simple traceroutes as they discover the IP > addresses of routers. Added. Thanks so much! > 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) My experience seems to indicate that adding "NAT" to any document (particularly if IPv6-related) is asking for trouble. :-)) -- So I'd personally leave that out. :-) Thanks so much! Best regards, -- 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
