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

["Tony Hain" <alh-ietf@tndh.net>]

One of the things that this draft might want to do is note that 'sparse
allocation of the space' is the function that mitigates scanning. There is a
focus on 'random' which is the mechanism to distribute sparsely in the
space, but I have found that many people get hung up on 'random' and miss
the point that sparseness is the value. 

Tony

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of Tim Chown
> Sent: Tuesday, November 28, 2006 9:46 AM
> To: Eric Klein
> Cc: Stig Venaas; dhcwg@ietf.org; v6ops@ops.ietf.org
> Subject: Re: [dhcwg] Review of draft-ietf-v6ops-scanning-implications
> 
> 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
>