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

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

On Mon, Nov 27, 2006 at 07:21:02PM +0200, Eric Klein wrote:
> On Mon, Nov 27, 2006 Tim Chown wrote
> 
> >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.

I don't think this concern is valid.  The draft talks about the current
defacto subnet size of /64, in which the host address space is in effect
infinite.   Maybe one day another /8 of unicast space will be deployed
with 96 bit network prefixes, but that's not the case today.

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

But whether you allocate sequentially or randomly you have to check through
a list in some way to see where the next address to allocate will come from,
i.e. if you allocate sequentially you'll have gaps in your sequence that
can be reused.    Although actually in v6 you could argue you never need
to check for those gaps since you have a lot of mileage in just using the next
address each time, if you chose to.

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

I'm just saying what we're seeing.  There would be a stateful firewall where
the NAT box is today, indeed they would likely be the same box in a dual stack
site, so I'm not sure what your point is here.
 
> >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.

That doesn't matter.  To a home user they might see DHC addresses for v6
allocated as they are today, sequentially from <prefix>::1, but they could
check a tickbox on their router web interface to say 'allocate dhc addresses
randomly', just as there may be a tickbox for dhc privacy addresses.  Today's
IPv6 routers, running NAT or not, offer options for things such as static 
address allocation by MAC address, address pools to use, etc, so it's not
unfamiliar to today's more experienced users.

Tim