IETF Logo Mail Archive

Re: [sidr] RPKI-RTR implementation clues

"Borchert, Oliver (Fed)" <oliver.borchert@nist.gov> Wed, 27 September 2017 16:09 UTC

Return-Path: <oliver.borchert@nist.gov>
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 9710D134D7C for <sidr@ietfa.amsl.com>; Wed, 27 Sep 2017 09:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EhjV5XR957Y for <sidr@ietfa.amsl.com>; Wed, 27 Sep 2017 09:09:14 -0700 (PDT)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0126.outbound.protection.outlook.com [23.103.200.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE854134DA1 for <sidr@ietf.org>; Wed, 27 Sep 2017 09:09:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=coqfrIMaKfPsvDjT1RgCxPrv48DDwMv7fOyH4y2xFyM=; b=J7WpMpU0/eRqhT/BqOhB7AOYD81U6eXUQ4huxgI8SfvrFRhi+q2G3zjesZ92y3UcqZLsNZUVmQ2c/x2Uht7ZSPAtzrxT/smdHnOJpfLfznBop84s7RpJ1v7nkhwsM/8gWuHGkyvLEl/oZanBZksIrti1ulcMA0qKvfqqEPkQqrA=
Received: from CY4PR09MB1205.namprd09.prod.outlook.com (10.172.65.147) by CY4PR09MB1207.namprd09.prod.outlook.com (10.172.65.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 27 Sep 2017 16:09:12 +0000
Received: from CY4PR09MB1205.namprd09.prod.outlook.com ([10.172.65.147]) by CY4PR09MB1205.namprd09.prod.outlook.com ([10.172.65.147]) with mapi id 15.20.0077.011; Wed, 27 Sep 2017 16:09:12 +0000
From: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
To: Ruediger Volk <rv@NIC.DTAG.DE>, Denis Fondras <ietf@ledeuns.net>
CC: "rv@limes.NIC.DTAG.DE" <rv@limes.NIC.DTAG.DE>, "sidr@ietf.org" <sidr@ietf.org>
Thread-Topic: [sidr] RPKI-RTR implementation clues
Thread-Index: AQHTN3aUU5hTijjwikWXkBnNlrj6x6LI4QWw
Date: Wed, 27 Sep 2017 16:09:12 +0000
Message-ID: <CY4PR09MB12059A29EB15E8C91032B9C498780@CY4PR09MB1205.namprd09.prod.outlook.com>
References: Your message of "Wed, 27 Sep 2017 11:18:05 +0200." <20170927091805.GH41648@carcass.ledeuns.net> <2061.1506506056@x59.NIC.DTAG.DE>
In-Reply-To: <2061.1506506056@x59.NIC.DTAG.DE>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov;
x-originating-ip: [129.6.140.119]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1207; 6:JE211Ey/3E3B8nKjVcTm2nDsP9k9FC/YQqpVn9XMuYXhGw1FdFfFeZE+Jnr8I+LK4Ivotfz1NYRMiUbWLF8GSMfc0qapmqIqJ9pjOGZS+SkzC/sJ8/wBIpkgeKGC2f4bH5amdoXzQRdncWJl1pa62uhGYfv+kgkUX6Y0PI9K6VFIWQdqkhnTdJlNi0TjBlrpmR1E9xCryD+Wr6n7rVeHklqml1GKmxTaH20fGxfZEmP26TJAo4zxOxdNWYcL+Dswc2bRcLSKKy9USdTFuuP8mqcivMQceTaFhpOre0cwblYZ/we43epxZ1s1ispHJsdft687e+mNU7RNlUMxinMOuA==; 5:sTIga09Xf4+BG6sW5dewCPP06k6ENz8Jm14/C0dKHj7v6H3ilf2G+Y2Zhb+CAX6HtqLKPJRpwQiCEDg4//v1nOQy71mZUhfp+gXFSx+yq43B02vpqMdeNqXytFyuMOzu9tMfi7xqpm/v+S0vudmX9w==; 24:Kqb7/BUnuJcfS7GI1VSUFjaPTrHTfdgdCjlP1QILGzXt8cSa4m6hlnAgO4BookCXCqeOxqrINT+6UOIWIJbpFRgLxKjP/ZO/yXTxeHU16Ws=; 7:RX83IgjRcH0KDDyVLOqkvlk7cGoAhHxH/PJ6w6f+qJxbyRE89FSf7XHe6ap4tCokEvdoUl1f7dURf7DdaY+k89sbScaycJaeZKxNnKyJtUfqiKYioogr8rAmxBE9ZnVDXon2uH0Jsd2Vz9vSoE9rTQIuhz6am0ReWI8huZPdgJbGoZHCqe7QauY+3RJx9zsUFyN+Vv7NJJHt7Jbj1DDpnAPrskT8UB+ZRBFHBDNEH1U=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 02d49a09-0e71-46a3-4c0c-08d505c2180b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR09MB1207;
x-ms-traffictypediagnostic: CY4PR09MB1207:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: <CY4PR09MB120757DB8D520D15AE9B509398780@CY4PR09MB1207.namprd09.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1207; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1207;
x-forefront-prvs: 04433051BF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(199003)(377454003)(504964003)(189002)(13464003)(54906003)(53936002)(74316002)(50986999)(9686003)(316002)(97736004)(8936002)(229853002)(110136005)(77096006)(3660700001)(101416001)(7696004)(25786009)(33656002)(478600001)(2906002)(4326008)(66066001)(99286003)(6246003)(6116002)(81166006)(86362001)(7736002)(3846002)(305945005)(6506006)(55016002)(53546010)(8676002)(76176999)(2900100001)(6436002)(5660300001)(102836003)(966005)(68736007)(6306002)(3280700002)(54356999)(105586002)(189998001)(81156014)(2950100002)(106356001)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1207; H:CY4PR09MB1205.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2017 16:09:12.6418 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1207
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/axeWgDGFTJfzbOokASp9eORagnc>
Subject: Re: [sidr] RPKI-RTR implementation clues
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 27 Sep 2017 16:09:17 -0000

Hi Dennis,

The issue is not only with new BGP updates you receive during the cache update, the issue is also how to treat already received updates.
The safest is to operate with the RPKI state known prior the start of a cache update. Once the cache is updated, re-evaluate all 
BGP updates you know already using the new RPKI information.

Oliver

-----Original Message-----
From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Ruediger Volk
Sent: Wednesday, September 27, 2017 5:54 AM
To: Denis Fondras <ietf@ledeuns.net>
Cc: rv@limes.NIC.DTAG.DE; sidr@ietf.org
Subject: Re: [sidr] RPKI-RTR implementation clues

Hi Denis,
  > Hi,
  >
  > I'm in the process of adding RPKI-RTR (RFC6810) support to OpenBGPd and I am
  > wondering about how others have implemented it.
great to hear about implementation efforts for another (nice) BGP implementation.

  > - How is the process started ?
  > Currently, when I start bgpd, it will fetch a list of VRP from the cache
  > and at the same time get prefixes from its peers.  As soon as it gets
  > a VRP, it will
  > try to validate prefixes in the RIB. The goal is to get a state as sooner as
  > possible to apply filters if needed.
  > The problem is I can have an unknown state in the case a prefix tries to get
  > validated while the VRP list is not complete. The solution is to make anoth er
  > round of validation when I get a complete VRP list.
  > Do you wait until you get a complete VRP list (ENDOFDATA message) before
  > starting the validation process ?
it is a bad idea to do origin validation based on incomplete cache state.
For example consider that a more specific (e.g. beef:dead::/32) will be classified INVALID if there is a matching ROA but only a covering but NOT matching aggregate ROA (e.g. beef::/16-16) is available before the more specific VRP.

  > - How are subsequent validation handled ?
  > Do you start the validation process as soon as you get a new VRP or do you wait
  > for a refresh timer ? In the former, a prefix could stay in the wrong state  for
  > some time. I am assuming that every new prefix is validated as it arrives.
Lazy origin validation classification is allowed (but it implies that besides unknown/valid/invalid you should support a 4th class of "unclassified"
is needed). It's great if recceived announcements are immediately classified
- but that can only be done correctly against a complete cache state.

  > Thank you in advance,
  > Denis
  >
  > _______________________________________________
  > sidr mailing list
  > sidr@ietf.org
  > https://www.ietf.org/mailman/listinfo/sidr

Ruediger Volk

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

v2.23.0 | Report a Bug | By Email