Re: [sidr] A quick note from RPKI in the wild

Matthias Waehlisch <waehlisch@ieee.org> Thu, 08 December 2011 17:11 UTC

Return-Path: <waehlisch@ieee.org>
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 8133221F8A7B for <sidr@ietfa.amsl.com>; Thu, 8 Dec 2011 09:11:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 qBMGJmKnhIn3 for <sidr@ietfa.amsl.com>; Thu, 8 Dec 2011 09:11:00 -0800 (PST)
Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id D990D21F85CE for <sidr@ietf.org>; Thu, 8 Dec 2011 09:10:59 -0800 (PST)
Envelope-to: sidr@ietf.org
Received: from 75-148-178-225-houston.hfc.comcastbusiness.net ([75.148.178.225] helo=mw-PC.globalsuite.net) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from <waehlisch@ieee.org>) id 1RYhUP-0005W8-ND; Thu, 08 Dec 2011 18:10:34 +0100
Date: Thu, 08 Dec 2011 11:10:32 -0600
From: Matthias Waehlisch <waehlisch@ieee.org>
To: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C49308EE1E84C1@MBCLUSTER.xchange.nist.gov>
Message-ID: <Pine.WNT.4.64.1112080951080.8356@mw-PC>
References: <F88C726A-DB3E-452D-9906-67B84F9B19C8@ripe.net> <D7A0423E5E193F40BE6E94126930C49308EEE3BB2A@MBCLUSTER.xchange.nist.gov>, <Pine.WNT.4.64.1112072138260.8356@mw-PC> <D7A0423E5E193F40BE6E94126930C49308EE1E84C1@MBCLUSTER.xchange.nist.gov>
X-X-Sender: mw@mail2.rz.fhtw-berlin.de
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de)
X-HTW-DELIVERED-TO: sidr@ietf.org
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] A quick note from RPKI in the wild
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Thu, 08 Dec 2011 17:11:05 -0000

Hi Sriram,

On Thu, 8 Dec 2011, Sriram, Kotikalapudi wrote:

>  >I'm not sure if I understand your quote correctly: Do you only
> consider the case where the super-block encloses the sub-allocations
> (e.g., x.y.0.0/16-32 and x.y.z.0/24)? In this case, that would be no
> MaxLength violation, right?.
> 
> KS: No. I am taking about something different.
> If ISP A (with AS A) creates a ROA for its super-block x.y.0.0/16
> and its Customer B (with AS B) has a sub-allocation x.y.z.0/24 and
> has NOT created a ROA yet, then the customer's announcement will be Invalid.
> The same effect happens whether ISP A's ROA is:
> {ROA: x.y.0.0/16, AS A} (w/o maxLength; defaulted to maxLength = 16)
> or, {ROA: x.y.0.0/16, AS A, maxLength = 24}
> or, {ROA: x.y.0.0/16, AS A, maxLength = 18}.
> With any of the above ROAs, Cust. B's announcement is Invalid
> because it doesn't have a ROA yet for its sub-allocation.
> 
  definitely agree.

> KS: The BCP I quoted from origin-ops requires that ISP A MUST
> register its ROA only after the customer sub-allocation ROAs
> have been created (or, register all necessary ROAs simultaneously).
> In the above example: ISP A can create a ROA for Customer B
> along with its own ROA as follows:
> {ROA: x.y.0.0/16, AS A} and {ROA: x.y.z.0/24, AS B}
> That ensures that Customer B is not in trouble.
> 
> This is the bottom up approach for ROA creation.
> Question is: Do the ISP's (or super-block owners) in your
> measurement data seem to be compliant with said BCP. 
> 
  My point was that it is not too easy to decide if the ISPs are 
compliant with the BCP. But I think I got your point: If the origin AS 
in the Update has (somehow) a *customer* relationship with the ROA AS it 
is more likely that the ISP's ROA creation is in violation of the BCP.

  In our last IETF presentation, we identified for the incorrect origin 
ASes that there exists a ROA Origin that is 1 hop away (ignoring 
prepending) from the announced origin AS in 90% of the cases. Coming 
back to your question: Yes, most of the announcements are invalid 
probably due to the violation of the BCP but I will try to verify in 
more detail.


Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net