Hi, Alissa, Thanks so much fr your feedback! -- Please find my comments in-line....
On 08/19/2015 09:46 PM, Alissa Cooper wrote: > On the VMWare ESX example given in Sec. 3.1.1.1, the OUI given for > automatically-generated MAC addresses (00:05:59) does not seem correct. > In the linked documentation, it is listed as 00:0C:29. In the IEEE OUI > list, 00:0C:29 is registered to VMWare but 00:05:59 is registered to some > other company. You seem to be absolutely right :-?. I'll double-check and update as warranted. > In Sec. 3.1.1.3 and 3.1.1.4, I wonder if you might want to re-use the > terminology from draft-ietf-6man-ipv6-address-generation-privacy in the > section headings, in particular to differentiate "Constant" IIDs from > "Stable" IIDs. I think this would be better than using "Privacy-Enhanced" > as the term "privacy" is now overloaded when it comes to different types > of v6 addresses. Fully agree. Will update accordingly. > I think the tables in 3.1.5 would be a lot more useful if the table > captions noted the total number of addresses investigated (N). Not sure what you mean. Isn't it more meaningful to talk about percentages rather than number of addresses? > In Section 3.5, wouldn't using RFC 4941 addresses count as a mitigation > as well (first bullet)? Not really: The problem is that RFC4941 (temporary) addresses are configured *in addition* to the stable addresses. SO no matter how random the RFC4941 addresses are, they will not mitigate address scanning if your stable addresses are predictable. > Sections 5-13 seem like they belong as subsections of an overarching > section about "Other Network Reconnaissance Techniques" or some such. They are kind of "top level".... but since many of such sections are really short, I understand they could be thought of as "Other Network Reconnaissance Techniques" -- I will leave this one up to Tim (co-author). > It > might also help to provide some indication of how resource-intensive > these techniques might be relative to each other. These are hard to compare with each other. For instance, many of the "gleand information from the..." are not expensive at all: the information is just out there (as long as you have the necessary credentials). > There are other > application-specific ways of gathering information about active IP > addresses that aren't listed here (the example that comes to mind is an > attacker standing up a TURN server) but are probably also more trouble > than they're worth for most attackers, which is presumably why they are > not included in the list. Agreed. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
