Re: [dhcwg] Review of draft-ietf-v6ops-scanning-implications
Ralph Droms <rdroms@cisco.com> Mon, 19 March 2007 08:59 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 1HTDi0-0007mz-Bx; Mon, 19 Mar 2007 04:59:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDhz-0007mX-7Z for dhcwg@ietf.org; Mon, 19 Mar 2007 04:59:15 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTDhx-00049P-RT for dhcwg@ietf.org; Mon, 19 Mar 2007 04:59:15 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Mar 2007 04:59:13 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2J8xDKq001078; Mon, 19 Mar 2007 04:59:13 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2J8xDGd019370; Mon, 19 Mar 2007 08:59:13 GMT
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 04:59:12 -0400
Received: from 10.86.242.109 ([10.86.242.109]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Mar 2007 08:59:12 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Mon, 19 Mar 2007 04:59:21 -0400
Subject: Re: [dhcwg] Review of draft-ietf-v6ops-scanning-implications
From: Ralph Droms <rdroms@cisco.com>
To: alh-ietf@tndh.net, Tim Chown <tjc@ecs.soton.ac.uk>
Message-ID: <C223C929.3DF0E%rdroms@cisco.com>
Thread-Topic: [dhcwg] Review of draft-ietf-v6ops-scanning-implications
Thread-Index: AccSysHzMawMdgYJQTGao/LeZ+i9TRXNl5LAAADwe1Y=
In-Reply-To: <000a01c76a02$a2c225e0$e84671a0$@net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 19 Mar 2007 08:59:12.0980 (UTC) FILETIME=[DD5FB940:01C76A04]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4860; t=1174294753; x=1175158753; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20<rdroms@cisco.com> |Subject:=20Re=3A=20[dhcwg]=20Review=20of=20draft-ietf-v6ops-scanning-imp lications |Sender:=20 |To:=20<alh-ietf@tndh.net>,=20Tim=20Chown=20<tjc@ecs.soton.ac.uk>; bh=qriafYZWDmdf0C3T2L19nzGTE5Y6wDKV5Wdas6hGNms=; b=CWtxhfJcVRQHlfydpREuAyR8LllIdMnGb0KNrjDc6cf8wEEsbMmYIvm4hkzn6lypkqkLfkg2 ksezkC86pq5XSuMZn0bSAaVRDULR2Tp3KW2slmImJpIGQLhENmWY34oB;
Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Cc: v6ops@ops.ietf.org, dhcwg@ietf.org
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
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 >> > _______________________________________________ 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