Subject: [OPSEC] Stephen Farrell's Yes on draft-ietf-opsec-ipv6-host-scanning-07: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 19 Aug 2015 15:57:43 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-opsec-ipv6-host-scanning-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- general: @Fernando: thank you for writing a document that does
not recommend turning off IPv6:-)

- general: shouldn't you recommend a honeynet approach as another
way of spotting scans when there ought be none? That might fit in
3.5 I guess.

- intro: what evidence is there that the number of hosts per
subnet is likely to stay the same? (And what do you consider an
IPv4 subnet here? a /16 is it? Maybe worth saying.) The density
point still applies though, but good to not assume things that
aren't needed.

- 3.1.1 - I would recommend you check with Christian Huitema
about Windows10 which has some new features related to MAC
addresses. I don't know if there is new IPv6 handling associated
with those changes.

- 3.4.1 s/patters/patterns/

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Aug 2015 01:18:04 +0200

Hi, Stephen,

Thanks so much for your feedback! Please find my comments in-line....

> not recommend turning off IPv6:-)

(a comment on this one at the end of this emai :-) )  (*)

> way of spotting scans when there ought be none? That might fit in

The goal here is not to detect host scanning, but to perform it or
mitigate them -- rather than detecting the host scanning attacks.

> point still applies though, but good to not assume things that

What evidence there is that this is going to change?

> addresses. I don't know if there is new IPv6 handling associated

I will.

> - 3.4.1 s/patters/patterns/

Will fix.

<off-topic>
(*)

P.S.: You keep repeating this one :-), but the only document in which I
noted that the unfortunate only possible approach might be to disable v6
at the time was RFC7359 (and in RFC7123, as one possible approach).

As unfortunate as it was, it was correct. And there was a recent wave of
press on this topic:
<http://docs.media.bitpipe.com/io_10x/io_102267/item_465972/VPN%20Looking%20Glass.pdf>
with kind of sad comments about IPv6.

I think our advice was timely, and in line with a quote from Bertrand
Russell I like:

"The intellectual thing I should want to say is this: When you are
studying any matter, or considering any philosophy, ask yourself only
what are the facts and what is the truth that the facts bear out. Never
let yourself be diverted either by what you wish to believe, or by what
you think would have beneficent social effects if it were believed. But
look only, and solely, at what are the facts."

Everything else I've authored has been about improvements, not "turning
it off"... and for instance, I've been IPv6 enabled for years... ;-)
</off-topic>

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Aug 2015 00:28:12 +0100

> (a comment on this one at the end of this emai :-) )  (*)

Fair enough. We can delve into that one over a beer sometime:-)

> mitigate them -- rather than detecting the host scanning attacks.

I'd argue that detecting scanning is an entirely relevant
mitigation.

> What evidence there is that this is going to change?

That's backwards. The draft makes a positive claim that the
number of hosts per subnet won't change but that's not
currently well-founded. I'd say just removing the unfounded
claim would be easiest.

Cheers,
S.