IETF Logo Mail Archive

Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here

Sam Silvester <sam.silvester@gmail.com> Tue, 01 February 2011 03:04 UTC

Return-Path: <sam.silvester@gmail.com>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82803A6CC4 for <v6ops@core3.amsl.com>; Mon, 31 Jan 2011 19:04:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 Vsz0SpHPutt2 for <v6ops@core3.amsl.com>; Mon, 31 Jan 2011 19:04:01 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BBFDD3A6A86 for <v6ops@ietf.org>; Mon, 31 Jan 2011 19:04:00 -0800 (PST)
Received: by fxm9 with SMTP id 9so6921660fxm.31 for <v6ops@ietf.org>; Mon, 31 Jan 2011 19:07:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=rFu1ORBCayADcVoiEOUlTeiqkSgZmsAMn5Q+iNJ+kQU=; b=S+8+zsMX7DRfEacasGT8S/ofPC64pAh+x+o064RJsifvMj18tFALmPMcZOlG+t/k44 JOTRUC4LsXBoYIUWc3MqE6jrHLA6pw77Oj9nCasYDwgAP3T61BnVswjAdNIA7KyvIMbK rUYYdd8ehU5r/+fzOH3y4AirNlKe9nmnkur6A=
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 :content-type:content-transfer-encoding; b=nF8+d7w0bM0QwVMGxNiFK+8RjX98/q5Vd8JOSywmnpEoPudyCUDiVlvT1n9XvoWfMo meh9+3YZqCoLlHNOyHu0kvximXDUS49ZQv5SHNeVL6PoZmA3O5oJ4mI9W737tmOcKeg6 deO10w6zOYk9Mxg7g0qCrUxrvFoU/2ccM/Lt0=
MIME-Version: 1.0
Received: by 10.223.114.14 with SMTP id c14mr6769778faq.103.1296529635991; Mon, 31 Jan 2011 19:07:15 -0800 (PST)
Received: by 10.223.115.207 with HTTP; Mon, 31 Jan 2011 19:07:15 -0800 (PST)
In-Reply-To: <4D472732.5070104@brightok.net>
References: <8C80472E-DEF2-45DE-BECB-D09E58328D14@cisco.com> <4D46D04C.9080600@brightok.net> <79156CD2-EF2D-4A67-BF40-C67A3FD2B49D@cisco.com> <4D46DDA2.1090204@brightok.net> <B711D39C-5888-4619-B8BF-29A317145E51@cisco.com> <4D46F5BD.2050704@brightok.net> <20110201073623.5628b0b9@opy.nosense.org> <4D472732.5070104@brightok.net>
Date: Tue, 01 Feb 2011 13:37:15 +1030
Message-ID: <AANLkTi=Lu64kPViWnphYf_j0o+n+y8dUdXV20wEZ4Uu8@mail.gmail.com>
From: Sam Silvester <sam.silvester@gmail.com>
To: IPv6 Operations <v6ops@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [v6ops] draft-wbeebee-v6ops-ipv6-cpe-router-bis - where to go from here
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2011 03:04:02 -0000

On Tue, Feb 1, 2011 at 7:48 AM, Jack Bates <jbates@brightok.net> wrote:
> On 1/31/2011 3:06 PM, Mark Smith wrote:
>>
>> Consider the operational consequences of allowing customers to make
>> dynamic subnet requests -
>>
>> - your customer aggregation routers will now have additional control
>>   plane load of processing those requests. This may also create involve
>>   additional load on backend authentication servers. Some malicious
>>   customers (let's call then "kids") might use this as a DoS vector,
>>   for Saturday afternoon entertainment.
>
> The same can be done with a single device making repetitive requests.
> Control knobs are necessary to protect the ISP in either case. In this case,
> the CPE itself can self rate-control such requests.

I don't know that I'd be comfortable trusting the CPE with this
responsibility unless I as the service provider managed it; in fact,
in many cases for residential ISPs, the customer owns / manages their
own CPE (and are even welcome to bring their own as opposed to buying
the one their ISP provides).

Sam

v2.23.0 | Report a Bug | By Email