Subject: Re: [v6ops] [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-04.txt

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 20 Jun 2014 15:13:56 +0000

Fernando and Tim [Adding V6OPS in cc],

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)
- 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?
- 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)
- 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. My default Mac OS/X
configuration also prevents replying to any ICMP echo request...
- section 3.4 not sure whether an inventory of existing scanning tools is
valuable and this is an every changing world
- 3.5 about mitigations, IPFIX can also help a lot with regard to
detecting a scan
- 3.5 I do not like the idea that error messages should not be generated
when destination is a multicast... We need at least packet too big as well
as parameter problem if we still dream about mcasted IPv6 video streaming
- 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 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?
- section 8 (ND cache), it is not only by 'login' but also available
through SNMP (see also section 5 of draft-ietf-opsec-v6)
- 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)
- appendix A, not sure whether it brings value

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.

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.

You may also want to add simple traceroutes as they discover the IP
addresses of routers.

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)

-éric

On 15/06/14 01:54, "[email-masked]" <[email-masked]>
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Operational Security Capabilities for
>IP Network Infrastructure Working Group of the IETF.
>
>        Title           : Network Reconnaissance in IPv6 Networks
>        Authors         : Fernando Gont
>                          Tim Chown
>	Filename        : draft-ietf-opsec-ipv6-host-scanning-04.txt
>	Pages           : 31
>	Date            : 2014-06-14
>
>Abstract:
>   IPv6 offers a much larger address space than that of its IPv4
>   counterpart.  An IPv6 subnet of size /64 can (in theory) accommodate
>   approximately 1.844 * 10^19 hosts, thus resulting in a much lower
>   host density (#hosts/#addresses) than is typical in IPv4 networks,
>   where a site typically has 65,000 or less unique addresses.  As a
>   result, it is widely assumed that it would take a tremendous effort
>   to perform address scanning attacks against IPv6 networks, and
>   therefore brute-force IPv6 address scanning attacks have been
>   considered unfeasible.  This document updates RFC 5157, which first
>   discussed this assumption, by providing further analysis on how
>   traditional address scanning techniques apply to IPv6 networks, and
>   exploring some additional techniques that can be employed for IPv6
>   network reconnaissance.  In doing so, this document formally
>   obsoletes RFC 5157.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-04
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-host-scanning-04
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>OPSEC mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/opsec

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Jun 2014 16:08:40 -0300

Hi, Eric,

Thanks so much fr your feedback! Please find my responses in-line...

> IMHO (update also section 4.4)

Agreed. Will do.

> 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....

> same address(es) for years (even if the DHCP client went away for months)

Good point. Will do.

> 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).

> 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

Anything better than "IPFIX [RFC7011] could also be of help to detect
host scanning attacks"?

> 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

That would go against RFC4443.

> 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.

> reply code of reverse DNS servers? More work to be done in DNSEXT? Or

I had checked this before, and apparently "it was not possible". But
please let me re-check again.

> 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.

> 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).

> 2.5.1.2 of draft-ietf-opsec-v6.

Duble-checking: This would be for *legitimate* audits of *active* nodes,
right?

> without actively participating in the NDP exchange, so, it is also another

Will do.

> You may also want to add simple traceroutes as they discover the IP

Good pint.

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

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 23 Jun 2014 21:38:16 -0700 (PDT)

> That would go against RFC4443.

That's not what I read.  Section 2.4(e) says:

   (e) An ICMPv6 error message MUST NOT be originated as a result of
       receiving the following:

       (e.1) An ICMPv6 error message.

       (e.2) An ICMPv6 redirect message [IPv6-DISC].

       (e.3) A packet destined to an IPv6 multicast address.  (There are
             two exceptions to this rule: (1) the Packet Too Big Message
             (Section 3.2) to allow Path MTU discovery to work for IPv6
             multicast, and (2) the Parameter Problem Message, Code 2
             (Section 3.4) reporting an unrecognized IPv6 option (see
             Section 4.2 of [IPv6]) that has the Option Type highest-
             order two bits set to 10).

Seems like PTB is always allowed/required.

//cmh