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

Danny McPherson <danny@tcb.net> Mon, 01 December 2008 22:35 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 D81C728C11E; Mon, 1 Dec 2008 14:35:18 -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 45A4428C136 for <sidr@core3.amsl.com>; Mon, 1 Dec 2008 14:35:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.065
X-Spam-Level:
X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482]
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 X08KHFS8Loeb for <sidr@core3.amsl.com>; Mon, 1 Dec 2008 14:35:16 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 89DBD28C11E for <sidr@ietf.org>; Mon, 1 Dec 2008 14:35:16 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id 21785268766; Mon, 1 Dec 2008 15:35:13 -0700 (MST)
Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 01 Dec 2008 15:35:12 -0700 (MST) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=51110; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0
Message-Id: <B1CD0A34-FFCC-4F27-9AE7-34DE9E89176A@tcb.net>
From: Danny McPherson <danny@tcb.net>
To: sidr@ietf.org
In-Reply-To: <p06240500c559bde54579@[128.89.89.227]>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Mon, 01 Dec 2008 15:35:12 -0700
References: <C542C40B.5166%andy@arin.net> <A3751517-D15C-45DD-B530-027758F36B04@apnic.net> <FC10BBCC-6144-4420-ACFC-9454F26444BE@tcb.net> <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <C4A37FE7-88F1-4DEC-AB81-CC2EC6A96C79@tcb.net> <AF626DBA-482A-4985-B149-F34450D25805@apnic.net> <p06240500c559bde54579@[128.89.89.227]>
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"
Sender: sidr-bounces@ietf.org
Errors-To: sidr-bounces@ietf.org

BOA I-D authors,
Perhaps some of my confusion from this discussion stems from
the use of the term "bogon".  So, with that, I have two more
questions I'm hoping will help clarify the goals here for me.

1) Given the use of the term "bogon" within sidr today, it's
clearly much wider than the traditional "unallocated from
IANA or an RIR" AS number or prefix.  Exactly what is a "bogon"
in your mind, and shouldn't it be spelled out in the draft?
The use of the term "invalid" recurs throughout, but what
constitutes a bogon here appears to be well beyond today's
operational interpretation of such a term.  Projecting this
effort under the auspices of "bogons" as we know them today
seems a bit inadequate.

2) The BOA draft suggests that if a valid ROA exists for a
given prefix then a BOA should be disregarded.  Can you explain
to me where or why this apparent conflict would occur?

3) Also, I'm still not entirely up to speed here, but say, as
an ISP, I issue a ROA for a prefix I want to permit another
AS to originate.  IF a BOA exists for the AS originating the
route then according to the BOA draft "local policies" should
be enacted (e.g., drop the "route object").  However, if for
a prefix, then if a ROA exists it should essentially trump the
BOA.  Could you explain the logic behind this text?

Thanks!

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