[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Mon, Nov 27, 2006 Tim Chown wrote


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.
True, but as history has shown "inifinate" addresses of IPv4 were not as unlimited as had been hoped. I would not hold the draft for this, but I wonder what we will all be saying in another 10-15 years when we all need fixed addresses for 100 appliances and who knows what else for each of the 10+ billion people of the world. 



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.
"Cost should in principle not be high" is not the same as free, and some companies like to cut corners in development. Again, not a show stopper to me.
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.
True, this is how it will work in large companies where they track firewall traffic, but in homes or smaller networks frequently there is no one to do this monitoring or checking. This is why some small companies rely on NAT rather than firewalls for security. 



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.
Same problem as previous comment. Companies that are small tend to have some "super" user or vendor set things up. These people tend to go for the eacy to remember (i.e. maintain) configurations. And in the case of small networking vendors they may use the same pool and default numbers to make their lives easy when handeling service calls.