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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 27 Nov 2006 10:14:43 -0500

I fully agree with and support this text.

- Bernie

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Thursday, November 23, 2006 4:40 PM
To: [email-masked]
Subject: Re: [dhcwg] Review of draft-ietf-v6ops-scanning-implications

Per Fred's request, please let v6ops and/or authors know if you have
any thoughts regarding this draft. In particular there is the following
section:

4.2.  DHCP Service Configuration Options

    The administrator should configure DHCPv6 so that the first
addresses
    allocated from the pool begins much higher in the address space than
    at [prefix]::1.  DHCPv6 also includes an option to use Privacy
    Extension [2] addresses, i.e. temporary addresses, as described in
    Section 12 of the DHCPv6 [5] specification.  It is desirable that
    allocated addresses are not sequential, nor have any predictable
    pattern to them.

Stig

Fred Baker wrote:
> The v6ops working group is approaching a working group last call on  
> draft-ietf-v6ops-scanning-implications within the coming few weeks.
We 
> would appreciate a review from your working group of this document  
> before we do so. How that is done is up to you; you may designate one

> or more reviewers, or simply conduct the review on your mailing list,

> or whatever else suits you. But please respond to the authors copying

> v6ops within the coming four weeks if you would.
> 
> Thank you for your help in this.
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Eric Klein" <[email-masked]>
Date: Mon, 27 Nov 2006 18:35:56 +0200

>     allocated addresses are not sequential, nor have any predictable

 I am not sure that I like the idea that we are suggesting that the DCHPv6 
start higher than 1 for 2 reasons:
1. It reduces the number of addresses available, by 1 less than the starting 
number chosen by the administrator. Yes I know that there are many more 
numbers available, but I am hesitant to start recommending that they be 
arbitrarily reduced for a dubious security consideration (see reason #2).

2. By stating that it is desirable, but not mandatory that the numbers from 
the address pool of numbers are not allocated sequentially, you leave the 
possibility that people choosing the easy coding methodology will still 
allow it to be sequential. So, by choosing a number higher than 1 you have 
only reduced the security implications by a few seconds as the scan will 
eventually reach the first entry and then be able to scan the network.

---

From: Tim Chown <[email-masked]>
Date: Mon, 27 Nov 2006 17:02:16 +0000

On Mon, Nov 27, 2006 at 06:35:56PM +0200, Eric Klein wrote:
> 1. It reduces the number of addresses available, by 1 less than the 
> starting number chosen by the administrator. Yes I know that there are many 
> more numbers available, but I am hesitant to start recommending that they 
> be arbitrarily reduced for a dubious security consideration (see reason #2).

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.

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.

> eventually reach the first entry and then be able to scan the network. 

It would be likely to take more than a few seconds, and would probably
generate traffic that would alert an IDS to the scan.

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.   

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.

-- 
Tim

---

From: "Eric Klein" <[email-masked]>
Date: Mon, 27 Nov 2006 19:21:02 +0200

On Mon, Nov 27, 2006 Tim Chown wrote

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

> such an address is already used, but that cost should in principle not be
"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.

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

> scanning obfuscation.   It's a trade-off but it would be nice to have

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.

---

From: Tim Chown <[email-masked]>
Date: Tue, 28 Nov 2006 08:45:44 +0000

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

> companies like to cut corners in development. Again, not a show stopper to 

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.

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

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

---

From: Gert Doering <[email-masked]>
Date: Wed, 29 Nov 2006 12:33:19 +0100

Hi,

On Mon, Nov 27, 2006 at 07:21:02PM +0200, Eric Klein wrote:
> unlimited as had been hoped. 

The number of magnitude diffence between 2^32 and 2^128 is fairly
significant.

> I would not hold the draft for this, but I 

We're talking about address wastage on a given link here - out of the
2^64 addresses available *per link*.

So yes, even if you waste half of them, you still have 2^63 addresses 
- that's about 2^54 times more than you need for "100 appliances".

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  98999

SpaceNet AG                    Mail: [email-masked]
Joseph-Dollinger-Bogen 14      Tel : +49-89-32356-0
D- 80807 Muenchen              Fax : +49-89-32356-234