Re: [dhcwg] Review of draft-ietf-v6ops-scanning-implications

[Tim Chown <tjc@ecs.soton.ac.uk>]

On Mon, Nov 27, 2006 at 06:35:56PM +0200, Eric Klein wrote:
> On Thursday, November 23, 2006 Stig Venaas  wrote:
> >
> >Per Fred's request, please let v6ops and/or authors know if you have
> >any thoughts regarding this draft. In particular there is the following
> >section:
> >
> >4.2.  DHCP Service Configuration Options
> >
> >    The administrator should configure DHCPv6 so that the first
> >addresses
> >    allocated from the pool begins much higher in the address space than
> >    at [prefix]::1.  DHCPv6 also includes an option to use Privacy
> >    Extension [2] addresses, i.e. temporary addresses, as described in
> >    Section 12 of the DHCPv6 [5] specification.  It is desirable that
> >    allocated addresses are not sequential, nor have any predictable
> >    pattern to them.
> 
> I am not sure that I like the idea that we are suggesting that the DCHPv6 
> start higher than 1 for 2 reasons:
> 1. It reduces the number of addresses available, by 1 less than the 
> starting number chosen by the administrator. Yes I know that there are many 
> more numbers available, but I am hesitant to start recommending that they 
> be arbitrarily reduced for a dubious security consideration (see reason #2).

A nice property of IPv6 is that you have effectively infinite addresses on
a link.   You don't have to resize links like you do in IPv4 today.  You
don't need to worry about 'lost' space.

The aim of the text is to encourage DHCPv6 server implementors to support
an option to configure an address pool that can in effect serve addresses
randomly from that pool.   This implies some overhead in checking whether
such an address is already used, but that cost should in principle not be 
that high.

> 2. By stating that it is desirable, but not mandatory that the numbers from 
> the address pool of numbers are not allocated sequentially, you leave the 
> possibility that people choosing the easy coding methodology will still 
> allow it to be sequential. So, by choosing a number higher than 1 you have 
> only reduced the security implications by a few seconds as the scan will 
> eventually reach the first entry and then be able to scan the network. 

It would be likely to take more than a few seconds, and would probably
generate traffic that would alert an IDS to the scan.

Our evidence here is that we see scans run on specific ports of addresses
that we publish (DNS, MX, etc) and also on low addresses, <prefix>::1
being the primary example.   

Emphasis here is on the option to support this.   If you chose to number
sequentially from <prefix>::1 you choose to have easier-to-remember
addresses at the cost of a ignoring an opportunity for a little port 
scanning obfuscation.   It's a trade-off but it would be nice to have
the choice.

-- 
Tim