Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-00

Danny McPherson <danny@tcb.net> Wed, 21 January 2009 03:56 UTC

Return-Path: <opsec-bounces@ietf.org>
X-Original-To: opsec-archive@optimus.ietf.org
Delivered-To: ietfarch-opsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B9B3A6935; Tue, 20 Jan 2009 19:56:11 -0800 (PST)
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618753A6935 for <opsec@core3.amsl.com>; Tue, 20 Jan 2009 19:56:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.684
X-Spam-Level:
X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, SARE_SUB_RAND_LETTRS4=0.799]
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 vOiEJS3yRnYy for <opsec@core3.amsl.com>; Tue, 20 Jan 2009 19:56:09 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 91B6A3A682C for <opsec@ietf.org>; Tue, 20 Jan 2009 19:56:09 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id 7B6802684EA; Tue, 20 Jan 2009 20:55:53 -0700 (MST)
Received: from jchouinard-sim-105.eng.ellacoya.com (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for opsec@ietf.org; Tue, 20 Jan 2009 20:55:53 -0700 (MST) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=52044; syn-fingerprint=65535:55:1:64:M1408,N,W3,N,N,T,S; data-bytes=0
Message-Id: <337CC62A-F021-49D0-AA8E-AF1250124C72@tcb.net>
From: Danny McPherson <danny@tcb.net>
To: opsec wg mailing list <opsec@ietf.org>
In-Reply-To: <E3B4452D-A984-439F-9069-7E43F51E3F42@kumari.net>
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 20 Jan 2009 20:55:52 -0700
References: <E3B4452D-A984-439F-9069-7E43F51E3F42@kumari.net>
X-Mailer: Apple Mail (2.930.3)
Subject: Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-00
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: opsec-bounces@ietf.org
Errors-To: opsec-bounces@ietf.org On Jan 20, 2009, at 11:21 AM, Warren Kumari wrote:

> Now, for the big question:
>
> In the draft we are are requesting a registered BGP community to be  
> used to signal your provider that you want destination based RTBH  
> applied to an announced prefix.
>
> There are two viewpoints on this -- I will try to capture them both,  
> apologies if I mess this up:
> Viewpoint 1:
> This should be removed -- different providers will implement RTBH  
> (src and dest) in different ways and will provide different  
> capabilities (drop on the "edge", only install in a specific region,  
> etc) and so there will need to be multiple communities. Getting this  
> info from your provider (and having them enable the feature), etc is  
> (and should remain) a required step.
>

Viewpoint 1 is mine..  I've seen providers with 10 communities
or more, and I'm not sure that defining well-known ones fixes
anything.

I too, as you might imagine, agree with Warren that we'd very
much like to see what the WG thinks about this.

-danny

> Viewpoint 2:
> I'd like to keep the registered community -- while different  
> providers will support different subsets of this, having a well  
> known way to enable this seems good to me. Currently providers  
> support different communities for different things (e.g: announce  
> this only to peers, set the MED, etc) but there are still some well  
> known (e.g NO_EXPORT) communities that the provider probably  
> implements. I dislike being in the situation where I am experiencing  
> a DoS attack and have misplaced the napkin that I scribbled the  
> secret community on last time. Now, while I am down I need to fight  
> my way through Tier 1 - Tier N trying to find the magic community to  
> apply for provider X. I'd rather just tag an announcement with the  
> registerd RTBH community. If the provider doesn't support this, I'm  
> no worse off, if they do, I've bought some time.
>
> I'd appreciate any feedback on this, and the rest of the doc. And,  
> once again, thnaks to all who have already provided feedback...

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec