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

["Tony Hain" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Tim Chown
> Sent: Tuesday, November 28, 2006 9:46 AM
> To: Eric Klein
> Cc: Stig Venaas; [e-mail]; [e-mail]
> 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
> th [XMail 1.17 (Win32/Ix86) ESMTP Server]
	id <S2A2268> for <[e-mail]> from <[e-mail]>;
	Mon, 19 Mar 2007 01:43:19 -0700
From: "Tony Hain" <[e-mail]>
To: "'Tim Chown'" <[e-mail]>
References: <[e-mail]>
	<027101c71242$1ec75570$[e-mail]>
	<[e-mail]>
	<028a01c71248$6bec1dd0$[e-mail]>
	<[e-mail]>
In-Reply-To: <[e-mail]>
Subject: RE: [dhcwg] Review of draft-ietf-v6ops-scanning-implications
Date: Mon, 19 Mar 2007 09:43:13 +0100
Message-ID: <000a01c76a02$a2c225e0$e84671a0$@net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AccSysHzMawMdgYJQTGao/LeZ+i9TRXNl5LA
Content-Language: en-us
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
X-Mailman-Approved-At: Tue, 27 Mar 2007 09:30:44 -0400
Cc: [e-mail], [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>,
	<mailto:[e-mail]?subject=subscribe>
Errors-To: [e-mail]

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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Tim Chown
> Sent: Tuesday, November 28, 2006 9:46 AM
> To: Eric Klein
> Cc: Stig Venaas; [e-mail]; [e-mail]
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg





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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg