Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt

George Michaelson <ggm@apnic.net> Thu, 27 November 2008 00:18 UTC

Return-Path: <sidr-bounces@ietf.org>
X-Original-To: sidr-archive@megatron.ietf.org
Delivered-To: ietfarch-sidr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA453A6C96; Wed, 26 Nov 2008 16:18:01 -0800 (PST)
X-Original-To: sidr@core3.amsl.com
Delivered-To: sidr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38713A6C96 for <sidr@core3.amsl.com>; Wed, 26 Nov 2008 16:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 QRByXmSrMxJe for <sidr@core3.amsl.com>; Wed, 26 Nov 2008 16:18:00 -0800 (PST)
Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id A06683A6C90 for <sidr@ietf.org>; Wed, 26 Nov 2008 16:17:59 -0800 (PST)
Received: from dhcp151.apnic.net (dhcp151.apnic.net [202.12.29.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4B301110068 for <sidr@ietf.org>; Thu, 27 Nov 2008 10:17:56 +1000 (EST)
Message-Id: <02154410-86D5-47E1-9EED-491D7FD55346@apnic.net>
From: George Michaelson <ggm@apnic.net>
To: sidr@ietf.org
In-Reply-To: <492CF285.6090900@psg.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 27 Nov 2008 10:17:56 +1000
References: <C5521DCD.5484%andy@arin.net> <492CCB80.2030501@psg.com> <EED84F5B-FA73-48BC-8BA5-42C0F53051BB@apnic.net> <492CEC10.1070109@psg.com> <41F912C2-9F6E-4DD9-9D94-2359944DDA5F@apnic.net> <492CF285.6090900@psg.com>
X-Mailer: Apple Mail (2.929.2)
Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-01.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: sidr-bounces@ietf.org
Errors-To: sidr-bounces@ietf.org

On 26/11/2008, at 4:53 PM, Randy Bush wrote:

>> ie, if you dislike these words, please instead of just knocking down,
>> can you help construct?
>
> see wrestling with pigs.  and this is my last go on this for today.

I find this comment offensive, and if the intention was to belittle  
me, then it has certainly succeeded.


>
>> noting netmask, maxlen, which clearly removed the 'rigorous' -what  
>> else
>> is wrong with the text?
>
> it does not even say that if there is a roa specifying that A may
> announce P, that, in the absence of a roa saying that B may also
> announce P, an announcement of P by B should be rejected.

So, although previously you have said that you do not wish downstream  
players to be brought into this process involuntarily, and you have  
also stated that we should respect current ISP/Operator practice,  
which includes holders of aggregate/covering blocks announcing that  
block, but permitting specific prefixes to be multihomed and announced  
as more specifics, you now say that in this emerging reality, if a ROA  
exists for the superblock then a consequence is that *ALL*  
announcements for more specifics *MUST* be covered by a ROA, even  
during the partial deployment scenario.

IE you are now a 'maximalist' and believe that the act of a superior  
delegate LIR/ISP issuing a ROA requires all downstream participants  
with routing rights in that block, to become full-blown players in RPKI?

Can I just confirm that on-record Randy?

>
>
> it should. the owner stated their intent.  if they had intended B to
> announce, they could and should have said so.  they did not run out of
> ink or lack the pen.
>
> in fact, it strangely says the opposite,
>
> "While the presence of a valid ROA that matches the advertisement is a
> strong indication that an advertisement matches the authority provided
> by the prefix holder to advertise the prefix into the routing system,
> the absence of a ROA or the invalidity of a covering ROA does not
> provide a conclusive indication that the advertisement has been
> undertaken without the address holder's permission ..."
>
> to me that is a whole lot of broken words merely in order to justify  
> boas.

Randy, the text *I* posted to you, came from the ---> R.O.A. <---  
draft, which is authored by Steve Kent and others. It has *NO*  
reference to BOA, none at all.

If you wish to critique the formalisms over a ROA, the canonical text  
is in the ROA draft, and if you wish to discuss the ROA draft, and its  
definitional language, then I think you should discuss the ROA draft.

Not the BOA draft, which of course, is a different draft. Nor this  
draft you cite in fact.

What you quoted was the validation draft. This does not define the  
ROA. It is a draft where we discuss validation of routing, as it says  
in the title:

	Validation of Route Origination in BGP using the Resource Certificate  
PKI

-George

>
>
> randy

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