comments on draft-chown-v6ops-port-scanning-implications-01

[Pekka Savola <pekkas@netcore.fi>]

Hi,

Generic comment:  this document already discusses a lot a slightly more
generic subject, "host scanning" or scanning for hosts.  Maybe this should
be reflected in the title etc. and the rest of the doc?  FWIW,
draft-savola-v6ops-security-overview-02 appendix contains some analysis of
host probing as well, which could maybe be adopted here.

semi-editorial
--------------

  Further reductions may be possible if the attacker knows the target
   is using 6over4, ISATAP, or other techniques that derive low-order
   bits from IPv4 addresses (though in this case, unless they are using
   IPv4 NAT, the IPv4 addresses may be probed anyway).

==> know whether the site or whether the particular host is using such
mechanisms?

Note that if ISATAP or such addresses are recognizable, just guessing or
seeing one will simplify the scanning for that site a bit, as one could
assume there will be more hosts using the same mechanism and format..


editorial
---------

 However, with a growing usage of IPv6 devices in open
   networks likely,

==> sounds weird.. "in open networks likely"

   Port scanning is quite a prevalent tactic from would-be attackers.
   The author observes that a typical university firewall will generate
   many Megabytes of log files on a daily basis purely from port
   scanning activity.

==> s/Mega/mega/
==> is it really megabytes?  or is it after filtering/not logging
everything.  I'd imagine it would be dozens or hundreds of megabytes..

  The IPv6 host address space through which an attacker may search can
   be reduced in at least two ways.  First, the attacker may rely on the
   administrator conveniently numbering their hosts [prefix]::1 upwards.

==> s/hosts/hosts from/ ?

For such hosts, if
   the Ethernet vendor is known, the search space may be reduced to 24
   bits (with a one probe per second scan then taking 194 days).  Even 
   where the exact vendor is not known, using a set of common vendor
   prefixes can reduce the search space.


   Even if the vendor code is not known, the search space can be reduced
   by using well-known, common vendor codes.


==> some repetition here at the last section of 1st para and 2nd para?


 This implies restricting zone transfers is (more) important
   for IPv6.

==> luckily enough, I think they're alreayd forbidden pretty much
everywhere..

  and devices become more commonplace, given that most IPv6 hosts are
   currently dual stack, with (more readily scannable) IPv4 connectivity
   also.  However, many applications or services (e.g.  new peer-to-peer

==> move "also" before "with" ?

  By using the IPv6 Privacy Extensions [3] the hosts in the network
   would only ever connect to external sites using their (temporary)
   privacy address.

==> not quite "only ever" -- it shouldn't be an on/off toggle (though it
probably currently is) -- applications MUST have an API to influence that
decision.. 

4.3  Defensive Scanning

==> should this belong in section 2 or somewhere else?

7  Informative References

==> I guess these could all be normative as well.. well, maybe [4] is not
quite as widely referenced here that it should be..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings