Re: [dhcwg] Review of draft-ietf-v6ops-scanning-implications
Tim Chown <tjc@ecs.soton.ac.uk> Mon, 19 March 2007 17:37 UTC
Return-path: <dhcwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLnC-00010R-O6; Mon, 19 Mar 2007 13:37:10 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLnA-00010L-WE for dhcwg@ietf.org; Mon, 19 Mar 2007 13:37:09 -0400
Received: from owl.ecs.soton.ac.uk ([152.78.68.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTLn6-0001ib-7Q for dhcwg@ietf.org; Mon, 19 Mar 2007 13:37:08 -0400
Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id l2JHaeSV032172; Mon, 19 Mar 2007 17:36:40 GMT
Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id l2JHaS8v028852; Mon, 19 Mar 2007 17:36:28 GMT
Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id l2JHaSRq031790; Mon, 19 Mar 2007 17:36:28 GMT
Date: Mon, 19 Mar 2007 17:36:28 +0000
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org, dhcwg@ietf.org
Subject: Re: [dhcwg] Review of draft-ietf-v6ops-scanning-implications
Message-ID: <20070319173624.GG30942@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org, dhcwg@ietf.org
References: <000a01c76a02$a2c225e0$e84671a0$@net> <C223C929.3DF0E%rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C223C929.3DF0E%rdroms@cisco.com>
User-Agent: Mutt/1.4i
X-Null-Tag: 8f5792f3ee5f3cc2c142fd9cab841105
X-Null-Tag: 8af53291334808265606232f1a1be5c3
X-ECS-MailScanner: Found to be clean, Found to be clean
X-Spam-Status: No
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
Cc:
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Errors-To: dhcwg-bounces@ietf.org
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 On Mon, Mar 19, 2007 at 04:59:21AM -0400, Ralph Droms wrote: > 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 > >> > > -- Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Review of draft-ietf-v6ops-scanning-impli… Fred Baker
- Re: [dhcwg] Review of draft-ietf-v6ops-scanning-i… Stig Venaas
- RE: [dhcwg] Review of draft-ietf-v6ops-scanning-i… Bernie Volz (volz)
- Re: [dhcwg] Review of draft-ietf-v6ops-scanning-i… Tim Chown
- Re: [dhcwg] Review of draft-ietf-v6ops-scanning-i… Tim Chown
- Re: Teredo for reducing search space (was: [dhcwg… Alexandru Petrescu
- Re: [dhcwg] Review of draft-ietf-v6ops-scanning-i… Ralph Droms
- Re: [dhcwg] Review of draft-ietf-v6ops-scanning-i… Tim Chown
- RE: [dhcwg] Review of draft-ietf-v6ops-scanning-i… Tony Hain
- Re: [dhcwg] Review of draft-ietf-v6ops-scanning-i… Bud Millwood