Re: I-D.ietf-v6ops-cpe-simple-security-09

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Sun, 21 March 2010 01:06 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5902C3A6767 for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 20 Mar 2010 18:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.9
X-Spam-Level:
X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4u7d6r7TPFI for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 20 Mar 2010 18:06:37 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A1693A672E for <v6ops-archive@lists.ietf.org>; Sat, 20 Mar 2010 18:06:37 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1Nt9XA-000N12-Oo for v6ops-data0@psg.com; Sun, 21 Mar 2010 01:00:52 +0000
Received: from [202.136.110.251] (helo=smtp2.adam.net.au) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1Nt9X7-000Mz9-SU for v6ops@ops.ietf.org; Sun, 21 Mar 2010 01:00:50 +0000
Received: from 219-90-253-216.ip.adam.com.au ([219.90.253.216] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1Nt9Wz-0003uC-OD; Sun, 21 Mar 2010 11:30:41 +1030
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 72E984930C; Sun, 21 Mar 2010 11:30:38 +1030 (CST)
Date: Sun, 21 Mar 2010 11:30:37 +1030
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: Fred Baker <fred@cisco.com>
Cc: Mark Townsley <townsley@cisco.com>, james woodyatt <jhw@apple.com>, IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09
Message-ID: <20100321113037.13756c12@opy.nosense.org>
In-Reply-To: <F0FDFF3D-F703-422A-9443-D6F723FB034C@cisco.com>
References: <D6F5ACD2-EB43-477E-9F48-AC3EDB3F7EB4@apple.com> <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <9EEBEB1D-8D88-45DB-9200-EBE2ED0D84CF@apple.com> <4BA524A8.9020201@cisco.com> <D6BE2A3C-57BD-486D-B9C6-382B42FA4A67@cisco.com> <4BA55147.601@cisco.com> <F0FDFF3D-F703-422A-9443-D6F723FB034C@cisco.com>
X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Sat, 20 Mar 2010 15:55:52 -0700
Fred Baker <fred@cisco.com> wrote:

> >>> Rate-limiting unsolicited inbound connections rather than rejecting them provides greater end-to-end transparency while still providing protection against address and port scanning attacks as well as overloading of slow links or devices within the home.
> >>>     
> >> SIlly question. Why do you believe that? An address or port scanning attack is not intended to overload a network, it is intended to find an address port that can be used or attacked.
> > The sentence is referencing two different things. One, the possibility that uninvited packets might overload some device or slow link (something I consider unlikely, but has been identified as a concern by some), the other is, indeed, designed to make blind port and address scanning less likely to succeed in a given amount of time.
> > 
> > - Mark
> >>  Making the scan take more time doesn't prevent it from reaching its target. In what way does rate limiting an address or port scan provide protection?
> 
> With all due respect, when I set up security for my home or office, and when Cisco InfoSec sets up security for its home offices (of which mine is one), they're not asking about making an attack take ten minutes vs five. They're asking about preventing an attack from succeeding. Now, we can discuss the logic of the notion that "the bad guys are out there and the good guys are in here", but given the assumption, we need to be rational about the threats we are trying to prevent from succeeding.
> 

One thing that does seem to be missing from the draft is a specific
list of threats it is attempting to mitigate i.e. a threat model. With
luck, that sort of list would end up on the outside of the cardboard
box the CPE comes in, so that when people buy the CPE, they don't
assume the device is taking care of "all security", and therefore don't
have to bother with any other security measures.





>