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

Cameron Byrne <cb.list6@gmail.com> Sun, 21 March 2010 03:04 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 3DEB53A698D for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 20 Mar 2010 20:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.225
X-Spam-Level:
X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[AWL=-2.824, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 4t2ZUX5rz3rP for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 20 Mar 2010 20:04:24 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 09CC33A6944 for <v6ops-archive@lists.ietf.org>; Sat, 20 Mar 2010 20:04:24 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1NtBOa-000DT1-55 for v6ops-data0@psg.com; Sun, 21 Mar 2010 03:00:08 +0000
Received: from [209.85.210.184] (helo=mail-yx0-f184.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <cb.list6@gmail.com>) id 1NtBOX-000DSc-Bt for v6ops@ops.ietf.org; Sun, 21 Mar 2010 03:00:05 +0000
Received: by yxe14 with SMTP id 14so2142640yxe.5 for <v6ops@ops.ietf.org>; Sat, 20 Mar 2010 20:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+D57j6hIGmBajlXdIf6WQCeRrn3rrTT91VVR9oiBuY4=; b=ddcaiK7o4cIeFEpw1uOpMakxnEO3QbqoR5SNRXsqMaSBljSBAvke3IYBxERtIGXdt5 nQZWEJwu9HDuEQZxE67c5eJ9y4+81xqOlhqBsalpNzQw0p12ozj9mQjpR+Pf2gzAlGGt GNhxJDGnkQz3qKtm3EMlfSNKmysNjyFWk/4Ts=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KygxuFY8VczKGz1h4/sycZvlceGI/d+y9rpD4uQbdqvL9m8oRz6nPprxO02n4w3EmL offPQZCqLAgLSBZ4FkPLoLGDaVUoMATn59OVH8zMEns9ptTi/FlPVBBmqhENCkpN1Htk +0XqqQuv4+G8jztHUQ8XMXxgqFXp4P+kR6UxE=
MIME-Version: 1.0
Received: by 10.150.47.11 with SMTP id u11mr9663050ybu.140.1269140403436; Sat, 20 Mar 2010 20:00:03 -0700 (PDT)
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>
Date: Sat, 20 Mar 2010 20:00:03 -0700
Message-ID: <bcff0fba1003202000q455e81fdg2e00057483166763@mail.gmail.com>
Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09
From: Cameron Byrne <cb.list6@gmail.com>
To: Fred Baker <fred@cisco.com>
Cc: Mark Townsley <townsley@cisco.com>, james woodyatt <jhw@apple.com>, IPv6 Operations <v6ops@ops.ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Sat, Mar 20, 2010 at 3:55 PM, 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.
>

Agreed, rate-limiting does not add value in this scope.  We know that
IPv6 is hard to scan successfully, and we know that rate limiting it
on the CPE won't protect the external link from becoming saturated
during an attack.  From the service provider perspective, rate
limiting causes inconsistency in services (some packets get through in
this sample test but not in the next sample test) and thus injects
greater complexity for the folks trying to troubleshoot. I prefer
consistent and deterministic behavior.  I would say the principle of
default-deny and least privilege are philosophically correct in
general, but i am not sure it needs to be applied in simple CPE.  I
believe most current host OS software ships these days with default
deny, and authorized administrators and applications can open the
proper ports when needed.  If the trend is default-deny on the host
which is "application aware", we do not need default-deny on the
simple CPE which is not application aware.

Cameron