IETF Logo Mail Archive

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

"Ryan Mcdowell (rymcdowe)" <rymcdowe@cisco.com> Thu, 22 January 2009 01:04 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 995E03A6A5D; Wed, 21 Jan 2009 17:04:30 -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 30F433A6A5D for <opsec@core3.amsl.com>; Wed, 21 Jan 2009 17:04:30 -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 gXmtdkmizppL for <opsec@core3.amsl.com>; Wed, 21 Jan 2009 17:04:29 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id F3E123A69EC for <opsec@ietf.org>; Wed, 21 Jan 2009 17:04:28 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,303,1231113600"; d="scan'208";a="34505886"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Jan 2009 01:03:45 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0M13jsT003742 for <opsec@ietf.org>; Wed, 21 Jan 2009 20:03:45 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0M13jGq025002 for <opsec@ietf.org>; Thu, 22 Jan 2009 01:03:45 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 20:03:45 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 21 Jan 2009 20:04:09 -0500
Message-ID: <A759481225F9064586B34D2B490AB73206B93277@xmb-rtp-20e.amer.cisco.com>
In-Reply-To: <A759481225F9064586B34D2B490AB73206B93254@xmb-rtp-20e.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OPSEC] draft-ietf-opsec-blackhole-urpf-00
Thread-Index: Acl7fci3riQSCU4XTd2nIH2FNRMTKQApZqXwAAJ0YeA=
References: <E3B4452D-A984-439F-9069-7E43F51E3F42@kumari.net><19805DE9-0FB7-46C6-8984-DD82A6BB11E4@cisco.com> <A759481225F9064586B34D2B490AB73206B93254@xmb-rtp-20e.amer.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 01:03:45.0360 (UTC) FILETIME=[466B9D00:01C97C2D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3281; t=1232586225; x=1233450225; c=relaxed/simple; s=rtpdkim1001; 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=c6gjqk1Q1ssi9vttJbwC5XLI+ywYoQvn7kNmz55grLY=; b=O1Nt/KALwdAc5Z/vqFpiFf+FtAaGulnQRFaNrX51ba2BTV3iNDExSJdqIv n3nDv4P9HAvMZkLs73SLx4rD76ef/hrq5NhxdFdPacAfGqnsAfwwQ2U+Czjd ldDJFyR3Qk;
Authentication-Results: rtp-dkim-1; header.From=rymcdowe@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 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 Doah...

s/I think a standard/I don't think a standard/ 


----------------------------
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 Ryan Mcdowell (rymcdowe)
Sent: Wednesday, January 21, 2009 7:06 PM
To: Roland Dobbins (rdobbins); opsec wg mailing list
Subject: Re: [OPSEC] draft-ietf-opsec-blackhole-urpf-00

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
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

v2.23.0 | Report a Bug | By Email