Re: Review of draft-ietf-v6ops-scanning-implications

Tony - is the desired property "unpredictable
sparseness"?

- Ralph

On 3/19/07 4:43 AM, "Tony Hain" <alh-ietftndh.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-v6opsops.ietf.org
[mailto:owner-v6opsops.ietf.org] On
>> Behalf Of Tim Chown
>> Sent: Tuesday, November 28, 2006 9:46 AM
>> To: Eric Klein
>> Cc: Stig Venaas; dhcwgietf.org; v6opsops.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
>> 
> 

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

Re: Review of draft-ietf-v6ops-scanning-implications

Thread: Re: Review of draft-ietf-v6ops-scanning-implications