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 IESG member
Yes
Yes (for -07)

                            
Stephen Farrell Former IESG 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 IESG member
No Objection
No Objection (for -07)

                            
Alissa Cooper Former IESG 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 IESG 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 IESG member
No Objection
No Objection (for -07)

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -07)

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -07)

                            
Kathleen Moriarty Former IESG 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 IESG member
No Objection
No Objection (for -07)

                            
Spencer Dawkins Former IESG 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 IESG member
No Objection
No Objection (for -07)