Skip to main content

Network Reconnaissance in IPv6 Networks
RFC 7707

Yes

(Joel Jaeggli)

No Objection

(Alia Atlas)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)
(Terry Manderson)

Note: This ballot was opened for revision 07 and is now closed.

Alvaro Retana No Objection

Comment (2015-08-19 for -07)
Just a couple of nits:  

1. If this document obsoletes rfc5157, then it can’t really update it, can it?   You mention it updates and obsoletes 5157 in the Abstract and Introduction.

2. Introduction.  I think you meant:  s/[van-Dijk] describes a technique for leveraging DNS reverse mappings for discovering IPv6 nodes./Section 4 describes a technique for leveraging DNS reverse mappings for discovering IPv6 nodes [van-Dijk]

(Joel Jaeggli; former steering group member) Yes

Yes (for -07)

                            

(Stephen Farrell; former steering group member) Yes

Yes (2015-08-19 for -07)
- 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/

(Alia Atlas; former steering group member) No Objection

No Objection (for -07)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (2015-08-19 for -07)
Interesting work, thanks.

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.

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.

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

In Section 3.5, wouldn't using RFC 4941 addresses count as a mitigation as well (first bullet)?

Sections 5-13 seem like they belong as subsections of an overarching section about "Other Network Reconnaissance Techniques" or some such. It might also help to provide some indication of how resource-intensive these techniques might be relative to each other. 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.

(Barry Leiba; former steering group member) No Objection

No Objection (2015-08-14 for -07)
Nice document you have here.  Just two really small comments, neither of which needs any response, and both of which you can ignore if you prefer.

An observation: Three times, you say that something is "obvious", and this can come across as condescending -- and can be frustrating to a reader for whom it isn't obvious.  I suggest omitting that, so 

- In Section 3.1.1.1, change "Firstly, as it should be obvious from the algorithm described above" to "Firstly, as shown by the algorithm described above".

- In Section 3.1.3.2, change "For obvious reasons, the search space for addresses following" to "The search space for addresses following".

- In Section 3.3, change "Obviously, a number of other network reconnaissance vectors" to "A number of other network reconnaissance vectors".

-- Section 3.1.1.1 --

An observation, for which the response is probably "everyone knows this, so no change is needed," but please think about it for a fleeting moment:

   1.  The "Universal" bit (bit 6, from left to right) of the address is
       set to 1

Bit 6, starting from 0, or from 1?  The answer (which I can see from the example) is "starting from 0."

   Firstly, as it should be obvious from the algorithm described above,
   two bytes (bytes 4-5) of the resulting address always have a fixed
   value (0xff, 0xfe)

Bytes 4-5, starting from 0 or from 1?  The answer (which I can see from the example) is "starting from 1."

The fact that the origins differ makes me think that it'd be nice if that were made clear.  Please give it a thought, to say that bits are numbered from left to right starting at 0, and bytes are numbered from left to right starting at 1.

(Ben Campbell; former steering group member) No Objection

No Objection (for -07)

                            

(Deborah Brungard; former steering group member) No Objection

No Objection (for -07)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -07)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2015-08-20 for -07)
Thanks for your work pulling together a summary of reconnaissance techniques for IPv6.  I think this is a useful document, that will be helpful to operators and security professionals.  I don't have any comments to add that have not already been mentioned.

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -07)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (2015-08-16 for -07)
I echo Barry's "nice document", and would support the changes he suggested.

I did notice what I believe is a repeated "not" in "it is not not only the lowest-order byte".

In this text:

3.4.1.  Remote IPv6 Network Scanners

   Many address scanning tools such as nmap [nmap2012] do not even
   support sweeping an IPv6 address range.
                           ^ 
does this mean "sweeping an IPv6 address range in a remote IPv6 network"? I think that's implicit from the section title, but what nmap supports is clearer in the corresponding text in the next section:

3.4.2.  Local IPv6 Network Scanners

   There are a variety of publicly-available local IPv6 network
   scanners:

   o  Current versions of nmap [nmap2012] implement this functionality.

(Terry Manderson; former steering group member) No Objection

No Objection (for -07)