Re: [OPSEC] http://www.ietf.org/internet-drafts/draft-kumari-blackhole-urpf-00.txt

"Smith, Donald" <Donald.Smith@qwest.com> Thu, 11 September 2008 19:02 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 1F2D63A68B3; Thu, 11 Sep 2008 12:02:44 -0700 (PDT)
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 6C8BD3A6856 for <opsec@core3.amsl.com>; Thu, 11 Sep 2008 12:02:42 -0700 (PDT)
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 zpQznRKEtPxI for <opsec@core3.amsl.com>; Thu, 11 Sep 2008 12:02:38 -0700 (PDT)
Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id B4AAE28C102 for <opsec@ietf.org>; Thu, 11 Sep 2008 12:02:21 -0700 (PDT)
Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id m8BJ0tJA020700; Thu, 11 Sep 2008 13:00:56 -0600 (MDT)
Received: from ITDENE2KSM02.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.0/8.14.0) with ESMTP id m8BJ0jvc006426; Thu, 11 Sep 2008 14:00:50 -0500 (CDT)
Received: from ITDENE2KM02.AD.QINTRA.COM ([10.1.4.66]) by ITDENE2KSM02.AD.QINTRA.COM with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Sep 2008 13:00:48 -0600
X-MessageTextProcessor: DisclaimIt (2.70.270) [Qwest Communications International Inc.]
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 11 Sep 2008 13:00:16 -0600
Message-ID: <A15EF332BA1FE04888F87DFEC06629F005C34A9C@ITDENE2KM02.AD.QINTRA.COM>
In-Reply-To: <48C95C1A.4070408@bogus.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OPSEC]http://www.ietf.org/internet-drafts/draft-kumari-blackhole-urpf-00.txt
Importance: normal
Priority: normal
thread-index: AckUN/UIVXU2+cY3RrmwZtqLFtiJvAABf0Xg
References: <48C95C1A.4070408@bogus.com>
From: "Smith, Donald" <Donald.Smith@qwest.com>
To: Joel Jaeggli <joelja@bogus.com>, opsec wg mailing list <opsec@ietf.org>
X-OriginalArrivalTime: 11 Sep 2008 19:00:48.0820 (UTC) FILETIME=[B4104F40:01C91440]
Subject: Re: [OPSEC] http://www.ietf.org/internet-drafts/draft-kumari-blackhole-urpf-00.txt
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

First let me say this is valuable work and it is well done.
It should be accepted as a WG document.



It suffers from inconsistent use of the following teams which appear to
mean the same thing I recommend Remote Triggered Black Hole filtering
but which ever term is used should be used consistently.

Triggered black-hole routing, Remote triggered black hole routing and
RTBH filtering.


If "As a matter of policy, operators SHOULD NOT accept source-based RTBH
announcements from their peers or customers" then why bother asking for
a registered community from IANA?

The cisco and juniper examples only covers destination based RTBH
filtering no urpf statements are included and therefore source based
RTBH is not provided by the example configs. That may have been the
intention of the authors but it wasn't what I expected.

Does this imply that strict mode urpf can't be used for source based
RTBH?

"In loose mode some vendors also verify that the destination route
   does not point to a discard interface."
If so going from strict mode to loose to support source based RTBH has
some serious security implications.

Security through obscurity WORKS against some worms and ssh attacks:)
Donald.Smith@qwest.com giac 

> -----Original Message-----
> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] 
> On Behalf Of Joel Jaeggli
> Sent: Thursday, September 11, 2008 11:58 AM
> To: opsec wg mailing list
> Subject: 
> [OPSEC]http://www.ietf.org/internet-drafts/draft-kumari-blackh
> ole-urpf-00.txt
> 
> Was one of the upcoming documents mentioned in the dublin meeting.
> 
> this document expands on the method in RFC3882 and I think much more
> accurately represents current operational practice.
> 
> some review on it's current form and consensus as to whether we should
> accept it as a working group document would be appreciated.
> 
> Thanks
> joelja
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
> 


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec