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

Shane Amante <shane@castlepoint.net> Sun, 21 March 2010 00:05 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 9543E3A69A3 for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 20 Mar 2010 17:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.107
X-Spam-Level: ***
X-Spam-Status: No, score=3.107 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 lJ-YRu9LlnEA for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 20 Mar 2010 17:05:34 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3BFFC3A694D for <v6ops-archive@lists.ietf.org>; Sat, 20 Mar 2010 17:05:31 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1Nt8Zu-000EvE-0n for v6ops-data0@psg.com; Sat, 20 Mar 2010 23:59:38 +0000
Received: from [64.78.150.133] (helo=dog.tcb.net) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <shane@castlepoint.net>) id 1Nt8Zp-000Eur-RL for v6ops@ops.ietf.org; Sat, 20 Mar 2010 23:59:33 +0000
Received: by dog.tcb.net (Postfix, from userid 0) id DCBC8268677; Sat, 20 Mar 2010 17:59:32 -0600 (MDT)
Received: from mbpw.castlepoint.net (71.215.81.125 [71.215.81.125]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sat, 20 Mar 2010 17:59:32 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.81.125; client-port=61397; client-dnsfail=71.215.81.125: name server failure; syn-fingerprint=65535:56:1:64:M1452,N,W1,N,N,T,S; data-bytes=0
Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <F0FDFF3D-F703-422A-9443-D6F723FB034C@cisco.com>
Date: Sat, 20 Mar 2010 17:59:16 -0600
Cc: Mark Townsley <townsley@cisco.com>, james woodyatt <jhw@apple.com>, IPv6 Operations <v6ops@ops.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C9616B83-659D-4FA8-A4EF-361B5FD2DA9B@castlepoint.net>
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>
To: Fred Baker <fred@cisco.com>
X-Mailer: Apple Mail (2.1077)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Mark, Fred,

On Mar 20, 2010, at 16:55 MDT, Fred Baker 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.

Agreed.  This proposal seems like a poor half-measure.  IMHO, if a client/host wants real end-2-end transparency, then it should use something like NAT-PMP to explicitly signal to the upstream FW that the client is wise and mature enough to deploy it's own, onboard FW to protect itself.  Although some people may think that's a bad idea, because a malware-infected PC/device could signal an upstream FW to open up everything, I personally think that's a very poor argument.

Namely, once a PC/device is infected, it's game-over, anyway.  Specifically, remote attackers already have the ability to remotely control that PC and perform further reconnaissance and attacks both /inside/ and outside the LAN.  Second, if technically savvy people still don't like the idea of NAT-PMP operating on their FW, then they will be smart enough to disable it altogether on their (personal) FW's.  

-shane