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

From: Ralph Droms <[email-masked]>
Date: Mon, 19 Mar 2007 04:59:21 -0400

Tony - is the desired property "unpredictable sparseness"?

- Ralph

On 3/19/07 4:43 AM, "Tony Hain" <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Tim Chown
>> Sent: Tuesday, November 28, 2006 9:46 AM
>> To: Eric Klein
>> Cc: Stig Venaas; [email-masked]; [email-masked]
>> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Mar 2007 17:36:28 +0000

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

-- 
Tim

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 19 Mar 2007 10:03:15 +0100

yes

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Monday, March 19, 2007 9:59 AM
> To: [email-masked]; Tim Chown
> Cc: [email-masked]; [email-masked]
> >> defacto subnet size of /64, in which the host address spaceFrom [email-masked] Tue Mar 27 09:31:47 2007
From: "Tony Hain" <[email-masked]>
To: "'Ralph Droms'" <[email-masked]>,
	"'Tim Chown'" <[email-masked]>
Subject: RE: [dhcwg] Review of draft-ietf-v6ops-scanning-implications
Date: Mon, 19 Mar 2007 10:03:15 +0100
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]

yes

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Monday, March 19, 2007 9:59 AM
> To: [email-masked]; Tim Chown
> Cc: [email-masked]; [email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 19 Mar 2007 09:43:13 +0100

Tony

> th [XMail 1.17 (Win32/Ix86) ESMTP Server]
	id <S2A2268> for <[email-masked]> from <[email-masked]>;
	Mon, 19 Mar 2007 01:43:19 -0700
From: "Tony Hain" <[email-masked]>
To: "'Tim Chown'" <[email-masked]>
Subject: RE: [dhcwg] Review of draft-ietf-v6ops-scanning-implications
Date: Mon, 19 Mar 2007 09:43:13 +0100
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]

Tony

---

From: Bud Millwood <[email-masked]>
Date: Tue, 27 Mar 2007 15:42:20 +0200

On Monday 19 March 2007 09:43, Tony Hain wrote:
> 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

Why not simply suggest "unpredictable" address allocation? Certainly "random" 
is different from "hashed", although hashed can also be difficult to predict.

- Bud

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687