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

[Ralph Droms <rdroms@cisco.com>]

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