IETF Logo Mail Archive

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

"Ryan Mcdowell (rymcdowe)" <rymcdowe@cisco.com> Thu, 22 January 2009 00:05 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 49A313A6998; Wed, 21 Jan 2009 16:05:49 -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 CA29628C12C for <opsec@core3.amsl.com>; Wed, 21 Jan 2009 16:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level:
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 VGvE84S-6yN2 for <opsec@core3.amsl.com>; Wed, 21 Jan 2009 16:05:47 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C9BE63A6978 for <opsec@ietf.org>; Wed, 21 Jan 2009 16:05:46 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,303,1231113600"; d="scan'208";a="34465151"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Jan 2009 00:05:30 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0M05UjM012384 for <opsec@ietf.org>; Wed, 21 Jan 2009 19:05:30 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0M05UUo019108 for <opsec@ietf.org>; Thu, 22 Jan 2009 00:05:30 GMT
Received: from xmb-rtp-20e.amer.cisco.com ([64.102.31.40]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 19:05:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 21 Jan 2009 19:06:17 -0500
Message-ID: <A759481225F9064586B34D2B490AB73206B93254@xmb-rtp-20e.amer.cisco.com>
In-Reply-To: <19805DE9-0FB7-46C6-8984-DD82A6BB11E4@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OPSEC] draft-ietf-opsec-blackhole-urpf-00
Thread-Index: Acl7fci3riQSCU4XTd2nIH2FNRMTKQApZqXw
References: <E3B4452D-A984-439F-9069-7E43F51E3F42@kumari.net> <19805DE9-0FB7-46C6-8984-DD82A6BB11E4@cisco.com>
From: "Ryan Mcdowell (rymcdowe)" <rymcdowe@cisco.com>
To: "Roland Dobbins (rdobbins)" <rdobbins@cisco.com>, opsec wg mailing list <opsec@ietf.org>
X-OriginalArrivalTime: 22 Jan 2009 00:05:29.0903 (UTC) FILETIME=[22F733F0:01C97C25]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2577; t=1232582730; x=1233446730; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rymcdowe@cisco.com; z=From:=20=22Ryan=20Mcdowell=20(rymcdowe)=22=20<rymcdowe@cis co.com> |Subject:=20RE=3A=20[OPSEC]=20draft-ietf-opsec-blackhole-ur pf-00 |Sender:=20 |To:=20=22Roland=20Dobbins=20(rdobbins)=22=20<rdobbins@cisc o.com>,=0A=20=20=20=20=20=20=20=20=22opsec=20wg=20mailing=20 list=22=20<opsec@ietf.org>; bh=Oc82MegQlFe4O8Vpl1+6s0q2pKi0LE6HN0XATbEi0vE=; b=P4MOpV7ij/hgA9o202zLG7EuajjMZzU4P5TWoZhq3vsF0hockqrcJ3gbSj UCP7V+puh+clcl5pHuPO8Vow4gCA1iNkn3bRnW4ZQXn0t2kx/MKDHnjcHicU fQ9UXoz0Ph;
Authentication-Results: rtp-dkim-2; header.From=rymcdowe@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: opsec-bounces@ietf.org
Errors-To: opsec-bounces@ietf.org Agree with Roland, too many ISP's do slightly different things. I think

a standard community could capture all the power and options possible.
A standard community would greatly reduce the flexibility.  

Does the provider set no-advertise on such updates so I have to
advertise them over every eBGP session?  Does the provider do source,
destination, or both blackholing?  Does the provider attempt to
propagate it to their upstreams?  If so, which ones?  Can I control
which ones?  If the provider has multiple ASes, do they propagate it to
all their ASes?  If so, which ones?  Can I control which ones?  Does the
provider offer QPPB instead of blackholing? Etc...  

----------------------------
Ryan McDowell
Systems Engineer
Cisco Systems, Inc
(W) +1 703.484.0040
(M) +1 703.201.5742
PGP Fingerprint: EED9 192F 9F45 FAE4 F6A3 8764 FEE1 299D 1B62 A361 
----------------------------

-----Original Message-----
From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf
Of Roland Dobbins (rdobbins)
Sent: Tuesday, January 20, 2009 11:07 PM
To: opsec wg mailing list
Subject: Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-00


On Jan 21, 2009, at 2:21 AM, Warren Kumari wrote:

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

The problem with this is that it lacks granularity, and if this were to
come to pass and you tagged your announcement accordingly, you don't
know what the result will be, nor where, nor how.

We've all seen instances of uncoordinated mitigation which have gone
awry and made things worse, not better.  Any kind of inter-provider
signaling of this type should only be undertaken/work after an explicit
mutual understanding has been reached regarding expectations and actual
behavior.

Given the fact that various operators have implemented various
communities for various purposes over time, and given the
situationally-specific nature of the blackholing mechanisms themselves,
I think that while this is a noble goal, that it simply isn't practical
in this particular milieu and should probably be removed.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins@cisco.com> // +852.9133.2844 mobile

      All behavior is economic in motivation and/or consequence.




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

v2.23.0 | Report a Bug | By Email