From nobody Wed Sep 13 07:20:44 2017 Return-Path: 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 0A89A132F31; Wed, 13 Sep 2017 07:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 YVXA2cFH2G92; Wed, 13 Sep 2017 07:20:29 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62AB51321A0; Wed, 13 Sep 2017 07:20:29 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ds8Wc-000Age-79; Wed, 13 Sep 2017 16:20:24 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-115.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ds8Wc-0002wh-2u; Wed, 13 Sep 2017 16:20:22 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 16:20:21 +0200 Cc: The IESG , Chris Morrow , sidr chairs , draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719e826c1347a9c9e6f41cb806eb3450c0f Archived-At: Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 14:20:32 -0000 Hi, My apologies for the delay - I am just back from a late summer holiday. Let me address the DISCUSS is in this, and Terry Manderson=E2=80=99s = email, first. > On 29 Aug 2017, at 04:36, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconside= red/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is probably just a matter of me being dense, but I'd like to = understand > what I am missing: >=20 > Is it legal to mix certificate policies in a given cert path? The last > paragraph of section 5 implies that you can, but doesn't say so = explicitly. If > you _can_ mix policies, what happens if you do? If I read the rules in = 4.2.4.4. > correctly (and it's likely that I am not), if you run into a cert in = the chain > that does not follow this profile, it's likely to give a null VRS-IP = or VRS-AS > value, which would seem to invalidate an certificate further down the = chain > that _does_ follow this policy? >=20 > So, I guess it comes down to the following: If mixed policies are = allowed, how > does that work? If mixed policies are not allowed, there needs to be = text that > says that. It's quite possible such text exists (here or elsewhere), = and I > missed it. >=20 First of all it was my understanding that there was an agreement with = the AD that actual deployment should be discussed in sidrops. So this = document serves as a benchmark to describe the alternative algorithm. In = my opinion a mix is supported by this document, but the choice whether = this is an acceptable deployment model can be discussed later. The current document leaves the OID as a per certificate choice and = 4.2.2.4 provides a validation model that can be used in either case. In = either case the VRS-IP/AS are calculated as described in item #7. Under = item #8, the VRS-IP/AS is then compared again to the certificate to = determine if it was =E2=80=98over-claiming=E2=80=99 compared to its = acceptable VRS-IP/AS set. The OID choice determines whether this results = in a warning about such over claiming resources, or rejecting. The = algorithm defined here when only old OIDs are used is semantically = equivalent to section 7.2 of RFC6847. Note that item #7 does not have explicit text on the case where = =E2=80=98inherit=E2=80=99 is used, but I believe that this is = technically covered by the text in sections 2.2.3.5 and 3.2.3.3 of = RFC3779. Essentially: the value of the signing certificate applies, use = recursion if that also uses inherit. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Substantive: >=20 > - General: There's a lot of amending going on here--does this draft = really not > update any RFCs (e.g. 6487)? >=20 > - 4.2.4.4: > -- "Any extension not thus identified MUST NOT appear in > certificate x." (Repeats multiple times) > That seems to prevent future extensibility. Is that the intent? >=20 > -- "Certificate x MUST NOT have been revoked, i.e., it MUST NOT > appear on a CRL issued by the CA represented by certificate x-1" > Is this intended as a requirement to check CRLs? If so, please say = that > explicitly. >=20 > Editorial: >=20 > -4.2.2.1: The third paragraph seems redundant to the first paragraph = (pattern > repeats in several sections.)he >=20 > - 4.2.4.3: "Either the IP Resources extension, or the AS Resources = extension, or > both, MUST be present in all RPKI certificates, and if present, MUST > be marked critical." > "... and if present..." seems redundant, since the previous clause = said one > MUST be present. >=20 > - 4.3.4.3: "... values are NOT supported..." > a floating, capitalized "NOT" is not defined in RFC 2119. I suspect = the > all-caps is just for emphasis, but we typically reserve that for RFC = 2119 > keywords. >=20 > - 4.2.4.4 : > -- "Certificate validation requires verifying that all of the = following > conditions hold, in addition to the certification path validation > criteria specified in Section 6 of [RFC5280]." >=20 > The "... in addition to..." part doesn't seem quite true. For example, = making > sure the current date fits in the active range, ensuring a cert is = signed by > the issuer, etc. are already covered in 5280. >=20 > - - "...certificate MUST contain all > extensions defined in section 4.8 of [RFC6487] that must be > present." > That seems tautologically true. If this is a statement of fact, then = please > avoid the MUST. If this is really a new normative requirement, then = I'm > confused at the intent. >=20 > -- "all extensions defined in section 4.8 of > [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be > present. " > It would be more reader-friendly to mention what extensions are = defined in > 4.8.9. >=20 > -- "7. Compute the VRS-IP and VRS-AS set values as indicated below:" > Inconsistent voice. >=20 > -- list entry 7, 4th bullet: "If the IP Address Delegation extension = is present > in > certificate x and x=3D1, set the VRS-IP to the resources = found > in this extension." > That seems identical to the first bullet. Should it has said "AS = Address > Delegation extension"? >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From nobody Wed Sep 13 07:29:54 2017 Return-Path: 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 15E87133039; Wed, 13 Sep 2017 07:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pxa7e6E5oJ4V; Wed, 13 Sep 2017 07:29:43 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C7E124239; Wed, 13 Sep 2017 07:29:43 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ds8fa-000B4D-RZ; Wed, 13 Sep 2017 16:29:40 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-115.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ds8fa-0004IQ-Nt; Wed, 13 Sep 2017 16:29:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: <150415018168.16876.13029068813873198020.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 16:29:38 +0200 Cc: The IESG , draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow , sidr-chairs@ietf.org, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <03BD2F5A-C67F-4030-8139-B30AB3BFD6A2@ripe.net> References: <150415018168.16876.13029068813873198020.idtracker@ietfa.amsl.com> To: Terry Manderson X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719b17f30877c0a7e092e10f4f7a8503b39 Archived-At: Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 14:29:45 -0000 Hi, My apologies for the delay - I am just back from a late summer holiday. > On 31 Aug 2017, at 05:29, Terry Manderson = wrote: >=20 > Terry Manderson has entered the following ballot position for > draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconside= red/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thank you for considering the stability of the internet's routing = system during > administrative changes to resources. >=20 > One thing isn't quite clear to me, so I'm balloting this as a DISCUSS = with the > plan that a small amount discussion will resolve it. >=20 > With the definition of the new validation OID (a idea that I like = BTW), at any > stage of the certificate issuance can the validation OID be switched? = That is a > TA has a particular OID and down the tree an issued certificate has a = different > OID? If that can't happen (and please make that clear in the document) = is there > plan to migrate the set of all issued certificates to the new OID? and > deprecate the old OID? As mentioned in the response to Ben Campbell=E2=80=99s discuss, this is = theoretically possible. It was agreed, in my understanding, that deployment would be discussed = in sidrops separate from this document, and the choice whether a mix OID = deployment is acceptable should be addressed in that discussion. >=20 > Logically speaking a trust anchor cannot be thought of as = over-claiming. (eg > you trust where the self signed cert came from, and its contents) = However the > new validation constructs suggest that a TA can over-claim, but it = seems like > there won't be any warning (as the example in S4.3) to highlight this = possible > eventuality when (in the model where all RIRs issue a TA) a resource = is > transferred from one RIR to another for the clients use. Is that = interpretation > correct? OR does this new model espouse the belief that all RIRs each = issue a > TA that covers 0/0 and ::/0 in perpetuity? In that construct does this = mean > that RFC6491 should be updated or made historic? No, the first bullet point under item #7 in section 4.2.2.4 covers TA = certificate. If =E2=80=98x=3D1=E2=80=99, this is the first certificate = in the tree and its resources are accepted as they appear. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I get the sense that many of the ramifications for this validation = change are > yet to be discovered. It worries me that from the shepherd writeup = "The > existing CA/RP code implementations will support this once published." = What > experiments have been done to identify any gaps and assumptions? The RIPE NCC RPKI Validator has supported this algorithm since version = 2.17 - 3 July 2014 - as a global configuration setting. In our case the code changes for this were trivial - in supporting the = =E2=80=98inherit=E2=80=99 case we were already keeping track of = resources per certificate in the tree - adding logic to accept the = intersection of resources and warn for over-claims instead of reject was = therefore very simple. Changing the behaviour to look at the OID of the = certificate under inspection instead will be trivial. The difficulty is = in accepting the new OIDs in the first place - again trivial from the = code perspective but from a deployment perspective demands that users = upgrade their software after we release a version with support for it. >=20 >=20 >=20 From nobody Wed Sep 13 08:57:58 2017 Return-Path: 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 1E161132949; Wed, 13 Sep 2017 08:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Z2BhnA-hsdiV; Wed, 13 Sep 2017 08:57:48 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65AE1132D3F; Wed, 13 Sep 2017 08:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3166; q=dns/txt; s=iport; t=1505318267; x=1506527867; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sXK8wVVP/99+kK9E3/CcCeB1NW6jefJCF1fF02Z8oJk=; b=CbWi6IHB8oV6caJgey6SxDyrNpS5WiSaRHkoOjlu9eh4geHmjwSUqud8 it0jrhp9aHM05QrTMBo57Dwi4Uj9u6xsSTiOOHF7KJQ2zUaLtBbe3W+U6 ve4KWF6Cn1gOektIcEGifsaqB5ZIF0uVwhw0NsDJXh4EUgEgP88YaBa4Z I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgB0VLlZ/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBeQeDcJpGgVKWSoISCoU+AhqEO0EWAQIBAQEBAQEBayiFGQY?= =?us-ascii?q?jEUUQAgEIGgIfBwICAjAVEAIEAQ0FijGtOoIniywBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEdgQ6CHYICgVCCDguCcoR4gxMwgjEBBIoGjjGIQgKUUYITiWaGe5UDAhE?= =?us-ascii?q?ZAYE4ASYCL4ENdxVcAYUGHBmBTnaJICuBBYEPAQEB?= X-IronPort-AV: E=Sophos;i="5.42,388,1500940800"; d="scan'208";a="294943410" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2017 15:57:46 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v8DFvkbg025071 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Sep 2017 15:57:46 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 13 Sep 2017 10:57:45 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1263.000; Wed, 13 Sep 2017 10:57:45 -0500 From: "Alvaro Retana (aretana)" To: Tim Bruijnzeels , Ben Campbell , "Terry Manderson" CC: Chris Morrow , sidr chairs , "sidr@ietf.org" , The IESG , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" Thread-Topic: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) Thread-Index: AQHTLJt75GQp8nYBi0GeTHtaF/g3J6KzCaCA Date: Wed, 13 Sep 2017 15:57:45 +0000 Message-ID: <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> In-Reply-To: <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:57:50 -0000 W0V4cGxpY2l0bHkgYWRkaW5nIFRlcnJ54oCmXQ0KDQpUaW06DQoNCkhpIQ0KDQpBcyBJIHRoaW5r IHlvdSB1bmRlcnN0YW5kIGZyb20gdGhlIHJlc3BvbnNlIGJlbG93LCB0aGVyZSBhcmUgdHdvIHBh cnRzIHRvIGNvbnNpZGVyIHdoZW4gZGVwbG95aW5nOiB3aGF0IGNhbiBiZSBkb25lLCBhbmQgd2hh dCB3aWxsIGJlIGRvbmUuICBJbnRlcnByZXRpbmcgd2hhdCBCZW4gYW5kIFRlcnJ5IHdyb3Rl4oCm d2hhdCBJIHRoaW5rIHRoZXkgYXJlIGFza2luZyBpcyBmb3IgeW91IHRvIGNsYXJpZnkgaW4gdGhp cyBkb2N1bWVudCB0aGUgY29uc2lkZXJhdGlvbnMgYXJvdW5kIG1peGluZyBwb2xpY2llcy4gIEZv ciBleGFtcGxlICh0byBib3Jyb3cgZnJvbSBUZXJyeSksIGlmIGEg4oCcVEEgaGFzIGEgcGFydGlj dWxhciBPSUQgYW5kIGRvd24gdGhlIHRyZWUgYW4gaXNzdWVkIGNlcnRpZmljYXRlIGhhcyBhIGRp ZmZlcmVudCBPSUTigJ0sIHdoYXQgYXJlIHRoZSBpbXBsaWNhdGlvbnMvcHJvYmxlbXMvZXRjLj8N Cg0KTm90ZSB0aGF0IHRoaXMgcXVlc3Rpb24gaXMgZGlmZmVyZW50IGZyb20gdGhlIGRvY3VtZW50 IGRlZmluaW5nIGhvdyB0aGluZ3MgbWF5IGVuZCB1cCBiZWluZyBkZXBsb3llZCBsYXRlciAo4oCc d2hldGhlciB0aGlzIGlzIGFuIGFjY2VwdGFibGUgZGVwbG95bWVudCBtb2RlbOKAnSkuICBUaGUg YWN0dWFsIGRlcGxveW1lbnQgZGlzY3Vzc2lvbnMgKGFzIGluLCB0aGlzIGlzIHdoYXQgd2XigJly ZSBnb2luZyB0byBkbyBhbmQgd2hlbikgc2hvdWxkIGhhcHBlbiBpbiBzaWRyb3BzLg0KDQpUaGFu a3MhDQoNCkFsdmFyby4NCg0KDQpPbiA5LzEzLzE3LCAxMDoyMCBBTSwgInNpZHIgb24gYmVoYWxm IG9mIFRpbSBCcnVpam56ZWVscyIgPHNpZHItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg dGltQHJpcGUubmV0PiB3cm90ZToNCg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5ESVNDVVNTOg0KPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj5UaGlzIGlzIHByb2JhYmx5IGp1c3QgYSBtYXR0ZXIgb2YgbWUgYmVpbmcgZGVu c2UsIGJ1dCBJJ2QgbGlrZSB0byB1bmRlcnN0YW5kDQo+d2hhdCBJIGFtIG1pc3Npbmc6DQo+SXMg aXQgbGVnYWwgdG8gbWl4IGNlcnRpZmljYXRlIHBvbGljaWVzIGluIGEgZ2l2ZW4gY2VydCBwYXRo PyBUaGUgbGFzdA0KPnBhcmFncmFwaCBvZiBzZWN0aW9uIDUgaW1wbGllcyB0aGF0IHlvdSBjYW4s IGJ1dCBkb2Vzbid0IHNheSBzbyBleHBsaWNpdGx5LiBJZg0KPnlvdSBfY2FuXyBtaXggcG9saWNp ZXMsIHdoYXQgaGFwcGVucyBpZiB5b3UgZG8/IElmIEkgcmVhZCB0aGUgcnVsZXMgaW4gNC4yLjQu NC4NCj5jb3JyZWN0bHkgKGFuZCBpdCdzIGxpa2VseSB0aGF0IEkgYW0gbm90KSwgaWYgeW91IHJ1 biBpbnRvIGEgY2VydCBpbiB0aGUgY2hhaW4NCj50aGF0IGRvZXMgbm90IGZvbGxvdyB0aGlzIHBy b2ZpbGUsIGl0J3MgbGlrZWx5IHRvIGdpdmUgYSBudWxsIFZSUy1JUCBvciBWUlMtQVMNCj52YWx1 ZSwgd2hpY2ggd291bGQgc2VlbSB0byBpbnZhbGlkYXRlIGFuIGNlcnRpZmljYXRlIGZ1cnRoZXIg ZG93biB0aGUgY2hhaW4NCj50aGF0IF9kb2VzXyBmb2xsb3cgdGhpcyBwb2xpY3k/DQo+U28sIEkg Z3Vlc3MgaXQgY29tZXMgZG93biB0byB0aGUgZm9sbG93aW5nOiBJZiBtaXhlZCBwb2xpY2llcyBh cmUgYWxsb3dlZCwgaG93DQo+ZG9lcyB0aGF0IHdvcms/IElmIG1peGVkIHBvbGljaWVzIGFyZSBu b3QgYWxsb3dlZCwgdGhlcmUgbmVlZHMgdG8gYmUgdGV4dCB0aGF0DQo+c2F5cyB0aGF0LiBJdCdz IHF1aXRlIHBvc3NpYmxlIHN1Y2ggdGV4dCBleGlzdHMgKGhlcmUgb3IgZWxzZXdoZXJlKSwgYW5k IEkNCj5taXNzZWQgaXQuDQoNCkZpcnN0IG9mIGFsbCBpdCB3YXMgbXkgdW5kZXJzdGFuZGluZyB0 aGF0IHRoZXJlIHdhcyBhbiBhZ3JlZW1lbnQgd2l0aCB0aGUgQUQgdGhhdCBhY3R1YWwgZGVwbG95 bWVudCBzaG91bGQgYmUgZGlzY3Vzc2VkIGluIHNpZHJvcHMuIFNvIHRoaXMgZG9jdW1lbnQgc2Vy dmVzIGFzIGEgYmVuY2htYXJrIHRvIGRlc2NyaWJlIHRoZSBhbHRlcm5hdGl2ZSBhbGdvcml0aG0u IEluIG15IG9waW5pb24gYSBtaXggaXMgc3VwcG9ydGVkIGJ5IHRoaXMgZG9jdW1lbnQsIGJ1dCB0 aGUgY2hvaWNlIHdoZXRoZXIgdGhpcyBpcyBhbiBhY2NlcHRhYmxlIGRlcGxveW1lbnQgbW9kZWwg Y2FuIGJlIGRpc2N1c3NlZCBsYXRlci4NCg0KDQoNCg== From nobody Wed Sep 13 14:19:03 2017 Return-Path: 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 8935A132F2A; Wed, 13 Sep 2017 14:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4HwQ40AYsu6L; Wed, 13 Sep 2017 14:18:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF9813293A; Wed, 13 Sep 2017 14:18:53 -0700 (PDT) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8DLIQSZ075788 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Sep 2017 16:18:26 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_145F40C7-405D-43B0-A65D-A511E92225FC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Sep 2017 16:18:24 -0500 In-Reply-To: <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> Cc: Tim Bruijnzeels , Terry Manderson , Chris Morrow , sidr chairs , "sidr@ietf.org" , The IESG , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" To: "Alvaro Retana (aretana)" References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 21:18:56 -0000 --Apple-Mail=_145F40C7-405D-43B0-A65D-A511E92225FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alvaro=E2=80=99s interpretation is indeed what I meant. My concern is = with what works and what doesn=E2=80=99t work with the basic mechanism. = How it will get used in practice is a related, but different, issue. Thanks! Ben. > On Sep 13, 2017, at 10:57 AM, Alvaro Retana (aretana) = wrote: >=20 > [Explicitly adding Terry=E2=80=A6] >=20 > Tim: >=20 > Hi! >=20 > As I think you understand from the response below, there are two parts = to consider when deploying: what can be done, and what will be done. = Interpreting what Ben and Terry wrote=E2=80=A6what I think they are = asking is for you to clarify in this document the considerations around = mixing policies. For example (to borrow from Terry), if a =E2=80=9CTA = has a particular OID and down the tree an issued certificate has a = different OID=E2=80=9D, what are the implications/problems/etc.? >=20 > Note that this question is different from the document defining how = things may end up being deployed later (=E2=80=9Cwhether this is an = acceptable deployment model=E2=80=9D). The actual deployment = discussions (as in, this is what we=E2=80=99re going to do and when) = should happen in sidrops. >=20 > Thanks! >=20 > Alvaro. >=20 >=20 > On 9/13/17, 10:20 AM, "sidr on behalf of Tim Bruijnzeels" = wrote: >=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >> This is probably just a matter of me being dense, but I'd like to = understand >> what I am missing: >> Is it legal to mix certificate policies in a given cert path? The = last >> paragraph of section 5 implies that you can, but doesn't say so = explicitly. If >> you _can_ mix policies, what happens if you do? If I read the rules = in 4.2.4.4. >> correctly (and it's likely that I am not), if you run into a cert in = the chain >> that does not follow this profile, it's likely to give a null VRS-IP = or VRS-AS >> value, which would seem to invalidate an certificate further down the = chain >> that _does_ follow this policy? >> So, I guess it comes down to the following: If mixed policies are = allowed, how >> does that work? If mixed policies are not allowed, there needs to be = text that >> says that. It's quite possible such text exists (here or elsewhere), = and I >> missed it. >=20 > First of all it was my understanding that there was an agreement with = the AD that actual deployment should be discussed in sidrops. So this = document serves as a benchmark to describe the alternative algorithm. In = my opinion a mix is supported by this document, but the choice whether = this is an acceptable deployment model can be discussed later. >=20 >=20 >=20 --Apple-Mail=_145F40C7-405D-43B0-A65D-A511E92225FC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZuaChAAoJEIBWSmyV89QNcc4QAMal7q/OEwpkPhoDAFoRA0NV kI6ezI68vjyySFtOCJekU11NgJwhaZe+ogsyO2eCF/Id+9N0ZX+Qy51Nv1DU2vNu JasqY6o17s+q7uLGqfBMvknzzTHYRfQ4PsJZc0ODXytbUsvAI7EHriLTAI4ZAeFU +6R8h2Cgg/gbP5skzQVMKwvHEO11Ag+39lOGScyCe7yIYsYttcNA1d7MtaIe+rkL ltDfX8/TZZyPDkkvJsGyg9lYv05gmTuBxCLSVc8HUacEiWv9Njp0KcgxRyPAFrJM 94l9egxj4Yc1d9qiEuSx6Qt3WHmhwLpG6JgIhlQffepMovSEuwCC5UNVec12j1N0 MJMaLOzo5EaGn4zo8verk8szHcItgdc6U612X0ZsQE5643ZTEblToeProPYAOXnm Xg/RhkpO/NMZBiuykg6Mvhn5/dXLqlpgqOLPGxz5g/Da0q1SDSt/EmWY0e5CBT4e bx5IT6zDbDC6VIsvITqux5oigTSYRpN12gKaeE3yuw1+ce15xIDWr47d3FrPeYTN hcgLHgTkCWvfVS7H71d1V750Ykkr101ImLklaM53XgPy6x7pV0t6dHGrxNx30+RS viz5fdUM2UTtfa6zJJiMqD8o4YbBjxIrILpEqm6wA4ekl/GNU/jyTVnYNk3Sn4me KpsCNdFMv9GUVf3MP9lg =PpNA -----END PGP SIGNATURE----- --Apple-Mail=_145F40C7-405D-43B0-A65D-A511E92225FC-- From nobody Thu Sep 14 05:00:59 2017 Return-Path: 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 4C29F133020; Thu, 14 Sep 2017 05:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 emoo-Lul1JHr; Thu, 14 Sep 2017 05:00:48 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195D8132198; Thu, 14 Sep 2017 05:00:48 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1dsSoz-000BJ3-SL; Thu, 14 Sep 2017 14:00:43 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-254.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1dsSoz-0006vD-Ms; Thu, 14 Sep 2017 14:00:41 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: Date: Thu, 14 Sep 2017 14:00:40 +0200 Cc: "Alvaro Retana (aretana)" , Terry Manderson , Chris Morrow , sidr chairs , "sidr@ietf.org" , The IESG , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7D2605E4-F0C8-477E-BBDB-CDD71057B483@ripe.net> References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07196577235a6631a2a92db2e5f4e8af5d34 Archived-At: Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 12:00:50 -0000 Hi, Sure. I also proceeded to discuss your and Terry=E2=80=99s points, but = apparently not to the desired level of clarity. Let me try again here, = and tackle both your and Terry=E2=80=99s discuss items since they are = closely related. > Is it legal to mix certificate policies in a given cert path? The last > paragraph of section 5 implies that you can, but doesn't say so = explicitly. According to this document it is. Section 4.2.2.4 starts with the = following: The following is an amended specification for path validation to be used in place of section 7.2 of [RFC6487] allowing for the validation of both certificates following the profile defined in [RFC6487], as well as certificates following the profile described above. So the intent here is to describe a single validation algorithm that can = be used to validate a chain of old OIDs only (in which case it=E2=80=99s = semantically equivalent to the current spec in RFC6487), new OIDs only = (as described in the example in 4.3), or indeed a mix - but no example = is given on how that works out. > If you _can_ mix policies, what happens if you do? If I read the rules = in 4.2.4.4. > correctly (and it's likely that I am not), if you run into a cert in = the chain > that does not follow this profile, it's likely to give a null VRS-IP = or VRS-AS > value, which would seem to invalidate an certificate further down the = chain > that _does_ follow this policy? The =E2=80=9CValidated Resource Sets=E2=80=9D (VRS-*) are always = calculated, regardless of whether the old or new OIDs are used. If no =E2=80=98over-claims=E2=80=99 are found (still very much the = intended normal) the validation result will be the same whether old OIDs = only, new OIDs only, or a mix of OIDs are used. In case over-claims do exist then it depends on whether the certificate = under inspection uses the new OIDs or not. In case it doesn=E2=80=99t, = it will be rejected and things behave as in RFC6487. In case it does, = then the intersection of resources is still accepted. Any certificates = issued further down the tree that also include these over-claimed = resource would then be rejected if they happen to use the old OIDs, or = if they use the new OIDs the intersection of quoted resources and the = VRS-* of the issuing certificate would be accepted.=20 I can illustrate by example, and if desired extend section 4.3 with = this: Consider the following example where a mix of old and new OIDs are = used in the RPKI tree: Certificate 1 (TA): OID: NEW Issuer TA, Subject TA, Resources 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32, AS64496-AS64500 Verified Resource Set: 192.0.2.0/24, 198.51.100.0/24, 2001:db8::/32, AS64496-AS64500 Warnings: none NOTE: The choice of OID is irrelevant for the TA. By definition, = it cannot be over-claiming. Certificate 2 (CA1): Issuer TA, Subject CA1, OID: OLD Resources 192.0.2.0/24, 2001:db8::/32, AS64496 Verified Resource Set: 192.0.2.0/24, 2001:db8::/32, AS64496 Warnings: none Certificate 3 (CA2): Issuer CA1, Subject CA2, OID: NEW Resources 192.0.2.0/24, 198.51.100.0/24, AS64496 Verified Resource Set: 192.0.2.0/24, AS64496 Warnings: over-claim for 198.51.100.0/24 NOTE: Even though Certificate 2 used the old OIDs, Certificate 3 = can be accepted with a reduced VRS since it uses the new OIDs. Certificate 4 (CA3): Issuer CA2, Subject CA3, OID: NEW Resources 192.0.2.0/24 Verified Resource Set: 192.0.2.0/24 Warnings: none Certificate 5 (CA4): Issuer CA2, Subject CA4 OID: NEW Resources 198.51.100.0/24 Verified Resource Set: empty Warnings: 198.51.100.0/24 Note: The accepted VRS-* contains no resources. So even if the = certificate itself is accepted, its key cannot be used to make valid assertions about any resources. ROA 1 for CA3 (valid): Embedded Certificate R1 (EE certificate): Issuer CA4, Subject R1, OID: OLD Resources 192.0.2.0/24 Verified Resource Set: 192.0.2.0/24 Warnings: none Prefix 192.0.2.0/24, Max Length 24, ASN 64496 ROA1 is considered valid because the prefix matches the Verified Resource Set on the embedded EE certificate. ROA 2 for CA3 (invalid): Embedded Certificate R2 (EE certificate invalid): Issuer CA2, Subject R2, OID: OLD Resources 198.51.100.0/24 Verified Resource Set: none (certificate is rejected) Warnings: none (certificate rejected) Prefix 198.51.100.0/24, Max Length 24, ASN 64496 ROA2 is considered invalid because the embedded EE certificate is considered invalid. ROA 3 for CA4 (invalid): Embedded Certificate R3 (EE certificate invalid): Issuer CA2, Subject R3, OID: NEW Resources 198.51.100.0/24 Verified Resource Set: empty Warnings: 198.51.100.0/24 Prefix 198.51.100.0/24, Max Length 24, ASN 64496 ROA3 is considered invalid because the prefix is not included in = the empty VRS. Note: since all ROA Prefixes need to be in the VRS-* for the ROA to be valid, it might make sense to simply mandate old OIDs on ROA EE certificates. I hope this clarifies. But please let me know if it doesn=E2=80=99t, and = thank you for helping to clarify the document. Tim > On 13 Sep 2017, at 23:18, Ben Campbell wrote: >=20 > Alvaro=E2=80=99s interpretation is indeed what I meant. My concern is = with what works and what doesn=E2=80=99t work with the basic mechanism. = How it will get used in practice is a related, but different, issue. >=20 > Thanks! >=20 > Ben. >=20 >> On Sep 13, 2017, at 10:57 AM, Alvaro Retana (aretana) = wrote: >>=20 >> [Explicitly adding Terry=E2=80=A6] >>=20 >> Tim: >>=20 >> Hi! >>=20 >> As I think you understand from the response below, there are two = parts to consider when deploying: what can be done, and what will be = done. Interpreting what Ben and Terry wrote=E2=80=A6what I think they = are asking is for you to clarify in this document the considerations = around mixing policies. For example (to borrow from Terry), if a =E2=80=9C= TA has a particular OID and down the tree an issued certificate has a = different OID=E2=80=9D, what are the implications/problems/etc.? >>=20 >> Note that this question is different from the document defining how = things may end up being deployed later (=E2=80=9Cwhether this is an = acceptable deployment model=E2=80=9D). The actual deployment = discussions (as in, this is what we=E2=80=99re going to do and when) = should happen in sidrops. >>=20 >> Thanks! >>=20 >> Alvaro. >>=20 >>=20 >> On 9/13/17, 10:20 AM, "sidr on behalf of Tim Bruijnzeels" = wrote: >>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>> This is probably just a matter of me being dense, but I'd like to = understand >>> what I am missing: >>> Is it legal to mix certificate policies in a given cert path? The = last >>> paragraph of section 5 implies that you can, but doesn't say so = explicitly. If >>> you _can_ mix policies, what happens if you do? If I read the rules = in 4.2.4.4. >>> correctly (and it's likely that I am not), if you run into a cert in = the chain >>> that does not follow this profile, it's likely to give a null VRS-IP = or VRS-AS >>> value, which would seem to invalidate an certificate further down = the chain >>> that _does_ follow this policy? >>> So, I guess it comes down to the following: If mixed policies are = allowed, how >>> does that work? If mixed policies are not allowed, there needs to be = text that >>> says that. It's quite possible such text exists (here or elsewhere), = and I >>> missed it. >>=20 >> First of all it was my understanding that there was an agreement with = the AD that actual deployment should be discussed in sidrops. So this = document serves as a benchmark to describe the alternative algorithm. In = my opinion a mix is supported by this document, but the choice whether = this is an acceptable deployment model can be discussed later. >>=20 >>=20 >>=20 >=20 From nobody Fri Sep 15 14:20:42 2017 Return-Path: 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 09E8F134217; Fri, 15 Sep 2017 14:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 owI8tY4H2oS0; Fri, 15 Sep 2017 14:20:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7000B13421D; Fri, 15 Sep 2017 14:20:37 -0700 (PDT) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8FLK8VD089852 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Sep 2017 16:20:09 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] From: Ben Campbell Message-Id: <4EAF550B-34F0-4736-AD7B-252DFCF7D58E@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_46FD720F-792C-4261-ADC7-DD859C551C2B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 15 Sep 2017 16:20:09 -0500 In-Reply-To: <7D2605E4-F0C8-477E-BBDB-CDD71057B483@ripe.net> Cc: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , Chris Morrow , sidr chairs , The IESG , "sidr@ietf.org" , "Alvaro Retana (aretana)" , Terry Manderson To: Tim Bruijnzeels References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> <7D2605E4-F0C8-477E-BBDB-CDD71057B483@ripe.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 21:20:40 -0000 --Apple-Mail=_46FD720F-792C-4261-ADC7-DD859C551C2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, See comments inline. I apologize in advance if I am just being dense, = and I cannot claim to be an expert on how one applies a path validation = policy OID in general. Thanks! Ben. > On Sep 14, 2017, at 7:00 AM, Tim Bruijnzeels wrote: >=20 > Hi, >=20 > Sure. I also proceeded to discuss your and Terry=E2=80=99s points, but = apparently not to the desired level of clarity. Let me try again here, = and tackle both your and Terry=E2=80=99s discuss items since they are = closely related. >=20 >> Is it legal to mix certificate policies in a given cert path? The = last >> paragraph of section 5 implies that you can, but doesn't say so = explicitly. >=20 > According to this document it is. Section 4.2.2.4 starts with the = following: >=20 > The following is an amended specification for path validation to be > used in place of section 7.2 of [RFC6487] allowing for the = validation > of both certificates following the profile defined in [RFC6487], as > well as certificates following the profile described above. >=20 > So the intent here is to describe a single validation algorithm that = can be used to validate a chain of old OIDs only (in which case it=E2=80=99= s semantically equivalent to the current spec in RFC6487), new OIDs only = (as described in the example in 4.3), or indeed a mix - but no example = is given on how that works out. >=20 >=20 >> If you _can_ mix policies, what happens if you do? If I read the = rules in 4.2.4.4. >> correctly (and it's likely that I am not), if you run into a cert in = the chain >> that does not follow this profile, it's likely to give a null VRS-IP = or VRS-AS >> value, which would seem to invalidate an certificate further down the = chain >> that _does_ follow this policy? >=20 >=20 > The =E2=80=9CValidated Resource Sets=E2=80=9D (VRS-*) are always = calculated, regardless of whether the old or new OIDs are used. This is where I am confused. The calculation of VRS is described in this = draft in the amendment to the path validation in section 7.2 of 6487. I = assumed that the amended path validation procedure only applies with the = =E2=80=9Cnew=E2=80=9D OID. Is that incorrect? If so, can you point to = the text that states that? (It=E2=80=99s entirely possible I missed = something, or completely misunderstand how the OIDs are applied. ) If that assumption was correct, then I would assume the VRS for a cert = using the old OID would be undefined, and that if cert X has an = undefined VRS. (comment continued in the example below=E2=80=A6) >=20 > If no =E2=80=98over-claims=E2=80=99 are found (still very much the = intended normal) the validation result will be the same whether old OIDs = only, new OIDs only, or a mix of OIDs are used. >=20 > In case over-claims do exist then it depends on whether the = certificate under inspection uses the new OIDs or not. In case it = doesn=E2=80=99t, it will be rejected and things behave as in RFC6487. In = case it does, then the intersection of resources is still accepted. Any = certificates issued further down the tree that also include these = over-claimed resource would then be rejected if they happen to use the = old OIDs, or if they use the new OIDs the intersection of quoted = resources and the VRS-* of the issuing certificate would be accepted. >=20 > I can illustrate by example, and if desired extend section 4.3 with = this: >=20 >=20 > Consider the following example where a mix of old and new OIDs are = used in the RPKI tree: >=20 >=20 > Certificate 1 (TA): > OID: NEW > Issuer TA, > Subject TA, > Resources 192.0.2.0/24, 198.51.100.0/24, > 2001:db8::/32, AS64496-AS64500 >=20 > Verified Resource Set: 192.0.2.0/24, 198.51.100.0/24, > 2001:db8::/32, AS64496-AS64500 > Warnings: none >=20 > NOTE: The choice of OID is irrelevant for the TA. By definition, = it cannot be over-claiming. >=20 >=20 > Certificate 2 (CA1): > Issuer TA, > Subject CA1, > OID: OLD > Resources 192.0.2.0/24, 2001:db8::/32, AS64496 >=20 > Verified Resource Set: 192.0.2.0/24, > 2001:db8::/32, AS64496 > Warnings: none It=E2=80=99s not clear to me why the VRS is set to that in the cert with = the old OID. Does the amended validation process in this draft apply for = certs that do not use the new OID? If not, wouldn=E2=80=99t the VRS here = be null, undefined, or simply non-existant? >=20 >=20 > Certificate 3 (CA2): > Issuer CA1, > Subject CA2, > OID: NEW > Resources 192.0.2.0/24, 198.51.100.0/24, AS64496 >=20 > Verified Resource Set: 192.0.2.0/24, AS64496 > Warnings: over-claim for 198.51.100.0/24 >=20 > NOTE: Even though Certificate 2 used the old OIDs, Certificate 3 = can be accepted with a reduced VRS since it uses the new OIDs. Continuing with the assumption that the VRS in cert 2 is undefined, = doesn=E2=80=99t that make the VRS in cert 3 the intersection of = "192.0.2.0/24, 198.51.100.0/24=E2=80=9D and the undefined VRS from Cert = 2? How is the result of that something other than a null set, which = would then propagate down the chain as as you calculate each set = intersection? >=20 >=20 > Certificate 4 (CA3): > Issuer CA2, > Subject CA3, > OID: NEW > Resources 192.0.2.0/24 >=20 > Verified Resource Set: 192.0.2.0/24 > Warnings: none >=20 >=20 > Certificate 5 (CA4): > Issuer CA2, > Subject CA4 > OID: NEW > Resources 198.51.100.0/24 >=20 > Verified Resource Set: empty > Warnings: 198.51.100.0/24 >=20 > Note: The accepted VRS-* contains no resources. So even if the = certificate itself is accepted, its key cannot be used > to make valid assertions about any resources. >=20 >=20 > ROA 1 for CA3 (valid): > Embedded Certificate R1 (EE certificate): > Issuer CA4, > Subject R1, > OID: OLD > Resources 192.0.2.0/24 >=20 > Verified Resource Set: 192.0.2.0/24 > Warnings: none >=20 > Prefix 192.0.2.0/24, Max Length 24, ASN 64496 >=20 > ROA1 is considered valid because the prefix matches the Verified > Resource Set on the embedded EE certificate. >=20 >=20 > ROA 2 for CA3 (invalid): > Embedded Certificate R2 (EE certificate invalid): > Issuer CA2, > Subject R2, > OID: OLD > Resources 198.51.100.0/24 >=20 > Verified Resource Set: none (certificate is rejected) > Warnings: none (certificate rejected) >=20 > Prefix 198.51.100.0/24, Max Length 24, ASN 64496 >=20 > ROA2 is considered invalid because the embedded EE certificate = is > considered invalid. >=20 > ROA 3 for CA4 (invalid): > Embedded Certificate R3 (EE certificate invalid): > Issuer CA2, > Subject R3, > OID: NEW > Resources 198.51.100.0/24 >=20 > Verified Resource Set: empty > Warnings: 198.51.100.0/24 >=20 > Prefix 198.51.100.0/24, Max Length 24, ASN 64496 >=20 > ROA3 is considered invalid because the prefix is not included in = the > empty VRS. >=20 > Note: since all ROA Prefixes need to be in the VRS-* for the > ROA to be valid, it might make sense to simply mandate > old OIDs on ROA EE certificates. >=20 >=20 > I hope this clarifies. But please let me know if it doesn=E2=80=99t, = and thank you for helping to clarify the document. >=20 > Tim >=20 >=20 >=20 >=20 >=20 >> On 13 Sep 2017, at 23:18, Ben Campbell wrote: >>=20 >> Alvaro=E2=80=99s interpretation is indeed what I meant. My concern is = with what works and what doesn=E2=80=99t work with the basic mechanism. = How it will get used in practice is a related, but different, issue. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>> On Sep 13, 2017, at 10:57 AM, Alvaro Retana (aretana) = wrote: >>>=20 >>> [Explicitly adding Terry=E2=80=A6] >>>=20 >>> Tim: >>>=20 >>> Hi! >>>=20 >>> As I think you understand from the response below, there are two = parts to consider when deploying: what can be done, and what will be = done. Interpreting what Ben and Terry wrote=E2=80=A6what I think they = are asking is for you to clarify in this document the considerations = around mixing policies. For example (to borrow from Terry), if a =E2=80=9C= TA has a particular OID and down the tree an issued certificate has a = different OID=E2=80=9D, what are the implications/problems/etc.? >>>=20 >>> Note that this question is different from the document defining how = things may end up being deployed later (=E2=80=9Cwhether this is an = acceptable deployment model=E2=80=9D). The actual deployment = discussions (as in, this is what we=E2=80=99re going to do and when) = should happen in sidrops. >>>=20 >>> Thanks! >>>=20 >>> Alvaro. >>>=20 >>>=20 >>> On 9/13/17, 10:20 AM, "sidr on behalf of Tim Bruijnzeels" = wrote: >>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>> This is probably just a matter of me being dense, but I'd like to = understand >>>> what I am missing: >>>> Is it legal to mix certificate policies in a given cert path? The = last >>>> paragraph of section 5 implies that you can, but doesn't say so = explicitly. If >>>> you _can_ mix policies, what happens if you do? If I read the rules = in 4.2.4.4. >>>> correctly (and it's likely that I am not), if you run into a cert = in the chain >>>> that does not follow this profile, it's likely to give a null = VRS-IP or VRS-AS >>>> value, which would seem to invalidate an certificate further down = the chain >>>> that _does_ follow this policy? >>>> So, I guess it comes down to the following: If mixed policies are = allowed, how >>>> does that work? If mixed policies are not allowed, there needs to = be text that >>>> says that. It's quite possible such text exists (here or = elsewhere), and I >>>> missed it. >>>=20 >>> First of all it was my understanding that there was an agreement = with the AD that actual deployment should be discussed in sidrops. So = this document serves as a benchmark to describe the alternative = algorithm. In my opinion a mix is supported by this document, but the = choice whether this is an acceptable deployment model can be discussed = later. >>>=20 >>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_46FD720F-792C-4261-ADC7-DD859C551C2B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZvEQJAAoJEIBWSmyV89QNmVMP/160hJZzHJVgDe9Q1FOYVhs6 lbMzl9NWscVJc2s1bx2QkCeCF9jR7xTdIvZ3i35ObkKXYxW6NtlkWg3W+4lbFTqL bSOwskgqr1GHsO9JyJCEtqcYnQ8SilwPz4uO9rdKs9k5K7IkzutwpSiwMGNjDAAu TrveZ5DgxbR2nUEZK5YkIF8yLATSmgiNLt7EwAkvFmIDaxGrvRn+apK+Wfq2I/tT gIOuhJ+qgLRNwyqXpdvRCgLus5ZMPUCInuU73Ge1wh7ClCt0uk8ab3hnM+affXQ2 XPcWV/jQPK03WBFVFjSzErQVIaS7jaCQ5KG+6nw3QEwcWusmXHlloROzY5z+Dm/1 BRI/DhGzbx69+D1FNCMqEzeXypsbUVI1EialiTya0uv4LKkbfChib/qfZX6zStZ7 42pB/su7kWMyyMhTCCGYljWoCipXieqMajoOAPbS3TgpBfbp/2uosIhD2Es7UN6D iMWJ7kXSZ1jg9HhzFZc8DmLwRtMC+cMZPU4kncIDbsNjQ4hAyL0XovYNCDTrI7gK nQn7wxDtDK1Oh+wwCS+WZTj9acEhwz25qBu+3694OruMoZ9AALT8hDB6+fIRuV+s NQ9ng45oFjg7HkDJM1HjxxWD0T724ArpfPGicGYslLcVZdA6V3OFnQVCHu8yk837 Qp1AP912ev8d6CJSn78U =VXHc -----END PGP SIGNATURE----- --Apple-Mail=_46FD720F-792C-4261-ADC7-DD859C551C2B-- From nobody Mon Sep 18 06:16:00 2017 Return-Path: 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 8CC08132332; Mon, 18 Sep 2017 06:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 QcQ31nI5ooaS; Mon, 18 Sep 2017 06:15:51 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71871126C7A; Mon, 18 Sep 2017 06:15:51 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1dtvtp-0001Aq-OT; Mon, 18 Sep 2017 15:15:47 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-69.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1dtvtp-0003rO-KH; Mon, 18 Sep 2017 15:15:45 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: <4EAF550B-34F0-4736-AD7B-252DFCF7D58E@nostrum.com> Date: Mon, 18 Sep 2017 15:15:44 +0200 Cc: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , Chris Morrow , sidr chairs , The IESG , "sidr@ietf.org" , "Alvaro Retana (aretana)" , Terry Manderson Content-Transfer-Encoding: quoted-printable Message-Id: <30E4E5AD-9ECA-4D66-B6EB-99912082EF12@ripe.net> References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> <7D2605E4-F0C8-477E-BBDB-CDD71057B483@ripe.net> <4EAF550B-34F0-4736-AD7B-252DFCF7D58E@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071946d84913d78809baa06facaa5300609e Archived-At: Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 13:15:53 -0000 Hi Ben, all, > On 15 Sep 2017, at 23:20, Ben Campbell wrote: >=20 > Hi, >=20 > See comments inline. I apologize in advance if I am just being dense, = and I cannot claim to be an expert on how one applies a path validation = policy OID in general. >=20 >=20 > Thanks! >=20 > Ben. >=20 >> On Sep 14, 2017, at 7:00 AM, Tim Bruijnzeels wrote: >>=20 >> Hi, >>=20 >> Sure. I also proceeded to discuss your and Terry=E2=80=99s points, = but apparently not to the desired level of clarity. Let me try again = here, and tackle both your and Terry=E2=80=99s discuss items since they = are closely related. >>=20 >>> Is it legal to mix certificate policies in a given cert path? The = last >>> paragraph of section 5 implies that you can, but doesn't say so = explicitly. >>=20 >> According to this document it is. Section 4.2.2.4 starts with the = following: >>=20 >> The following is an amended specification for path validation to be >> used in place of section 7.2 of [RFC6487] allowing for the = validation >> of both certificates following the profile defined in [RFC6487], as >> well as certificates following the profile described above. >>=20 >> So the intent here is to describe a single validation algorithm that = can be used to validate a chain of old OIDs only (in which case it=E2=80=99= s semantically equivalent to the current spec in RFC6487), new OIDs only = (as described in the example in 4.3), or indeed a mix - but no example = is given on how that works out. >>=20 >>=20 >>> If you _can_ mix policies, what happens if you do? If I read the = rules in 4.2.4.4. >>> correctly (and it's likely that I am not), if you run into a cert in = the chain >>> that does not follow this profile, it's likely to give a null VRS-IP = or VRS-AS >>> value, which would seem to invalidate an certificate further down = the chain >>> that _does_ follow this policy? >>=20 >>=20 >> The =E2=80=9CValidated Resource Sets=E2=80=9D (VRS-*) are always = calculated, regardless of whether the old or new OIDs are used. >=20 > This is where I am confused. The calculation of VRS is described in = this draft in the amendment to the path validation in section 7.2 of = 6487. I assumed that the amended path validation procedure only applies = with the =E2=80=9Cnew=E2=80=9D OID. Is that incorrect? If so, can you = point to the text that states that? (It=E2=80=99s entirely possible I = missed something, or completely misunderstand how the OIDs are applied. = ) First paragraph of 4.2.2.4: "The following is an amended specification for path validation to be = used in place of section 7.2 of [RFC6487] allowing for the validation of both certificates following the profile = defined in [RFC6487], as well as certificates following the profile described above." So, yes, as far as I am concerned the intent was to have this cover both = the old and new OIDs. Where the algorithm if applied to old OID only is = semantically equivalent to section 7.2 of RFC6487 - or at least: it has = the same outcome. If this needs to be more explicit I am happy to accept a suggestion - as = an author knowing my own intentions, it=E2=80=99s not always trivial to = see how others would interpret text differently. Kind regards Tim Bruijnzeels= From nobody Mon Sep 18 14:36:53 2017 Return-Path: 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 A121A132153; Mon, 18 Sep 2017 14:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 FUJ0XghigPeX; Mon, 18 Sep 2017 14:36:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4D11241F3; Mon, 18 Sep 2017 14:36:44 -0700 (PDT) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8ILaD3x024090 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 18 Sep 2017 16:36:14 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] From: Ben Campbell Message-Id: <24E0B229-B5C0-446C-BD41-E90234C1C405@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_726D02F1-8B93-4EDF-B972-060FE1D9BFC9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 18 Sep 2017 16:36:12 -0500 In-Reply-To: <30E4E5AD-9ECA-4D66-B6EB-99912082EF12@ripe.net> Cc: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , Chris Morrow , sidr chairs , The IESG , "sidr@ietf.org" , "Alvaro Retana (aretana)" , Terry Manderson To: Tim Bruijnzeels References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> <7D2605E4-F0C8-477E-BBDB-CDD71057B483@ripe.net> <4EAF550B-34F0-4736-AD7B-252DFCF7D58E@nostrum.com> <30E4E5AD-9ECA-4D66-B6EB-99912082EF12@ripe.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 21:36:47 -0000 --Apple-Mail=_726D02F1-8B93-4EDF-B972-060FE1D9BFC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 18, 2017, at 8:15 AM, Tim Bruijnzeels wrote: >=20 > Hi Ben, all, >=20 >> On 15 Sep 2017, at 23:20, Ben Campbell wrote: >>=20 >> Hi, >>=20 >> See comments inline. I apologize in advance if I am just being dense, = and I cannot claim to be an expert on how one applies a path validation = policy OID in general. >>=20 >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>> On Sep 14, 2017, at 7:00 AM, Tim Bruijnzeels wrote: >>>=20 >>> Hi, >>>=20 >>> Sure. I also proceeded to discuss your and Terry=E2=80=99s points, = but apparently not to the desired level of clarity. Let me try again = here, and tackle both your and Terry=E2=80=99s discuss items since they = are closely related. >>>=20 >>>> Is it legal to mix certificate policies in a given cert path? The = last >>>> paragraph of section 5 implies that you can, but doesn't say so = explicitly. >>>=20 >>> According to this document it is. Section 4.2.2.4 starts with the = following: >>>=20 >>> The following is an amended specification for path validation to be >>> used in place of section 7.2 of [RFC6487] allowing for the = validation >>> of both certificates following the profile defined in [RFC6487], as >>> well as certificates following the profile described above. >>>=20 >>> So the intent here is to describe a single validation algorithm that = can be used to validate a chain of old OIDs only (in which case it=E2=80=99= s semantically equivalent to the current spec in RFC6487), new OIDs only = (as described in the example in 4.3), or indeed a mix - but no example = is given on how that works out. >>>=20 >>>=20 >>>> If you _can_ mix policies, what happens if you do? If I read the = rules in 4.2.4.4. >>>> correctly (and it's likely that I am not), if you run into a cert = in the chain >>>> that does not follow this profile, it's likely to give a null = VRS-IP or VRS-AS >>>> value, which would seem to invalidate an certificate further down = the chain >>>> that _does_ follow this policy? >>>=20 >>>=20 >>> The =E2=80=9CValidated Resource Sets=E2=80=9D (VRS-*) are always = calculated, regardless of whether the old or new OIDs are used. >>=20 >> This is where I am confused. The calculation of VRS is described in = this draft in the amendment to the path validation in section 7.2 of = 6487. I assumed that the amended path validation procedure only applies = with the =E2=80=9Cnew=E2=80=9D OID. Is that incorrect? If so, can you = point to the text that states that? (It=E2=80=99s entirely possible I = missed something, or completely misunderstand how the OIDs are applied. = ) >=20 > First paragraph of 4.2.2.4: >=20 > "The following is an amended specification for path validation to be = used in place of section 7.2 of [RFC6487] > allowing for the validation of both certificates following the profile = defined in [RFC6487], as well as certificates > following the profile described above." >=20 > So, yes, as far as I am concerned the intent was to have this cover = both the old and new OIDs. Where the algorithm if applied to old OID = only is semantically equivalent to section 7.2 of RFC6487 - or at least: = it has the same outcome. >=20 That intent surprises me, I was under the impression the entire document = was specific to the new OIDs. This seems to be supported by this text in = the abstract: "The use of this updated procedure is signalled by form of a set of = alternative Object Identifiers (OIDs) indicating that the alternative = version of RFC 3779 X.509 Extensions for IP Addresses and AS = Identifiers, and certificate policy for the Resource Public Key = Infrastructure ( RFC 6484) defined in this document should be used.=E2=80=9D= =E2=80=A6 and in the specific case of the certificate validation policy = OID, there is this text in 4.2.1: "This alternative Certificate Policy is the same as the Certificate = Policy described in [ RFC6484], except that it indicates that the validation rules described = in Section 4.2.4.4 are to be used.=E2=80=9D If the rules in 4.2.4.4 are used even when that OID is not present, then = I=E2=80=99m confused about what the OID signals in the first place. > If this needs to be more explicit I am happy to accept a suggestion - = as an author knowing my own intentions, it=E2=80=99s not always trivial = to see how others would interpret text differently. I=E2=80=99m not sure this is just a matter of clarification. The text I = mention above explicitly says the OID signals the use of the amended CP. = I have to assume that was the working group intent, and what was = understood by people during IETF LC. If that is _not_ the intent, we = would need some degree of consensus to change that text. ( I suspect = that would mean going back to the WG or IETF LC, but I will leave that = to Alvaro to decide.) My strictly personal opinion is that it would be _really_ confusing to = have some aspects of the new CP apply even when the new OID is not used. Thanks, Ben. --Apple-Mail=_726D02F1-8B93-4EDF-B972-060FE1D9BFC9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZwDxMAAoJEIBWSmyV89QNZ1kP/2yYBVu6k8IR5+Fu5wwIZQrt +jkkFtDO63GQB3urHCAU6w1U5U5i7LObA6gU781MVNs+eB/RmOz10+RxbJ7PlZ9y NLIfMzThFEQPCjaXtNTh4e7Puyvf0myzRxGa2gSmaQZ3AqDzgF78q0MQHQGQ9jUa IvItanUJv4GK4nBlz7cBHDjTUttaMAs3zkR61mRrFXRAqtVnA1llkpRk86nVr723 Dh/uNg/GZ/WaV1If3Gh0TjABMqdGQhgEYmZNS4Px0k2gylbClApv2nJ4is5un3US 6B8nbr4w9HmMtTgNrheyKEJGAvATBh7DTC1Z8i7M5WtUcd6FxaWga8n64upiyCna q+BQFUk7nYJ2pkiU12j0wvlCrjNaEnp/PQU+OrZkUoU1Pf/wtS7HiQZ1n2zcKtm+ fRx4kWt5Pe4Xt3QQgsDQr3nx2ntOp3G7AJwC+HgM61tehPPapTKzhn1XP/Kyz6QQ PBL5TI4/49SpRQsqpgjcldhhtEp2Qo+3zBnYCQXkuwIKBhVrqS8CGS8vYdfLst58 LKT1TuM8BE7nJIkAqVIYo+dWYJNT/pdRuAD24i0XjEOvQWt/MqWeWGDtBKza1Knr YntTvLPePNI0/URcnibH+Ks6gPYR1Ju+A1NILxqpLoIlAmx61b9uGYJlDgMpTz5W HgkOmrbDOKns07A32ygr =rtrn -----END PGP SIGNATURE----- --Apple-Mail=_726D02F1-8B93-4EDF-B972-060FE1D9BFC9-- From nobody Tue Sep 19 04:54:41 2017 Return-Path: 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 7B65113421B; Tue, 19 Sep 2017 04:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 aaTkiZ4_dIP7; Tue, 19 Sep 2017 04:54:31 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCC41331E7; Tue, 19 Sep 2017 04:54:31 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1duH6f-0000g1-72; Tue, 19 Sep 2017 13:54:26 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-6.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1duH6f-0006kp-3n; Tue, 19 Sep 2017 13:54:25 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: <24E0B229-B5C0-446C-BD41-E90234C1C405@nostrum.com> Date: Tue, 19 Sep 2017 13:54:24 +0200 Cc: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , Chris Morrow , sidr chairs , The IESG , "sidr@ietf.org" , "Alvaro Retana (aretana)" , Terry Manderson Content-Transfer-Encoding: quoted-printable Message-Id: References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> <7D2605E4-F0C8-477E-BBDB-CDD71057B483@ripe.net> <4EAF550B-34F0-4736-AD7B-252DFCF7D58E@nostrum.com> <30E4E5AD-9ECA-4D66-B6EB-99912082EF12@ripe.net> <24E0B229-B5C0-446C-BD41-E90234C1C405@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719c5c0e98361cdaa0fc60d58b3b6cc75e4 Archived-At: Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 11:54:33 -0000 > On 18 Sep 2017, at 23:36, Ben Campbell wrote: >=20 >>=20 >> On Sep 18, 2017, at 8:15 AM, Tim Bruijnzeels wrote: >>=20 >> Hi Ben, all, >>=20 >>> On 15 Sep 2017, at 23:20, Ben Campbell wrote: >>>=20 >>> Hi, >>>=20 >>> See comments inline. I apologize in advance if I am just being = dense, and I cannot claim to be an expert on how one applies a path = validation policy OID in general. >>>=20 >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>>> On Sep 14, 2017, at 7:00 AM, Tim Bruijnzeels wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> Sure. I also proceeded to discuss your and Terry=E2=80=99s points, = but apparently not to the desired level of clarity. Let me try again = here, and tackle both your and Terry=E2=80=99s discuss items since they = are closely related. >>>>=20 >>>>> Is it legal to mix certificate policies in a given cert path? The = last >>>>> paragraph of section 5 implies that you can, but doesn't say so = explicitly. >>>>=20 >>>> According to this document it is. Section 4.2.2.4 starts with the = following: >>>>=20 >>>> The following is an amended specification for path validation to be >>>> used in place of section 7.2 of [RFC6487] allowing for the = validation >>>> of both certificates following the profile defined in [RFC6487], as >>>> well as certificates following the profile described above. >>>>=20 >>>> So the intent here is to describe a single validation algorithm = that can be used to validate a chain of old OIDs only (in which case = it=E2=80=99s semantically equivalent to the current spec in RFC6487), = new OIDs only (as described in the example in 4.3), or indeed a mix - = but no example is given on how that works out. >>>>=20 >>>>=20 >>>>> If you _can_ mix policies, what happens if you do? If I read the = rules in 4.2.4.4. >>>>> correctly (and it's likely that I am not), if you run into a cert = in the chain >>>>> that does not follow this profile, it's likely to give a null = VRS-IP or VRS-AS >>>>> value, which would seem to invalidate an certificate further down = the chain >>>>> that _does_ follow this policy? >>>>=20 >>>>=20 >>>> The =E2=80=9CValidated Resource Sets=E2=80=9D (VRS-*) are always = calculated, regardless of whether the old or new OIDs are used. >>>=20 >>> This is where I am confused. The calculation of VRS is described in = this draft in the amendment to the path validation in section 7.2 of = 6487. I assumed that the amended path validation procedure only applies = with the =E2=80=9Cnew=E2=80=9D OID. Is that incorrect? If so, can you = point to the text that states that? (It=E2=80=99s entirely possible I = missed something, or completely misunderstand how the OIDs are applied. = ) >>=20 >> First paragraph of 4.2.2.4: >>=20 >> "The following is an amended specification for path validation to be = used in place of section 7.2 of [RFC6487] >> allowing for the validation of both certificates following the = profile defined in [RFC6487], as well as certificates >> following the profile described above." >>=20 >> So, yes, as far as I am concerned the intent was to have this cover = both the old and new OIDs. Where the algorithm if applied to old OID = only is semantically equivalent to section 7.2 of RFC6487 - or at least: = it has the same outcome. >>=20 >=20 > That intent surprises me, I was under the impression the entire = document was specific to the new OIDs. This seems to be supported by = this text in the abstract: >=20 > "The use of this updated procedure is signalled by form of a set of = alternative Object Identifiers (OIDs) indicating that the alternative = version of RFC 3779 X.509 Extensions for IP Addresses and AS = Identifiers, and certificate policy for the Resource Public Key = Infrastructure ( RFC 6484) defined in this document should be used.=E2=80=9D= >=20 > =E2=80=A6 and in the specific case of the certificate validation = policy OID, there is this text in 4.2.1: >=20 > "This alternative Certificate Policy is the same as the Certificate = Policy described in [ > RFC6484], except that it indicates that the validation rules described = in > Section 4.2.4.4 are to be used.=E2=80=9D >=20 > If the rules in 4.2.4.4 are used even when that OID is not present, = then I=E2=80=99m confused about what the OID signals in the first place. The OIDs are used to drive a decision in the rules described in 4.2.4.4. =3D Old OIDs -> reject over-claim, this has the same result as section = 7.2 in RFC6487 =3D New OIDs -> warn on over-claim So as far as clarity goes, it might be better to either leave out the = set regarding the need for the different OIDs in their respective = sections, or say =E2=80=9CThis OID is used to in the decision process of = the validation rules described in 4.2.4.4. >> If this needs to be more explicit I am happy to accept a suggestion - = as an author knowing my own intentions, it=E2=80=99s not always trivial = to see how others would interpret text differently. >=20 > I=E2=80=99m not sure this is just a matter of clarification. The text = I mention above explicitly says the OID signals the use of the amended = CP. I have to assume that was the working group intent, and what was = understood by people during IETF LC. If that is _not_ the intent, we = would need some degree of consensus to change that text. ( I suspect = that would mean going back to the WG or IETF LC, but I will leave that = to Alvaro to decide.) >=20 It was my assumption that my intent was clear. But I will accept whatever Alvaro decides on this. > My strictly personal opinion is that it would be _really_ confusing to = have some aspects of the new CP apply even when the new OID is not used. The assumption on my part here was that RPs can decide to support this = RFC-to-be and then use section 4.2.4.4 to validate old and new CP alike. The process described in 4.2.4.4 when used for old OIDs only has the = same outcome as section 7.2 of RFC 6487. It=E2=80=99s true that = =E2=80=9CValidated Resource Sets=E2=80=9D are not named in RFC6487, but = in a tree where only old OIDs are used one will find that the Validated = Resource Set for a given *valid* certificate always matches the = certificate itself. Thanks Tim >=20 > Thanks, >=20 > Ben. From nobody Fri Sep 22 13:56:45 2017 Return-Path: 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 8772C132F3F; Fri, 22 Sep 2017 13:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 WTXHk3DryS83; Fri, 22 Sep 2017 13:56:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BA4A13292A; Fri, 22 Sep 2017 13:56:36 -0700 (PDT) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8MKu83V002361 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 22 Sep 2017 15:56:09 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] From: Ben Campbell Message-Id: <58459EC7-14B4-4F27-929B-3BB9017C48A8@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_05EBCFDB-3B39-4783-B9A5-BCCA7940B477"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 22 Sep 2017 15:56:10 -0500 In-Reply-To: Cc: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , Chris Morrow , sidr chairs , The IESG , "sidr@ietf.org" , "Alvaro Retana (aretana)" , Terry Manderson To: Tim Bruijnzeels References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> <7D2605E4-F0C8-477E-BBDB-CDD71057B483@ripe.net> <4EAF550B-34F0-4736-AD7B-252DFCF7D58E@nostrum.com> <30E4E5AD-9ECA-4D66-B6EB-99912082EF12@ripe.net> <24E0B229-B5C0-446C-BD41-E90234C1C405@nostrum.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 20:56:38 -0000 --Apple-Mail=_05EBCFDB-3B39-4783-B9A5-BCCA7940B477 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 19, 2017, at 6:54 AM, Tim Bruijnzeels wrote: >=20 >=20 >> On 18 Sep 2017, at 23:36, Ben Campbell wrote: >>=20 >>>=20 >>> On Sep 18, 2017, at 8:15 AM, Tim Bruijnzeels wrote: >>>=20 >>> Hi Ben, all, >>>=20 >>>> On 15 Sep 2017, at 23:20, Ben Campbell wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> See comments inline. I apologize in advance if I am just being = dense, and I cannot claim to be an expert on how one applies a path = validation policy OID in general. >>>>=20 >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>>=20 >>>>> On Sep 14, 2017, at 7:00 AM, Tim Bruijnzeels wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Sure. I also proceeded to discuss your and Terry=E2=80=99s points, = but apparently not to the desired level of clarity. Let me try again = here, and tackle both your and Terry=E2=80=99s discuss items since they = are closely related. >>>>>=20 >>>>>> Is it legal to mix certificate policies in a given cert path? The = last >>>>>> paragraph of section 5 implies that you can, but doesn't say so = explicitly. >>>>>=20 >>>>> According to this document it is. Section 4.2.2.4 starts with the = following: >>>>>=20 >>>>> The following is an amended specification for path validation to = be >>>>> used in place of section 7.2 of [RFC6487] allowing for the = validation >>>>> of both certificates following the profile defined in [RFC6487], = as >>>>> well as certificates following the profile described above. >>>>>=20 >>>>> So the intent here is to describe a single validation algorithm = that can be used to validate a chain of old OIDs only (in which case = it=E2=80=99s semantically equivalent to the current spec in RFC6487), = new OIDs only (as described in the example in 4.3), or indeed a mix - = but no example is given on how that works out. >>>>>=20 >>>>>=20 >>>>>> If you _can_ mix policies, what happens if you do? If I read the = rules in 4.2.4.4. >>>>>> correctly (and it's likely that I am not), if you run into a cert = in the chain >>>>>> that does not follow this profile, it's likely to give a null = VRS-IP or VRS-AS >>>>>> value, which would seem to invalidate an certificate further down = the chain >>>>>> that _does_ follow this policy? >>>>>=20 >>>>>=20 >>>>> The =E2=80=9CValidated Resource Sets=E2=80=9D (VRS-*) are always = calculated, regardless of whether the old or new OIDs are used. >>>>=20 >>>> This is where I am confused. The calculation of VRS is described in = this draft in the amendment to the path validation in section 7.2 of = 6487. I assumed that the amended path validation procedure only applies = with the =E2=80=9Cnew=E2=80=9D OID. Is that incorrect? If so, can you = point to the text that states that? (It=E2=80=99s entirely possible I = missed something, or completely misunderstand how the OIDs are applied. = ) >>>=20 >>> First paragraph of 4.2.2.4: >>>=20 >>> "The following is an amended specification for path validation to be = used in place of section 7.2 of [RFC6487] >>> allowing for the validation of both certificates following the = profile defined in [RFC6487], as well as certificates >>> following the profile described above." >>>=20 >>> So, yes, as far as I am concerned the intent was to have this cover = both the old and new OIDs. Where the algorithm if applied to old OID = only is semantically equivalent to section 7.2 of RFC6487 - or at least: = it has the same outcome. >>>=20 >>=20 >> That intent surprises me, I was under the impression the entire = document was specific to the new OIDs. This seems to be supported by = this text in the abstract: >>=20 >> "The use of this updated procedure is signalled by form of a set of = alternative Object Identifiers (OIDs) indicating that the alternative = version of RFC 3779 X.509 Extensions for IP Addresses and AS = Identifiers, and certificate policy for the Resource Public Key = Infrastructure ( RFC 6484) defined in this document should be used.=E2=80=9D= >>=20 >> =E2=80=A6 and in the specific case of the certificate validation = policy OID, there is this text in 4.2.1: >>=20 >> "This alternative Certificate Policy is the same as the Certificate = Policy described in [ >> RFC6484], except that it indicates that the validation rules = described in >> Section 4.2.4.4 are to be used.=E2=80=9D >>=20 >> If the rules in 4.2.4.4 are used even when that OID is not present, = then I=E2=80=99m confused about what the OID signals in the first place. >=20 > The OIDs are used to drive a decision in the rules described in = 4.2.4.4. > =3D Old OIDs -> reject over-claim, this has the same result as section = 7.2 in RFC6487 > =3D New OIDs -> warn on over-claim Are you suggesting the text =E2=80=9Cshould=E2=80=9D say that, or = =E2=80=9Cdoes=E2=80=9D say that? As written, the OID seems to drive the = selection about whether you use the rules in 4.2.4.4 or not. But I think = you are saying that, if you implement these OIDs, you SHOULD/MAY use the = rules in 4.2.4.4 all the time, but use the OID as an input to those = rules. Is that correct? >=20 > So as far as clarity goes, it might be better to either leave out the = set regarding the need for the different OIDs in their respective = sections, or say =E2=80=9CThis OID is used to in the decision process of = the validation rules described in 4.2.4.4. I=E2=80=99m not sure what you mean by the former. If you go with the = latter, then the rules in 4.2.4.4 will need to be explicit in how the = OID is used in that process. >=20 >>> If this needs to be more explicit I am happy to accept a suggestion = - as an author knowing my own intentions, it=E2=80=99s not always = trivial to see how others would interpret text differently. >>=20 >> I=E2=80=99m not sure this is just a matter of clarification. The text = I mention above explicitly says the OID signals the use of the amended = CP. I have to assume that was the working group intent, and what was = understood by people during IETF LC. If that is _not_ the intent, we = would need some degree of consensus to change that text. ( I suspect = that would mean going back to the WG or IETF LC, but I will leave that = to Alvaro to decide.) >>=20 >=20 > It was my assumption that my intent was clear. >=20 > But I will accept whatever Alvaro decides on this. >=20 >=20 >> My strictly personal opinion is that it would be _really_ confusing = to have some aspects of the new CP apply even when the new OID is not = used. >=20 > The assumption on my part here was that RPs can decide to support this = RFC-to-be and then use section 4.2.4.4 to validate old and new CP alike. >=20 > The process described in 4.2.4.4 when used for old OIDs only has the = same outcome as section 7.2 of RFC 6487. It=E2=80=99s true that = =E2=80=9CValidated Resource Sets=E2=80=9D are not named in RFC6487, but = in a tree where only old OIDs are used one will find that the Validated = Resource Set for a given *valid* certificate always matches the = certificate itself. As I mentioned above, if the idea is to always use the rules in 4.2.4.4, = and use the OID to drive decisions _within_ those rules, the rules need = to be updated with the explicit details. >=20 > Thanks > Tim >=20 >=20 >>=20 >> Thanks, >>=20 >> Ben. >=20 --Apple-Mail=_05EBCFDB-3B39-4783-B9A5-BCCA7940B477 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZxXjqAAoJEIBWSmyV89QNZHsQAIO7RwrGt4ULHrcJf46BCvMv RCDjHvMmb+jrlFDxC837hg8OjafDcd9tbui/0PxrJ7Q5wtizq0dZOFe3gjjtbJ1c CTPqHtRSmfEViq02Ps+Ti167n+MWSWhwDSAAD7kZoswuHfSEdhgPsKSazMzErNNF fOkx4GBGInvMOUOm4NiBHm/VaK0RuQDvhxmvQOKvEPsTVBRPVpLwILdHmGi1G1QB 9XPxEjWJl2U1M3pd0YyxPpYtU1BqC+ljQMamt+hY97UTslFuuelcvjm0smMqi/i9 XbDYl4eagYGDy6lob7BAso72t2gkXOuVBEcneYVeVzHMWkc5yUSAa0y0UFNqzzIR so6e3Mccs7sYLEtn+1rVN5HuwDOQ5bLfDyaVqLPBik+smEVC5WPw26/hpE/Y7AL/ 0hEfkdzAPUkKD/QEB4SxazoryUVo+bZKwGr/5knOPBFGoL6BpcNMZ66Wk4W4LYAy naYmryQgil/Xiw57OLZhFHZfAvvcrA7L6WdxHHlBzBebuYdNEpkErlmFYfk0croH HNx+72PvoruyD2giL8wJU0k7rnweeb7WxGz01FoxKhH2HH/ge+wRp09b4jO2FScL F7Dd4GIVsUJX1RpcN82i6FUTzTDKi+p/WVlPFLNmxsed48mMF8GYViRONEnIc27b 4QYdqklcZZTX3gkra4UO =Tr03 -----END PGP SIGNATURE----- --Apple-Mail=_05EBCFDB-3B39-4783-B9A5-BCCA7940B477-- From nobody Mon Sep 25 17:18:53 2017 Return-Path: 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 B919C134617; Mon, 25 Sep 2017 17:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 esQsdM4qcigd; Mon, 25 Sep 2017 17:18:49 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6001342E4; Mon, 25 Sep 2017 17:18:49 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id s15so5446920uag.1; Mon, 25 Sep 2017 17:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0PvcOSnCzlCj8HEN+vLFX7/+nTTcvOJAmS+8C3nxoLY=; b=pdsiSTdwImnhKEDT3Fo2L14a5/SdRfyQZxi00z75jU+PIBVFZYHla4Zkpg0m+EYyX1 SdIUXhsOJ8OWG438VUAy1+F4fRLBY9u9Oi4FWEY7hyceeDd4uuRDQghWHVQZ9uJyg3bR sUTL2km1cLI5C/mIeeh/wT0OHsubl1bNGoqYzkHYIEViDJZxO8K8Y/fN+WY3ywqX+yfd sA052kjKdDRI0AsDa4e4BDi328NYyklRMKtnPqhneWNNgZz3mJgr3/fKY6YcQkjnTpnG x/GzQ+urfaCYrytKZC6jIIa/K8gw8Y67Z4ycr3M3SsBwUt/9L0/KMKmE0WFcJK8NetwJ CwmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0PvcOSnCzlCj8HEN+vLFX7/+nTTcvOJAmS+8C3nxoLY=; b=klmqFVXzsBXT267VOYYYQmVL/GwOlsj3r0G0C5nIUUjVNwbZ8QWpMqYSQHlfiV2feu tLDBCfbGi0NbFAdDVCTqNsZXmevTGL79H7amHGWTd2jE7WxiXMMF+533rvXKci56oG0C 0+GdtdKnXoPRN2fa8F3jYj1G4YJFeVzUiTpJpgRyYtC903ypkKqg3aePxqkuuMWcWzHn tuJYC71KTLu2KfT9pyixKF+Rg+0Kpkb3aS+UV3H+fOklvrblFrNj7CrKgiSIQE157hKA hDnSMwl+Gm5Bmmy2zcLd39rJQFXfjNxJ9GlIUr4RIuFf8+Ifbiq8thI6Vm4tB0gUufel 6uwg== X-Gm-Message-State: AHPjjUiyEVvljO+HJaQESRfMPDXL5nsUBPK6lfHqwTzrSXvCHHhN7q4k O2B7J/NjlWtjEt3TIiKR38TTToAYFJcbHh0A4vTnDnBY X-Google-Smtp-Source: AOwi7QBZy4lqxjPHUS5pIF4N/QCaGjq0yVIcTD6FM/5mcieT6cj8nrlPVhC5t4zb2H8GP5fYNwJtu5LkGBnOAFS/83g= X-Received: by 10.159.51.81 with SMTP id a17mr9242387uac.103.1506385128423; Mon, 25 Sep 2017 17:18:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.61.98 with HTTP; Mon, 25 Sep 2017 17:18:48 -0700 (PDT) From: Christopher Morrow Date: Mon, 25 Sep 2017 20:18:48 -0400 Message-ID: To: "sidr@ietf.org" , "sidr-chairs@ietf.org" , sidr-ads@ietf.org Content-Type: multipart/alternative; boundary="f403043ec39479871c055a0c9e1f" Archived-At: Subject: [sidr] WGLC: draft-ietf-sidr-rtr-keying - ends 10/09/2017 (Oct 9, 2017) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 00:18:52 -0000 --f403043ec39479871c055a0c9e1f Content-Type: text/plain; charset="UTF-8" howdy wg folk, please consider this the start of the WGLC for: https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-13 Abstract: BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. The authors believe this current version contains answers/compromises/fixes to all of the last set of comments/questions/concerns. Please make your thoughts known via both List Traffic and telekinesis, thanks! your faithful co-chair, Chris (co-chair for a little longer... move along little drafties, move along!) --f403043ec39479871c055a0c9e1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
howdy wg folk,
please consider this the start of the W= GLC for:
=C2=A0=C2=A0https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-1= 3

