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

Matthias Waehlisch <waehlisch@ieee.org> Thu, 08 December 2011 04:36 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 4133211E80A2 for <sidr@ietfa.amsl.com>; Wed, 7 Dec 2011 20:36:25 -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 kPltmVVkF-54 for <sidr@ietfa.amsl.com>; Wed, 7 Dec 2011 20:36:24 -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 1B1A611E8099 for <sidr@ietf.org>; Wed, 7 Dec 2011 20:36:24 -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 1RYViY-0006Yy-H8; Thu, 08 Dec 2011 05:36:23 +0100
Date: Wed, 7 Dec 2011 22:36:20 -0600 (Mittelamerikanische Normalzeit)
From: Matthias Waehlisch <waehlisch@ieee.org>
To: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C49308EEE3BB2A@MBCLUSTER.xchange.nist.gov>
Message-ID: <Pine.WNT.4.64.1112072138260.8356@mw-PC>
References: <F88C726A-DB3E-452D-9906-67B84F9B19C8@ripe.net> <D7A0423E5E193F40BE6E94126930C49308EEE3BB2A@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 04:36:25 -0000

Hi Sriram,

  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?.

  If the super-block does not enclose the announced prefix but there is 
an incorrect origin AS, you cannot easily decide about the primary 
reason for the invalidation (i.e., whether the ROA has been created 
without considering sub-allocations or the origin AS has been announced 
by mistake).

  Anyhow, for the measurements we presented last IETF, 80% of the 
invalid announcements are due to invalid origin ASes. The remaining 20% 
are due to obvious MaxLength violation (i.e., same origin AS in BGP 
update and ROA, but longer prefix length in BGP update). Regarding the 
announcements with incorrect origin AS, for approx. 85% of these BGP 
updates there exists at least one ROA with a longer MaxLength value 
compared to the prefix length announced (i.e., the ROA encloses the 
incorrectly announced prefix). ... Maybe it makes sense to investigate 
this case in more detail. For example, looking if there is a direct 
peering between the ROA origin AS and the origin AS within the BGP 
update.



Thanks
  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

On Wed, 7 Dec 2011, Sriram, Kotikalapudi wrote:

> >By the latter group, 416 Route Origin Authorization (ROA) objects 
> >have been created, covering the equivalent of 230,000 /24 prefixes 
> >and 8,600 /32 IPv6 prefixes. MaxLength in ROAs is sorely 
> >misunderstood, lots of education is needed there. Most leave the 
> >field blank, causing more specific announcements to be invalid.
> 
> Alex,
> 
> Can you comment if (a) the more specifics are announced from the same AS as seen 
> in the ROA, or (b) they are announced from a different AS (e.g., customer AS)?
> If it is the latter, then even the ROA creation (for the less specific)
> is possibly in violation of: 
> "Before issuing a ROA for a super-block, an operator MUST ensure that
>    any sub-allocations from that block which are announced by other ASs,
>    e.g. customers, have correct ROAs in the RPKI." from the origin-ops doc. 
> http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-13#section-3 
> 
> As for education, the origin-ops document as well as the use-cases
> document (Sections 3, 7) 
> http://tools.ietf.org/html/draft-ietf-sidr-usecases-03 
> can be referred.
> 
> Sriram
> 
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>