Subject: Re: [OPSEC] Alissa Cooper's No Objection on draft-ietf-opsec-ipv6-host-scanning-07: (with COMMENT)

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Aug 2015 22:56:05 +0200

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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Aug 2015 00:41:27 +0200

Hi, Alissa,

On 08/20/2015 12:21 AM, Alissa Cooper wrote:
>>> 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).
>> 
> I meant the total number of addresses. Like, 6% of 100 hosts
> investigated doesn’t mean much but 6% of a million hosts might. I
> assume these totals are in the papers but it would be easier to
> include them directly in the document. Or maybe I misunderstood what
> the table data represents?

All percentages are statistically significative... the measurements were
performed based on ALexa's top 1M sites....

Thanks!

Best regards,