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

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

Thanks Tony; a good perspective that I'll add into -03 along with Dave's
comment on less specific 3306's prefixes, and we can then re-WGLC.

Tim

On Mon, Mar 19, 2007 at 04:59:21AM -0400, Ralph Droms wrote:
> Tony - is the desired property "unpredictable sparseness"?
> 
> - Ralph
> 
> 
> On 3/19/07 4:43 AM, "Tony Hain" <alh-ietf@tndh.net> wrote:
> 
> > 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
> >> 
> > 

-- 
Tim