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

Warren Kumari <warren@kumari.net> Tue, 20 January 2009 18:21 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 E5F293A6895; Tue, 20 Jan 2009 10:21:32 -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 9B8FA3A6895 for <opsec@core3.amsl.com>; Tue, 20 Jan 2009 10:21:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LzbvitdOlACZ for <opsec@core3.amsl.com>; Tue, 20 Jan 2009 10:21:30 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 753B43A6878 for <opsec@ietf.org>; Tue, 20 Jan 2009 10:21:30 -0800 (PST)
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id n0KILCAs000513 for <opsec@ietf.org>; Tue, 20 Jan 2009 18:21:12 GMT
Received: from dhcp-172-29-120-232.ame.corp.google.com (dhcp-172-29-120-232.ame.corp.google.com [172.29.120.232]) (authenticated bits=0) by wpaz13.hot.corp.google.com with ESMTP id n0KIL99v010435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <opsec@ietf.org>; Tue, 20 Jan 2009 10:21:10 -0800
Message-Id: <E3B4452D-A984-439F-9069-7E43F51E3F42@kumari.net>
From: Warren Kumari <warren@kumari.net>
To: opsec@ietf.org
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 20 Jan 2009 13:21:09 -0500
X-Mailer: Apple Mail (2.929.2)
Subject: [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-Type: multipart/mixed; boundary="===============0922403527=="
Sender: opsec-bounces@ietf.org
Errors-To: opsec-bounces@ietf.org

Hello all,

I have just posted draft-ietf-opsec-blackhole-urpf-00 (ex raft-kumari- 
blackhole-blckhole-02)

I appreciate all of the feedback (and especially the suggested  
text :-)) that people have been supplying and hope that I have  
accurately captured your input -- if not, I *do* apologize, I decided  
to batch up all the changes and they might have gotten away from me.  
Please let me know if I messed up and I will fix it...

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 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...


W


--
"Go on, prove me wrong. Destroy the fabric of the universe. See if I  
care."  -- Terry Prachett


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