Re: [sidr] route leaks message to IDR

Robert Raszuk <robert@raszuk.net> Mon, 19 March 2012 22:42 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1E521E8052 for <sidr@ietfa.amsl.com>; Mon, 19 Mar 2012 15:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level:
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWq4IDdt8kLn for <sidr@ietfa.amsl.com>; Mon, 19 Mar 2012 15:42:15 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 2738021E8051 for <sidr@ietf.org>; Mon, 19 Mar 2012 15:42:15 -0700 (PDT)
Received: (qmail 5834 invoked by uid 399); 19 Mar 2012 22:42:14 -0000
Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.28.249.1) by mail1310.opentransfer.com with ESMTPM; 19 Mar 2012 22:42:14 -0000
X-Originating-IP: 83.28.249.1
Message-ID: <4F67B647.10904@raszuk.net>
Date: Mon, 19 Mar 2012 23:42:15 +0100
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Brian Dickson <brian.peter.dickson@gmail.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6C75A0@Hermes.columbia.ads.sparta.com> <DCC302FAA9FE5F4BBA4DCAD465693779173BA12C3E@PRVPEXVS03.corp.twcable.com> <5E228600-8A59-40F0-BB4E-5FBAA50EF16E@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C7D36@Hermes.columbia.ads.sparta.com> <144F8BE8-2A9A-4967-AA7D-0702670BF820@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6C815F@Hermes.columbia.ads.sparta.com> <CAH1iCipxuXU2B17NjrdmOq6D_OhYq3PbE0EyArwJVNbC3FhG8Q@mail.gmail.com> <p06240802cb8ceb04d6ac@[192.168.1.5]>
In-Reply-To: <p06240802cb8ceb04d6ac@[192.168.1.5]>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] route leaks message to IDR
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2012 22:42:15 -0000

Hi Brian,

> The desired outcome is that sender/receiver _negotiate_ what is or is not to be sent,
> and the protocol merely enforces what has been agreed upon. The automatic enforcement
> of this high-level policy, is what stops route leaks from being initiated or propagated.
> The policy is still determined by the operators at both ends of a peering session.
> Just like the IP addresses and ASNs, the policies have to match for BGP session establishment.
> Unilateral misconfiguration (whether by accident or deliberate act), which could have introduced
> or propagated route leaks, are prevented.

I have read your drafts reg route leaks however I would like to clarify 
one very basic question.

When any provider creates a BGP peering relation to his customer it is a 
common best practice among most if not all ISPs that there is a strict 
BGP policy applied over the session to make sure only legitimate 
customer blocks are advertised.

If such policy would be required to be share one could use prefix ORF.

With this in mind I am really not clear what practical vs theoretical 
problems you are attempting to solve ?

Best regards,
R.