Abstract:

=C2=A0 =C2= =A0BGPsec-speaking routers are provisioned with private keys in order to
=C2=A0 =C2=A0sign BGPsec announcements.=C2=A0 The corresponding pub= lic keys are
=C2=A0 =C2=A0published in the global Resource Public= Key Infrastructure, enabling
=C2=A0 =C2=A0verification of BGPsec= messages.=C2=A0 This document describes two methods
=C2=A0 =C2= =A0of generating the public-private key-pairs: router-driven and
= =C2=A0 =C2=A0operator-driven.

The authors be= lieve this current version contains answers/compromises/fixes to all of the= last set of comments/questions/concerns.

Please make your th= oughts known via both List Traffic and telekinesis, thanks!

<= /div>
your faithful co-chair,
Chris
(co-chair for a= little longer... move along little drafties, move along!)
--f403043ec39479871c055a0c9e1f-- From nobody Wed Sep 27 02:19:03 2017 Return-Path: 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 BCF60134828 for ; Wed, 27 Sep 2017 02:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no 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 LlkhPeSBNMZe for ; Wed, 27 Sep 2017 02:18:59 -0700 (PDT) Received: from carcass.ledeuns.net (unknown [IPv6:2a00:6060:ffff::1005:ff02]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726B4134874 for ; Wed, 27 Sep 2017 02:18:08 -0700 (PDT) Received: from localhost (carcass.ledeuns.net [local]) by carcass.ledeuns.net (OpenSMTPD) with ESMTPA id a10bf6fd for ; Wed, 27 Sep 2017 11:18:05 +0200 (CEST) Date: Wed, 27 Sep 2017 11:18:05 +0200 From: Denis Fondras To: sidr@ietf.org Message-ID: <20170927091805.GH41648@carcass.ledeuns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.2 (2016-07-01) Archived-At: Subject: [sidr] RPKI-RTR implementation clues X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:19:02 -0000 Hi, I'm in the process of adding RPKI-RTR (RFC6810) support to OpenBGPd and I am wondering about how others have implemented it. - 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 another 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 ? - 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. Thank you in advance, Denis From nobody Wed Sep 27 02:24:00 2017 Return-Path: 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 8FB6E1348A8 for ; Wed, 27 Sep 2017 02:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no 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 yea6__zkmZeO for ; Wed, 27 Sep 2017 02:23:59 -0700 (PDT) Received: from carcass.ledeuns.net (unknown [IPv6:2a00:6060:ffff::1005:ff02]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79531348A7 for ; Wed, 27 Sep 2017 02:23:57 -0700 (PDT) Received: from localhost (carcass.ledeuns.net [local]) by carcass.ledeuns.net (OpenSMTPD) with ESMTPA id d30e8042 for ; Wed, 27 Sep 2017 11:23:55 +0200 (CEST) Date: Wed, 27 Sep 2017 11:23:55 +0200 From: Denis Fondras To: sidr@ietf.org Message-ID: <20170927092355.GJ41648@carcass.ledeuns.net> References: <20170927091805.GH41648@carcass.ledeuns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170927091805.GH41648@carcass.ledeuns.net> User-Agent: Mutt/1.6.2 (2016-07-01) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:24:00 -0000 > - 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 ^^^ latter From nobody Wed Sep 27 02:40:34 2017 Return-Path: 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 CD03A1348E4 for ; Wed, 27 Sep 2017 02:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 8-e07l00Pyje for ; Wed, 27 Sep 2017 02:40:31 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2211348E3 for ; Wed, 27 Sep 2017 02:40:31 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id BE92B282548; Wed, 27 Sep 2017 11:40:28 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id B7BCD282734; Wed, 27 Sep 2017 11:40:28 +0200 (CEST) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id B1419282548; Wed, 27 Sep 2017 11:40:28 +0200 (CEST) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id AE69F6649280; Wed, 27 Sep 2017 11:40:28 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id A995C3FFF5; Wed, 27 Sep 2017 11:40:28 +0200 (CEST) Date: Wed, 27 Sep 2017 11:40:28 +0200 From: Stephane Bortzmeyer To: Denis Fondras Cc: sidr@ietf.org Message-ID: <20170927094028.o4jfm2gvnaaahitj@nic.fr> References: <20170927091805.GH41648@carcass.ledeuns.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170927091805.GH41648@carcass.ledeuns.net> X-Operating-System: Debian GNU/Linux 9.1 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.9.27.93017 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:40:34 -0000 On Wed, Sep 27, 2017 at 11:18:05AM +0200, Denis Fondras wrote a message of 28 lines which said: > I'm in the process of adding RPKI-RTR (RFC6810) support to OpenBGPd This is not directly related to your question, but note that the new RFC, standardizing the new version of RTR (version 1, RFC 6810 was version 0) is in AUTH48-DONE and can be published any time now From nobody Wed Sep 27 02:54:34 2017 Return-Path: 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 03EDB134940 for ; Wed, 27 Sep 2017 02:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 5akOIPjdtBUT for ; Wed, 27 Sep 2017 02:54:30 -0700 (PDT) Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBAB13493E for ; Wed, 27 Sep 2017 02:54:30 -0700 (PDT) Received: from x59.NIC.DTAG.DE (x59.NIC.DTAG.DE [194.25.1.154]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id LAA20926; Wed, 27 Sep 2017 11:54:16 +0200 (MEST) To: Denis Fondras cc: sidr@ietf.org, rv@limes.NIC.DTAG.DE From: Ruediger Volk In-Reply-To: Your message of "Wed, 27 Sep 2017 11:18:05 +0200." <20170927091805.GH41648@carcass.ledeuns.net> Date: Wed, 27 Sep 2017 11:54:16 +0200 Message-ID: <2061.1506506056@x59.NIC.DTAG.DE> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 09:54:33 -0000 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 From nobody Wed Sep 27 09:09:17 2017 Return-Path: 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 ; 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 ; 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 ; 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)" To: Ruediger Volk , Denis Fondras CC: "rv@limes.NIC.DTAG.DE" , "sidr@ietf.org" Thread-Topic: [sidr] RPKI-RTR implementation clues Thread-Index: AQHTN3aUU5hTijjwikWXkBnNlrj6x6LI4QWw Date: Wed, 27 Sep 2017 16:09:12 +0000 Message-ID: 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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 upd= ate, 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 cac= he update. Once the cache is updated, re-evaluate all=20 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 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 implement= ation. > - How is the process started ? > Currently, when I start bgpd, it will fetch a list of VRP from the cach= e > 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 soon= er as > possible to apply filters if needed. > The problem is I can have an unknown state in the case a prefix tries t= o get > validated while the VRP list is not complete. The solution is to make a= noth er > round of validation when I get a complete VRP list. > Do you wait until you get a complete VRP list (ENDOFDATA message) befor= e > 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 cla= ssified INVALID if there is a matching ROA but only a covering but NOT matc= hing aggregate ROA (e.g. beef::/16-16) is available before the more specifi= c 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 s= tate for > some time. I am assuming that every new prefix is validated as it arriv= es. Lazy origin validation classification is allowed (but it implies that besid= es unknown/valid/invalid you should support a 4th class of "unclassified" is needed). It's great if recceived announcements are immediately classifie= d - 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 From nobody Wed Sep 27 14:11:43 2017 Return-Path: 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 39599134EF4 for ; Wed, 27 Sep 2017 14:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 fo06tSNLvCD9 for ; Wed, 27 Sep 2017 14:11:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18C5133071 for ; Wed, 27 Sep 2017 14:11:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dxJcG-000734-8G; Wed, 27 Sep 2017 21:11:36 +0000 Date: Wed, 27 Sep 2017 14:11:34 -0700 Message-ID: From: Randy Bush To: Stephane Bortzmeyer Cc: Denis Fondras , sidr@ietf.org In-Reply-To: <20170927094028.o4jfm2gvnaaahitj@nic.fr> References: <20170927091805.GH41648@carcass.ledeuns.net> <20170927094028.o4jfm2gvnaaahitj@nic.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 21:11:42 -0000 >> I'm in the process of adding RPKI-RTR (RFC6810) support to OpenBGPd > This is not directly related to your question, but note that the new > RFC, standardizing the new version of RTR (version 1, RFC 6810 was > version 0) is in AUTH48-DONE and can be published any time now > you may also find draft-ymbk-sidrops-ov-clarify-01.txt useful randy From nobody Wed Sep 27 21:13:06 2017 Return-Path: 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 CBF6F1352AC; Wed, 27 Sep 2017 21:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 F-VRF81diJfN; Wed, 27 Sep 2017 21:12:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEDE1352A9; Wed, 27 Sep 2017 21:12:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F3F88B81445; Wed, 27 Sep 2017 21:12:30 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sidr@ietf.org Message-Id: <20170928041230.F3F88B81445@rfc-editor.org> Date: Wed, 27 Sep 2017 21:12:30 -0700 (PDT) Archived-At: Subject: [sidr] RFC 8205 on BGPsec Protocol Specification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 04:13:00 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8205 Title: BGPsec Protocol Specification Author: M. Lepinski, Ed., K. Sriram, Ed. Status: Standards Track Stream: IETF Date: September 2017 Mailbox: mlepinski@ncf.edu, kotikalapudi.sriram@nist.gov Pages: 45 Characters: 115900 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sidr-bgpsec-protocol-23.txt URL: https://www.rfc-editor.org/info/rfc8205 DOI: 10.17487/RFC8205 This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route. This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Sep 27 21:13:34 2017 Return-Path: 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 75B631352C0; Wed, 27 Sep 2017 21:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 E9f-ysl2gxrm; Wed, 27 Sep 2017 21:13:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64ABE1352B4; Wed, 27 Sep 2017 21:13:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D292EB81466; Wed, 27 Sep 2017 21:12:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sidr@ietf.org Message-Id: <20170928041249.D292EB81466@rfc-editor.org> Date: Wed, 27 Sep 2017 21:12:49 -0700 (PDT) Archived-At: Subject: [sidr] RFC 8206 on BGPsec Considerations for Autonomous System (AS) Migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 04:13:32 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8206 Title: BGPsec Considerations for Autonomous System (AS) Migration Author: W. George, S. Murphy Status: Standards Track Stream: IETF Date: September 2017 Mailbox: wesgeorge@puck.nether.net, sandy@tislabs.com Pages: 16 Characters: 36491 Updates: RFC 8205 I-D Tag: draft-ietf-sidr-as-migration-06.txt URL: https://www.rfc-editor.org/info/rfc8206 DOI: 10.17487/RFC8206 This document discusses considerations and methods for supporting and securing a common method for Autonomous System (AS) migration within the BGPsec protocol. This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Sep 27 21:14:00 2017 Return-Path: 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 9A6871344E2; Wed, 27 Sep 2017 21:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5s0dKZZubB9F; Wed, 27 Sep 2017 21:13:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7511352C5; Wed, 27 Sep 2017 21:13:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4F1C1B814A3; Wed, 27 Sep 2017 21:13:09 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sidr@ietf.org Message-Id: <20170928041309.4F1C1B814A3@rfc-editor.org> Date: Wed, 27 Sep 2017 21:13:09 -0700 (PDT) Archived-At: Subject: [sidr] BCP 211, RFC 8207 on BGPsec Operational Considerations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 04:13:58 -0000 A new Request for Comments is now available in online RFC libraries. BCP 211 RFC 8207 Title: BGPsec Operational Considerations Author: R. Bush Status: Best Current Practice Stream: IETF Date: September 2017 Mailbox: randy@psg.com Pages: 10 Characters: 21086 See Also: BCP 211 I-D Tag: draft-ietf-sidr-bgpsec-ops-16.txt URL: https://www.rfc-editor.org/info/rfc8207 DOI: 10.17487/RFC8207 Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. Operational practices are expected to evolve as BGPsec is formalized and initially deployed. This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Sep 27 21:14:37 2017 Return-Path: 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 6752D1352B9; Wed, 27 Sep 2017 21:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 42PsgiNKpqAs; Wed, 27 Sep 2017 21:14:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2663C1352D2; Wed, 27 Sep 2017 21:13:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AB910B814B6; Wed, 27 Sep 2017 21:13:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sidr@ietf.org Message-Id: <20170928041324.AB910B814B6@rfc-editor.org> Date: Wed, 27 Sep 2017 21:13:24 -0700 (PDT) Archived-At: Subject: [sidr] RFC 8208 on BGPsec Algorithms, Key Formats, and Signature Formats X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 04:14:24 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8208 Title: BGPsec Algorithms, Key Formats, and Signature Formats Author: S. Turner, O. Borchert Status: Standards Track Stream: IETF Date: September 2017 Mailbox: sean@sn3rd.com, oliver.borchert@nist.gov Pages: 19 Characters: 35568 Updates: RFC 7935 I-D Tag: draft-ietf-sidr-bgpsec-algs-18.txt URL: https://www.rfc-editor.org/info/rfc8208 DOI: 10.17487/RFC8208 This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure"). This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Sep 27 21:14:45 2017 Return-Path: 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 3926D1352DB; Wed, 27 Sep 2017 21:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QAyXAmynfl9Z; Wed, 27 Sep 2017 21:14:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34501352CE; Wed, 27 Sep 2017 21:14:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2F7EAB814C3; Wed, 27 Sep 2017 21:13:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sidr@ietf.org Message-Id: <20170928041340.2F7EAB814C3@rfc-editor.org> Date: Wed, 27 Sep 2017 21:13:40 -0700 (PDT) Archived-At: Subject: [sidr] RFC 8209 on A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 04:14:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8209 Title: A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests Author: M. Reynolds, S. Turner, S. Kent Status: Standards Track Stream: IETF Date: September 2017 Mailbox: mcr@islandpeaksoftware.com, sean@sn3rd.com, kent@alum.mit.edu Pages: 15 Characters: 29355 Updates: RFC 6487 I-D Tag: draft-ietf-sidr-bgpsec-pki-profiles-21.txt URL: https://www.rfc-editor.org/info/rfc8209 DOI: 10.17487/RFC8209 This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this document updates the RPKI Resource Certificates Profile (RFC 6487). This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Sep 27 21:15:09 2017 Return-Path: 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 3C3221352D0; Wed, 27 Sep 2017 21:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 L0IilRdgzlsX; Wed, 27 Sep 2017 21:14:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878C81352AC; Wed, 27 Sep 2017 21:14:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0F13BB814D0; Wed, 27 Sep 2017 21:13:53 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sidr@ietf.org Message-Id: <20170928041353.0F13BB814D0@rfc-editor.org> Date: Wed, 27 Sep 2017 21:13:53 -0700 (PDT) Archived-At: Subject: [sidr] RFC 8210 on The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 04:14:53 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8210 Title: The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 Author: R. Bush, R. Austein Status: Standards Track Stream: IETF Date: September 2017 Mailbox: randy@psg.com, sra@hactrn.net Pages: 35 Characters: 78467 Updates: RFC 6810 I-D Tag: draft-ietf-sidr-rpki-rtr-rfc6810-bis-09.txt URL: https://www.rfc-editor.org/info/rfc8210 DOI: 10.17487/RFC8210 In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810. This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Sep 27 21:15:48 2017 Return-Path: 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 AE6B61352BD; Wed, 27 Sep 2017 21:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XoyL_ERHQqoa; Wed, 27 Sep 2017 21:15:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB2A1352B4; Wed, 27 Sep 2017 21:14:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 58F26B814DD; Wed, 27 Sep 2017 21:14:06 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sidr@ietf.org Message-Id: <20170928041406.58F26B814DD@rfc-editor.org> Date: Wed, 27 Sep 2017 21:14:06 -0700 (PDT) Archived-At: Subject: [sidr] RFC 8211 on Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 04:15:28 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8211 Title: Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) Author: S. Kent, D. Ma Status: Informational Stream: IETF Date: September 2017 Mailbox: kent@alum.mit.edu, madi@zdns.cn Pages: 26 Characters: 64041 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sidr-adverse-actions-04.txt URL: https://www.rfc-editor.org/info/rfc8211 DOI: 10.17487/RFC8211 This document analyzes actions by or against a Certification Authority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by Relying Parties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data. This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Sep 28 01:51:05 2017 Return-Path: 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 03BFA1345C9 for ; Thu, 28 Sep 2017 01:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.293 X-Spam-Level: X-Spam-Status: No, score=0.293 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RDNS_NONE=0.793, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no 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 VjdGS2oP6ksK for ; Thu, 28 Sep 2017 01:51:02 -0700 (PDT) Received: from carcass.ledeuns.net (unknown [IPv6:2a00:6060:ffff::1005:ff02]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6155E13458F for ; Thu, 28 Sep 2017 01:51:01 -0700 (PDT) Received: from localhost (carcass.ledeuns.net [local]) by carcass.ledeuns.net (OpenSMTPD) with ESMTPA id 7ae22a1d for ; Thu, 28 Sep 2017 10:50:59 +0200 (CEST) Date: Thu, 28 Sep 2017 10:50:59 +0200 From: Denis Fondras To: sidr@ietf.org Message-ID: <20170928085059.GM41648@carcass.ledeuns.net> References: <20170927091805.GH41648@carcass.ledeuns.net> <2061.1506506056@x59.NIC.DTAG.DE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2061.1506506056@x59.NIC.DTAG.DE> User-Agent: Mutt/1.6.2 (2016-07-01) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 08:51:05 -0000 Thank you very much for the insight ! Denis